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

[Asgothian]

Hallo zusammen,

für eine neue Funktionalität im Zigbee Adapter benötige ich Freiwillige zum Testen. Wie oben beschrieben geht es um etwas was insbesondere bei Bewegungsmeldern, aber auch bei anderen Geräten interessant ist. Mich interessiert in wie weit das

• funktioniert
• von der Nutzung her eingängig ist
• Dem User einen Mehrwert bringt.

Worum geht es dabei:

• in zigbee2mqtt sind in den meisten Gerätebeschreibungen Options angegeben, die dem Gerät mitgegeben werden können.
• Diese Optionen fallen jeweils in eine von 3 Kategorien:

1. Optionen die das Gerät verwaltet - diese können üblicherweise via send_payload an das Gerät geschickt werden, wobei der Wert `{"<option_name>":<option_value>} sein sollte.
2. Optionen die von zigbee2mqtt bei Konfiguration oder intern benutzt werden
3. Optionen die bei der Umwandlung von eingehenden / ausgehenden Nachrichten mitgegeben werden.

Ob eine Option Typ 1 vorliegt lässt sich einfach testen: send_payload mit dem entsprechenden Wert absenden, ins Log schauen.

• Fehlermeldugen das das JSON nicht 'parsed' deuten auf einen Syntaxfehler hin
• Warnmeldungen mit no converter for '...' with key '...' zeigen das diese Option nicht typ 1 ist.

Ob eine Option Typ 2 vorliegt lässt sich so erst einmal nicht heraus finden.

Ob eine Option Typ 3 vorliegt lässt sich ausschliesslich dadurch testen das die Option über das neue UI (siehe unten) eingetragen wurde, und es den gewünschten Effekt bringt.

Da ich nur über eine begrenzte Anzahl von Geräten verfüge bin ich darauf angewiesen das dieses von Nutzern mit anderen Geräten aktiv getestet wird.

Erfolgreich getestet das es prinzipiell funktioniert habe ich es bisher nur mit den Aqara RTCGQ11LM Bewegungsmeldern. Da lässt sich sowohl die occupancy_timeout als auch die `no_occupancy_since' Option nutzen. Wobei auch da mein Test nicht vollständig erfolgreich war, da ich nicht über modifizierte BWM verfüge so das die Nutzung der Option eher sinnlos ist.

Zum test selber:

Warnhinweise

• Installation von Github beinhaltet immer risiken
• Die Version ist deutlich mitteilungsfreudiger als standard beta or stable Versionen
• Es ist eine 3.0 Version - der Haken bei 'Zigbee Netzwerk automatisch starten` ist notwendig, sonst wird die Version nicht durchstarten
• Alle Funktionen der 3.0.0 aus dem latest sind vorhanden - die meisten Kommentare aus dem dazu gehörigen Tester thread bleiben gültig.

Quelle
Installation von Github mit diesem Link: https://github.com/asgothian/ioBroker.zigbee/tarball/3.0.x_RC1

Anleitung

• Gerät zum Testen auswählen.
• passende Gerätekachel umdrehen:
  
• die z2m Gerätebeschreibung öffnen - dazu die Modellbezeichnung clicken - das ist ein (unsichtbarer) Link auf die Modellbeschreibung
• Den Edit Button betätigen (Stift icon, 2. von Rechts) Dann kommt so ein Dialog (bei Geräten ohne Optionen werden keine Optionen angezeigt, es gibt aber den '+' Button um Optionen hinzu zu fügen. Bei Geräten die auch in Gruppen zusammengefasst werden können wird auch noch die Gruppenzuordnung dargestellt - die ist für die Optionen aber nicht relevant.
  
• via + lassen sich Optionen hinzufügen. Option und Wert müssen manuell eingetragen werden - es gibt keinerlei Verifikation ob es eine Option gibt oder nicht
• via - lassen sich die Optionen vor dem Button löschen.
• bei save werden die Optionen gespeichert, bei cancel nicht.

Was passieren muss hängt von Gerät und Option ab. Ich habe jeweils ein zum Test passendes Blockly-Skript erstellt um zu sehen ob die Option wirkt. Bei Optionen die Werte oder Wertebereiche verändern ist das ggf. unnötig - da muss jeder selber sehen.

Ich würde mich freuen wenn möglichst viele Geräte in dieser Form getestet werden - insbesondere bei Funktionen die Leuten fehlen (wie z.Bsp. das mit dem occupancy_timeout bei den BWM.)

Erfahrungen und Fragen bitte in diesem Thread posten.

Hinweis - eine Version mit deutlich weniger Meldungen kommt demnächst ins latest. In wie weit bei dieser Funktion Anpassungen stattfinden hängt vom Feedback ab.

A.

[AlexHaxe]

Ich habe noch nicht verifiziert, ob die Optionen auch tatsächlich irgendwas in den Geräten machen, da muss ich mir mal überlegen, wie ich die einzelnen Optionen teste.

Was aber aufgefallen ist: sobald man einmal Optionen in einer Kachel drin hat, bzw. eine Kachel mit Optionen editiert oder auch nur angeschaut hat, dann tauchen die gleichen Optionen bei allen anderen Kacheln auf, bzw. auf allen Kacheln, die noch keine eigene Optionen gesetzt haben. Das mag ganz praktisch sein, wenn man die gleich x Optionen auf allen Geräten des selben Typs setzen will, wenn man aber ein neues Gerät aufmacht und dort tauchen die Optionen auf, dann ist nicht klar, ob die Optionen dort gesetzt sind, oder ein Überbleibsel der vorherigen Kachel. Lädt man die Adapter Seite neu, dann sind die Kacheln ohne gespeicherte Optionen auch wirklich ohne Optionen. Öffnet man dann eine Kachel mit Optionen, dann werden diese wieder überall angezeigt.

Ich schaue mal meine anderen Geräte durch, um zu sehen, ob diese irgendwelche interessanten Optionen anbieten.

Gesehen habe ich das no_occupancy_since als String übertragen wird, laut https://www.zigbee2mqtt.io/devices/9290030675.html#:~:text=be a number.-,no_occupancy_since,-%3A Sends a message sollte das eine Liste sein, z.B. [10, 60]. Ich konnte noch nicht sehen, ob das auf der Gegenseite trotzdem korrekt interpretiert wird, oder wegen falschen Datentyp ignoriert wird.

[Asgothian]

@alexhaxe Wann hast du installiert ? Ich hab vor 2 Stunden nochmal ein Update geschoben - bitte neu installieren

A.

[Asgothian]

@alexhaxe sagte in Test: Zigbee Adapter 3.0.1 RC1 und Bewegungsmelder:

Ich habe noch nicht verifiziert, ob die Optionen auch tatsächlich irgendwas in den Geräten machen, da muss ich mir mal überlegen, wie ich die einzelnen Optionen teste.

Was aber aufgefallen ist: sobald man einmal Optionen in einer Kachel drin hat, bzw. eine Kachel mit Optionen editiert oder auch nur angeschaut hat, dann tauchen die gleichen Optionen bei allen anderen Kacheln auf, bzw. auf allen Kacheln, die noch keine eigene Optionen gesetzt haben. Das mag ganz praktisch sein, wenn man die gleich x Optionen auf allen Geräten des selben Typs setzen will, wenn man aber ein neues Gerät aufmacht und dort tauchen die Optionen auf, dann ist nicht klar, ob die Optionen dort gesetzt sind, oder ein Überbleibsel der vorherigen Kachel. Lädt man die Adapter Seite neu, dann sind die Kacheln ohne gespeicherte Optionen auch wirklich ohne Optionen. Öffnet man dann eine Kachel mit Optionen, dann werden diese wieder überall angezeigt.

Ich schaue mal meine anderen Geräte durch, um zu sehen, ob diese irgendwelche interessanten Optionen anbieten.

Gesehen habe ich das no_occupancy_since als String übertragen wird, laut https://www.zigbee2mqtt.io/devices/9290030675.html#:~:text=be a number.-,no_occupancy_since,-%3A Sends a message sollte das eine Liste sein, z.B. [10, 60]. Ich konnte noch nicht sehen, ob das auf der Gegenseite trotzdem korrekt interpretiert wird, oder wegen falschen Datentyp ignoriert wird.

Ich hab gerade nochmal ein Update hochgeschoben.

• das Array sollte nicht als String sondern als Array weitergegeben werden.
• ein Fehler beim laden von Options bei Geräten ohne Options hat die fälschlicherweise mit angezeigt. Ist auch behoben.

A.

[AlexHaxe]

Mit der neuen Version wird der Wert [10, 60] zu 10,60.

Und ich bin immer noch nicht sicher, ob die Werte überhaupt was tun. Bei meinem Vallhorn Bewegungssensor von Ikea wiederholt sich die Zeile zigbee.1 (123456) localConfig:getOptions for XXXXX : {"illuminance_raw":true,"identify_timeout":30,"illuminance_calibration":1} im Log. Daraus schließe ich, dass das nicht erfolgreich war und wiederholt wird, bis es klappt?!

Vereinzelt sehe ich auch

2025-04-22 17:48:43.068  - warn: zigbee.0 (123456) collect options for AAAAA:  {}
2025-04-22 17:48:43.069  - warn: zigbee.0 (123456) collect options for AAAAA:  {"brightness":42}

für eine meiner Lampen (selbe ID), immer zwei Meldungen direkt hintereinander (brightness ist der gesetzte Wert, aber ist keine der gelisteten Optionen für dieses Gerät)

[Asgothian]

@alexhaxe sagte in Test: Zigbee Adapter 3.0.1 RC1 und Bewegungsmelder:

Und ich bin immer noch nicht sicher, ob die Werte überhaupt was tun. Bei meinem Vallhorn Bewegungssensor von Ikea wiederholt sich die Zeile zigbee.1 (123456) localConfig:getOptions for XXXXX : {"illuminance_raw":true,"identify_timeout":30,"illuminance_calibration":1} im Log. Daraus schließe ich, dass das nicht erfolgreich war und wiederholt wird, bis es klappt?!

Vereinzelt sehe ich auch

2025-04-22 17:48:43.068  - warn: zigbee.0 (123456) collect options for AAAAA:  {}
2025-04-22 17:48:43.069  - warn: zigbee.0 (123456) collect options for AAAAA:  {"brightness":42}

für eine meiner Lampen (selbe ID), immer zwei Meldungen direkt hintereinander (brightness ist der gesetzte Wert, aber ist keine der gelisteten Optionen für dieses Gerät)

Nein, das hat mit erfolg / Misserfolg nichts zu tun - es gibt mehrere Gründe warum es options gibt. Sprich die Einträge für 'options' sind in dem Fall normal.

A.

[AlexHaxe]

Bislang habe ich nur Optionen gefunden, für die kein Converter vorliegt (z.B. No converter available for 'E2134' with key 'illuminance_raw' ). Und wenn ich über die Optionen illuminance_raw: false setze, dann wird weiterhin illuminance_raw gemeldet / aktualisiert. Es kann natürlich sein, dass ich die Beschreibung der Option auf https://www.zigbee2mqtt.io/devices/E2134.html falsch interpretiere.

[Asgothian]

@alexhaxe sagte in Test: Zigbee Adapter 3.0.1 RC1 und Bewegungsmelder:

Und wenn ich über die Optionen illuminance_raw: false setze, dann wird weiterhin illuminance_raw gemeldet / aktualisiert. Es kann natürlich sein, dass ich die Beschreibung der Option auf https://www.zigbee2mqtt.io/devices/E2134.html falsch interpretiere.

Dieses ist ein Beispiel für eine Option die vom Typ 2 ist, da sie die Exposes anpasst. Diese kann also nicht beim Empfang von Nachrichten via Zigbee genutzt werden.

A.