MQTT / MQTT2 / Xiaomi MQTT

[ripperle]

Hallo Zusammen,

ich bin etwas verwirrt über die verschiedenen MQTT Modulen die aktuell in FHEM verfügbar sind. Das liegt wohl daran, dass hier aktuell fleißig weiterentwickelt wird 

Erst mal hier die Einträge die ich mir bereits angeschaut habe:

MQTT allgemein:
https://wiki.fhem.de/wiki/MQTT_Einf%C3%BChrung
https://wiki.fhem.de/wiki/MQTT#FHEM_und_MQTT
https://wiki.fhem.de/wiki/MQTT2_DEVICE#attrTemplate
https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#attrTemplate_2
https://forum.fhem.de/index.php/topic,94495.0.html
https://forum.fhem.de/index.php/topic,70119.0.html

Speziell für Xiaomi:
https://forum.fhem.de/index.php?topic=84790.0


Folgende Ausgangssituation:

• Angefangen habe ich mit Xiamo Sensoren und dem Xiaomi Modul von R. Neumann (siehe letzter Link oben)
  Das Hat alles super funktioniert und läuft bei mir fleißig. Ich habe daher den gute Mosquitto als Broker, "MQTT" als IO Device und "XiaomiDevice" für die einzelnen Sensoren bzw. für die Bridge
• Ich habe eine Lampe von Aldi gekauft und konnte diese mit zigbee2mqtt pairen (meldt sich als Müller Licht oder sowas).
  In FHEM wurde ein XiaomiDevice per auto create erstellt, was allerdings keine readings o.ä. hat, da das Module nur Xiaomi Geräte unterstützt
• Aus diesem Grund habe ich angefangen zu schauen was es für Module etc. in Fhem gibt (in IO Broker wird die Lampe automatisch angelegt und tut)
• Nach meinem Verständnis wäre das aktuell für mich der "MQTT2_CLIENT" zur Verbindung zum Mosquitto und dann entsprechend MQTT2_DEVICE für die einzelnen Geräte
• Über die anscheinend sehr neuen Funktion der attr templates (siehe auch Verlinkung oben) können nun komfortabel die Gerätespezifischen readings etc. eingerichtet werden

Nun zur Frage(n):

• Ist es in meinem Fall sinnvoll das Xiaomi Modul und MQTT als IO Dev zu löschen und alles mit MQTT2 zu ersetzen?
• Ist der Betrieb von MQTT2 mit dem Xiaomi Modul überhaupt möglich bzw. Sinnvoll?
• Die Funktion der MQTT_GENERIC_BRIDGE habe ich noch gar nicht verstanden 

Wäre toll wenn hier jemand etwas licht ins dunkle bringen würde 
ripperle

[Beta-User]

Das Verständnis, das du da zusammengetragen hast, paßt soweit, vor allem:
Man kann nach meinem Kennstnisstand auf einen mosquitto gleichzeitig mit MQTT und MQTT2_CLIENT zugreifen.

Was spricht also dagegen, die tint erst mal als MQTT2_DEVICE anzulegen? Dann lernst du diese Variante kennen und kannst entscheiden, ob du den Rest auch noch umstellen willst bzw. am Ende dann den Mosquitto noch brauchst?

Im Ergebnis läßt sich vermutlich auch die tint mit dem neumann-"Modul" anlegen, und zur vollständigen Integration@MQTT2_DEVICE einer RGBW gibt es zwar Beispiele, aber die zigbee2mqtt-Variante fehlt noch - das ist aber weder ein Hexenwerk noch sind dafür Anpassungen im Modul oder dem attrTemplate erforderlich. (Am Ende wäre es gut, in letzterer ein full-featured-template zu haben, notwendig ist das aber nicht).

Ich persönlich fand das Zusammenstricken passender JSON-Blobs in Senderichtung in MQTT2_DEVICE sehr viel einfacher als bei MQTT (hatte eine Zeitlang ein eigenes Modul für die Milight-Sidoh-Bridge versucht zu entwickeln - letztlich ging das aber mit MQTT2_DEVICE so derartig problemlos, das ich das bereits nach dem ersten Antesten von MQTT2 komplett eingestampft habe).

MQTT_GENERIC_BRIDGE kann mit beiden IO-Varianten und dient grob gesagt dazu, "nicht-MQTT-Geräte in FHEM" MQTT-fähig zu machen, also z.B. Steckdosen mit einem MQTT-Befehl steuerbar zu machen oder Readings per MQTT für andere HA-Lösungen breitzustellen.

[ripperle]

Das Verständnis, das du da zusammengetragen hast, paßt soweit, vor allem:
Man kann nach meinem Kennstnisstand auf einen mosquitto gleichzeitig mit MQTT und MQTT2_CLIENT zugreifen.

Was spricht also dagegen, die tint erst mal als MQTT2_DEVICE anzulegen? Dann lernst du diese Variante kennen und kannst entscheiden, ob du den Rest auch noch umstellen willst bzw. am Ende dann den Mosquitto noch brauchst?
...

Ok das werde ich mal probieren!
Hier ist die Frage nur, was mit der autorcreate funktion von Xiaomi Modul und MQTT2_CLIENT passiert...
Kann man die autocreate funktion von MQTT bzw. dem Xiaomi Modul abschalten (weis nicht welches Modul die neuen Geräte anlegt)? Sonst würden doch 2 Geräte erstellt oder?

...
Im Ergebnis läßt sich vermutlich auch die tint mit dem neumann-"Modul" anlegen, und zur vollständigen Integration@MQTT2_DEVICE einer RGBW gibt es zwar Beispiele, aber die zigbee2mqtt-Variante fehlt noch - das ist aber weder ein Hexenwerk noch sind dafür Anpassungen im Modul oder dem attrTemplate erforderlich. (Am Ende wäre es gut, in letzterer ein full-featured-template zu haben, notwendig ist das aber nicht).
...

Ja das ist schon klar, dass das irgendwie händisch geht, und das es da Beispiele gibt an denen man sich "orientieren" kann... War nur verwundert, als mein Vater das Gerät in ioBroker ohne weitere Maßnahmen automatisch anlegen konnte. Hätte gedacht, dass das dann in fhem (ich selber benutze nur fhem) ähnlich komfortabel gehen sollte...

...
Ich persönlich fand das Zusammenstricken passender JSON-Blobs in Senderichtung in MQTT2_DEVICE sehr viel einfacher als bei MQTT
...

OK, für jemand der aber eine Lampe vom Aldi kauft, diese einfach in FHEM anbinden will und sonst keine JSON-Blobs zusammenstickt, ist auch das nicht gerade "einfach". 

...
MQTT_GENERIC_BRIDGE kann mit beiden IO-Varianten und dient grob gesagt dazu, "nicht-MQTT-Geräte in FHEM" MQTT-fähig zu machen, also z.B. Steckdosen mit einem MQTT-Befehl steuerbar zu machen oder Readings per MQTT für andere HA-Lösungen breitzustellen.
...

Danke für die Erklärung!   

Werde das auf jedenfall ausprobieren und mein Ergebnis hier mitteilen

Gruß und Danke für die schnelle Antwort!

[Beta-User]

Hier ist die Frage nur, was mit der autorcreate funktion von Xiaomi Modul und MQTT2_CLIENT passiert...

Es sollte auch parallel gehen; solange du nicht ganz exakt gleichzeitig versuchst, beide dann angelegten Geräte zu steuern, sollte das keine Probleme geben (und vermutlich selbst dann nicht)...

Was IoBroker angeht, scheint das schlicht die Lösung zu sein, die auch kkoenk nutzt . Was er rausschickt, ist also durch IoBroker direkt nutzbar, woher die Infos auch im Detail stammen. Für FHEM braucht es eben noch etwas Anpassung, aber mit den templates@MQTT2 ist das idR. kein großes Ding (vermutlich auch nicht mit der Neumann-Lösung, die mich aber mit meinen ersten IKEA-Bulbs auch nicht überzeugt hat).

Welche Lösung für welchen Anwendungfall "besser" ist, ist wohl (teilweise) Ansichtssache und hier auch nicht Gegenstand der Diskussion.

[luke666s]

Mit der Tint kann ich dir leider nicht helfen... mein Aldi hatte keine (mehr)....

Nun zur Frage(n):

• Ist es in meinem Fall sinnvoll das Xiaomi Modul und MQTT als IO Dev zu löschen und alles mit MQTT2 zu ersetzen?

genau so habe ich es gemacht und nicht bereut...

• Ist der Betrieb von MQTT2 mit dem Xiaomi Modul überhaupt möglich bzw. Sinnvoll?

Funzte bei mir... aber mir war die Flexibilität und Unabhängigkeit ohne das Xiaomi Modul dann wichtiger... Und bei der Variante solltest du das Autocreate im MQTT2 aus haben, sonst werden die Devices doppelt angelegt...

• Die Funktion der MQTT_GENERIC_BRIDGE habe ich noch gar nicht verstanden 

Damit bekommst du den MQTT Broker ans Fhem dran. Vorteil mMn gegenüber der alten MQTT_BRIDGE ist Flexibilität und Einfachheit. Aber für mich war der MQTT2_SERVER dann doch das non plus ultra, grad auch weil ich kein Mosquitto etc mehr brauche...

Hoffe das hilft.

[Beta-User]

Damit bekommst du den MQTT Broker ans Fhem dran. Vorteil mMn gegenüber der alten MQTT_BRIDGE ist Flexibilität und Einfachheit. Aber für mich war der MQTT2_SERVER dann doch das non plus ultra, grad auch weil ich kein Mosquitto etc mehr brauche...

Irgendwie finde ich diese Erklärung verwirrend, leider ist nicht an allen Stellen im Wiki bereits alle soweit verlinkt, dass das für Neulinge einfach nachzuvollziehen ist. Daher mal der Versucht, das in Kurzform etwas auch im "historischen" Kontext zu ordnen:

Ursprünglich gab es die offiziellen Module MQTT, MQTT_DEVICE und MQTT_BRIDGE. Die "einfache" Bridge war dazu da, einem einzelnen (anderen) FHEM-Gerät MQTT als Sprache nach außen beizubringen.
Dann hat hexenmeister längere Zeit an der Idee gebastelt, statt einer 1:1 Lösung (also ein FHEM-Gerät+MQTT-Bridge) eine n:1 Lösung zu machen. Das wurde dann irgendwann Anfang des letzten Jahres als offizielles MQTT_GENERIC_BRIDGE-Modul eingecheckt. Alles noch im "klassischen MQTT".

Die beiden ursprünglichen weiteren ("MQTT2") Module MQTT2_SERVER und MQTT2_DEVICE sind dann erst im Sommer von Rudi als Maintainer erstellt und eingecheckt worden. "MQTT2" soll dabei bedeuten: Es handelt sich nicht um ein anderes Protokoll als MQTT, sondern bezieht sich nur auf die "neuen" für das MQTT-Protokoll geschriebenen Module von Rudi.

hexenmeister war dann so freundlich, MQTT_GENERIC_BRIDGE so zu erweitern, dass es auch mit MQTT2_SERVER läuft; das Modul selbst ist intern aber weiter abhängig von einigen Funktionen in 00_MQTT.pm, weswegen man dann eine bestimmte Perl-Lib zusätzlich installieren muß, wenn man sonst nur MQTT2 nutzt. Kurz nach den ersten beiden Modulen kam MQTT2_CLIENT, das Rudi dann dankenswerter Weise zusätzlich erstellt hat für Leute, die lieber mosquitto verwenden wollen, so dass man jetzt auch MQTT2 als FHEM2FHEM-Alternative hat (was hexenmeister mit der Gen-Bridge bereits seit langem so unter MQTT-"alt" betreibt).
Parallel dazu gab es dann die letzten paar Wochen noch die Erweiterung der setExtensions (die auch von vielen anderen Modulen genutzt werden, btw.! Auch von MQTT_DEVICE...) um attrTemplate. Ist eigentlich eine ganz andere Baustelle, aber eben gerade bei MQTT besonders komfortabel, wo vieles über Attribute geregelt wird. Es gibt aber mind. auch eine Testversion von HTTPMOD, die mit attrTemplate zusammenarbeitet. Wer einen hp-Drucker hat, kann's ausprobieren...

Jüngst gab es dann noch Änderungen v.a. im MQTT2-Bereich, die erforderlich waren, damit man MQTT2-IO's und MQTT_GENERIC_BRIDGE besser nebeneinander nutzen kann.

Langer Rede kurzer Sinn: Es ist selbstredend ohne weiteres möglich, MQTT_GENERIC_BRIDGE zusammen mit 00_MQTT.pm als IO-Modul zu betreiben.

Alles andere ist eine Komfortfrage; mir tut es auch _ein_ MQTT2-Server, und die template-Sache fand ich so hilfreich, dass ich mich zum Maintainen habe breitschlagen lassen...

[ripperle]

Also habe ich mich jetzt auch soweit mit dem MQTT2 angefreundet...
Habe auch die Aldi Lampe erfolgreich integrieren können, wobei die usability doch alles andere als intuitiv ist..
Dadurch das die Lampe nach dem anlernen erstmal nichts über mqtt sendet und dadurch auch erstmal keine readings da sind ist sehr verwirrend...
Mir ist klar das dies bedingt ist durch die allgemeine Verwendbarkeit des mqtt2 modules und die speziellen Eigenschaften von zigbee2mqtt (höhere Flexibilität zu Lasten der usability), trotzdem etwas verwirrend als neuling 

Zwischenzeitlich wurden auch die templates erweitert, sodass seit heute auch die L_02c_zigbee2mqtt_colorbulb_rgb zur Verfügung steht 
Konnte davor bei der Aldi Lampe die Farbe nicht setzen und beim einlesen wie der rgb colorpicker funktioniert wurde das template erweitert sodass mir dass erspart wurde...

Werde jetzt auch die xiaomi devices entfernen... Ein paralleler Betrieb mit mqtt2 macht keinen Sinn bzw Mehrwert und man hat Probleme beim autocreate beider Module...

Gruß

[Beta-User]

Dadurch das die Lampe nach dem anlernen erstmal nichts über mqtt sendet und dadurch auch erstmal keine readings da sind ist sehr verwirrend...

Vorab mal Danke für das positive feedback .

Was ich zwischenzeitlich rausgefunden habe: Man kann auch bulbs (und andere Router-Geräte, also im Prinzip alles, was an 230V hängt) dazu überreden, regelmäßig was zu senden, nämlich "online" und "offline" . In der configuration.yaml dazu unter "advanced" den Parameter availability_timeout: nutzen und auf was anderes wie '0' stellen. Bei mir derzeit: '300' (die einfachen ' sind wohl richtig, im Wiki bei zigbee2mqtt.io steht es anders).
Ich habe mir ein notify gebastelt, das mit "event-on-change..." dann "off" setzt, wenn die Dinger auf offline gehen und "on", wenn jemand wieder den Schalter betätigt hat... Noch nicht vollst. ausgetestet, aber prinzipiell gut .