NEWS
Ikea SOMRIG wird nicht unterstützt?
-
Inzwischen habe ich auf iobroker.zigbee Version 3.0.0 aktualisiert. Keine Veränderung, auch nicht nach einem erneuten Pairing.
Um beim Testen und der Fehlersuche noch einen Schritt weiterzugehen, habe ich jetzt eine lokale Instanz von iobroker laufen. Sie hat nichts mit der Live-Version zu tun und läuft auf dem selben Rechner wie zigbee2mqtt und sie wurde frisch installiert (mit beta Repositories und ebenfalls iobroker.zigbee 3.0.0).
Das Ergebnis ist das gleiche wie vorher. iobroker.zigbee kann den Button pairen, aber nurlink_qualityundavailablewerden gemeldet / aktualisiert. zigbee2mqtt volles Programm, alle Events und Buttons werden gemeldet.
Ich habe den selben Sonoff Zigbee Stick für beides verwendet, die iobroker Installation ist ansonsten unverändert (keine eigenmächtigen NPM Pakete eingespielt).Entweder stelle ich mich beim Einrichten und Betreiben des Systems zu doof an, oder es gibt einen Bug der verhindert, dass der Zigbee-Adapter die Geräte korrekt unterstützt.
Welche Debug-Möglichkeiten gibt es, um herauszufinden wo der Bug sitzt? Gibt es eine einfache Möglichkeit den Netzwerk-Verkehr mitzuschneiden, damit man zwischen zigbee2mqtt und iobroker.zigbee vergleichen kann, und schauen kann was letzterer nicht sendet / verarbeitet? -
Inzwischen habe ich auf iobroker.zigbee Version 3.0.0 aktualisiert. Keine Veränderung, auch nicht nach einem erneuten Pairing.
Um beim Testen und der Fehlersuche noch einen Schritt weiterzugehen, habe ich jetzt eine lokale Instanz von iobroker laufen. Sie hat nichts mit der Live-Version zu tun und läuft auf dem selben Rechner wie zigbee2mqtt und sie wurde frisch installiert (mit beta Repositories und ebenfalls iobroker.zigbee 3.0.0).
Das Ergebnis ist das gleiche wie vorher. iobroker.zigbee kann den Button pairen, aber nurlink_qualityundavailablewerden gemeldet / aktualisiert. zigbee2mqtt volles Programm, alle Events und Buttons werden gemeldet.
Ich habe den selben Sonoff Zigbee Stick für beides verwendet, die iobroker Installation ist ansonsten unverändert (keine eigenmächtigen NPM Pakete eingespielt).Entweder stelle ich mich beim Einrichten und Betreiben des Systems zu doof an, oder es gibt einen Bug der verhindert, dass der Zigbee-Adapter die Geräte korrekt unterstützt.
Welche Debug-Möglichkeiten gibt es, um herauszufinden wo der Bug sitzt? Gibt es eine einfache Möglichkeit den Netzwerk-Verkehr mitzuschneiden, damit man zwischen zigbee2mqtt und iobroker.zigbee vergleichen kann, und schauen kann was letzterer nicht sendet / verarbeitet? -
@alexhaxe bitte verifiziere welche ZHC / ZH Versionen von zigbee2mqtt.io genutzt werden. Die Kommunikation mit zigbee läuft in beiden Systemen identisch - sofern die gleichen Code-Versionen genutzt werden.
A.
@asgothian
iobroker (npm list -a |grep zigbee) :└─┬ iobroker.zigbee@3.0.0 ├─┬ zigbee-herdsman-converters@23.24.0 │ └── zigbee-herdsman@3.5.1 deduped └─┬ zigbee-herdsman@3.5.1 └── zigbee-on-host@0.1.10zigbee2mqtt:
zigbee2mqtt@2.1.3 /opt/zigbee2mqtt ├─┬ zigbee-herdsman-converters@23.13.0 │ └── zigbee-herdsman@3.4.8 deduped ├─┬ zigbee-herdsman@3.4.8 │ └── zigbee-on-host@0.1.9 └── zigbee2mqtt-frontend@0.9.4Die libs im iobroker sind Dank der 3.0.0 und der Neuinstallation neuer, aber ich kann nachher mal zigbee2mqtt auf den gleichen Stand bringen, um zu schauen ob es sich besinnt und aufhört zu funktionieren.
Irgendwo muss es einen Unterschied geben, der dafür sorgt, dass die Nachrichten der Buttons entweder nicht ankommen, nicht verarbeitet werden, oder der die Buttons so initialisiert, dass diese der Meinung sind keine Nachrichten außer
link_qualitysenden zu müssen.Andere Gerätschaften, wie z.B. die Parasoll Türsensoren funktionieren in beiden Systemen.
Wobei auch die Parasolls nicht ohne Probleme sind: Normalerweise senden diese alle 10 Minuten ein Update. Alle paar Tage bekommen sie einen Rappel und senden Updates alle 10-20 Sekunden. Meist sind sie dann auch nicht mehr wirklich funktionsbereit, sprich sie melden das Öffnen / Schließen der Kontake nicht mehr weiter. Batterie entfernen und wieder einsetzen (kein Batterietausch), also sprich ein Reboot des Geräts löst das Problem. Ich schätze wenn man diesen Zustand zu lange ohne Power-Cycle laufen lässt, wird Ratz-Fatz die Batterie leer. Zur Batterie-Leer-Problematik der Parasolls finden sich ja bereits einige Posts im Internet, der Konsenz ist Akkus zu nehmen. Aber selbst mit Akkus hat man das beschriebene Verhalten, allerdings halten die Akkus trotzdem mehrere Wochen durch, sofern man rechtzeitig die Reboots durchführt. Ein Gegentest mit Nicht-Akkus und regelmäßigen Reboots habe ich noch nicht angestellt, von daher ist unklar, ob Akkus wirklich helfen die Problematik zu entschärfen, oder ob es die Reboots beim Auftreten der Anomalie sind. Glücklicherweise habe ich ein Skript, dass mir Benachrichtigungen schickt, wenn die Geräte in diesen Modus verfallen.
Ich muss mal einen Langzeittest mit zigbee2mqtt anstellen, um zu sehen, ob dieses Verhalten dort ebenfalls auftritt. Könnte also gut sein, dass diese Thematik völlig losgelöst von den Somrigs ist, auch wenn beide vom selben Hersteller stammen. Immerhin verrichten die Parasolls ihre Arbeit - zumindest bis zum Eintreten der beschriebenen Problematik, während Somrigs im iobroker gar keine Anstalten machen. -
Nach weiteren Tests und der flüchtigen Überlegung meine Zigbee Netzwerke zu zigbee2mqtt zu migrieren, habe ich gestern nochmal genauer die beiden Sourcen verglichen (sprich Source-Code von iobroker.zigbee und zigbee2mqtt).
Dabei fiel mir auf, dass iobroker.zigbee bei einem der beidenconfigureAufrufe als dritten Parameter einthisübergibt, statt der Geräte-Konfiguration /-Mapping. Das erschien nicht nur komisch, es erweist sich auch als Quelle für die FehlermeldungFailed to configure. --> definition.endpoint is not a function. Übergibt man hiermappedDevice(wie dies auch im zigbee2mqtt unter anderem Namen der Fall ist) klappt das plötzlich mit dem Konfigurieren. Ich muss zwar trotzdem einmal die Batterie entfernen und wieder einsetzen, damit die Konfiguration nach Timeout sofort durchgeführt wird, aber danach werden die Button-Ereignisse anstandslos im Objektbaum wiedergegeben.Sobald sich jemand findet, der https://github.com/ioBroker/ioBroker.zigbee/pull/2463 merged und als neue Version veröffentlicht (oder sich eine bessere Lösung ausdenkt), kann der Thread meiner Meinung nach als gelöst markiert werden.
-
Nach weiteren Tests und der flüchtigen Überlegung meine Zigbee Netzwerke zu zigbee2mqtt zu migrieren, habe ich gestern nochmal genauer die beiden Sourcen verglichen (sprich Source-Code von iobroker.zigbee und zigbee2mqtt).
Dabei fiel mir auf, dass iobroker.zigbee bei einem der beidenconfigureAufrufe als dritten Parameter einthisübergibt, statt der Geräte-Konfiguration /-Mapping. Das erschien nicht nur komisch, es erweist sich auch als Quelle für die FehlermeldungFailed to configure. --> definition.endpoint is not a function. Übergibt man hiermappedDevice(wie dies auch im zigbee2mqtt unter anderem Namen der Fall ist) klappt das plötzlich mit dem Konfigurieren. Ich muss zwar trotzdem einmal die Batterie entfernen und wieder einsetzen, damit die Konfiguration nach Timeout sofort durchgeführt wird, aber danach werden die Button-Ereignisse anstandslos im Objektbaum wiedergegeben.Sobald sich jemand findet, der https://github.com/ioBroker/ioBroker.zigbee/pull/2463 merged und als neue Version veröffentlicht (oder sich eine bessere Lösung ausdenkt), kann der Thread meiner Meinung nach als gelöst markiert werden.
@alexhaxe PR ist gemerged. Danke dafür das du das ausgebuddelt hast. Ohne Deine Hilfe hätte ich das nicht gefunden da der Fehler bei mir nicht aufgetreten ist.
Eine neue Version fürs Latest ist in Vorbereitung - wird noch ein paar tage dauern, aber die GitHub Version sollte den Fehler nicht mehr zeigen .
A.
-
@alexhaxe PR ist gemerged. Danke dafür das du das ausgebuddelt hast. Ohne Deine Hilfe hätte ich das nicht gefunden da der Fehler bei mir nicht aufgetreten ist.
Eine neue Version fürs Latest ist in Vorbereitung - wird noch ein paar tage dauern, aber die GitHub Version sollte den Fehler nicht mehr zeigen .
A.
@asgothian said in Ikea SOMRIG wird nicht unterstützt?:
Ohne Deine Hilfe hätte ich das nicht gefunden da der Fehler bei mir nicht aufgetreten ist.
Der Fehler lässt sich mit der alten Version sehr einfach reproduzieren:
- In der Kachel eines SOMRIG Geräts eine manuelle Rekonfiguration auslösen.
- Nichts am Gerät drücken, und auf den Timeout in der Oberfläche / Log warten.
- Dann Batteriefach öffnen, und Batterie kurz raus und wieder rein.
- Gerät announced sich, und die Rekonfiguration wird versucht.
- In der Log-Datei wird man dann ein
DeviceConfigure:0xAAAAA SOMRIG shortcut button Failed to configure. --> definition.endpoint is not a functionvorfinden.
-
@asgothian said in Ikea SOMRIG wird nicht unterstützt?:
Ohne Deine Hilfe hätte ich das nicht gefunden da der Fehler bei mir nicht aufgetreten ist.
Der Fehler lässt sich mit der alten Version sehr einfach reproduzieren:
- In der Kachel eines SOMRIG Geräts eine manuelle Rekonfiguration auslösen.
- Nichts am Gerät drücken, und auf den Timeout in der Oberfläche / Log warten.
- Dann Batteriefach öffnen, und Batterie kurz raus und wieder rein.
- Gerät announced sich, und die Rekonfiguration wird versucht.
- In der Log-Datei wird man dann ein
DeviceConfigure:0xAAAAA SOMRIG shortcut button Failed to configure. --> definition.endpoint is not a functionvorfinden.
@alexhaxe sagte in Ikea SOMRIG wird nicht unterstützt?:
Der Fehler lässt sich mit der alten Version sehr einfach reproduzieren:
Leider nein - ich hab keinen Somrig. Nur ähnliche Ikea Knöpfe. Sprich ich kann das gar nicht verifizieren.
A.
Nachtrag - bei allen meinen Geräten funktioniert der Aufruf so wie er vorher im Code war. Auch von Anderen habe ich keine entsprechenden Fehlermeldungen bekommen. Daher meine initiale Skepsis.
-
@rissn hast du mit der 1.10.5 von Github getestet ob der Bug da immer noch existiert ?
Ich hab mehrere Somrig und kann das Problem nicht nachstellen.
A.
@asgothian said in Ikea SOMRIG wird nicht unterstützt?:
Ich hab mehrere Somrig und kann das Problem nicht nachstellen.
Sorry, ich bin fälschlicherweise davon ausgegangen, dass dies noch zutrifft.
Ich habe den Eindruck, dass sich die verschiedenen Geräte-Typen des Herstellers teilweise sehr unterschiedlich verhalten. Die Bewegungsmelder unterscheiden sich von den Türsensoren, und die SOMRIGs sind dann nochmal anders, vermutlich aufgrund anderer Parameter in der jeweiligen Firmware. Der Grund, warum SOMRIG in den Fehler läuft, könnte z.B. auch am Converter liegen. Was erklärt, warum andere Schalter/Taster, selbst vom selben Hersteller, eben nicht unbedingt das selbe Verhalten und die selben Probleme produzieren muss.
Ich habe etliche verschiedene Geräte von unterschiedlichen Herstellern, in vielen Fällen sogar unterschiedliche Hersteller für ein und dieselbe Geräteklasse, und keines hat Probleme wie die SOMRIGs gemacht. Ein Gerät, welches eigentlich als unterstützt gilt, dass sich aber einfach nicht korrekt einbinden lässt. Das Problem war also stark auf SOMRIG eingegrenzt, wobei es sicherlich mehr Geräte geben kann, die auf die gleiche Weise fehlschlagen.Ich habe keine Untersuchung von iobroker.zigbee 1.x durchgeführt, kann also nicht sagen, warum es damals auch schon fehlschlug. Aber damals habe ich dann zunächst aufgegeben und die Sache zur Seite gelegt und nicht weiter verfolgt. Da wir inzwischen bei 3.x sind und es nun einen Fix für diese Version gibt, ist da auch nicht weiter relevant.
-
@asgothian said in Ikea SOMRIG wird nicht unterstützt?:
Ich hab mehrere Somrig und kann das Problem nicht nachstellen.
Sorry, ich bin fälschlicherweise davon ausgegangen, dass dies noch zutrifft.
Ich habe den Eindruck, dass sich die verschiedenen Geräte-Typen des Herstellers teilweise sehr unterschiedlich verhalten. Die Bewegungsmelder unterscheiden sich von den Türsensoren, und die SOMRIGs sind dann nochmal anders, vermutlich aufgrund anderer Parameter in der jeweiligen Firmware. Der Grund, warum SOMRIG in den Fehler läuft, könnte z.B. auch am Converter liegen. Was erklärt, warum andere Schalter/Taster, selbst vom selben Hersteller, eben nicht unbedingt das selbe Verhalten und die selben Probleme produzieren muss.
Ich habe etliche verschiedene Geräte von unterschiedlichen Herstellern, in vielen Fällen sogar unterschiedliche Hersteller für ein und dieselbe Geräteklasse, und keines hat Probleme wie die SOMRIGs gemacht. Ein Gerät, welches eigentlich als unterstützt gilt, dass sich aber einfach nicht korrekt einbinden lässt. Das Problem war also stark auf SOMRIG eingegrenzt, wobei es sicherlich mehr Geräte geben kann, die auf die gleiche Weise fehlschlagen.Ich habe keine Untersuchung von iobroker.zigbee 1.x durchgeführt, kann also nicht sagen, warum es damals auch schon fehlschlug. Aber damals habe ich dann zunächst aufgegeben und die Sache zur Seite gelegt und nicht weiter verfolgt. Da wir inzwischen bei 3.x sind und es nun einen Fix für diese Version gibt, ist da auch nicht weiter relevant.
@alexhaxe sagte in Ikea SOMRIG wird nicht unterstützt?:
@asgothian said in Ikea SOMRIG wird nicht unterstützt?:
Ich hab mehrere Somrig und kann das Problem nicht nachstellen.
Ich habe keine Untersuchung von iobroker.zigbee 1.x durchgeführt, kann also nicht sagen, warum es damals auch schon fehlschlug. Aber damals habe ich dann zunächst aufgegeben und die Sache zur Seite gelegt und nicht weiter verfolgt. Da wir inzwischen bei 3.x sind und es nun einen Fix für diese Version gibt, ist da auch nicht weiter relevant.
Zumindest die Frage kann ich beantworten. Der Configue Code ist recht alt - das heisst innerhalb der 1.x hat das ganze solange funktioniert bis im ZHC oder ZH etwas umgestellt wurde. Das passiert regelmäßig, und wird nicht immer so kommuniziert das wir unseren Code proaktiv anpassen können. Nur bei ‘großen’ Anpassungen bekommt man das manchmal mit. So hab ich beim Wechsel 1.10.3 zu 1.10.14 ca. 4 Wochen gebraucht auf entsprechende Änderungen in ZH und ZHC zu reagieren. Auch da konnte ich das nur gegen bei mir vorhandene Hardware verifizieren.
Im Bezug auf das configure wurde da einiges umgestellt, insbesondere auch was die Häufigkeit und Nutzung angeht, so das das nur scheibchenweise ans Licht kam. Alle die Geräte mit 1.10.3 angelernt und konfiguriert hatten konnten diese weiter nutzen, es wegen das erst spät überhaupt aufgefallen ist. Aus der Zeit stammt z.bsp die Trennung zwischen ‘function’ und ‘Array of promises’ I’m configure code - Weil letzteres ‘Mal eben’ ohne weitere Info in den Konvertern auftauchte.
Am Ende bleibt was ich weiter oben geschrieben habe: Vielen Dank für die Zeit, die Beharrlichkeit und den Aufwand den du in die Analyse gesteckt hast. Hätte das wer anders gekonnt - bestimmt. Hätte ich das gekonnt - vielleicht. Mir wären ggf. Die Unterschiede im code aufgefallen - die Relevanz hätte ich aber nicht verifizierten können.
Als Entwickler eines hardwarenahen Adapters mit Nutzung einer externen Bibliothek bin ich genau auf diese Art von Hilfe angewiesen.
Nebenbei wirst du im changelog des Adapters Deinen GitHub Usernamen finden - das gehört sich so.
A.