Heute Vormittag habe ich festgestellt, dass ich keine zigbee Geräte mehr schalten kann.
Nach einiger Suche habe ich festgestellt, dass mein zigbee2mqtt nicht mehr erreichbar ist.
Beim Versuch, z2m manuell zu starten, passiert folgendes:
udo@z2m:/opt/zigbee2mqtt$ node index.js
Starting Zigbee2MQTT without watchdog.
{"level":"error","message":"z2m: MQTT error: write EPIPE","timestamp":"2026-10-15 12:29:38"}
{"level":"error","message":"z2m: MQTT error: write EPIPE","timestamp":"2026-10-15 12:29:40"}
Kann jemand etwas mit der Meldung anfangen?
- Die Suche nach der Fehlermeldung im Internet hat mich nicht wirklich weitergebracht.
- Der mqtt Server läuft, ich kann den übrigen ein- und ausgehenden Traffic beobachten.
- Der mqtt Server läuft in einer Proxmox VM.
- z2m läuft in einem Proxmox Container auf der gleichen Instanz.
Die einzige Änderung, die ich heute gemacht hatte, war das Update der Proxmox Instanz heute Morgen gegen die neuen Pakete von Proxmox.
Folgendes bekomme ich vorgeschlagen zu prüfen:
EPIPE heißt: die TCP-Verbindung zum Broker steht, aber der Broker legt sofort wieder auf. Netz/Proxmox-Firewall würde ich damit eher ausschließen, das sähe nach ECONNREFUSED oder Timeout aus.
Mein erster Verdacht ist eine doppelte Client-ID. Die muss am Broker eindeutig sein. Kommt ein zweiter Client mit derselben ID, wirft der Broker den ersten kommentarlos raus. Laufen zwei z2m-Instanzen (z.B. der systemd-Dienst und dein manuelles node index.js), kicken die sich gegenseitig im Sekundentakt. Das passt zu deinem Log (12:29:38, 12:29:40).
systemctl status zigbee2mqtt
ps aux | grep -i zigbee- auch an einen geklonten Container mit kopierter configuration.yaml denken
- ohne client_id in der configuration.yaml nimmt z2m eine zufällige ID, dann entfällt dieser Verdacht
Sonst:
- was sagt das Broker-Log zum Zeitpunkt des Connects? Dort steht der Grund (Auth, ACL, TLS, Protokollversion).
- hat der Container nach dem Proxmox-Update/Reboot eine andere IP und der Broker filtert nach IP?
Gegentest: z2m stoppen und aus dem z2m-Container mit den Daten aus der configuration.yaml verbinden,
mit derselben Client-ID:
mosquitto_sub -d -h <server> -p <port> -u <user> -P <pw> -i <client_id> -t '#'- CONNACK (0) und bleibt stehen → Broker ok, Problem liegt bei z2m
- fliegt trotz gestopptem z2m immer wieder raus → irgendwas anderes benutzt dieselbe Client-ID
- CONNACK mit Fehlercode → Auth/ACL
- Abbruch ohne CONNACK → Broker legt auf (TLS, IP-Filter, MQTT-Version) → Broker-Log ansehen
Danke, die meisten Vorschläge kann ich aber sicher ausschließen.
- doppelte clientId
- mehrfache z2m Instanzen
- neue IP
Der entscheidende Hinweis war die Frage nach dem Log - danke dafür!
Gedanklich bin ich nicht davon ausgegangen, dass z2m überhaupt bis zum mqtt server durchkommt, deshalb hatte ich da noch nicht nachgeschaut.
Im Log des mqtt server steht beim Verbindungsversuch:
nanomq[689]: 2026-10-15 16:27:19 [709] WARN /home/runner/work/nanomq/nanomq/nng/src/sp/protocol/mqtt/mqtt_parser.c:1359 nano_msg_notify: mqttjs_3800e36e online!
nanomq[689]: 2026-10-15 16:27:19 [710] ERROR /home/runner/work/nanomq/nanomq/nng/src/sp/transport/mqtt/broker_tcp.c:691 tcptran_pipe_recv_cb: Size of packet exceeds limitation: 0x95
nanomq[689]: 2026-10-15 16:27:19 [710] WARN /home/runner/work/nanomq/nanomq/nng/src/sp/transport/mqtt/broker_tcp.c:895 tcptran_pipe_recv_cb: tcptran_pipe_recv_cb: recv_error rv: 149
nanomq[689]: 2026-10-15 16:27:19 [710] WARN /home/runner/work/nanomq/nanomq/nng/src/sp/protocol/mqtt/mqtt_parser.c:1363 nano_msg_notify: mqttjs_3800e36e offline!
nanomq[689]: 2026-10-15 16:27:19 [709] INFO /home/runner/work/nanomq/nanomq/nng/src/supplemental/nanolib/mqtt_db.c:959 delete_dbtree_node: Delete retain msg at node: [#]
Also habe ich mich auf die Suche nach dem Parameter für die packet-size gemacht und den Wert von 16kB (default) auf 256kB erhöht.
Und schon funktioniert z2m wieder.
Danke für den Schubs in die richtige Richtung.