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 -
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 -
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 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. -
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 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.
-
@
ü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.@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 -
@
ü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.
@asgothian
Ja, sowohl die beiden PanID's als auch der Kanal ist anders.
Jürgen -
@
ünne da braucht es definitiv wesentlich mehr Informationen!Schuss ins Blaue:
die BWM sind noch im alten Netz registriert -
@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 -
@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@
ü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). -
@
ü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ät 0x0c2a6ffffe458de9, Endpunkt 2 und0x84b4dbfffebc5e02, Endpunkt 1 vorzunehmen, und zwar für den Cluster msOccupancySensing- 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.
-
@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ät 0x0c2a6ffffe458de9, Endpunkt 2 und0x84b4dbfffebc5e02, Endpunkt 1 vorzunehmen, und zwar für den Cluster msOccupancySensing- 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 -
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 -
@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
-
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 -
@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ät 0x0c2a6ffffe458de9, Endpunkt 2 und0x84b4dbfffebc5e02, Endpunkt 1 vorzunehmen, und zwar für den Cluster msOccupancySensing- 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.
@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 -
@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.. -
@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:@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ürgenBeim Thema Stabilit
ät kann ich das so nicht bestätigen. Zigbee Netze die sauber aufgebaut sind (hinreichend Router, gute Mesh-Abdeckung, wenig 2.4GHz Störsender sind extrem stabil und energie-effizient.Beim Thema Vereinheitlichung sind letztendlich die Kunden gefragt. So lange wie eher eine 10 Euro Steckdose mit propriet
ärem, an Zigbee angelehnten Protokoll gekauft wird als eine 15 Euro Steckdose die sich an die im Zigbee zur Interoperabilität definierten Regeln hält wird das nichts mit Vereinheitlichung. Es gibt keinen rein technischen Grund dafür, nicht die in der Spezifikation definierten Cluster zu nutzen. Es gibt aber wirtschaftliche Gründe dafür, das ggf. nicht (immer) zu tun.Das gleiche bei Lampen. Sensoren, etc. Alle beschweren sich dar
über das die Philips Hue Leuchten so teuer sind. Da kauft man lieber die 5 Euro China Leuchten, bei denen die Farbwidergabe zufall ist, und die nur via RGB und nicht via HSV angesprochen werden können.Fun fact: Man nehme 20 Leuchten, 10x Philips, 10x random Tuya. Man stelle bei allen R40 G10 B100 als Farbe ein. Dann hat man mindestens 2 unterschiedliche Farben bei den Leuchten - wenn nicht sogar 11. Wenn man (so sie das unterst
ützen) Hue 30, Saturation 100, Value 100 einstellt dann sind es fast sicher 11 unterschiedliche Farben.Bei den Hue Leuchten gilt die Gleichheit der Farbdarstellung sogar
über die eigentlichen Leuchtmittel hinweg, sprich unterschiedliche Hue Lampen liefern bei gleichen Einstellungen zumeist die gleiche Farbe./Exkursion ende
Zur
ück zum Thema Vereinheitlichung - die Hersteller sind prinzipiell nicht daran interessiert das ein Standard 100% Interoperabilität bietet, weil damit die Kunden nicht an das eigene Ecosystem gebunden werden. Das gilt für Tuya genauso wie für Lumi (Aqara) oder Philips.Das sich
überhaupt Geräte streng an die Vorgaben halten liegt daran das die 'kleinen' Hersteller gerne ihre Geräte im Eco-System der grossen Hersteller einsetzen wollen (Kompatibel mit Hue). Das gilt aber nur so lange wie es wirklich 'kleine' Hersteller sind. So ist der BWM RTCGQ14LM ein Nachfolgemodell von RTCGQ11LM.Und die meisten Hersteller die TuYa als Ecosytstem nutzen setzen auf die dazu geh
örende Bridge / App Lösung.A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@
ünne sagte in Probleme mit ZigBee Sensoren:@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ürgenBeim Thema Stabilit
ät kann ich das so nicht bestätigen. Zigbee Netze die sauber aufgebaut sind (hinreichend Router, gute Mesh-Abdeckung, wenig 2.4GHz Störsender sind extrem stabil und energie-effizient.Beim Thema Vereinheitlichung sind letztendlich die Kunden gefragt. So lange wie eher eine 10 Euro Steckdose mit propriet
ärem, an Zigbee angelehnten Protokoll gekauft wird als eine 15 Euro Steckdose die sich an die im Zigbee zur Interoperabilität definierten Regeln hält wird das nichts mit Vereinheitlichung. Es gibt keinen rein technischen Grund dafür, nicht die in der Spezifikation definierten Cluster zu nutzen. Es gibt aber wirtschaftliche Gründe dafür, das ggf. nicht (immer) zu tun.Das gleiche bei Lampen. Sensoren, etc. Alle beschweren sich dar
über das die Philips Hue Leuchten so teuer sind. Da kauft man lieber die 5 Euro China Leuchten, bei denen die Farbwidergabe zufall ist, und die nur via RGB und nicht via HSV angesprochen werden können.Fun fact: Man nehme 20 Leuchten, 10x Philips, 10x random Tuya. Man stelle bei allen R40 G10 B100 als Farbe ein. Dann hat man mindestens 2 unterschiedliche Farben bei den Leuchten - wenn nicht sogar 11. Wenn man (so sie das unterst
ützen) Hue 30, Saturation 100, Value 100 einstellt dann sind es fast sicher 11 unterschiedliche Farben.Bei den Hue Leuchten gilt die Gleichheit der Farbdarstellung sogar
über die eigentlichen Leuchtmittel hinweg, sprich unterschiedliche Hue Lampen liefern bei gleichen Einstellungen zumeist die gleiche Farbe./Exkursion ende
Zur
ück zum Thema Vereinheitlichung - die Hersteller sind prinzipiell nicht daran interessiert das ein Standard 100% Interoperabilität bietet, weil damit die Kunden nicht an das eigene Ecosystem gebunden werden. Das gilt für Tuya genauso wie für Lumi (Aqara) oder Philips.Das sich
überhaupt Geräte streng an die Vorgaben halten liegt daran das die 'kleinen' Hersteller gerne ihre Geräte im Eco-System der grossen Hersteller einsetzen wollen (Kompatibel mit Hue). Das gilt aber nur so lange wie es wirklich 'kleine' Hersteller sind. So ist der BWM RTCGQ14LM ein Nachfolgemodell von RTCGQ11LM.Und die meisten Hersteller die TuYa als Ecosytstem nutzen setzen auf die dazu geh
örende Bridge / App Lösung.A.
Standards sind sch
ön. Es sollte jeder einen eigenen haben! 
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden478
Online32.7k
Benutzer82.6k
Themen1.3m
Beiträge