UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Geesthachter]

Meine hier geschilderten Probleme wurden mit der Node.js-Version: 22.18.0 und der NPM-Version: 10.9.3 gelöst.

Hallo liebe Community,

ich hoffe, ihr könnt mir bei einem Problem helfen, das seit meinem Umstieg auf einen neuen Raspberry Pi auftritt.

Meine Systemkonfiguration:

Adaptername: MQTT und zigbee2mqtt

Link zu Adapterrepository: https://github.com/ioBroker/ioBroker.mqtt und https://github.com/arteck/ioBroker.zigbee2mqtt

Adapterversion: MQTT V6.1.2, zigbee2mqtt V3.0.9

js-controller Version: 7.0.7

Admin Version: 7.6.17

Hardwaresystem: Raspberry Pi 5

Arbeitsspeicher: 8GB

Festplattenart: 32GB SD-Karte

Betriebssystem: Debian GNU/Linux 12 (bookworm)

Node.js-Version: 22.18.0 (bis eben 20.19.4)

NPM-Version: 10.9.3 (bis eben 10.8.2)

Installationsart: Script

Image/Docker genutzt: Nein (Standard Raspberry Pi OS Lite Installation)

Systemdiagnose:

text
=== System Info ===
Linux raspberrypi5 6.12.34+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.34-1+rpt1~bookworm (2025-06-26) aarch64 GNU/Linux
=== Node.js & npm ===
v22.18.0
10.9.3
=== ioBroker Status ===
iobroker is running on this host.

Objects type: jsonl
States type: jsonl
=== Netzwerk ===
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 88:a2:9e:0e:8a:1e brd ff:ff:ff:ff:ff:ff
inet 192.168.178.190/24 brd 192.168.178.255 scope global dynamic noprefixroute wlan0
valid_lft 861584sec preferred_lft 861584sec
=== Speicher ===
total used free shared buff/cache available
Mem: 7.9Gi 3.2Gi 3.2Gi 13Mi 1.5Gi 4.6Gi
Swap: 511Mi 0B 511Mi
=== Festplatte ===
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p2 29G 8.9G 19G 33% /
Mein Problem:

Jahrelang habe ich ioBroker auf einem Raspberry Pi 4 betrieben und täglich nachts automatische Reboots durchgeführt - das funktionierte immer problemlos.

Seit meinem Umstieg auf den Raspberry Pi 5 und der gleichzeitigen Migration von den Zigbee- und Sonoff-Adaptern auf MQTT und zigbee2mqtt tritt ein merkwürdiges Problem auf:

Nach fast jedem Reboot gehen eine oder mehrere Zigbee oder auch WLAN Lampen (Tasmota) ungewollt an, obwohl dies nicht programmiert ist. Besonders auffällig dabei ist, dass die entsprechenden Datenpunkte weiterhin auf false stehen, die Lampen aber physisch brennen.

Es scheint, als würde während des Boot-Vorgangs eine Art "Phantom-Signal" gesendet werden, das die Lampen einschaltet, ohne dass dies in ioBroker registriert wird.

Als Workaround habe ich momentan ein Script eingerichtet, das nach jedem Reboot alle Lampen automatisch ausschaltet, aber das ist natürlich keine dauerhafte Lösung.

Meine Fragen:

Könnte das Problem mit der neuen Hardware (Pi 5 vs. Pi 4) zusammenhängen?

Liegt es möglicherweise an der Umstellung von Zigbee/Sonoff auf MQTT/zigbee2mqtt?

Gibt es bekannte Timing-Probleme beim Startup dieser Adapter?

Wie kann ich verhindern, dass während des Boots ungewollte Signale an die Zigbee-Geräte gesendet werden?

Hat jemand von euch ähnliche Erfahrungen gemacht oder eine Idee, wie sich dieses Problem lösen lässt?

Vielen Dank schon mal für eure Hilfe!

Beste Grüße

[mcm1957]

@geesthachter

Bin kein mqtt Spezialist - aber schau mal was du da beim mqtt Adapter eingestellt hast:

Publish own states on connect

Ansonsten wart mal auf besser informierte Antworten.

[arteck]

@geesthachter sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

Könnte das Problem mit der neuen Hardware (Pi 5 vs. Pi 4) zusammenhängen?

das hängt damit zusammen weil du den Pi neustartest.. warum auch immer... meiner rennt 24/7 365 ohne ein neustart

zum Problem.. zigbee2mqtt sendet nur den aktuellen zustand bei einer änderung.. ändert sich der Status einer Lampe während des reboots dann merkt das system das nicht. und wenn die AN war zuletzt wird das AN auch nochmal (da sich hier z2m den letzten zustand merkt) gesendet.

Lösung : lass das mit dem reboot jede nacht

[Codierknecht]

@arteck sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

Lösung : lass das mit dem reboot jede nacht

Dem würde ich auch erstmal zustimmen.
Ein Server läuft 24/7 und wird nur re-bootet wenn es notwendig ist.

Nutze bitte Code-Tags </> für Ausgaben aus Konsole und/oder Logs.

Nach fast jedem Reboot gehen eine oder mehrere Zigbee oder auch WLAN Lampen (Tasmota) ungewollt an, obwohl dies nicht programmiert ist.

Tatsächlich nicht? Bei jedem reboot werden auch die Scripte neu gestartet und somit sämtliche Variablen resettet.

[Geesthachter]

@arteck sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:9

wenn die AN war zuletzt wird das AN auch nochmal (da sich hier z2m den letzten zustand merkt) gesendet.

Das würde mir einleuchten aber die Lampen sind vor dem reboot alle aus aber nach dem Neustart gehen sie teilweise an. wenn ich sie dann nicht durch das Script ausschalten würde, dann würden sie dann auch an bleiben.

Lösung : lass das mit dem reboot jede nacht

Das wäre natürlich eine Lösung aber dennoch bleibt die Frage warum funktionierte es jahrelang mit dem Raspi 4 und dem Zigbee und Sonoff Adapter und jetzt nicht mehr.?
Selbst wenn ich das mit dem Reboot jede Nacht lasse, würde es dennoch passieren wenn ich manuell den Raspi 5 ausschalte um zum Beispiel eine Sicherung meiner SD Karte zu machen.

Lampen die ich dann im Blickfeld habe, könnte ich dann natürlich auch manuell ausschalten aber Lampen auf anderen Etagen oder im Garten würden dann brennen.
(Wobei dann natürlich mein Skript dafür sorgen würde das die Lampen ausgehen)
schöner wäre es natürlich wenn sie gar nicht erst angehen.

[Geesthachter]

@codierknecht sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

Tatsächlich nicht? Bei jedem reboot werden auch die Scripte neu gestartet und somit sämtliche Variablen resettet.

die Lampe gehen so früh an, das ich annehme das zu dem Zeitpunkt noch gar kein Script gestartet ist. Vielleicht noch nicht einmal die Adapter, ich vermute das da irgendwelche Signale beim hochfahren des Raspi 5 dazu führen das die Lampen angehen. Wie schon geschrieben die Datenpunkte bleiben ja auf false aber die Lampen sind an.
eine KI die ich danach befragte schrieb das es mit der Geschwindigkeit des Raspi 5 zu tun hat.

Da ich keine Ahnung davon habe ob das sein kann, frage ich hier halt mal im Forum nach.

[Geesthachter]

@mcm1957 sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

@geesthachter

Bin kein mqtt Spezialist - aber schau mal was du da beim mqtt Adapter eingestellt hast:

Publish own states on connect

Bei Eigene States beim Verbinden publizieren, habe ich den Haken drinn

[Asgothian]

@geesthachter sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

@codierknecht sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

Tatsächlich nicht? Bei jedem reboot werden auch die Scripte neu gestartet und somit sämtliche Variablen resettet.

die Lampe gehen so früh an, das ich annehme das zu dem Zeitpunkt noch gar kein Script gestartet ist. Vielleicht noch nicht einmal die Adapter, ich vermute das sa irgendwelche Signale beim hochfahren des Raspi 5 dazu führen das die Lampen angehen. Wie schon geschrieben die Datenpunkte bleiben ja auf false aber die Lampen sind an.
eine KI die ich danach befragte schrieb das es mit der Geschwindigkeit des Raspi 5 zu tun hat.

Da ich keine Ahnung davon habe ob das sein kann, frage ich hier halt mal im Forum nach.

Das beweist mal wieder das die KI absoluten Schwachsinn schreiben kann. Es ist eher ausgeschlossen das durch 'zufällige' Effekte genau die Byte-Abfolgen im 2.4 GHz Netz gesendet werden das dadurch Geräte schalten. Es muss also andere Effekte geben.

Dinge die du tun kannst:

• wie @arteck schrieb: auf den regelmässigen Neustart verzichten. Das System ist dafür gemacht durch zu laufen.
• Sicherstellen das der PI5 nicht im WiFi Aktiv ist (per dtoverlay abschalten)
• Sicherstellen das der PI5 nicht via BT aktiv ist (per dtoverlay abschalten)
• LAN-Koordinator für Zigbee nutzen, damit dieser keinen 'power-cycle' parallel zum PI5 macht.

@geesthachter sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

Könnte das Problem mit der neuen Hardware (Pi 5 vs. Pi 4) zusammenhängen?

Eher nein.

Liegt es möglicherweise an der Umstellung von Zigbee/Sonoff auf MQTT/zigbee2mqtt?

Eher ja.

Gibt es bekannte Timing-Probleme beim Startup dieser Adapter?

Meines Wissens nach nein.

Wie kann ich verhindern, dass während des Boots ungewollte Signale an die Zigbee-Geräte gesendet werden?

Das musst du nicht - während des Boot-Vorgangs werden keine Zigbee Signale ausgesandt. Die werden erst gesandt wenn z2m startet.

A.

[Geesthachter]

@asgothian sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

Sicherstellen das der PI5 nicht im WiFi Aktiv ist (per dtoverlay abschalten)

Ich habe den Raspi 5 tatsächlich per WLA mit meinem Router verbunden.
kann das die Ursache für den Fehler sein?

[crunchip]

@asgothian sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

Meines Wissens nach nein

Vllt doch, habe nicht erlesen welcher Stick und woran er hängt.

Ich kann nur aus eigener Erfahrung sprechen.
Z2m, Stick per LAN. Wenn Verbindung gestört, sprich keine Verbindung zum coordinator, dann geht bei mir ne Osram Birne im WC und ne Innr im Dachboden an.

[Asgothian]

@geesthachter sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

@asgothian sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

Sicherstellen das der PI5 nicht im WiFi Aktiv ist (per dtoverlay abschalten)

Ich habe den Raspi 5 tatsächlich per WLA mit meinem Router verbunden.
kann das die Ursache für den Fehler sein?

eher nicht, ist aber systematisch schlecht und sollte vermieden werden.

A.

[Asgothian]

@crunchip sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

Z2m, Stick per LAN. Wenn Verbindung gestört, sprich keine Verbindung zum coordinator, dann geht bei mir ne Osram Birne im WC und ne Innr im Dachboden an.

• welchen Stick ?
• immer die gleichen Geräte ?

[Geesthachter]

@crunchip sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

@asgothian sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

Meines Wissens nach nein

Vllt doch, habe nicht erlesen welcher Stick und woran er hängt.

ZBDongle-P

[Geesthachter]

@asgothian sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

@crunchip sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

Z2m, Stick per LAN. Wenn Verbindung gestört, sprich keine Verbindung zum coordinator, dann geht bei mir ne Osram Birne im WC und ne Innr im Dachboden an.

• welchen Stick ?
• immer die gleichen Geräte ?

nein es sind nicht immer die gleichen Geräte, nachdem ich neulich nachts um 4 Uhr von meiner Schlafzimmerlampe geweckt wurde habe ich den Reboot nun auf 9 Uhr gestellt.
schlimm wäre es wenn mal meine Eiswürfelmaschine im Keller betroffen wäre und ich das nicht bemerken würde. dann könnte ich vielleicht irgendwann mit Eiwürfeln die Nachbarn versorgen. lach

[crunchip]

@asgothian slzb-06m
Ja immer die selben Lampen

Es ist immer aufgetreten, wenn sich der unraid Server aufgehangen hat(Ram Probleme)
Mittlerweile läuft das System auf nem anderen Rechner mit doppelt so viel RAM und seitdem nicht mehr aufgetreten.

[FernetMenta]

@geesthachter Passiert das auch, wenn du im z2m Adapter den Dummy mqtt Server verwendest, statt mqtt als eigenen Adapter? Ich glaube mich zu erinnern, dass ein Bekannter von mir das gleiche Problem hatte. Eventuall wird da von mehreren Seiten eingewirkt.

[Asgothian]

@geesthachter sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

nein es sind nicht immer die gleichen Geräte

Wenn es unterschiedliche Geräte sind kann einzig eine Race-Kondition dazu führen das da irgendwas passiert. Wie oben schon geschrieben halte ich es für ausgeschlossen das der Neustart des PI zufällige 2.4 GHz Signale aussendet die von den Geräten als Schaltimpulse verstanden werden.

Was du versuchen kannst, wenn du unbedingt auf dem Reboot bestehst (den ich für unsinnig halte - mein PI5 mit Zigbee hat aktuell eine Uptime von 280 Tagen)

• 75 s vor dem Reboot: MQTT Server anhalten, MQTT Server
• 60 s vor dem Reboot: Zigbee2mqtt anhalten,
• Reboot auslösen

A.

[Asgothian]

@fernetmenta sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

@geesthachter Passiert das auch, wenn du im z2m Adapter den Dummy mqtt Server verwendest, statt mqtt als eigenen Adapter? Ich glaube mich zu erinnern, dass ein Bekannter von mir das gleiche Problem hatte. Eventuall wird da von mehreren Seiten eingewirkt.

guter Hinweis.

Dazu noch testen: Tritt der Effekt wirklich nur bei einem Reboot auf, oder reicht es z2m und ioBroker neu zu starten damit der Effekt auftritt ?

A.

[Geesthachter]

Hallo zusammen,

ich habe das Problem noch einmal zu reproduzieren versucht und dabei mehrfach beide Adapter neu gestartet – keine einzige Lampe ist dabei mehr angegangen.

ABER jetzt ist mir etwas aufgefallen, was ich vorher übersehen hatte:

Wie ich bei der Eröffnung des Threads erwähnt hatte, nutze ich seit kurzem die Node.js-Version 22.18.0 und bis kurz vor der Thread-Erstellung noch die Version 20.19.4. Das Gleiche gilt für NPM – aktuell verwende ich NPM-Version 10.9.3, vorher war es Version 10.8.2.

Der Grund, warum ich darauf zurückkomme: Ich habe eben mehrere Reboots durchgeführt und jetzt schaltet sich keine Lampe mehr automatisch ein nach dem Neustart.

Ist das purer Zufall oder hängt das tatsächlich mit den neueren Node.js- oder NPM-Versionen zusammen? Ehrlich gesagt bin ich mir nicht sicher.

Mein Plan ist es, die Lampen in den nächsten Tagen weiter zu beobachten und das Script zum automatischen Ausschalten der Lampen vorerst deaktiviert zu lassen.

Ich bin sehr gespannt, ob ich mich zu früh gefreut habe oder ob mein Problem tatsächlich durch die Version-Updates verschwunden ist.

Vielen herzlichen Dank für all eure hilfreichen Beiträge zu diesem Thema! Eure Unterstützung und Erfahrungen haben mir sehr weitergeholfen.

Beste Grüße

[crunchip]

@geesthachter sagte in Nach reboot am Raspi 5 Probleme mit Mqtt und Zigbee2mqttper.:

zu reproduzieren versucht und dabei mehrfach beide Adapter neu gestartet – keine einzige Lampe ist dabei mehr angegangen.

und auch nen reboot getestet?