MQTT2_SERVER und MQTT2_DEVICE

Martin Fischer · 05 November 2018, 23:47:36

Hallo Zusammen,

aus diversen Gründen, die hier nicht relevant sind, habe ich mich erst seit kurzem mit MQTT und FHEM beschäftigt.

Derzeit verbinde ich neben FHEM2FHEM mehrere FHEM Instanzen via MQTT_BRIDGE, MQTT_DEVICE und den obligatorischen Mosquitto als Broker über zwei ansonsten getrennte Netzwerke. Das klappt auch super. Was mich daran jedoch stört, das man für jedes bestehendes Device in FHEM ein MQTT_BRIDGE Device erstellen muss.

Da Rudi nun mit MQTT2_SERVER eine Lösung anbietet ohne externen Broker zu arbeiten und mittels MQTT2_DEVICE externe Geräte in FHEM einbindet, wäre es doch super, wenn nun jedes bereits vorhandene und beliebige FHEM Device zu einem MQTT fähigen Device via Attribut erweitert werden könnte. Die heute bereits erzeugten Events werden dann zusätzlich über den FHEM eigenen Broker versendet und durch. Die ggf. (notwendigen) Attribute entsprächen dann wohl denen vom MQTT_BRIDGE Device.

Diese Erweiterung würde dann zwar vermutlich und bedauerlicherweise die Daseinsberechtigung von MQTT_BRIDGE und MQTT_DEVICE in Frage stellen, sofern ich das richtig Überblicke (siehe Einleitung... noch nicht tief im Thema!). Aber man hätte dann eine "moderne" Form auch FHEM Instanzen untereinander eleganter als via FHEM2FHEM zu verbinden. Und vorallem würde dann das Anlegen von doppelten Devices entfallen.

Oder habe ich etwas übersehen und es geht heute bereits schon?

Viele Grüße
Martin

Beta-User · 06 November 2018, 00:11:39

So wie ich das verstanden habe, kann das die Generic_Bridge mit klassischem MQTT. Der Haupt-Vorteil liegt dabei darin, dass der Broker sich nicht die Ressourcen mit FHEM teilen muss.
Ob es in wirklich verteilten Setups lohnt, mosquitto einzusparen? M.E. eher nicht... Zur Klarstellung: Für meinen eigenen Anwendungsfall bin ich sehr froh, mit MQTT2 keinen externen broker mehr zu benötigen.
Andererseits würde es nicht schaden, wenn es eine generic bridge auch für mqtt2 gäbe...

Martin Fischer · 06 November 2018, 01:53:23

Ja, in der Tat... ich bin gerade eben über MQTT_GENERIC_BRIDGE gestolpert. Das kommt meinem Vorschlag schon sehr nahe.

hexenmeister · 06 November 2018, 05:55:09

So in der Art war auch meine Überlegung, als ich die GenericBrigde ins Leben gerufen habe. Hast du dazu noch Ideen oder Verbesserungsvorschläge?

Ich selbst sehe wenig bis gar keine Gründe, in einer single threaded Anwendung einen mqtt Server zu implementieren, dennoch habe ich darüber nachgedacht, mqtt2 Unterstützung einzubauen. Steht jedoch ganz unten in der Prioritätenliste.

Mir macht eher Sorgen, dass manche bestehende mqtt-client-module auf mqtt2 umgestellt werden und die alte mqtt Kompatibilität aufgeben. Dann bleiben die Nutzer in der mqtt2 Welt 'eingesperrt'. Das wäre für mich der Grund, keine mqtt2 Unterstützung in die GenericBrigde einzubauen um das nicht weiter zu befördern.

Beta-User · 06 November 2018, 07:04:19

Wäre super, wenn beide Welten einfach gegeneinander getauscht werden könnten. Was im Einzelfall mehr Sinn macht, hängt nach meinen bisherigen Erfahrungen sehr von den konkreten Anforderungen ab. MQTT2 macht m.e. viele "Module" überflüssig, die eigentlich nur dazu dienen, mit json umzugehen und ein paar Attribute zu setzen. Sowas braucht imho niemand - weswegen ich meine eigenen Bemühungen dazu auch direkt eingestellt habe.

Ich erzeuge mit meinen paar devices auch kaum Systemlast, die die Pflege eines Hilfssystems wie mosquitto rechtfertigen würde - was m.e. bei vielen anderen Usern auch so ist. MQTT2 ist daher kein Einsperren, sondern IMO eine Befreiung für diesen usertyp.

Trotzdem hat natürlich auch ein externer broker seine Berechtigung, gerade in euren Setups. Wäre also sehr zu wünschen, man hätte gerade bei sowas wie der GenericBridge die simple Option, zwischen den Welten (oder besser Varianten) zu wechseln. (Fhem2fhem usw. empfinde ich persönlich als reichlich kompliziert, ohne mich eingehend damit auseinander gesetzt zu haben - bei Installationen, die potentiell blockierende Internet-Abfragen und den Rest getrennt haben, könnte sowas sehr hilfreich sein.)

Vielleicht gibt es ja einen Weg? Mich würde das jedenfalls sehr freuen! (Auch wenn ich im Moment keinen usecase für mich selbst sehe, aber das habe ich zu MQTT auch mal gesagt

)

hexenmeister · 06 November 2018, 07:18:52

Naja. Mosquitto ist 'fire and forget'. Von 'Pflege' kann man dabei nicht sprechen.
Es wäre natürlich toll, wenn die Client-Devices frei wählen könnten, ob sie als IODev mqtt oder mqtt2 verwenden wollen. Leider ist das MQTT-Modul sehr eigenwillig implementiert, so dass diese Arbeitsweise erschwert ist.
Mittlerweile befinden sich die 'alten' MQTT-Module zwar in meiner Pflege, dennoch möchte ich derzeit keinen Komplettumbau durchziehen.
Meine Sorge ist, dass die MQTT-Kompatiblem Client-Module einseitig auf MQTT2 umgestellt werden und die Benutzer mit einem externen Server außen vor bleiben. Das ist das 'Einsperren', was ich meine. Ein 'Befreien' kann ich dabei nicht entdecken.
Die GenericBridge ist intern für eine MQTT2-Unterstützung bereits vorbereitet. Ich werde eine entsprechende Implementierung jedoch erst in Betracht ziehen, wenn alle Client-Module auch das 'alte' mqtt Unterstützen.

Beta-User · 06 November 2018, 07:39:13

Hmmm, vielleicht wäre es einfacher, MQTT2_Server eine Art "pass-through"-Modus zu spendieren? Also praktisch dasselbe zu machen wie 00_MQTT.pm (aus client-Sicht). Dann müsste man "nur" "deine" beiden client-Module entsprechend umbauen?

(Ich kennen sonst keine ernstzunehmende weitere Variante eines client-Moduls...).

Ob sowas viel Aufwand wäre, kann ich nicht sagen; einen Umbau von MQTT hatte Rudi (und nach meinem Eindruck noch min. ein weiterer crack) ja geprüft und dann nicht umgesetzt. Dürfte seine Gründe gehabt haben, obwohl ihm dieser Schritt nach meinem Eindruck auch nicht leicht gefallen zu sein scheint.

Aber wir sind OT...

hexenmeister · 06 November 2018, 08:56:34

Etwas OT sind wir schon

Dennoch... Die GenericBridge könnte die beiden Module MQTT_DEVICE und MQTT_BRIDGE überflüssig machen. Aber die ganzen neuen Version von Zigbee, Milight etc. funktionieren, wenn ich richtig verstanden habe, nur mit MQTT2. Also keine Chance für einen externen MQTT-Server. Aus meiner Sicht eine Katastrofe.

Ich denke auch, dass die beste Lösung ein Modul wie MQTT2_CLIENT (pendant zu MQTT) wäre, womit ein Server wie Mosquitto angebunden werden könnte. Dann würde ich natürlich sofort die entsprechende Unterstüzung in der GenericBridge vorantreiben.

Beta-User · 06 November 2018, 09:08:04

Na ja, sowas wie MQTT_Device macht schon Sinn, oder sollen das Dummys werden?

Die von dir als Katastrophe bezeichneten Einbindungen von zigbee2mqtt und milight sind schlicht MQTT2_Devices, die völlig verquere (meine Auffassung) Implementierungen aus der alten MQTT-Welt deutlich vereinfachen.

Im Ergebnis glaube ich aber nicht, dass wir weit auseinander liegen. (Hast du mal zigbee2mqtt im Einsatz oder einen Blick in das xiaomi-"Modul" geworfen? Mach das evtl. mal...)

hexenmeister · 06 November 2018, 09:17:13

Jepp, Dummies eignen sich hervorragend dafür.

Mir geht es nicht darum, ob die neuen Implementierungen sauberer sind, glaube ich sofort. Aber was sollen die Nutzer tun, die gute Gründe haben den MQTT2_SERVER NICHT zu nutzen? Lässt man sie dabei nicht im Regen stehen?

Ich habe selbst zwar zigbee, könnte ich in der aktuellen Situation ja auch gar nicht verwenden, da ich MQTT2 weder nutzen kann, noch will.

rudolfkoenig · 06 November 2018, 09:54:14

ZitatIch selbst sehe wenig bis gar keine Gründe, in einer single threaded Anwendung einen mqtt Server zu implementieren

Es besteht ein Problem, wenn man Module verwendet, die sich blockieren oder lange im Vordergrund Rechnen. Keiner meiner Module tut das (wenn man plotFork voraussetzt), ich gebe aber zu, dass fuer einen Anfaenger nicht einfach ist, diese Module (insb. im Voraus, bei der Planung) zu identifizieren. Vlt. sollten wir eine Kennzeichnung dafuer einfuehren.

Zitateinen Umbau von MQTT hatte Rudi [...] ja geprüft und dann nicht umgesetzt.

Das hatte ich nie vor, ich wollte aber urspruenglich MQTT_DEVICE wiederverwenden. Das waere aber nicht ohne groesseren Umbau (des nicht mir unterstehenden MQTT_DEVICE Moduls) moeglich, weil MQTT_DEVICE Funktionen aus MQTT direkt aufruft. MQTT2_SERVER erlaubt (im Gegensatz zu einem externen Server) den Zugriff auf das MQTT-ClientId, was das automatische Anlegen/Konfigurieren von MQTT2_DEVICE Instanzen erleichtert (autocreate). Ein MQTT2_CLIENT (als alternatives IODev fuer MQTT2_DEVICE) waere zwar relativ einfach moeglich, der Benutzer muesste aber damit auf autocreate (jedenfalls teilweise) verzichten.

ZitatDie von dir als Katastrophe bezeichneten Einbindungen von zigbee2mqtt und milight sind schlicht MQTT2_Devices, die völlig verquere (meine Auffassung) Implementierungen aus der alten MQTT-Welt deutlich vereinfachen.

Und ich arbeite daran, es fuer den Benutzer weiter zu vereinfachen, siehe https://forum.fhem.de/index.php/topic,91394.msg854282.html#msg854282

Beta-User · 06 November 2018, 10:13:54

Aus didaktischen Gründen halte ich Dummy nicht für optimal - gerade Einsteiger nutzen es m.E. zu oft. Ein eigenes Modul ist da hilfreich, selbst wenn es praktisch auf dasselbe hinausläuft.

Hätten die alten Module es eher erlaubt (bzw. hätte es Beispiele gegeben), json zu senden, wäre ich vermutlich auch nicht umgestiegen. Aber jetzt wollte ich die flexiblen Möglichkeiten der MQTT2-Lösung nicht mehr missen... (Und dabei nicht auf weitere Perl-Pakete angewiesen zu sein).

Wenn es darum geht, ggf. Brücken-Devices zu testen, bin ich gerne dabei. Wie gesagt, beides hat seine Berechtigung, es sollte v.a. darum gehen, es für "normale Anwender" gut und flexibl nutzbar zu machen.

hexenmeister · 06 November 2018, 11:15:36

Das ist natürlich alles schön und richtig aber was ist mit den Anwendern, die einen externen MQTT-Server brauchen?
Das fängt schon damit an, dass man mehrere FHEM-Instanzen parallel fährt.

Code Auswählen

Aus didaktischen Gründen halte ich Dummy nicht für optimal - gerade Einsteiger nutzen es m.E. zu oft. Ein eigenes Modul ist da hilfreich, selbst wenn es praktisch auf dasselbe hinausläuft.

Muss gestehen, das verstehe ich nicht. Wo liegt der Vorteil?

ZitatHätten die alten Module es eher erlaubt (bzw. hätte es Beispiele gegeben), json zu senden, wäre ich vermutlich auch nicht umgestiegen.

JSON-Unterstützung ist in der GenericBridge in Vorbereitung.

ZitatEin MQTT2_CLIENT (als alternatives IODev fuer MQTT2_DEVICE) waere zwar relativ einfach moeglich, der Benutzer muesste aber damit auf autocreate (jedenfalls teilweise) verzichten.

Wäre eine gute Sache, die Autocreate ist IMHO verschmerzbar.

Beta-User · 06 November 2018, 11:30:34

Für den externen Server wäre dann MQTT2_CLIENT die Brücke, wenn ich das richtig verstanden habe. Dann würde man zukünftig nur noch mqtt2_Devices nutzen können/benötigen.

Das mit der Didaktik hat schlicht die Bewandtnis, dass viele Einsteiger zu glauben scheinen, alles müsse irgendwie mit Dummy gelöst werden und dann Readings zwanghaft umpacken usw. statt einfach Readings zu nutzen und zusammen zu fassen, was zusammen gehört...

Das mit json in genericbridge ist schön zu hören, hätte mir ohne Beispiel aber vermutlich nicht weitergeholfen.

Wäre jedenfalls Klasse, wenn ihr beiden mqtt-Experten eine Art gemeinsamer Brücke zwischen den beiden Server-Optionen hinbekämt...

hexenmeister · 06 November 2018, 12:01:09

ZitatFür den externen Server wäre dann MQTT2_CLIENT die Brücke, wenn ich das richtig verstanden habe. Dann würde man zukünftig nur noch mqtt2_Devices nutzen können/benötigen.

Das ist richtig, nur derzeit hat keiner vor diese zu entwicklen. Und alle Nutzer mit einem externen Server fühlen sich alleine gelassen.

ZitatDas mit der Didaktik hat schlicht die Bewandtnis, dass viele Einsteiger zu glauben scheinen, alles müsse irgendwie mit Dummy gelöst werden und dann Readings zwanghaft umpacken usw. statt einfach Readings zu nutzen und zusammen zu fassen, was zusammen gehört...

Naja, aber genau für solche Zwecke sind Dummies nun mal da

ZitatDas mit json in genericbridge ist schön zu hören, hätte mir ohne Beispiel aber vermutlich nicht weitergeholfen.

Wie gesagt, noch nicht fertig, aber im Commandref habe ich immer Beispiele für die wichtigsten Anwendunsfälle dabei.