zigbee per mqtt und HUEDevice statt MQTT2_DEVICE als client?

[justme1968]

mir ist gerade die frage in den sinn gekommen ob es nicht sinnvoll sein könnte auch bei anbindung per mqtt statt MQTT2_DEVICE ein HUEDevice als client zu verwenden zu können...

das würde die readings und icons vereinheitlichen, die anbindung per sprachassistenten etwas vereinfachen, die auswahl eines templates erübrigen, ...

oer läuft es per MQTT2_DEVICE so gut das es niemand mehr braucht?

[Beta-User]

...stelle ich mir schwierig vor:
- HUEDevice müßte als Client für die MQTT2-IOs gültig werden und dann die Nachrichten dispatchen können (u.a. die JSON-Blobs). Das sollte prinzipiell gehen, aber das erinnert mich an die Diskussion zur MQTT_GENERIC_BRIDGE; da mußte irgendwas aufgebort werden, dass beide Client-Typen gleichzeitig lauschen können, und zum anderen würde man dann im Prinzip den Code aus MQTT2_DEVICE doppeln (denke ich zumindest). Da sehe ich im Moment den Mehrwert nicht so recht...

- Dann müßte HUEDevice wissen, was für eine Type sich da meldet; zigbee2mqtt liefert aber erst mal nur die IEEE-ID, keine weiteren Infos (könnte man händisch überspielen, via Attribu oder so). Erweiterte Infos bekäme man über die map-Daten (wie im anderen Thread eben).

- Was ich mir "einfacher" vorstelle: Der Stick scheint eigentlich nur eine Art Modem zu sein (mit einer anderen Firmware wird wireshark verwendet, um den Datenverkehr zu sniffen). Viel schöner wäre es, das Ding als serielles Interface zu nutzen und auf den Java-Überbau zu verzichten).

Ich schick' dir gerne kostenfrei einen mit der aktuellen firmware geflashten Stick zu (oder notfalls sogar zwei mit beiden firmware-Varianten), wenn du dazu an Bord kämst . (Zu dem Zweck habe ich die rumliegen, bin aber vermutlich nicht Perl-fit genug).

[justme1968]

die 'anderen' interfaces die das HUEDevice modul unterstützt (hue bridge, deconz und tradfri) verwenden auch json. von daher sollte das verstehen der nachrichten nicht so schwierig werden. da  muss meiner Meinung nach nicht viel verdoppelt werden.

fhem kann auch mit einer n:m zuordnung von io und modul umgehen. allerdings muss der anwender eingreifen wenn die zuordnung nicht eindeutig ist. das wäre tatsächlich ein nachteil.


das mit dem direkten ansprechen des io ist aus user sicht sicher einfacher . ich hatte mir das für den deconz schon mal ganz kurz angeschaut als er noch nicht headless lief. allerdings ist die doku nicht vorhanden und da man dann auch low level dinge wie pairing und neue devices einbauen muss rennt man dann immer dem hersteller hinterher.

gerade wenn der stick wirklich 'nur' modem ist steckt in der java software vermutlich einiges an mehr oder weniger low level zigbee handling. das noch mal neu zu machen bringt vermutlich nicht viel.


mal sehen ob es noch mehr meinungen gibt.

[Beta-User]

Das mit n:m-Zuordnung von Device und Modul sollte einfacher sein wie du denkst, da es auch mWn. bei der MQTT_Generic_Bridge so ist, dass die Nachricht auch dann weitergereicht wird, wenn es schon ein "abnehmendes" MQTT2_DEVICE gäbe (deswegen gibt es auch Probleme mit aktiviertem MQTT2_DEVICE-autocreate, wenn man parallel beide Module für ein MQTT2-IO verwendet). Du müßtest "nur" im HUE-Client sehen, ob du was mit (jeder!) MQTT-Nachricht anfängst (aber man könnte z.B. auch einen 2. Server nutzen, um das zu minimieren).

Das mit dem direkten IO ist mit dem CC253x vermutlich einfacher als bei deconz, weil der Quelltext verfügbar (und mAn. relativ gut geordnet) ist - der IO-Teil ist mWn. zigbee-shepherd (bzw. demnächst? https://github.com/Koenkk/zigbee-herdsman), die Umwandlung in Standards macht zigbee-shepherd-converters (?, weiteres Repo da) und zigbee2mqtt übernimmt dann die Umwandlung nach MQTT. Vielleicht reicht es auch, auf dem converters-Code aufzusetzen? (Wäre aber immer noch Java, bäh, aber einen Schritt weiter ).

Leider kann ich da nicht viel mehr liefern als die "graue Theorie", bisher habe ich nicht mal den Initialisierungscode gefunden, um rauszukriegen, was da überhaupt "rausfällt" über die serielle Schnittstelle (außer dem Nebenffekt, dass autocreate das Teil nicht sauber von einem CUL unterscheiden kann ).