Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[DirkS]

@Asgothian
Werde ich die Tage machen, wenn es etwas ruhiger wird.
Es ist aber schon sehr kurrios. Wenn ich SQL Logging einschaltet, sollte doch der letzte Zustand protokolliert sein? Dieser passt manchmal nicht zum aktuellen Zustand der Erreichbarkeit.
Das nächste ist, dass z.B. von meinen geliebten OSRAM Dingern die Erreichbarkeit als nicht vorhanden angezeigt wird, diese sich aber schalten lassen. Ich vermute, dass es dann den umgekehrten Fall auch gibt?
[Nachtrag]
Vermutlich kein Zusammenhang, habe gerade ein Update-Check gestartet und bekomme nun dies hier ins Log

zigbee.1	2020-12-17 07:39:13.231	error	at Timer.processTimers (timers.js:223:10)
zigbee.1	2020-12-17 07:39:13.231	error	at listOnTimeout (timers.js:263:5)
zigbee.1	2020-12-17 07:39:13.231	error	at tryOnTimeout (timers.js:300:5)
zigbee.1	2020-12-17 07:39:13.231	error	at ontimeout (timers.js:436:11)
zigbee.1	2020-12-17 07:39:13.231	error	at Timeout.waiter.timer.setTimeout [as _onTimeout] (/opt/iobroker/node_modules/iobroker.zigbee/node_modules/zigbee-herdsman/dist/utils/waitress.js:46:35)
zigbee.1	2020-12-17 07:39:13.231	error	(10275) Error: Timeout - 46243 - 1 - null - 25 - 1 after 30000ms
zigbee.1	2020-12-17 07:39:13.231	error	(10275) unhandled promise rejection: Timeout - 46243 - 1 - null - 25 - 1 after 30000ms
Unhandled	2020-12-17 07:39:13.230	error	promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().

[Asgothian]

@DirkS sagte in Zigbee Geräte schalten verzögert:

Vermutlich kein Zusammenhang, habe gerade ein Update-Check gestartet und bekomme nun dies hier ins Log

Irgendwie scheint dieser Eintrag unvollständig. Der entscheidende Teil fehlt.

@DirkS sagte in Zigbee Geräte schalten verzögert:

Das nächste ist, dass z.B. von meinen geliebten OSRAM Dingern die Erreichbarkeit als nicht vorhanden angezeigt wird, diese sich aber schalten lassen. Ich vermute, dass es dann den umgekehrten Fall auch gibt?

Soweit ich das überblicke gibt es diesen Fall nur bei batteriebetriebenen Geräten, bei denen die Erkennung der Anwesenheit generell problematisch ist, da sie nicht abgefragt werden können. Eine saubere Erkennung basierend auf der letzten erhaltenen Nachricht ist nicht immer Einfach, da sich das Intervall in dem sich die Geräte melden von Gerät zu Gerät extrem unterscheiden kann.

A.

[DirkS]

@Asgothian
Leider ist im Log nicht mehr vorhanden, außer dass es sich mehrfach wiederholt und dann der Adapter irgendwann automatisch neu startet.

Bei der Erreichbarkeit geht es ja nicht um die Batterie betriebenen Geräte. Es ist der OSRAM Led Stripe.

[Asgothian]

@DirkS sagte in Zigbee Geräte schalten verzögert:

Bei der Erreichbarkeit geht es ja nicht um die Batterie betriebenen Geräte. Es ist der OSRAM Led Stripe.

Bei dem sollte der "available" Datenpunkt zumindest in dem 5 Minuten Raster des Abfragen korrekt sein, sprich es gibt ein Zeitfenster von max. 5 Minuten in denen der Strip noch mit "available = wahr" geführt wird, obwohl er bereits aus ist. Danach wird er auf jeden Fall auf falsch gehen da er auf den Ping der ihm geschickt wird nicht reagieren wird.

A.

[DirkS]

@Asgothian
Sicher nicht mehr der richtige Thread.
Habe heute folgende Einträge im Log

zigbee.1	2020-12-18 07:17:11.563	error	at fulfilled (/opt/iobroker/node_modules/iobroker.zigbee/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:24:58)
zigbee.1	2020-12-18 07:17:11.563	error	at Generator.next (<anonymous>)
zigbee.1	2020-12-18 07:17:11.563	error	at ZStackAdapter.<anonymous> (/opt/iobroker/node_modules/iobroker.zigbee/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:339:27)
zigbee.1	2020-12-18 07:17:11.563	error	(29141) Error on send command to 0xXXXXXXXXXXXXXXXX. Error: Error: Command 0xXXXXXXXXXXXXXXXX/1 genOnOff.off({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultRespon

Der State vom "available" ist aber die ganze Zeit auf true und die Protokollierung zeigte auch seit gestern keine Änderung.
Sollte denn dann zuminest bei so einem Fehler der State nicht auf false gehen?

[Asgothian]

@DirkS

• Stimmt, nicht der richtige Thread ;)
• Das Log ist unvollständig - die entscheidende Information ist (mal wieder) abgeschnitten
• Aktuell ist es so dass ein Router-Device nur dann auf "available=false" gesetzt wird wenn es auf den "ping" nicht reagiert.

A.

[DirkS]

@asgothian
Nachdem ich nun dummerweise beim Flashen der neuen Firmware auch einen Haken bei "Full erase " gesetzt hatten, musste ich danach alle Geräte neu anlernen. Danach lief es bis zum letzten Wochenende echt super. Nun fängt das beschriebene Problem wieder an. Die Geräte schalten wieder etwas verzögert.
Im Log ist im Level Info keine Ausgabe zu den Zeitpunkten. Ich habe habe aber nun auch vermehrt die Hinweise "Failed to Ping" zu mehreren Geräten.

[Asgothian]

@dirks Die vermehrten Meldungen zum nicht erfolgreichen Ping deuten auf Probleme mit der Funkverbindung hin. Ich würde hier zunächst das Funk-Umfeld prüfen (WLan / DECT) prüfen.

Insbesondere WLan Router die ihre Frequenz automatisch wählen können da zu Auffälligkeiten führen.

A.

[DirkS]

@asgothian
Wie so üblich, "ich habe nichts gemacht".
Die Router und Repeater (alles AVM) laufen im Mesh und sind fest auf einen Kanal, der mit dem Nachbarn abgesprochen ist, eingestellt.
Ich werde es aber noch einmal überprüfen, ob mir da jemand auf dem WLan Kanal 1 zu nahe kommt.

[watcherkb]

@asgothian habe das Problem hier auch wie @DirkS. Verzögertes Schalten der Zigbee-Geräte und Ping Meldungen im Log.
Mein Zigbee Gerät hängt im EG Hauswirtschaftsraum direkt neben der FritzBox. Wenn ich das ganze Haus abdecken will, welcher Standort ist besser geeignet? EG oder OG? Also besser zentral platzieren im Haus? Ich habe die CC2538+CC2592 Platine von arteck.

[DirkS]

@watcherkb
Ich denke hier muss man etwas rumprobieren. Ich vermute das Problem aber doch etwas woanders bei mir. Zwei von den Xiaomi Umweltsensoren sind nicht mehr verfügbar und ein Tuya Smart Plugist komplett "verschwunden", als ob dieser entfernt wurde.

[Asgothian]

@dirks

Du musst auch auf bestimmte Konstellationen achten. So entfernen immx plugs regelmässig sämtliche Xiaomi Sensoren und Schalter aus dem Netz die versuchen über die Immax Steckdosen geroutet zu werden.

Wenn Du da zusammenhänge erkennst bin ich für Hinweise dankbar - sie werden auf dieser Seite (https://github.com/ioBroker/ioBroker.zigbee/wiki/problem-devices) Eingang finden.

A.

[Asgothian]

@watcherkb sagte in Zigbee Geräte schalten verzögert:

@asgothian habe das Problem hier auch wie @DirkS. Verzögertes Schalten der Zigbee-Geräte und Ping Meldungen im Log.
Mein Zigbee Gerät hängt im EG Hauswirtschaftsraum direkt neben der FritzBox. Wenn ich das ganze Haus abdecken will, welcher Standort ist besser geeignet? EG oder OG? Also besser zentral platzieren im Haus? Ich habe die CC2538+CC2592 Platine von arteck.

Direkt neben der FritzBox ist generell schlecht. Ich würde einen Abstand von mindestens 2 Metern zwischen Koordinator und WLan Router empfehlen. Dabei ist es ideal wenn die beiden nicht horizontal oder vertikal nebeneinander stehen.

A.

[DirkS]

@asgothian
Genau die Blitzwolf Plugs habe ich im Einsatz. Im Gegensatz zu den Osram Plugs laufen diese bis auf wenige Ausnahmen wirklich stabil und haben eine höhere Reichweite. Die Xiaomi Sensoren sind regelmäßig nicht erreichbar. Teilweise über Tage. Da ich inzwischen meinen Befeuchter mit den Werten ein/aus schalte, fällt es mir nun eher auf. Außer den Ping-Fehler ist in den Log nichts drin.

[watcherkb]

@asgothian Wäre es möglich den Coordinator per LAN-Anschluss woanders zu platzieren? Hab im ganzen Haus LAN-Dosen. Oder besser einen Raspi und per ser2net anbinden?

[Asgothian]

@dirks sagte in Zigbee Geräte schalten verzögert:

Die Xiaomi Sensoren sind regelmäßig nicht erreichbar. Teilweise über Tage

Nicht erreichbar in "sie senden keine Werte obwohl sich der Status ändert" oder "wenn ich versuche von Ihnen Werte abzufragen antworten sie nicht" ?

A.

[Asgothian]

@watcherkb Ich kenne die LogiLink dinger nicht. Wenn sie ohne Treiber transparent sauber arbeiten, warum nicht.

Ich persönlich nutze ser2net.

A.

[DirkS]

@asgothian
Sie sind als abwesend gekennzeichnet und liefern auch keine Daten mehr.
Ein einfaches Batterie raus/rein hat nicht geholfen. Ich musste sie entfernen und neu anlernen. Denke ich werde die wohl dann auch mal gegen andere Sensoren tauschen.

[Asgothian]

@dirks das einzige was mir noch einfällt ist die Frage über welche Router sie gehen. Es gibt router die Sensoren raus werfen die sich lange nicht melden.

A

[DirkS]

@asgothian Die Sensoren sind nicht einmal das Problem.
Eben gerade kam es wieder zu einer Verzögerung. Es gab unmittelbar zu dem Zeitpunkt folgenden Ausschrieb:

Error on send command to 0x842e14fffe139455. Error: Error: Command 0x842e14fffe139455/1 genOnOff.off({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultRespons

Das Gerät ist ein Smartplug, geschaltet werden sollte aber eigentlich ein ganz anderes. Es schaltete dann auch.
Das mit dem Fehler angezeigten Smartplug ist aber "anwesend" und lässt sich nun auch schalten.