Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[chucky666]

bei zeigt er manchmal das an
00158d00019f4fad das ist ein fensterkontakt , ich vermute der ist kaputt ( ersatz ist schon bestellt )

2026-04-16 13:16:16.006	warn	ELEVATED:I04 (8805) value generated '466' from device 00158d00019f4fad for 'Number of power outages'

zigbee.0
2026-04-16 13:16:16.006	warn	ELEVATED:I04 (8805) value generated '3045' from device 00158d00019f4fad for 'Voltage of the battery in millivolts'

zigbee.0
2026-04-16 13:16:16.006	warn	ELEVATED:I04 (8805) value generated '100' from device 00158d00019f4fad for 'Battery percent'

zigbee.0
2026-04-16 13:16:16.006	warn	ELEVATED:I03 (8805) message received '{"voltage":3045,"battery":100,"power_outage_count":466}' from device 00158d00019f4fad type 'MCCGQ01LM'

zigbee.0
2026-04-16 13:16:16.006	warn	ELEVATED:I02.1c (8805) candidates: [{"voltage":3045,"battery":100,"power_outage_count":466}] => payload {"voltage":3045,"battery":100,"power_outage_count":466}

zigbee.0
2026-04-16 13:16:16.006	warn	ELEVATED:I02.0b (8805) data: {"65282":[{"elmType":16,"elmVal":0},{"elmType":33,"elmVal":3045},{"elmType":33,"elmVal":17320},{"elmType":36,"elmVal":1},{"elmType":33,"elmVal":467},{"elmType":32,"elmVal":96}]} options: {} meta:{"deviceIEEE":"0x00158d00019f4fad","logger":"StatesController","state":{"state":""}} result:{}

zigbee.0
2026-04-16 13:16:16.006	warn	ELEVATED:I02.1a (8805) converter 1 : Cluster genBasic

zigbee.0
2026-04-16 13:16:16.006	warn	ELEVATED:I04 (8805) value generated '112' from device 00158d00019f4fad for 'Link quality'

zigbee.0
2026-04-16 13:16:16.006	warn	ELEVATED:I03 (8805) message received '{"linkquality":112}' from device 00158d00019f4fad type 'MCCGQ01LM'

zigbee.0
2026-04-16 13:16:16.006	warn	ELEVATED:I02 (8805) 1 converter available for 'MCCGQ01LM' '00158d00019f4fad' with cluster 'genBasic' and type 'attributeReport'

zigbee.0
2026-04-16 13:16:16.005	warn	ELEVATED:I01 (8805) Zigbee Event of Type attributeReport from device 0x00158d00019f4fad, incoming event: {"type":"attributeReport","data":{"65282":[{"elmType":16,"elmVal":0},{"elmType":33,"elmVal":3045},{"elmType":33,"elmVal":17320},{"elmType":36,"elmVal":1},{"elmType":33,"elmVal":467},{"elmType":32,"elmVal":96}]},"linkquality":112,"groupID":0,"cluster":"genBasic","meta":{"rawData":{"type":"Buffer","data":[28,52,18,85,10,2,255,76,6,0,16,0,33,229,11,33,168,67,36,1,0,0,0,0,33,211,1,32,96]},"zclTransactionSequenceNumber":85,"manufacturerCode":4660,"frameControl":{"frameType":0,"manufacturerSpecific":true,"direction":1,"disableDefaultResponse":true,"reservedBits":0}},"endpoint_id":1}

[Asgothian]

Wieso sollte der kaputt sein - da hast du das device-debug eingeschaltet (siehe hier: https://github.com/ioBroker/ioBroker.zigbee/wiki/Device-messaging-debug). Ansonsten sehe ich erst nichts was da komisch ist.

A.

[chucky666]

@Asgothian boah peinlich , tatsächlich war es eingeschaltet . ich dachte der macht probleme .
ok dann wird weiter geforscht

[rewenode]

@Asgothian sagte:

Wichtig ist erst einmal was passiert wenn er die Verbindung verliert, und ob auf dem Cod.M zu dem Zeitpunkt noch eine Verbinung angezeigt wird.

Wie stelle ich das fest?
Ich sehe nur, dass die Verbindungszeit zurückgesetzt wurde.

Der Koordinator läuft aber durch, das scheint alles ok.
Könnte man hier parallel Z2M aktivieren?

Dann ließe sich evtl. nachschauen, ob der mqtt Broker noch korrekt bedient wird.

[Asgothian]

Nein, kannst du nicht.

Du musst dir die Verbindung in dem Moment anschauen wo der Adapter nicht läuft. Wenn dann noch ein Client verbunden ist dann ist das ein Hinweis darauf was passiert.

A.

[rewenode]

@Asgothian sagte:

Du musst dir die Verbindung in dem Moment anschauen wo der Adapter nicht läuft

Alles klar, dann bin ich mal ganz Auge;-) und sammle Infos.
Danke.

[rewenode]

Gerade wieder so einen Fall erwischt.

zigbee.0 2026-04-17 08:58:33.761	error	Failed to start Zigbee: no message given

zigbee.0 2026-04-17 08:58:33.761	error	Starting zigbee-herdsman problem : Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)

zigbee. 2026-04-17 08:58:33.761	warn	unable to stop zigbee-herdsman after failed startup

zigbee.0 2026-04-17 08:58:33.759	info	Network parameters on Coordinator: panID=6754 channel=11 extendedPanID=bac04019004b1200

zigbee.0 2026-04-17 08:58:33.758	info	Network parameters in Config : panID=6754 channel=11 extendedPanID=bac04019004b1200

zigbee.0 2026-04-17 08:58:33.758	error	Failed to start Zigbee: no message given

zigbee.0 2026-04-17 08:58:33.758	error	Starting zigbee-herdsman problem : Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)

zigbee.0 2026-04-17 08:58:33.758	warn	unable to stop zigbee-herdsman after failed startup

zigbee.0 2026-04-17 08:58:33.756	info	Network parameters on Coordinator: panID=6754 channel=11 extendedPanID=bac04019004b1200

zigbee.0 2026-04-17 08:58:33.756	info	Network parameters in Config : panID=6754 channel=11 extendedPanID=bac04019004b1200

zigbee.0 2026-04-17 08:58:33.756	error	Failed to start Zigbee: no message given

zigbee.0 2026-04-17 08:58:33.756	error	Starting zigbee-herdsman problem : Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)

zigbee.0 2026-04-17 08:58:33.755	warn	unable to stop zigbee-herdsman after failed startup

zigbee.0 2026-04-17 08:58:33.751	info	Network parameters on Coordinator: panID=6754 channel=11 extendedPanID=bac04019004b1200

zigbee.0 2026-04-17 08:58:33.751	info	Network parameters in Config : panID=6754 channel=11 extendedPanID=bac04019004b1200

zigbee.0 2026-04-17 08:58:33.751	error	Failed to start Zigbee: no message given

Während der Adapter nicht automatisch neustarten kann, zeigt der Koordinator noch Verbindungszeit seit: mehr als eine Stunde an. (Könnte die Zeit seit letzen Crash sein).
Dann habe ich den Adapter manuell neu gestartet. Das geht und der Koordinator setzt die Verbindungszeit zurück auf 0.

Das wird nun langsam recht lästig und ich würde gern die Ursache finden.
Ich habe evtl. die Möglichkeit einen SMLIGHT SLZB-06 leihweise für ein paar tage zu bekommen.
Ich habe mir überlegt, ob ich den nicht nutzen kann, um den cod.m definitiv als Ursache ausschließen zu können.
Dazu würde ich den cod.m vorübergehend gegen den SMLIGHT SLZB-06 tauschen.
Dabei muss aber unbedingt sichergestellt sein, dass keine sensoren/aktoren (panID/exPanID) nei gepaairt werden müssen. Bei derzeit rund 80 Geräten wäre das eine Katastrophe.
Ich würde das Ganze dann ein paar Tage beobachten und entweder den cod.m tauschen oder wieder einsetzen.

Geht das so zu machen?

[Asgothian]

@rewenode sagte:

Wichtig wäre zu sehen was passiert bevor der Adapter versucht neu zu starten. Kannst du bitte die Log meldungen des ioBroker von 8:53 bis 8:59 posten ?

Dazu würde ich den cod.m vorübergehend gegen den SMLIGHT SLZB-06 tauschen.
Dabei muss aber unbedingt sichergestellt sein, dass keine sensoren/aktoren (panID/exPanID) nei gepaairt werden müssen. Bei derzeit rund 80 Geräten wäre das eine Katastrophe.
Ich würde das Ganze dann ein paar Tage beobachten und entweder den cod.m tauschen oder wieder einsetzen.

Geht das so zu machen?

Das kann gehen - allerdings musst du das NVRAM auf dem SLZB löschen damit die Daten aus dem nvbackup.json übernommen werden - ansonsten erkennt der die Geräte nicht an.

A.

[rewenode]

Hab mal die Logs der letzen Tage einer KI vorgeworfen mit der Bitte um Analyse.
Ist da was Brauchbares dabei?

Absturz-Zeitpunkte

Datum	Uhrzeit	Erfolg beim Neustart
14.04.	03:52	Ja (nach 2 Versuchen)
14.04.	06:45	Ja (nach mehreren Versuchen)
14.04.	11:59	Ja
16.04.	03:32	Ja
16.04.	08:09	Nein (dauerhaft)
17.04.	07:42	Nein (dauerhaft)

Wahrscheinliche Ursachen

1. Coordinator-Stick ( wahrscheinlichste Ursache)

• Es gibt keine Korrelation mit anderen Events

2. Software-Versionen

• Adapter: iobroker.zigbee@3.3.5 (Converters 25.112.0)
• Herdsman: 8.1.0
• Coordinator-Firmware: ZStack3x0 20250321 (2-1.2.7.1)
• Die Kombination scheint bekannte Probleme zu haben

3. Keine äußeren Auslöser

• Keine Korrelation mit backup, mqtt, admin oder anderen Adaptern
• Auch nicht bei hoher Geräteanzahl (59-60)

[Asgothian]

@rewenode sagte:

Hab mal die Logs der letzen Tage einer KI vorgeworfen mit der Bitte um Analyse.
Ist da was Brauchbares dabei?

Nein.

Alles was da steht ist bereits aus dem geposteten Log-Snippet bekannt.Einzig die race-condition kann ausgeschlossen werden - es sei denn du hast mehrere Zigbee Instanzen auf dem gleichen Koordinator laufen (was nicht geht)

A.

[rewenode]

@Asgothian sagte:

Alles was da steht ist bereits aus dem geposteten Log-Snippet bekannt.Einzig die race-condition kann ausgeschlossen werden

Schon mal was. Ich sag ja KI ist überbewertet, wenn man in einem guten Forum ist
Was ich seit heute mal teste (irgendwo muss man ja anfangen)
Habe den Koordinator umplatziert und jetzt ist nur noch ein Hub dazwischen.
Gibt es irgendwelche Hinweise für die Dockerkonfiguration? Läuft im Moment im bridge-mode. Allerdings sind mir im Laufe der Jahre diesbezüglich noch keine Netzwerk-Auffälligkeiten begegnet.

[Asgothian]

@rewenode sagte:

Gibt es irgendwelche Hinweise für die Dockerkonfiguration? Läuft im Moment im bridge-mode. Allerdings sind mir im Laufe der Jahre diesbezüglich noch keine Netzwerk-Auffälligkeiten begegnet.

Bei Docker bin ich raus - bei mir läuft alles nativ.

Die LAN Koordinatoren haben alle das gleiche Risiko:
RS232 Protokolle sind nicht darauf ausgelegt das Pakete fehlen oder 'out of turn' ankommen. Sobald es Paketverlust / Paketverzögerung gibt muss die Firmware des ETH zu RS232 Wandlers die Kommunikation mit einem eigenen Puffer sauber zusammen setzen. Wenn das nicht klappt dann bricht die serielle Kommunikation zusammen.

Ich denke das ist es was passiert wenn der Adapter nicht mehr will.

A.