Probleme mit ZigBee Sensoren
-
@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..
-
@ü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!
