MQTT2_SERVER und MQTT2_DEVICE

[Martin Fischer]

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]

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]

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

[hexenmeister]

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]

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]

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]

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]

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]

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]

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]

Ich 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.

einen 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.

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.

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]

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]

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 Erweitern

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?

Hä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.

Ein 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]

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]

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 ist richtig, nur derzeit hat keiner vor diese zu entwicklen. Und alle Nutzer mit einem externen Server fühlen sich alleine gelassen.

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...

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

Das 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.

[Beta-User]

K.A., ob sich User mit klassischen mqtt-Einbindungen alleine gelassen fühlen. Ich fühlte mich damals etwas alleine, was auch an der neuartigen nutzung der sidoh-firmware lag; aber jetzt sind wir ein paar Monate bzw codezeilen weiter. Im Moment muss man sich halt entscheiden, und das zu einem Zeitpunkt, in dem man klassischerweise keine Ahnung hat. Das ist ein Dilemma, aus dem so eine Brücke helfen könnte. Ob jemand den Aufwand für so ein Modul treiben will? Mal schauen...

Was Dummy angeht: der Zweck ist klar, nur gibt es häufiger Leute, die vorhandene Info planlos umpacken bzw. keine Phantasie dahingehend haben, dass man einen Dummy für mehrere Infos nutzen könnte usw.. Wenn man _wirklich_ nur ein Objekt braucht, ist es völlig OK. Nur ist das eher selten der Fall .

[hexenmeister]

Der Unterschied ist, es existiert anscheinend kein Weg mehr, diese Module in einer Umgebung zu nutzen, wo ein externer Server unvermeidlich ist. Das war vorher nicht so. Und jetzt einfach nicht (mehr) möglich. Aus meiner Sicht ein No-Go

[Beta-User]

Den Einwand verstehe ich nicht. Erstens gibt es.heute beide Wege und man kann beides mit verschiedenen Ports nebeneinander betreiben. Vermutlich kann man auch beide Servertypen sogar brücken (geht mit 2 mosquittos ja auch).

Was die sehr viel flexiblere Konfiguration für Widgets und Json-Sendeblobs mit Mqtt2 angeht, hindert dich niemand, das ähnlich oder gleich anzubieten, ich unterstelle mal, dass Rudi keine Einwände GG. einen coder-reuse hätte. Dann könnte man in der raw-Definition einfach die "2" löschen und das IO ändern, um zwischen den Welten zu wechseln.

Oder habe ich irgendwas völlig missverstanden?

[hexenmeister]

Vlt. missverstehe ich was... Wenn ich es richtig verstanden habe, können mehrere mqtt Client Module nicht mehr direkt mit mqtt als IO verwendet werden. Mosquitto mit MQTT2_SERVER zu brücken ist keine Lösung, da ineffizient. Zwei echte Server zu brücken ist ein ganz andere Geschichte.

[Beta-User]

Nein, es gibt nur ein einziges Mqtt2-Modul (MQTT2_DEVICE), das nicht mit 00_MQTT zusammenarbeitet.

Und das ist sehr flexibel. Vielleicht kannst du auch 00_MQTT so umbauen, dass es das 2-er Device als client akzeptiert? Dann müsste man nur das IO ändern. Sollte eigentlich kein Ding der Unmöglichkeit sein (ohne dazu in den code gesehen zu haben. Aber es geht intern ja "nur" darum, einfachen Text zu manipulieren).

[hexenmeister]

Leider ist das durch die Art, wie das Modul damals von dem ursprünglichen Entwickler erstellt wurde, nicht ganz so einfach. Das Modul ist alles andere als fhem-konform. Dennoch war das über eine längere Zeit Standard. Und ist in Gegensatz zum neuen eine allgemeinlösung. Mag sein, dass die neue Lösung bequemer ist, aber durch ihre Art für viele Szenarien nicht einsetzbar. Und jetzt werden die speziellen Hardware Module nur für eine kleine Teilmenge der Nutzer angeboten.

[Beta-User]

Tut mir leid, aber das mit den "speziellen Hardwaremodulen" verstehe ich nicht. Es gibt nur ein Client-Modul, das sich flexibel auf alle mir bisher begegneten Varianten von Topics und Messages anpassen läßt.

Aber ohne den Code aller Module mal im Detail angesehen zu haben, führt das nicht weiter. Ich mach das mit meinen ziemlich besch...einen "Kenntnissen" bei Gelegenheit mal, allerdings wird das dauern. Die Idee wäre, 00_MQTT zu einer Art "Doppelmodul" zu erweitern, das auch mit 2-er Devices als Client klar kommt. Wäre zwar bei jeder Massage eine Unterscheidung mehr, aber im Ergebnis bekäme der user davon nix mit und wäre bei Wahl dieses Clients nicht an einen bestimmten broker-Typ.gebunden. "best of both worlds..."

[hexenmeister]

Das verstehe ich jetzt nicht. Es gibt ein allgemeines Client Modul (MQTT2_DEVICE) und spezielle Module für milight, zigbee, die nicht mehr mit mqtt zusammen verwendet werden können. Richtig?

[Beta-User]

Na ja, (angesehen von der vermuteten Option, die Server zu Brücken) muss man sich im Moment schon entscheiden, an welchen Broker zigbee2mqtt (oder irgend eine anderen konkrete HW) seine Daten schicken soll. Meinst du das?

[rudolfkoenig]

Es gibt ein allgemeines Client Modul (MQTT2_DEVICE) und spezielle Module für milight, zigbee, die nicht mehr mit mqtt zusammen verwendet werden können. Richtig?

Mein Stand: Es gibt ein Modul fuer sidoh-bridge (fuer Milight, setzt auf MQTT auf), was nicht mehr weiterentwickelt wird, weil eine vergleichbare(?) Funktionalitaet durch das Konfigurieren einer MQTT2_DEVICE erreicht werden kann. Fuer zigbee2mqtt gab so ein Modul noch nie, nur die Beschreibung der MQTT2_DEVICE Konfiguration. Die MQTT2-Verschwoerung gegen die MQTT-Fraktion ist deutlich kleiner als angenommen.

[hexenmeister]

Nein. Meine Frage ist, kann ich diese Module ganz OHNE MQTT2_SERVER verwenden oder nicht?

[hexenmeister]

Ich verwende beides nicht, es geht jedoch um eine prinzipielle Klärung, ob es akzeptabel ist, die bestimmte Anwendungsfälle auszuschließen.
Ein Modul, was nicht weiter entwickelt wird im Gegensatz zu seinen Pendant ist über kurz oder lang tot.

Ich spreche nicht von einer Verschwörung, ich will nur alle sensibilisieren, das es gerade eine unnötige Spaltung herbei geführt wird.

[hexenmeister]

Wenn es nur Konfiguration ist, dann habe ich es falsch verstanden und müsste mir alles mal genau ansehen.
Dennoch finde ich, die Entwicklung geht in die falsche Richtung. Ist natürlich nur meine Meinung.

[Beta-User]

Jedenfalls um Moment kannst du das Modul mqtt2_device nur mit dem zugehörigen Server-Modul verwenden. Die Hardware kannst du aber auch mit mosquitto sprechen lassen und auf dem bisherigen - schwerer zu konfigurierenden Weg einrichten. Es gibt allerdings nach meiner Kenntnis noch keine vollwertigen Beispiele für Hue-Geräte unter den alten Modulen.

Daher nochmal: das Beste aus usersicht wäre, das (eine!) Client-Device-Modul einrichten zu können und dann das IO (also die broker-Komponente) nach Belieben wechseln zu können...

M.E. geht die Diskussion jetzt in die richtige Richtung: aus usersicht geht es nur um Konfiguration! Und die ist in Rudi's Modul m.E. benchmark (templates mal vorweggenommen, aber eigentlich auch jetzt schon...)

[hexenmeister]

Ich fand die alten Module nie besonders toll. Aus meiner Sicht, das Richtige wäre, wir tun uns zusammen und schaffen einen kompatibles Pendant zum MQTT2_SERVER für Anbindung von externen Servern. MQTT2_CLIENT oder so.

[Beta-User]

...auch gut...
Wir sollten halt die user nicht im Regen stehen lassen, die heute die alten Module nutzen. Von daher wäre es m.E. besser, die Namen weiter zu verwenden as is und.das alte client-Modul für legacy zu erklären. Damit bliebe genericbridge auch unangetastet, was sonst ein Problem wäre.
Damit sollte der Bedarf für Sonderlocken gedeckt sein (xiaomi-Modul oder meine alten milight-Versuche)...

[Billy]

Aus meiner Sicht, das Richtige wäre, wir tun uns zusammen und schaffen einen kompatibles Pendant zum MQTT2_SERVER für Anbindung von externen Servern. MQTT2_CLIENT oder so.

Dem kann ich als user nur beipflichten.
Das jetzige Wirrwar dürfte für Anfänger schwierig sein.
Die Generic Bridge zur Anbindung bestehender FHEM-Devices sollte allerdings überleben.
Trotzdem waren die alten Module für mich hilfreich, da es nichts besseres gab.
Hat mich sowieso gewundert wie lange es gedauert hat bis die Profis sich dem Thema Mqtt in FHEM angenommen haben.

[Martin Fischer]

Hola! Da habe ich ja mal ein Faß aufgemacht. Schööööön 

Ich bin nun nicht komplett in Eure Diskussion abgetaucht, sehe aber durchaus gute Argumente auf beiden Seiten. Nun jedoch ein ABER:
Bzgl. MQTT bin ich (noch) ein unbeschriebenes Blatt. Ich habe mich in der Vergangenheit nicht damit befasst / befassen müssen.

Nun habe ich innerhalb der FHEM Welt damit angefangen. Für meinen Anwendungsfall benötige ich derzeit keinen externen Broker; mir würde einer der direkt aus FHEM heraus erzeugt wird reichen. In meinem Szenario möchte ich einfach nur FHEM Devices aus FHEM Instanzen, die in unterschiedlichen Netzsegmenten vorhanden sind an einer anderen Stelle zusammen führen. Und das möglichst nicht mittels FHEM2FHEM. So bin ich letztlich bei MQTT_SERVER (und Mosquito), MQTT_BRIDGE und MQTT_DEVICE gelandet. Das läuft auch "out of the box". Danke an dieser Stelle an den / die Maintainer.

Allerdings stört mich das "Doppeln" der Devices doch arg. Ich bin dann über MQTT2_SERVER und MQTT2_DEVICE gestolpert. Den (für meinen Anwendungsfall) ausreichenden Ansatz auf einen externen Broker verzichten zu können, hielt ich für den ersten Augenblick super. Es kam Ernüchterung als ich sah, das es keinen "Bridgemode" gab (oder ich ihn übersehen habe).

Mein Ziel ist es nicht, die beiden "Lager" MQTT & MQTT2 gegeneinander aufzuwiegeln. Nein! Ich versuche das Ganze aus Sicht des Users zu sehen (in diesem Fall trifft das ja auch auf mich zu.). Je transparenter das Thema ist und je weniger Aufwand betrieben werden muss, desto einfacher ist es.

Ich fände es sinnvoll die Energie der Entwickler zu bündeln und daraus ein Ergebnis zu schaffen, das als "core feature" für FHEM einfliesst. Aus diesem Gedanken resultierte mein erster Beitrag.

Nach meinem Verständnis sollte dabei folgendes entstehen (Namen sind variabel):
MQTT_SERVER als "Proxy" für einen externen Broker oder als eigenständiger Broker konfigurierbar.
MQTT_DEVICE um "externe" Geräte die MQTT "sprechen" in FHEM einzubinden. Das kann auch ein FHEM Device aus einer anderen FHEM Instanz sein.
Neben diesen beiden Modulen werden neue globale Attribute eingeführt, mit denen jedes (beliebiges?) FHEM Device ohne zusätzliches Bridge oder generisches MQTT Device ebenfalls bidirektional über den bereits definierten Broker via MQTT_SERVER kommunizieren kann.

Ohne mir arg Gedanken über die Architektur gemacht zu haben. Also quasi "FHEM core interne notify Funktionalitäten zur Auswertung und dispatchen der Events von MQTT Devices".

[Beta-User]

Hmmm, also mal meine Gedankenwelt (bin ebenfalls user, habe aber etwas Erfahrung mit den Internas):
Zwei IO-Varianten:
MQTT - Broker ist extern (kann mosquitto über localhost oder ein entferntes FHEM mit MQTT2_Server sein)
MQTT2_Server als Generisches IO und Server von weiteren Installationen zu erreichen.
Generische mqtt-Geräte (z.B. ein Tasmota-ESP) werden über ein Modul, das wie MQTT2_Device in der heutigen Fassung konfiguriert werden kann eingebunden. Kann intern mit beiden Servertypen...

Bestehende Devices werden über Generic_Bridge (as is) angebunden (ein Zusatzmodel pro Fhem-Installation, das diese Option für alle Devices dieses Fhems anbietet).

Damit gäbe es nur zwei Baustellen:
Schnittstelle MQTT zu MQTT2_Device (bereits hier diskutiert)
IO-Funktionalität für Generic_Bridge auf dem FHEM-Rechner, der MQTT2_Server bereitstellt (bisher nicht ausdrücklich thematisiert)

So kann man das m.e. auch Einsteigern halbwegs verständlich machen, warum es jeweils bestimmte Module gibt).

[hexenmeister]

Mit dem meisten völlig einverstanden. Ein Extra-Device (GenericBridge) würde ich vorziehen vor der automatischen Unterstützung MQTT-Funktionalität für alle Devices. Kann man natürlich diese Erweiterung in die MQTT-Instanz einbauen, ich finde jedoch, man sollte sie nicht unnötig überfrachten.

GenericBridge würde ich ggf. erweitern und mit MQTT2 kompatibel machen. Ich könnte auch MQTT2_DEVICE kompatibles MQTT Modul entwickeln, kommen allerdings nicht so schnell dazu.

[Beta-User]

Bei Bedarf kann ich gerne Unterstützung anbieten. Bin aber nicht der Perl-Held... Die MQTT-Module scheinen aber ähnlich aufgebaut zu sein wie MySensors - und die kenne ich... Geht aber auch nicht gleich.

@Martin Fischer:
Das meiste geht übrigens heute schon und würde sich - bis auf die MQTT2-Geschichte auf dem Fhem, das den MQTT2-Server hostet - ohne weiteres umsetzen lassen.
Ergänzend (wenn auch nicht optimal bzw ressourcenschonend): man kann auch MQTT auf den MQTT2-Server auf demselben Rechner konfigurieren. Wenn das setting dann mal so kommt, dass intern der Zwischenschritt wegfallen kann, ist der Umbau schnell gemacht...

[Martin Fischer]

MQTT_GENERIC_BRIDGE ist sicher ein guter Ansatz aber so wie ich das sehe habe ich nur zwei Möglichkeiten:
entweder ich überwache alle FHEM Devices (bei mir zur Zeit 587 Definitionen in einer einzelnen FHEM Instanz) was vermutlich eine gewisse Last (und Latenz) mit sich bringen wird

oder

ich muss via [devspec] einen Rattenschwanz an Devices einzeln auführen oder via RegExp schauen, das ich alles unterkriege. Alternative: mehrere MQTT_GENERIC_BRIDGE Devices für weitere Devices (Devicegruppen).

Ich finde beide Varianten nicht so "benutzerfreundlich". 

Was ist wenn ich ca. 20 bis 30 ausgewählte Devices via MQTT einbinden will. Z.B. um für eine weitere FHEM Insanz ein Display mittels SmartVISU in einem anderen Netzsegment zu "bestücken"? Dies ist z.B. einer meiner aktuellen Anwendungsfälle.

Ein defmod <mqtt.foo> MQTT_GENERIC_BRIDGE mqtt <device01>,<device02>,.......<device29>,<device30> halte ich für nicht praktikalbel, geschweige denn übersichtlich. Was wenn ich <device17> und <device23> nicht mehr benötige? Dann muss ich jedesmal das MQTT_GENERIC_BRIDGE Device anpassen. Hm...

Ein defmod <mqtt.foo> MQTT_GENERIC_BRIDGE mqtt TYPE=<foo>,TYPE=<bar>,<device_x>,<device_y> ist auf Grund der unterschiedlichen Devices die ich auswähle auch nicht möglich. Ebenso kein Regular Expression, die meine Device "einfangen" würde.

Daher der Gedanke das über globale Attribute zu Regeln. Dann kann ich gezielt bereits bestehende Devices über das Setzen der entsprechenden Attribute am betroffenen Device selbst festlegen. Ich finde den Ansatz über eine Bridge nicht notwendig, wenn man die Philosophie "Standardprotokoll für das Internet der Dinge" in den Fokus nimmt und diese für FHEM als "Kernbestandteil" aufgreift.

[hexenmeister]

Ich verstehe nicht, wie sich dein Ansatz davon unterscheidet, alle Devices mit der GenericBridge zu überwachen? Auch ihne Bridgeinstanz müsste man das selbe tun. Weil alle Geräte potenziell betroffen sein können, müssen alle überwacht werden.
Aber besonders viel Last erzeugt das nicht. Die Bridge merkt schnell, dass es sich ggf. un einen 'fremden' Gerät handelt. Sollte es hier dennoch Performanceprobleme geben, hätte ich noch eine oder andere Optimierung einbauen können.

Meine älteste FHEM-Instanz (die räume ich nach und nach auf und verlagere einzelne Gerätegrupper (per MQTT angebunden) in andere FHEMs) hat aktuell 831 Geräte. Und keine Performanceprobleme mit der Bridge. 

Unten ein Auszug aus apptime-Ausgabe. Da sind einige 'böse' Kandidaten. GenericBridge ist das aber nicht (s. letzte Zeile). Trotz dem, dass alle Geräte pauschal überwacht werden.

Code Auswählen Erweitern

fhem> apptime
active-timers: 92; max-active timers: 94; max-timer-load: 15  min-tmrHandlingTm: 0.3ms; max-tmrHandlingTm: 1958.8ms; totAvgDly: 27.9ms

name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
tmr-myCtrlBase_ProcessTimer              HASH_unnamed                          1958      217    7536.94    34.73  1143.21    45.39 06.11. 21:34:20 HASH(0x211c940)
hmlgw                                    HMUARTLGW_Read                         652      111    9378.47    84.49     0.00     0.00 06.11. 21:33:01 HASH(hmlgw)
HC_Test                                  HourCounter_Notify                     448      261    1565.36     6.00     0.00     0.00 06.11. 21:33:02 HASH(HC_Test); HASH(EG_HA_SA01.Zirkulationspumpe)
HMLAN1                                   HMLAN_Read                             407       80    3321.64    41.52     0.00     0.00 06.11. 21:31:21 HASH(HMLAN1)
tmr-at_Exec                              HASH(0x422d140)                        387        1     387.03   387.03    78.67    78.67 06.11. 21:33:00 HASH(T.AT.Steuerung_Zirkulationspumpe)
tmr-SYSMON_Update                        HASH(0x4541890)                        354        4    1139.57   284.89   819.84   283.07 06.11. 21:34:21 HASH(sysmon)
EG_HA_SA01.Zirkulationspumpe             CUL_HM_Set                             256        2     263.90   131.95     0.00     0.00 06.11. 21:33:00 HASH(EG_HA_SA01.Zirkulationspumpe); EG_HA_SA01.Zirkulationspumpe; on
tmr-at_Exec                              HASH(0x44c7b08)                        246        1     246.87   246.87     2.52     2.52 06.11. 21:32:43 HASH(TE_NN_SAVE_STATE)
hmusb                                    HMLAN_Read                             157       64    1044.76    16.32     0.00     0.00 06.11. 21:33:01 HASH(hmusb)
FGW14                                    TCM_Read                               126     2899   12958.98     4.47     0.00     0.00 06.11. 21:30:49 HASH(FGW14)
GC.notify                                notify_Exec                            122        5     279.13    55.83     0.00     0.00 06.11. 21:31:37 HASH(GC.notify); HASH(GC)
tmr-SYSMON_Update                        HASH(0x4785080)                        114        4     284.16    71.04   724.65   283.22 06.11. 21:33:21 HASH(sysmon_r3)
tmr-CUL_HM_respPendTout                  respPend                               112        4     120.57    30.14    36.60    10.70 06.11. 21:32:41 respPend:286734
mqtt                                     MQTT::Read                             107       47    1878.67    39.97     0.00     0.00 06.11. 21:32:20 HASH(mqtt)
tmr-at_Exec                              HASH(0x4540e40)                        106        4     391.74    97.94   466.06   119.68 06.11. 21:34:00 HASH(tickHeartbeat)
tPort_127.0.0.1_45797                    telnet_Read                             92       96     449.03     4.68     0.00     0.00 06.11. 21:33:03 HASH(tPort_127.0.0.1_45797)
mqttGeneric                              MQTT::GENERIC_BRIDGE::Notify            91      261     211.02     0.81     0.00     0.00 06.11. 21:32:21 HASH(mqttGeneric); HASH(DG_WZ_KS01)


[Martin Fischer]

In der Tat lässt hier apptime auf wenig Last schliessen. Das ist doch dann gut und somit spräche ja auch (vermutlich) nichts gegen eine Überwachung aller Devices. Ich möchte an dieser Stelle nicht missverstanden werden: Ich versuche hier nicht die Bridge schlecht zu reden. Ich hinterfrage und beleuchte nur verschiedene Ansätze.

Einer davon ist:
Wenn ich 587 oder 831  Devices definiert habe aber nur 20, 30 Devices via MQTT kommunizieren lassen will, warum sollen dann permanent 587 / 831 Devices "überwacht" werden. Ein Grossteil ist da ja nicht involviert.

Ein anderer Ansatz ist:
Die 20, 30 Devices gezielt mittels Attribut am Device selbst (weil ich gerne die entsprechenden Informationen am Device vorhalten würde ) zu konfigurieren und dann auf nur diese zu überwachen.

Meine Anmerkungen zum Thema Last und Latenz beziehen sich u.a. auf die commandref:

The second parameter ('devspec') allows to minimize the number of devices to be monitored (otherwise all devices will be monitored, which may cost performance).

Aber das scheint hier dann ja so nicht der Fall zu sein. Letztlich suche ich gerade nur den richtigen Weg für meinen Einstieg in MQTT und werde mich Euren Vorgaben fügen  und vielleicht das eine oder andere mal laut denken. Da ich im Moment wenig bis gar keine Zeit zum coden habe, werde ich auch kein MQTT3 auf den Markt schmeissen 

Schön fände ich wenn das Zusammenspiel der FHEM Module "harmonisiert" und transparenter wird.

[hexenmeister]

Ich habe zunächst auch Probleme an der Stelle (Notify) erwartet und hatte schon mal Optimierungsstrategien überlegt. Man könnte natürlich auch dynamisch die Liste der zu überwachenden Devices erweitern etc. Allerdings habe ich erstmal alle Optimierungspläne verworfen, da derzeit es nichts zu optimieren gibt.
Es passiert ja auch nicht viel - in der notify-sub wird geprüft, ob das Gerät bekannt ist, wenn nicht - fertig. Vereinfacht dargestellt - ein kurzes Lookup in einem Hash.

[Martin Fischer]

So wie ich es im Moment durchblicke, scheint es da auch keinen Stress zu geben.

Im Moment rätsel ich allerdings warum meine MQTT_GENERIC_BRIDGE nicht an das entsprechene MQTT_DEVICE published... und finde oder sehe den Fehler gerade nicht... *grummel*

[hexenmeister]

Meinst du ein mqtt_device in einer anderen fhem Instanz?
Posten mal bitte deine Konfiguration für die betroffenen devices.

[Martin Fischer]

Danke für Dein Interesse, Alex. Es lag wohl an dem vermeintlich fehlerhaften Modul mit Datum Ende Oktober. Ich bin in einem anderen Thread fündig geworden, wo Du bereits aktiv wurdest. Ein Update löste dann das Problem und bestätigte mir, das ich doch nicht blind war 

[rudolfkoenig]

Ich habe ein/das(?) MQTT2_CLIENT Modul eingecheckt, im wesentlichen ist es eine Alternative fuer MQTT2_SERVER, falls man externe MQTT-Server verwenden will.

Da ich es nicht ausgiebig getestet habe, bin ich auf Feedback angewiesen.

Achtung: da MQTT2_CLIENT keinen Zugriff auf das urspruengliche clientId hat, ist autocreate nur begrenzt moeglich.

[hexenmeister]

Prima Sache
Werde ich die Tage unbedingt testen (und mich daran machen, GenericBridge-Kompatibilität herzustellen )

[hexenmeister]

Konnte nicht abwarten, habe mir fhem.pl und 00_MQTT2_CLIENT aus SVN geholt.
Leider komme ich nicht sehr weit. Device-Instanz wird gleich wieder gelöscht.

fhem> define mqtt2client MQTT2_CLIENT 192.168.0.15:1883
fhem> l mqtt2client
No device named mqtt2client found

2018.11.07 20:54:26 5: Cmd: >define mqtt2client MQTT2_CLIENT 192.168.0.15:1883<
2018.11.07 20:54:26 5: Starting notify loop for global, 1 event(s), first is DEFINED mqtt2client
2018.11.07 20:54:26 5: createNotifyHash
2018.11.07 20:54:26 5: End notify loop for global
2018.11.07 20:54:26 3: Opening mqtt2client device 192.168.0.15:1883
2018.11.07 20:54:26 3: mqtt2client device opened
2018.11.07 20:54:26 4: Syswrite: Can't use an undefined value as a symbol reference at fhem.pl line 741.
, deleting mqtt2client

[rudolfkoenig]

Ich habe leichte Aenderungen in fhem.pl, DevIo.pm und MQTT2* gemacht.

[hexenmeister]

Danke, sieht besser aus
Ich schaue mir das dann mal an.

[Billy]

Prima Sache

Kann ich nur beipflichten! Dann ist ja das MQTT-Schisma schon fast beendet!
Werde MQTT2_CLIENT morgen mal testen.

[Beta-User]

 
Prima Sache.

Da im Anfängerbereich jemand fragte, wie er eine color_temp-zigbee2mqtt-Leuchte einbinden kann:
Wäre es ein Problem, von einer FHEM-Instanz parallel mit MQTT und MQTT2_CLIENT auf demselben mosquitto zuzugreifen?

Wäre für Umstiegs-Szenarien ggf. hilfreich zu wissen...

[hexenmeister]

Geht beides parallel.

[Beta-User]

Danke, ich geb's weiter...