Hallo @pierre-gilles
Ich habe gerade auf v4.17.0 aktualisiert und stelle Fehler in Zigbee2MQTT fest.
Das ist wahrscheinlich damit verbunden, ich kann meine Zigbee-Geräte seit dem Update nicht mehr steuern, aber die Gladys-Oberfläche funktioniert.
Ich bestätige:
- Zigbee2MQTT funktioniert über die dedizierte Weboberfläche (Port 8080)
- Steuerung über Gladys nicht möglich
Hallo, ich habe den Eindruck, dass der Fehler einfach besagt, dass Gladys einen Wert von zigbee2mqtt erhält, dieser aber von Gladys nicht verarbeitet wird.
Kannst du versuchen, dein Gerät von der Seite „Zigbee Discovery“ des Dienstes Zigbee2Mqtt aus zu aktualisieren?
Ich habe nachgeschaut, es gab kein Update für das Zigbee-Gerät in den Service-Einstellungen.
Ich habe gerade deine Lösung gesehen… es ist trotzdem ärgerlich, dass es so instabil ist…
Zögere nicht, weitere Logs / Infos zu geben, falls Instabilitätsprobleme wieder auftreten.
Je mehr Infos wir haben, desto eher können wir einen Fix versuchen.
Zur Info, die v4.17.0 betrifft nicht Zigbee2mqtt, also musst du auf einen Fehler beim Neustart von Gladys oder beim Neustart eines der beiden für diese Integration notwendigen Container gestoßen sein.
Es hätten die vollständigen Logs gebraucht, um zu sehen, was passiert ist. Denk beim nächsten Mal daran, sie zu behalten 
Was ist der beste Weg, um das zurückzubekommen?
Damit ich es das nächste Mal weiß…
Ich würde machen:
docker logs gladys &> gladys_logs.txt
Das sind ganz schön viele Logs, aber es funktioniert tatsächlich.
Aber MQTT wurde gestern bei mir aktualisiert… Vielleicht ein Zusammenhang?
Reagiert Zigbee2mqtt gut auf den Neustart des MQTT-Containers? Und Gladys?
Falls jemand ein reproduzierbares Beispiel hat
Ich habe heute Morgen gesehen, dass ich auf 4.17.0 bin… das Erste, was ich mache: Ich öffne meine Rollläden (z2m) und bei mir gibt es keine Probleme.
Hallo,
Bei mir scheint der Service korrekt neu gestartet zu sein (laut Konfigurationsmenü der Integration ist alles gestartet).
Allerdings werden meine Geräte der Integration seit dem Neustart nach dem Gladys-Update nicht mehr aktualisiert. Ich schaue mir heute Abend die Logs an, um die Diskussion zu bereichern.
@AlexTrovato Falls Gladys jemals neu startet und der MQTT-Container nicht verfügbar ist, kann sich Gladys dann später wieder verbinden, wenn der MQTT-Container verfügbar ist?
Ich antworte mir selbst, aber beim Lesen des Codes und der Dokumentation von MQTT.js habe ich den Eindruck, dass, wenn die Verbindung nicht innerhalb der ersten 30 Sekunden hergestellt wird, es vorbei ist
Zigbee2mqtt-Integration in Gladys:
(Quelle: Gladys/server/services/zigbee2mqtt/lib/connect.js at master · GladysAssistant/Gladys · GitHub )
MQTT.js-Dokumentation:
Dokumentation: https://www.npmjs.com/package/mqtt#connect
In manchen Fällen, wenn MQTT direkt nach der Gladys-Aktualisierung aktualisiert wird (was logisch ist, Watchtower macht alles nacheinander zur gleichen Zeit), und wenn die Aktualisierung länger als 30 Sekunden dauert (was durchaus möglich ist, wenn die Internetverbindung des Nutzers nicht optimal ist), dann wird der Nutzer kein Zigbee2mqtt mehr haben
Das sollte in der Praxis getestet werden, aber ich denke, dass das das Problem ist.
@AlexTrovato was denkst du?
Meiner Meinung nach brauchen wir eine echte Reconnect-Strategie, auch vor der ersten Verbindung, falls etwas schiefgeht. Wir sollten prüfen, ob es eine empfohlene Methode mit dieser Bibliothek gibt, um alle 15 Sekunden „ad vitaam“ erneut zu versuchen?
Das kommt mir trotzdem komisch vor, wenn man sich den WatchTower-Befehl ansieht. Der Neustart dieser Container (mosquito und zigbee2mqtt) ist quasi sofort, der Download sollte doch vorher erfolgen.
Watchtower lädt Ihr neues Image herunter, beendet Ihren bestehenden Container und startet ihn mit denselben Optionen neu, die bei der anfänglichen Bereitstellung verwendet wurden.
Gibt es vielleicht einen Parameter wie eine Verzögerung für das Aktualisieren der Container durch Watchtower?
@cicoub13 Stimmt! Aber ich denke trotzdem, dass wir ein Loch im Paddel in diesem Ausmaß haben, es ist heikel, wenn die Integration nicht auf ihren eigenen Beinen landen kann, wenn ein Container für 30 Sekunden nicht verfügbar ist (für die erste Verbindung).
Da ich zigbee-Geräte mit hoher Datenmenge habe, könnte das manchmal zu einem langsameren Neustart bei einem Z2M-Update führen?
Jedenfalls sollte die Integration regelmäßig einen erneuten Verbindungsversuch unternehmen. Man ist nicht vor Verzögerungen gefeit, einem Benutzer, der zur falschen Zeit eine Manipulation durchführt, usw.