Zigbee2MQTT Container stürzt ab

[guybrush2012]

Hi, betreibe seit ca. einer Woche anstatt HomeAssistant mit ZHA mit dem Zigbee2MQTT 2.X Container in Unraid mit einem SMLIGHT SLZB-06M im Netzwerk.

Problem, ist der SLZB-06M nicht mehr erreichbar z.B. durch kurzem Neustart der FritzBox, stoppt der ZigBee2MQTT Container mit einem Fehler. Der Fehler läßt sich reproduzieren, einfach Adapter abstecken, so dass er nciht mehr erreichbar ist, und dann stürzt der Container ab.

[2025-02-13 13:28:07] error:    zh:ember:uart:ash: Port Error: read ETIMEDOUT
[2025-02-13 13:28:07] error:    zh:ember: Adapter fatal error: ERROR_SERIAL_INIT
[2025-02-13 13:28:07] error:    z2m: Adapter disconnected, stopping

Das ist meine Config:

version: 4
homeassistant:
  enabled: true
frontend:
  enabled: true
mqtt:
  base_topic: zigbee2mqtt
  server: mqtt://192.168.178.5:1883
  user: hierstehtderuser
  password: hierstehtmeinpasswort
serial:
  port: tcp://192.168.178.109:6638
  baudrate: 115200
  adapter: ember
  disable_led: false
advanced:
  transmit_power: 20
  last_seen: ISO_8601_local
  log_level: error
availability:
  enabled: true

Hat jemand eine Idee wie ich das beheben kann?
Alternativ wäre die Umstellung auf einem HomeAssisstant VM oder wieder zurück zu ZHA denkbar.

[totow]

@guybrush2012

mit dem Zigbee2MQTT 2.X Container in Unraid

Ich kenne mich mit Unraid nicht aus aber kann man da keine restart police auswählen, ist doch Docker oder?

Bei Portainer kann man das ohne Probleme einstellen:

LG

[guybrush2012]

Du kannst den Watchdog aktivieren um den Container automatisiert bei einem Absturz neu starten. Besser wäre jedoch, was das nicht der Fall wäre.

Warum macht das Zigbee2MQTT???

[totow]

@guybrush2012

Warum macht das Zigbee2MQTT???

Weil Zigbee(2MQTT) nicht ohne Coordinator funktioniert, und eine Netzwerkverbindung wird nie so Stabil sein wie eine direkte Verbindung.
Im schlimmsten fall lässt du den Coordinator noch über WLAN laufen.

[LvS21]

Ich habe mein z2m auch unter unraid laufen und per unraid Plugin “User Script” folgendes Script im Minutentakt laufen.

#!/bin/bash

# Name des Docker Containers
CONTAINER_NAME="zigbee2mqtt"

# Überprüfen, ob der Container läuft
if [ $(docker inspect -f '{{.State.Running}}' $CONTAINER_NAME) = "false" ]
then
    echo "Der Docker-Container $CONTAINER_NAME läuft nicht. Starte neu..."
    #logger "Der Docker-Container $CONTAINER_NAME wurde neu gestartet."

    docker start $CONTAINER_NAME
#else
    #echo "Der Docker-Container $CONTAINER_NAME läuft."
fi

EDIT: Habe gerade noch diesen reddit gefunden

https://www.reddit.com/r/unRAID/comments/10wvn9b/way_to_automatically_restart_a_stopped_container/?rdt=53286

Gruß, Lars

[guybrush2012]

@totow

Weil Zigbee(2MQTT) nicht ohne Coordinator funktioniert, und eine Netzwerkverbindung wird nie so Stabil sein wie eine direkte Verbindung.
Im schlimmsten fall lässt du den Coordinator noch über WLAN laufen.

Die eine Sache ist die Überprüfung beim start, die andere wenn es kurz für ein paar sekunden nicht erreichbar ist.

Das ist eine Schwachstelle von Zigbee2MQTT. Da ist ZHA eindeutig besser.

@LvS21

Ich habe mein z2m auch unter unraid laufen und per unraid Plugin “User Script” folgendes Script im Minutentakt laufen.

Du kannst auch den Watchdog aktivieren.

https://www.zigbee2mqtt.io/guide/installation/15_watchdog.html

[totow]

@guybrush2012

die andere wenn es kurz für ein paar sekunden nicht erreichbar ist.

Dafür ist Zigbee nicht gemacht, Coordinator weg → Funktioniert nicht.

ZHA spuckt doch bestimmt dabei auch Fehler aus.

@guybrush2012

Das ist eine Schwachstelle von Zigbee2MQTT. Da ist ZHA eindeutig besser.

Bei Z2M ist der watchdog eine Schwachstelle und HA was bei Fehlern von Integration immer mal wieder versucht Integration (ZHA) neu zu laden ist besser?
Ist effektiv auch nur ein watchdog oder was übersehe ich hier?

[LvS21]

@guybrush2012

Du kannst auch den Watchdog aktivieren.

Watchdog | Zigbee2MQTT

Das kannte ich noch nicht - ich habe den Parameter nun im unraid konfiguriert und meinen eigenen Job deaktiviert - mal sehen…

Gruß, Lars

[LvS21]

@LvS21

Das kannte ich noch nicht - ich habe den Parameter nun im unraid konfiguriert und meinen eigenen Job deaktiviert - mal sehen…

Ergänzung nach 4 Tage:

Gestern war mein zigbee-Netz dann von HA aus auf einmal nicht mehr zu erreichen. Kurze Recherche ergab, dass der z2m Docker Container unter unraid nicht mehr lief. Da hat dann der eingebaute Watchdog von z2m doch nichts mehr retten können.

Habe nun meinen oben erwähnten unraid-watchdog-Job wieder aktiviert.

Gruß, Lars

[Philos]

Bei mir sind die Verbindungsabbrüche wie folgt verteilt:

Mal läuft’s ein paar Stunden, dann nur ein paar Minuten. Warum? Warum gibt’s das nicht in stabil?

War übrigens mal so, ist vor ein paar Wochen dann verkackt. Container auf Synology.

Wie kann ich sehen, warum das so ist?

Warum ist das so?

Wo kann man nachgucken, warum das so häufig abstürzt?

Wo kann ich den Watchdog einschalten? Also dieses

“Z2M_WATCHDOG=default”

Wo schreibe ich das hin?

Haha, gerade wollte ich schreiben, dass die anderen Container stabil laufen, aber jetzt kacken die auch rum:

[LvS21]

@Philos

Container auf Synology.

Wenn jetzt auch noch andere Container betroffen sind, deutet das doch eh auf ein Problem mit deinem Container-Management auf Synology hin.

Wenn der z2m Container beendet ist/wird nutzt dir auch der Parameter Z2M_WATCHDOG nichts, da ja z2m in diesem Moment komplett steht. Der Parameter gehört ansonsten in die configuration.yaml von zigbee2mqtt.

Hier die Beschreibung des Parameters aus der Doku.

“Zigbee2MQTT supports a simple watchdog for “soft failures” (failures that Zigbee2MQTT can handle properly without crashing, like “adapter disconnected”).”

Es geht also nur um “weiche Fehler”.

Wenn du den eigentlichen Container-Status überwachen möchtest, brauchst du andere Wege. Zur reinen Überwachung nutze ich selber Uptime Kuma.

Gruß, Lars

[Philos]

Danke für die Rückmeldung. Tatsächlich ist das größte Hemmnis, dass ich nicht weiß, warum der Z2M-Container abstürzt, weil das Log nach jedem Reboot wieder weg ist (*). Das heißt, das könnte ich mit Uptima Kuma besser managen?

(*) Notiz an mich: Auto-Restart vom Container ausschalten würde Log erhalten?

Zwischenzeitlich teste ich meine Config an einer Virtuellen Maschine auf derselben Synology. Würde das aber nicht als Dauerlösung lassen wollen, da im Vergleich zur Container-Lösung ca. doppelt soviel CPU-Load (ca. 7 % vs. ca. 15 % Gesamt-System-Last) und unschön viel RAM (+3GB) gebraucht werden. Da ist Docker deutlich sparsamer bzw. geht mit dem RAM dynamisch um.

[dp20eic]

Moin,

@Philos

weil das Log nach jedem Reboot wieder weg ist (*)

wieso?
Wie hast Du denn den Z2M Container gebaut, werden da die Logs nicht auf der Synology persistiert?
Steht nichts in den Synology Logs, dass es einen Fehler mit dem Container gegeben hat?

@Philos

Das heißt, das könnte ich mit Uptima Kuma besser managen?

Uptime-Kuma ist ein reines Überwachungstool, da kann man schauen, ob das überwachte System noch antwortet, und sich eine Meldung schicken lassen, wenn dem nicht so ist.
Kann dann so aussehen,

Übersicht

Detailansicht

VG
Bernd

P.S.: man könnte den Gesundheitszustand von Zigbee2MQTT über MQTT abfragen, werde ich mir heute mal anschauen und in Uptime Kuma versuchen umzusetzen, obwohl ich bei mir unter Proxmox keine Probleme habe, ich bin ein Monitoring-Fetischist

[Philos]

“Dummerweise” schickt sich die VM-Lösung gerade an, stabil und nicht weniger flink als die Container-Variante zu laufen. Die Gesamt-CPU-Last der Synology hat sich nun auf knapp unter 10 Prozent eingependelt - das ist nicht zu beklagen.

Außerdem muss ich bei einem Supervisor-Update nicht mehr manuell eingreifen (Container-Neustart) und ich bin die Veraltete-Installationsmethode-Meldung los.

Zum Preis von 3GB blockiertem RAM…

@dp20eic

wieso?
Wie hast Du denn den Z2M Container gebaut, werden da die Logs nicht auf der Synology persistiert?
Steht nichts in den Synology Logs, dass es einen Fehler mit dem Container gegeben hat?

Der Container wurde von Homeassistant gebaut, glaube ich, als ich das entsprechende Addon installiert habe. Die Logs kann ich immer nur für die aktuelle Containerlaufzeit bzw. für die letzte Laufzeit sehen, zumindest im Container-Manager. Starte ich den Container neu, fängt ein neues Log an. Und ja, Synology meldet dass der Container “unerwartet beendet wurde”. Mehr aber nicht.

by HarryP: Zusammenführung Doppelpost (bei Änderungen oder hinzufügen von Inhalten bitte die „Bearbeitungsfunktion“ anstatt „Antworten“ zu nutzen)

[dp20eic]

Moin,

@Philos

Der Container wurde von Homeassistant gebaut, glaube ich, als ich das entsprechende Addon installiert habe

also Du hast HA als VM auf der Synology, dann darin das Z2M Add-on installiert, ah jetzt ist es klar, aber auch da stimmt das nicht, dass die Logs weg sind, denn die liegen in HA, genau auf der gleichen Ebene, wie die configuration.yaml von HA

Wobei das Logfile mit dem Präfix 1 am Ende, das Logfile von vor dem reboot ist.

@Philos

Und ja, Synology meldet dass der Container “unerwartet beendet wurde”. Mehr aber nicht.

Dann verstehe ich es doch nicht, Stürtzt Deine ganze VM ab, oder hast Du einen Docker Container im Containermanager erstellt, oder betreibst Du HA im Docker.

Also irgendwie stehe ich bei Deinen Aussagen echt auf dem Schlauch wie jetzt was läuft

Und was hast Du jetzt als VM installiert, nur Z2M oder was?

VG
Bernd

[Philos]

Okay, das war verwirrend: Das Problem, das ich beschrieben habe, bezog sich auf ein HA-System als Container im Container Manager der Synology. Kein VM.

Von VM hatte ich gesprochen, weil ich es gerade als Backupsystem betreibe.

Zu den Logs: Tatsächlich hatte ich bislang nur das Log von Z2M-Addon bzw. Container im Sinn. Das Log von HA habe ich mir gerade mal angesehen - ist unglaublich lang (80.000 Zeilen an einem Vormittag). Aber leider ohne nennenswertes zu prägnanten Sichtwörtern (mqqt, z2m, zigbee, …)

[dp20eic]

Moin,

@Philos

Von VM hatte ich gesprochen, weil ich es gerade als Backupsystem betreibe.

ich kapiere zwar immer noch nicht wie das aktuelle System aussieht, und wie das Problem damit aussieht, aber egal.

Wenn man eine HAOS VM betreibt und darin auch die Add-ons, z. B. Zigbee2MQTT, MQTT Broker Mosquitto, usw., dann schreiben die auch ihre Logs so, dass sie über die HA Web-UI erreichbar sind,

Aber wie gesagt, ich habe das Problem nicht verstanden, sorry.

VG
Bernd

[Philos]

Mal zusammengefasst:

Aus noch unbekanntem Grund bricht die Verbindung vom Z2M-Addon zum Adapter/Koordinator in unregelmäßigen Abständen ab. Kann von “mehrmals pro Stunde” bis “tagelang stabil” reichen.

Wenn HA und seine Addons als Container im Container-Manager der Synology laufen, führt der Verbindungsverlust zu einem Absturz des Containers. Neustart erfolgt automatisch, das führt gelegentlich zu Zickereien.

Wenn HA als virtuelle Maschine läuft, kommen Verbindungsprobleme scheinbar auch vor. In den paar Tagen, in denen ich das beobachte, war es nur heute, dreimal. Log:

[2025-07-17 09:42:52] error: 	zh:ember:uart:ash: Received ERROR from adapter, with code=ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT.
[2025-07-17 09:42:52] error: 	zh:ember:uart:ash: ASH disconnected | Adapter status: ASH_NCP_FATAL_ERROR
[2025-07-17 09:42:52] error: 	zh:ember:uart:ash: Error while parsing received frame, status=ASH_NCP_FATAL_ERROR.
[2025-07-17 09:42:52] error: 	zh:ember: Adapter fatal error: HOST_FATAL_ERROR
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash: ASH COUNTERS since last clear:
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   Total frames: RX=2502, TX=2882
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   Cancelled   : RX=0, TX=0
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   DATA frames : RX=2485, TX=381
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   DATA bytes  : RX=83353, TX=10288
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   Retry frames: RX=16, TX=0
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   ACK frames  : RX=0, TX=2501
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   NAK frames  : RX=0, TX=0
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   nRdy frames : RX=0, TX=0
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   CRC errors      : RX=0
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   Comm errors     : RX=0
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   Length < minimum: RX=0
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   Length > maximum: RX=0
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   Bad controls    : RX=0
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   Bad lengths     : RX=0
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   Bad ACK numbers : RX=0
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   Out of buffers  : RX=0
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   Retry dupes     : RX=16
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   Out of sequence : RX=0
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash:   ACK timeouts    : RX=0
[2025-07-17 09:42:52] info: 	zh:ember:uart:ash: ======== ASH stopped ========
[2025-07-17 09:42:52] info: 	zh:ember:ezsp: ======== EZSP stopped ========
[2025-07-17 09:42:52] info: 	zh:ember: ======== Ember Adapter Stopped ========
[2025-07-17 09:42:52] error: 	z2m: Adapter disconnected, stopping
[2025-07-17 09:42:52] info: 	z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/state', payload '{"state":"offline"}'
[2025-07-17 09:42:52] info: 	z2m: Disconnecting from MQTT server
[2025-07-17 09:42:52] info: 	z2m: Stopping zigbee-herdsman...
[2025-07-17 09:42:52] info: 	z2m: Stopped zigbee-herdsman
[2025-07-17 09:42:52] info: 	z2m: Stopped Zigbee2MQTT
[09:43:10] INFO: Preparing to start...
[09:43:11] INFO: Socat not enabled
[09:43:11] INFO: Starting Zigbee2MQTT...
Starting Zigbee2MQTT without watchdog.

Der Adapter, ein SLZB-06M via LAN an einer Fritz, meldet folgendes:

Betriebszeit Gerät 1t 01h 40m
Betriebszeit Z2M/ZHA 0t 07h 45m

[09:42:53] taskZB | Client disconnected, id: 0
[09:43:14] taskZB | New client: 192.168.178.27 id: 0
[11:38:54] taskZB | Client disconnected, id: 0
[11:39:19] taskZB | New client: 192.168.178.27 id: 0
[13:24:54] taskZB | Client disconnected, id: 0
[13:25:31] taskZB | New client: 192.168.178.27 id: 0
[13:53:22] taskZB | Client disconnected, id: 0
[13:53:46] taskZB | New client: 192.168.178.27 id: 0

Nun ja, das ist bisken trocken.

Wer verrät uns denn nun, WARUM gedisconnected wird?

[dp20eic]

Moin,

@Philos

Wer verrät uns denn nun, WARUM gedisconnected wird?

eigentlich gibt es ja die Meldungen mit dem Error wenn man damit mal bei Github im Projekt sucht, dann findet man das

zh:ember:uart:ash: Received ERROR from adapter, with code=ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT

Da hat ein User, verdächtige Geräte in seinem Zigbee Mesh, nachdem das Polling abgeschaltet wurde war Ruhe.

VG
Bernd