Probleme mit ZigBee Sensoren
-
Hallo zusammen,
ich habe Probleme mit diversen Sensoren.
Aber zum besseren Verständnis der Hintergrund:
Ich habe bis vor ein paar Wochen ein Zigbee-Netz mit einem Sonoff-Dongle betrieben, welches auch halbwegs stabil war.
Nur die Vallhorn-Bewegungsmelder im Garten hatten eine schlechte Verbindung (link quality ~10) und lösten nicht immer aus.
Daher habe ich eine Etage tiefer ein zweites zigbee-Netz mit einem Ethernet SLZB-06 gespannt.
Die Verbindung waren deutlich stabiler und auch die Bewegungsmelder hatten eine bessere Verbindung (link-quality >150)
Allerdings löst keiner der drei Bewegungsmelder nach Löschen im Zigbee.0 und neues Pairing im Zigbee.1 mehr aus. Nur beim Pairing löst occupancy aus.
Auch andere Sensoren z.B. SNZB-02D, die im Zigbee.0 Netz liefen, weigern sich in Zigbee.1 Netz Werte zu senden, obwohl sie gut verbunden sind.Mache ich etwas Grundsätzlich falsch? Der Ausfall eines Bewegungsmelders ist ok, aber drei?
Danke für Tipps
Jürgen -
@ünne da braucht es definitiv wesentlich mehr Informationen!
Schuss ins Blaue:
die BWM sind noch im alten Netz registriert -
@ünne said in Probleme mit ZigBee Sensoren:
Auch andere Sensoren z.B. SNZB-02D, die im Zigbee.0 Netz liefen, weigern sich in Zigbee.1 Netz Werte zu senden, obwohl sie gut verbunden sind.
Ich würde mal über die Kacheln im zigbee.1 ein Rekonfigure der jeweiligen Geräte auslösen. Wenn das auf einen Timeout läuft (weil Gerät nicht wach), hat sich zumindest bei Ikea Geräten bewährt, kurz Batterie raus und wieder rein, dann erscheint "DeviceConfigure successful" im Log (der Trick mag auch bei anderen batteriebetriebenen Geräten funktionieren). Dann könnten wieder Werte geliefert werden - sofern kein anderes Problem vorliegt.
-
@ünne sagte in Probleme mit ZigBee Sensoren:
Hallo zusammen,
ich habe Probleme mit diversen Sensoren.
Aber zum besseren Verständnis der Hintergrund:
Ich habe bis vor ein paar Wochen ein Zigbee-Netz mit einem Sonoff-Dongle betrieben, welches auch halbwegs stabil war.
Nur die Vallhorn-Bewegungsmelder im Garten hatten eine schlechte Verbindung (link quality ~10) und lösten nicht immer aus.
Daher habe ich eine Etage tiefer ein zweites zigbee-Netz mit einem Ethernet SLZB-06 gespannt.
Die Verbindung waren deutlich stabiler und auch die Bewegungsmelder hatten eine bessere Verbindung (link-quality >150)
Allerdings löst keiner der drei Bewegungsmelder nach Löschen im Zigbee.0 und neues Pairing im Zigbee.1 mehr aus. Nur beim Pairing löst occupancy aus.
Auch andere Sensoren z.B. SNZB-02D, die im Zigbee.0 Netz liefen, weigern sich in Zigbee.1 Netz Werte zu senden, obwohl sie gut verbunden sind.Mache ich etwas Grundsätzlich falsch? Der Ausfall eines Bewegungsmelders ist ok, aber drei?
Danke für Tipps
JürgenHat das Netz in der Etage tiefer andere Einstellungen als das Netz oben ? (PanID, ExtPanID, Kanal) ?
Ansonsten das was @AlexHaxe geschrieben hat.
A.
-
@alexhaxe
Das habe ich gerade ausprobiert und bekomme folgende Error-Meldung:
Configuration timed out 0x0c2a6ffffe458de9 VALLHORN Wireless Motion Sensor. The device did not repond in time to the configuration request. Another attempt will be made when the device is awake.Dann wie du geschrieben hast, Batterie raus und wieder rein, wieder reconfigure .....und jetzt klappt es. Danke für den Tipp.
Ich weiß allerdings nicht, was ich gemacht habe, also technisch. Kannst du mir da auch was zu sagen?
Gruß
Jürgen -
@alexhaxe
Tja, leider ist das Problem doch noch nicht gelöst.
Nachdem ich das Spiel: reconfigure, batterie raus, rein, mit dem zweiten Bewegungsmelder durchgeführt habe, bekam ich eine andere Fehlermeldung:0x0c2a6ffffe458de9 VALLHORN Wireless Motion Sensor Failed to configure. --> Bind 0x0c2a6ffffe458de9/2 msOccupancySensing from '0x84b4dbfffebc5e02/1' failed (Delivery failed for '48731'.)
Was kann ich aus dieser Meldung lernen? Hab versucht zu googeln, habe aber nichts gefunden.
Gruß
Jürgen -
@asgothian
Ja, sowohl die beiden PanID's als auch der Kanal ist anders.
Jürgen -
@homoran
Die Geräte habe ich mit "Löschen erzwingen-Häckchen" entfernt.
Gruß
Jürgen -
@alexhaxe
So, jetzt bin ich letztlich doch -hoffentlich- erfolgreich.
Da es im Netz ähnliche Verbindungsprobleme zu finden gibt, schien es mir, dass es Problem sein kann, Verfügbarkeit und Rekonfiguration gleichtzeitig zu haben.
Statt Batterie raus und rein, habe ich die Verbindungstaste genutzt um das Gerät zu wecken. Bei dem IKEA BWM muss man diese Taste 4x zum Pairen drücken. Nach 2x drücken und dann reconfigure, hat es dann geklappt.
Auch einen smart-Button und ein Sonoff-Thermometer konnte ich mit dem Batterie-Trick rettten.Also, erfolgreich. Ich hoffe, längerfristig.
Ich bedanke mich für den Tipp.
Gruß
Jürgen -
@ünne said in Probleme mit ZigBee Sensoren:
Configuration timed out 0x0c2a6ffffe458de9 VALLHORN Wireless Motion Sensor. The device did not repond in time to the configuration request. Another attempt will be made when the device is awake.
Ich weiß allerdings nicht, was ich gemacht habe, also technisch. Kannst du mir da auch was zu sagen?
Die Fehlermeldung ist der Timeout von dem ich sprach. Geräte mit Batterie sind nicht permanent auf "Lauschbetrieb", kriegen also nicht mit, wenn jemand etwas von ihnen will (Senden und Empfangen kostet Batterie-Laufzeit). Bei manchen Geräten kann man durch mehrfaches Betätigen der Taster oder Kontakte den Wachzustand (und damit das Lauschen auf Nachrichten) erzwingen und so die Konfiguration erfolgreich abschließen. Andere Geräte kriegen es mit der Zeit hin, sprich wenn das Gerät das nächste Mal sendet, wird die Konfiguration zu diesem Zeitpunkt automatisiert erneut versucht. Bei Ikea Geräte war dies nach meinen Erfahrungen auch nach Tagen nicht der Fall. Deshalb der Trick mit Batterie raus und wieder rein. Das Gerät wird dabei neu gestartet und macht in dem Zug das Empfangsfenster kurz auf und siehe da, die Konfiguration wird empfangen und verarbeitet. Dieser Trick kann auch bei anderen batteriebetriebenen Geräten funktionieren, wenn man zu wenig Geduld hat, das System mehrere Stunden laufen zu lassen, um zu sehen ob es von alleine klappt.
Normalerweise sollte der Adapter die Konfiguration automatisch durchführen, und keine manuelle Auslösung über die Kachel erfordern. In letzter Zeit habe ich aber den Eindruck, dass dies fast immer notwendig ist. Das mag durchaus an den Geräten liegen, die ich in letzter Zeit eingebunden habe, bereits eingebundene Geräte benötigen diese Prozedur i.d.R. nicht, sie funktionieren seit Version iobroker.zigbee 1.x (inzwischen 3.x) ohne neues Anlernen.
Meine Theorie zum manuellen Anlernen: Wenn ein neues Gerät verbunden wird (Pairing), dann lernt der Zigbee Adapter aus den Herdsman Konvertern welche Datenpunkt das Gerät grundsätzlich liefern kann und legt diese im Objektbaum an. Das bedeutet aber noch nicht, dass das Gerät sie auch tatsächlich meldet. Mein spekulativer Eindruck ist, dass der Adapter sein Interesse an den Datenpunkten dem Gerät mitteilen oder ausverhandeln muss, bevor das Gerät beginnt die Werte zu senden. Die geschieht während der Konfiguration. Da bei den Ikea Geräten die automatische Konfiguration ausbleibt / fehlschlägt, denkt das Gerät "keiner interessiert sich für meine Daten, also gibt es nur 'link quality' und 'available' von mir" und dann nimm es den Lauschbetrieb überhaupt nicht mehr auf. Nur ein Reboot durchbricht das Schweigen, bzw. Ohren zuhalten. - soweit meine Theorie, ich habe die Zigbee Spezifikation nicht mal grob überflogen, gebe also keine Garantie, dass das auch nur halbwegs den Tatsachen entspricht. Für mich ist das zumindest eine plausible Erklärung, auch wenn die technischen Details vermutlich komplexer oder gar anders sind als diese sehr vereinfachte Darstellung.
@ünne said in Probleme mit ZigBee Sensoren:
0x0c2a6ffffe458de9 VALLHORN Wireless Motion Sensor Failed to configure. --> Bind 0x0c2a6ffffe458de9/2 msOccupancySensing from '0x84b4dbfffebc5e02/1' failed (Delivery failed for '48731'.)
Diese Meldung habe ich so auch noch nicht gesehen, möglicherweise hast Du die Batterien entfernt, als gerade eine Konfiguration lief. Die Reihenfolge ist wichtig: Kachel -> Rekonfigure -> Warten bis Timeout in Oberfläche angezeigt, bzw. "Configuration timed out" im Log erscheint -> Batterie raus -> ca. 1s warten -> Batterie rein -> Log checken auf "DeviceConfigure successful". Notfalls wiederholen nach ausreichender Wartezeit (30-60s).
-
@alexhaxe sagte in Probleme mit ZigBee Sensoren:
Meine Theorie zum manuellen Anlernen: Wenn ein neues Gerät verbunden wird (Pairing), dann lernt der Zigbee Adapter aus den Herdsman Konvertern welche Datenpunkt das Gerät grundsätzlich liefern kann und legt diese im Objektbaum an. Das bedeutet aber noch nicht, dass das Gerät sie auch tatsächlich meldet. Mein spekulativer Eindruck ist, dass der Adapter sein Interesse an den Datenpunkten dem Gerät mitteilen oder ausverhandeln muss, bevor das Gerät beginnt die Werte zu senden. Die geschieht während der Konfiguration. Da bei den Ikea Geräten die automatische Konfiguration ausbleibt / fehlschlägt, denkt das Gerät "keiner interessiert sich für meine Daten, also gibt es nur 'link quality' und 'available' von mir" und dann nimm es den Lauschbetrieb überhaupt nicht mehr auf. Nur ein Reboot durchbricht das Schweigen, bzw. Ohren zuhalten. - soweit meine Theorie, ich habe die Zigbee Spezifikation nicht mal grob überflogen, gebe also keine Garantie, dass das auch nur halbwegs den Tatsachen entspricht. Für mich ist das zumindest eine plausible Erklärung, auch wenn die technischen Details vermutlich komplexer oder gar anders sind als diese sehr vereinfachte Darstellung.
Hier kann ich aushelfen:
In der Zigbee Firmware kann (muss aber nicht) voreingestellt werden, ob zu bestimmten Clustern und Attributen Nachrichten per Default an den bestimmte Geräte oder Gruppen gesendet werden sollen. Beispiele dafür sind:
- Aqara Sensoren, die generell an den Koordinator senden auch wenn sie nicht konfiguriert wurden
- Ikea Fernbedienungen, die generell alle Aktionen an die Gruppe 901 senden (und diese auch anlegen sofern sie nicht existiert)
Wenn das nicht der Fall ist dann muss dieses dem Gerät mitgeteilt werden. Dazu dient die Konfiguration. Was zu konfigurieren ist ist auch in den ZHC definiert. Der Adapter hat da keine Aktien dran - kann aber abfragen ob ein Gerät konfiguriert ist oder nicht.
Geräte bei denen der ZH der Meinung ist das sie nicht konfiguriert sind werden beim Start des Adapters zur Konfiguration vorgeschlagen.Eine Neukonfiguration ist Zwingend erforderlich wenn
- das Gerät zurück gesetzt wurde (in den Pairing modus gebracht)
- sich die Koordinator-IEEE geändert hat (Austausch des Koordinators im Bestehenden Netz)
- ein Batteriebetriebenes Gerät zu lange ohne Strom war
Optional kann durch Firmware-Updates oder ZHC Updates eine Neukonfiguration notwendig werden. Beispiel: Firmware-Updates bei den Nous A1Z Steckdosen)
Während der Konfiguration wird. z.Bsp. ein 'Binding' von einem Cluster (an einem Endpunkt des zu konfigurierenden Gerätes) an ein anderes Gerät (wieder: Cluster, Endpunkt) vorgenommen. Wenn dieses nicht stattfindet dann weiss das Gerät einfach nicht an wen es die Nachricht senden soll. Insbesondere bei den Ikea Geräten ist das die Voreinstellung - diese sind für einen Autarken Betrieb ohne Koordinator vorgesehen.
In dem Zusammenhang: in der Meldung
0x0c2a6ffffe458de9 VALLHORN Wireless Motion Sensor Failed to configure. --> Bind 0x0c2a6ffffe458de9/2 msOccupancySensing from '0x84b4dbfffebc5e02/1' failed (Delivery failed for '48731'.)wird versucht ein zwischen dem Gerät0x0c2a6ffffe458de9, Endpunkt 2 und0x84b4dbfffebc5e02, Endpunkt 1 vorzunehmen, und zwar für den ClustermsOccupancySensing- welcher im Zigbee Standard für die BWM vorgesehen ist.Kleiner Exkurs zwischendurc. Ich hab mir das mal bei meinen 'Testobjekten' angeschaut. Reines Chaos:
- der Sonoff SNZB-03 nutzt den Cluster
ssIasZone - der Aqara RTCGQ14LM nutzt den Cluster
manufSpecificLumi - der Aqara RTCGQ11LM nutzt den Cluster
msOccupancySensing - der TuYa ZY-M100-24GV3 nutzt den Cluster
manuSpecificTuya - Alle Hue-Kompatiblen Sensoren nutzen
msOccupancySensing
Aber zurück zu Anlernen und Konfiguration:
Im Rahmen des Anlernen bekommt der Adapter mit das ein neues Gerät verfügbar ist. Aus der Definition in den Konvertern (ZHC) ermittelt der Adapter welche Datenpunkte anzulegen sind. Das passiert während der Herdsman (ZH) und das Gerät den Beitritt zum Netz aushandeln. An dieser Stelle wird interessant
- wann das Gerät mit dem Pairing begonnen hat
- wie lange dieses gedauert hat, da das Gerät ja zunächst 'bemerken' muss das ein offenes Netzwerk auf einer bestimmten Frequenz verfügbar ist
- wie lange ein Gerät nach dem erfolgreichen Beitritt zum Netzwerk 'aktiv' bleibt, so das eine Kommunikation in beide Richtungen möglich ist
- wie lange der ZH / der Adapter für den Beitritt und die darauf folgende Konfiguration benötigen.
Je nach dem wie diese Parameter zusammen spielen ist die Konfiguration beim Anlernen sofort erfolgreich oder nicht. Meine Erfahrung ist dabei das bei batterie-betriebenen Geräten bei nur 30-50% der Fälle direkt erfolgreich sind. Leider bekommt der Adapter das zu diesem Zeitpunkt nicht automatisch mit - Es wird zu diesem Zeitpunkt aber nicht automatisch versucht neu zu konfigurieren da dieses im Zweifelsfall ins leere laufen würde (Bei Batteriebetriebenen Geräten - wo es am ehesten benötigt wird - klappt es zumeist nicht weil die Geräte schlafen)
Ab Adapter 3.0.1 gibt es ein relativ erfolgreiches ConfigureOnMessage Protokoll - sprich sobald die Konfiguration durch einen Timeout abgebrochen wurde wird ein Gerät in dieses Protokoll eingetragen. Ein neuer Versuch zu konfigurieren findet statt sobald eine Nachricht vom Gerät empfangen wurde (z.Bsp. LQI). Deswegen gilt ab 3.0.1:
- Erst die Konfiguration anstossen
- Dann den timeout abwarten
- Dann das Gerät wecken.
Auf diesem Wege konnte ich bisher alle (bei mir zum Text vorhandenen) Geräte erfolgreich konfigurieren.
Ich hoffe damit etwas Licht ins Dunkel gebracht zu haben.
A.
-
Hi,
wollte eben eine neue Steckdose anlernen und bekommen stat dem Anlernfenster und einem Countdown nur die folgende Meldung
Error: Failed to touchlinkReset Error: SRSP - AF - interPanCtl after 6000ms at Object.start (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/waitress.ts:67:23) at /opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/znp/znp.ts:252:45 at Queue.execute (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/queue.ts:36:26) at Znp.request (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/znp/znp.ts:245:27) at /opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:983:28 at Queue.execute (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/queue.ts:36:26) at ZStackAdapter.restoreChannelInterPAN (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:982:33) at Touchlink.factoryResetFirst (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/touchlink.ts:139:32) at Controller.touchlinkFactoryResetFirst (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/controller.ts:244:16) at ZigbeeController.touchlinkReset (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:1172:13). undefined Error: Failed to touchlinkReset Error: Touchlink operation already in progress at Touchlink.lock (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/touchlink.ts:21:19) at Touchlink.factoryResetFirst (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/touchlink.ts:107:14) at Controller.touchlinkFactoryResetFirst (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/controller.ts:244:37) at ZigbeeController.touchlinkReset (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:1172:33) at Commands.touchlinkReset (/opt/iobroker/node_modules/iobroker.zigbee/lib/commands.js:243:31) at Commands.onMessage (/opt/iobroker/node_modules/iobroker.zigbee/lib/commands.js:68:34) at Zigbee.<anonymous> (/opt/iobroker/node_modules/iobroker.zigbee/lib/commands.js:20:48) at Zigbee.emit (node:events:530:35) at Zigbee.emit (node:domain:489:12) at change (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/src/lib/adapter/adapter.ts:10953:34). undefined Touchlink reset startedError: Failed to open the network: Error: Cannot execute command, in Inter-PAN mode at ZStackAdapter.checkInterpanLock (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:1192:19) at func (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:333:18) at Queue.execute (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/queue.ts:36:26) at ZStackAdapter.sendZdoInternal (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:428:60) at ZStackAdapter.sendZdo (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:305:27) at ZStackAdapter.permitJoin (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:185:24) at Controller.permitJoin (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/controller.ts:299:32) at ZigbeeController.permitJoin (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:659:33) at Commands.letsPairing (/opt/iobroker/node_modules/iobroker.zigbee/lib/commands.js:217:31) at Commands.onMessage (/opt/iobroker/node_modules/iobroker.zigbee/lib/commands.js:63:34). undefinedSoweit funktioniert noch alles, außer das die neue Steckdose nicht anlernbar ist...
Hatte jemand schon einmal diese Fehlermeldung?
Tobias -
-
@homoran
Das kann ich dir nicht sagen, da mir diese Funktion bis eben unbekannt war. -
@würfel sagte in Probleme mit ZigBee Sensoren:
@homoran
Das kann ich dir nicht sagen, da mir diese Funktion bis eben unbekannt war.ist es ein Ikea Gerät?
die verwenden so etwas z.B.Anmelden nur ganz nahe am Koordinator
-
@würfel das liest sich so als ob du statt das Netz zu öffnen den touchlink Reset Button gedrückt hast.
Du musst die Steckdose noch einmal zurücksetzen und dann das Netzwerk normal öffnen.A.
-
@asgothian
@AlexHaxe
Ich bedanke mich für eure ausführlichen Erläuterungen.
Beim ersten Lesen habe ich nicht alles verstanden, aber ich arbeite daran.
Aber es scheint mir so, dass bei zigbee Kommunikation hinsichtlich Stabilität und Vereinheitlichung noch deutlich Luft nach oben ist.
Gruß Jürgen -
@ünne sagte in Probleme mit ZigBee Sensoren:
Aber es scheint mir so, dass bei zigbee Kommunikation hinsichtlich Stabilität und Vereinheitlichung noch deutlich Luft nach oben ist.
es scheint dir.... aha.. und auf die Aussage kommst du weil ?? 2 Geräte mal eben nicht laufen in einem lass mich mal so ausdrücken "besonderen System"
hier läuft das Netz mit 150 Geräten ohne probleme.. aber ja... manche Geräte sind halt.. bääähhh, vor alem Tuya macht da schmuh.. das heisst aber nicht dass Zigbee allgemein "schrott" ist..
