Hallo zusammen,
nachdem ich gestern meine ersten Gehversuche mit den neuen MQTT2-Modulen von Rudi gemacht habe, hier die Vorwarnung:
Ich werde vermutlich die Milights@sidoh-briodge auf MQTT2 umstellen und daher selbst das
Modul hier mittelfristig nicht mehr nutzen und daher auch
nicht weiterentwickeln.
Zwar ist mir manches im Detail noch unklar, es scheint aber ungleich einfacher, die Konfiguration darüber zu machen.
Motivation:- Generische Unterstützung, keine externe Serverkomponente (mosquitto uä.) erforderlich =>
sehr viel einsteigerfreundlicher, jeder der nur wenige MQTT-Komponenten wie z.B. die Bridge hat, kann sofort loslegen und sein FHEM unabhängig von externer Software halten
. (Das ist keine Kritik an Mosquitto, der läuft wie eine 1; es sind nur sehr viel weniger Schritte, und alle innerhalb FHEM).
- kein Pflegeaufwand für ein eigenes Modul. Da MQTT2 von Rudi kommt, dürfte die langfristige Verfügbarkeit außer Frage stehen, von seiner ungleich größeren Kompetenz beim Lösen evtl. aufretender Probleme will ich garn nicht reden
. Außerdem dürfte setExtensions schon eingebaut sein
.
- autocreate möglich, alle JSON-Readings werden direkt angelegt (ein Punkt, der vermutlich für mich ähnlich viel Aufwand bedeutet hätte wie der Wechsel zu MQTT2)
Erste Feststellungen:- Alle Readings landen via autocreate in einem "Großdevice", bei MQTT2 scheint erst mal jede IP als eigener Client zu gelten. Das irritiert etwas im Zusammenhang mit einem Gerät wie der Bridge, die eigentlich nur ein IO für mehrere physische Geräte ist.
- Das Aufteilen in mehrere FHEM-Devices scheint aber kein Problem zu sein, man legt einfach für jede Bulb ein weiteres MQTT2_DEVICE an und kopiert den entsprechenden Subset aus dem Großdevice, dann werden - so jedenfalls mein erster Test - beide Geräte aktualisiert, wenn man über die Web-Schnittstelle der Bridge schaltet (für FB's müßte dasselbe gelten).
- Irritiert hat mich, dass da im Device irgendwie noch eine Nummer (der Verbindung?) mit drin ist, deren Herkunft mir nicht so klar ist (und vor allem, ob das Neustarts usw. überlebt...). Hätte erwartet, dass es nur mit einer IP-Angabe gehen sollte. Das dürfte aber klärbar sein.
- Schalten gelang mir noch nicht, da muß ich mich erst eindenken, wie das mit dem Zusammenbauen des JSON gehen soll. Wenn jemand Erfahrung oder eine Idee hat: her damit... (Eigentlich müßte auch das mit Bordmitteln - "{toJSON(??)}" - gehen; das sieht eigentlich auch kaum anders aus als die Sendefunktion im bisherigen Modul).
Ausblick:Im Prinzip war das "alte" Modul nur eine Hilfestellung zum Anlegen passender Attribute, zum Zusammensetzen des Sendestrings als JSON und (bislang nur rudimentär) ein Hilfsmittel für devStateIcon.
Fazit: Das meiste kann man auch auf anderem Wege haben, wie geschildert sogar (viel?) einfacher als bisher...
Zu gegebener Zeit liefere ich auch gerne meine Erkenntnisse zu den passenden Vorgaben und ggf. Code für myUtils-Routinen für das dynamische Icon; da gibt es aber auch schon einiges in color.pm, ggf. fehlt nur ein passendes userreading für RGB (da liefert nach meinem Eindruck aber die Bridge für meine RGBW-Devices keine brauchbaren Infos...).
Wer in diese Richtung mitdenken/testen will: Willkommen!
Bei Gelegenheit wird es dazu dann einen separaten Thread geben.
Vorab schon mal Danke für euer Verständnis,
Beta-User
