EDIT: Zigbee2mqtt ist jetzt nativ in Gladys integriert!
Hallo zusammen,
Nach Monaten des Wartens gibt es jetzt ein neues Testbild von Gladys mit dem integrierten Zigbee2mqtt-Dienst.
In dieser Version ist alles automatisch: Es ist nicht mehr nötig, Docker-Container manuell zu starten.
Daher habe ich eine Ansicht hinzugefügt, um den Status des Dienstes bei der Aktivierung zu verfolgen:
Ich habe auch die Tabelle mit dem Container-Status beibehalten, falls jemand Hilfe benötigt, aber ich denke, ich werde sie in der Version entfernen, die in Gladys integriert wird.
Ihr könnt das Bild auf Dockerhub herunterladen:
Zur Info, ich habe es mit der Gladys-Version getaggt, auf der es basiert, und füge ein -n hinzu, wobei n die Entwicklungen des Zigbee2mqtt-Dienstes darstellt.
Daher heißt diese Version v4.0.0-1.
Wenn ihr es mit dem Tag latest installiert und Watchtower auf eurem Rechner läuft, wird es automatisch bei jeder Entwicklung aktualisiert.
Oder ihr installiert und startet es direkt mit dem in der Gladys-Dokumentation angegebenen Befehl:
Im Vergleich zur Gladys-Dokumentation habe ich die Option -v /run/udev:/run/udev:ro hinzugefügt, die mehr Informationen über USB-Geräte (insbesondere den Hersteller) liefert. Dadurch können Sie z. B. die Dongles unterscheiden, wenn Sie einen Zigbee2mqtt-Dongle und einen Z-Wave-Dongle einstecken.
Zögert nicht, eure Erfahrungen in diesem Thema zu kommentieren und auch Issues auf meinem GitHub zu hinterlassen, um Fehler und nicht unterstützte Geräte zu identifizieren. Bitte beschreibt eure Installation und wie ihr den Fehler verursacht habt, so detailliert wie möglich.
Vielen Dank an alle für eure Geduld, in der Hoffnung, dass es bestmöglich funktioniert.
Zur Info, ich habe bereits einen MQTT-Container auf dem Host und einen zigbee2mqtt-Container. Können wir in diesem Fall die Möglichkeit haben, einfach eine MQTT-Adresse anzugeben?
Edit: Mein Zigbee2mqtt-Container existierte bereits unter diesem Namen, daher funktioniert es nicht. Ich denke, es sollte ein Präfix hinzugefügt werden.
Laut deinen Logs gibt es keine Fehler bei der Installation und dem Start der Container.
Das ist erstaunlich, da du sagst, du hättest bereits einen Container mit diesem Namen.
Der MQTT-Broker wird auf Port 1884 gestartet, um Konflikte mit dem MQTT-Dienst zu vermeiden.
Soweit ich verstanden habe, bevorzugte @pierre-gilles einen separaten Broker.
Kannst du daher die Logs der beiden Container des Dienstes überprüfen, um dein Verbindungsproblem zu lösen?
Ich habe vergessen, Ihnen zu sagen, dass man physisch sehen kann, ob die Service-Konfiguration erfolgreich war: Beim Start sollte die LED des Dongles ausgehen.
Ach ja, es gibt ein verstecktes Bonus-Feature in einem der Reiter. Ein Pluspunkt für den, der es findet…
Hallo, zuerst möchte ich dir für deine Arbeit danken, es wird cool sein, sich eine Xiaomi-Gateway sparen zu können
Ich habe jedoch ein Berechtigungsproblem bei meiner Installation, der MQTT-Container startet zwar, startet aber in einer Endlosschleife neu, weil er seine Konfigurationsdatei nicht öffnen kann (Log des MQTT-Containers: 1605448659: Error: Unable to open config file /mosquitto/config/mosquitto.conf.).
Ich habe zwar die Zuordnung $DATA_PATH/gladys_zigbee:/var/lib/gladysassistant in meinen Volumes und habe auch erzwungen, dass Gladys den Benutzer root verwendet (user: « 0:0 ») in meiner docker-compose-Datei, aber es ändert sich nichts…
OK, ich schau mir das heute Abend an, aber das Problem ist, dass der Container bereits existiert und nicht für den vom Service erstellten MQTT-Container konfiguriert ist.
Das muss eine Frage der Berechtigungen sein.
Überprüfe die Berechtigungen der Datei /var/lib/gladysassistant/zigbee2mqtt/mqtt/mosquitto.conf.
Im mqtt-Container ist der Benutzer nicht root, sondern mosquitto. Das könnte das Problem sein.
Die Berechtigungen der Datei sind korrekt auf root/root mit dem Wert 644 gesetzt, egal ob ich in meiner docker-compose-Datei den Wert user: "0:0" hinzufüge oder nicht.
Gibt es eine Möglichkeit, dem MQTT-Container den zu verwendenden Benutzer zuzuweisen? (Wenn es derselbe wie der von Gladys ist, würde das die Sache erleichtern und solche Probleme in Zukunft vermeiden.)
EDIT: Oder eine alternative Image zu verwenden?
In meinem Fall habe ich bei vorherigen Tests die Image eclipse-mosquitto verwendet, die, soweit ich mich erinnere, standardmäßig als root läuft (auch wenn das nicht unbedingt sicher ist…).
Aus Sicherheitsgründen ist es absolut nicht ratsam, die Container als Root zu starten!
Warum startest du Gladys auf diese Weise?
Das Beispiel in der Dokumentation tut das nicht. Allerdings wird die Option privileged verwendet.
Es ist tatsächlich das eclipse-mosquitto-Image, das gestartet wird, und es verwendet nicht den Root-Benutzer. Kein gut gemachtes Image, übrigens…
Für die Nutzung von root war das nur ein Test (so starte ich es normalerweise nicht), um zu sehen, ob die Hinzufügung eines Benutzers die Berechtigungen für die Konfigurationsdatei von Mosquitto ändert, aber das ändert nichts.
Es muss also an HypriotOS liegen, da alle Dateien von Gladys von root erstellt werden…
Normalerweise sollte der Besitzer des mqtt-Verzeichnisses 1883:1883 auf dem Host und mosquitto:mosquitto im Container sein.
Du musst den Container ohne den Benutzer root neu starten, aber vorher musst du das bereinigen, was von der vorherigen Installation generiert wurde:
Es handelt sich tatsächlich um den Container ohne den Benutzer root und mit vorheriger Bereinigung, ich glaube, dass standardmäßig bei HypriotOS der Benutzer, der die Rechte an Docker hat, root ist, egal welchen Container ich starte, die persistenten Daten gehören immer root…
Ich konnte nicht mehr testen, weil man diesen Fehler beheben muss (die Info in der UI zurückgeben)
2020-11-15T18:05:02+0100 <error> installMqttContainer.js:43 (Zigbee2mqttManager.installMqttContainer) MQTT-Broker konnte nicht als Docker-Container installiert werden: Error: (HTTP-Code 500) Serverfehler - toomanyrequests: Sie haben Ihr Pull-Rate-Limit erreicht. Sie können das Limit erhöhen, indem Sie sich authentifizieren und aufrüsten: https://www.docker.com/increase-rate-limit
at /src/server/node_modules/docker-modem/lib/modem.js:257:17
at IncomingMessage.<anonymous> (/src/server/node_modules/docker-modem/lib/modem.js:284:9)
at IncomingMessage.emit (events.js:326:22)
at endReadableNT (_stream_readable.js:1223:12)
at processTicksAndRejections (internal/process/task_queues.js:84:21) {
reason: 'server error',
statusCode: 500,
json: null
}
Das ist mir noch nie passiert, aber egal, ich hatte nicht die Info, dass etwas schiefgehen könnte
Du kannst ein „docker login“ auf deinem Docker-Host ausführen, damit kannst du dich beim Docker Hub anmelden, der jetzt eine Authentifizierung erfordert, da es eine Begrenzung für die Anzahl der Pulls vom Docker Hub gibt…
