Artikelstruktur zu MQTT-Themen

[andies]

MQTT_GENERIC_BRIDGE paßt insgesamt nirgends so recht rein, ich kann dazu aber eigentlich auch nichts sinnstiftendes beitragen, da ich das nur kurz angetestet hatte, es betrifft aber einen für manche user wichtigen Teilaspekt, der in dem Thread von hexenmeister aber ganz ordentlich dargestellt ist (denke ich jedenfalls?!?). Und MQTT2_CLIENT und MQTT_GENERIC_BRIDGE in Kombination mit autocreate ist ebenfalls ein "lustiges" Thema.

Ich muss noch mal ganz auf Anfang. Kann mir jemand mal erklären, wozu es diese Generic_Bridge gibt? Das ist im Wiki auch nicht so erklärt, dass ich es verstehe.

Ich schreibe auch mal die Hauptseite sprachlich um.

[andies]

Noch einmal, was ich nicht verstehe. Im Wiki steht

Briges und Devices unterscheiden sich wie folgt. Eine Bridge ist ein Gerät, das bereits in FHEM angelegt wurde und nur mit MQTT verbunden werden soll. Ein Device existiert noch nicht in FHEM und soll erst angelegt werden.

Wieso? Ein Device wird doch auch über das IODev mit MQTT verbunden und das device muss doch angelegt werden, damit es in FHEM ein device wird?! Sonst ist es gar nichts.

[DasQ]

Thx Beta Bau ich nachert um. Ich dürft auch gern freihandskizzen machen (abfotografieren und Posten) oder in die Bildchen von mir mit paint oder was auch immer drin rumeditieren, ich mach das dann schon ordentlich 

[Maui]

Ich muss noch mal ganz auf Anfang. Kann mir jemand mal erklären, wozu es diese Generic_Bridge gibt? Das ist im Wiki auch nicht so erklärt, dass ich es verstehe.

Ich schreibe auch mal die Hauptseite sprachlich um.

Ich versuche es mal aus Anwendersicht.
Im Thread zu der GENERIC_BRIDGE (GB) wird es im Grunde auch erklärt.

Die GB sammelt und verteilt alle MQTT-Meldungen. Sowohl empfangend als auch sendend.
Ein Beispiel. Du hast ein tasmota Gerät (sonoff zb) und willst das in FHEM mit DOIF beim Klicken/Schalten... mit bestimmten Aktionen belegen. Durch die GB kannst du mit mqttSubscribe und mqttPublish einfach den PowerState lesen und ein Schalten senden. Du hast dadurch alles was du brauchst in einem Device.
Das gleiche geht natürlich mit dummy.
Oder wofür ich sie hauptsächlich nutze. Als RFHEM Ersatz.
Ich habe ein Device beliebigen Types auf einem meiner 3 Fhem Instanzen. Alle 3 fhems haben eine GB definiert und das MQTT-IoDev zeigt bei allen auf mein MQTT-Server.
Nun habe ich zb die Wettervorhersage auf einer Instanz und möchte die Readings in der Hauptinstanz haben da ich dort (fast) alle Logik abhandle.
In Fhem 2 (neben) sei ein Device mit wea_Ort und einigen Readings. Dort ein

Code: [Auswählen]

mqttPublish
*:topic={"$base/$device/$name"}In Fhem 1 (Haupt) definiere ich ein dummy mit dem gleichen Namen.
Nun reicht mir als Attribut

Code: [Auswählen]

mqttSubscribe
*:topic={"$base/$device/$name"} und beim nächsten update bekomme ich alle Readings auf mein hauptDevice.
Möchte ich es jetzt ebenfalls in Fhem 3 sehen, so reicht mir ebenfalls ein subscribe.
Ein Event-on-change-Reading .* ist natürlich sinnvoll auf Fhem 2.

Jetzt habe ich ein wenig ausgeholt aber ich hoffe so konnte man es verstehen.

Gruß
Maui

[DasQ]

zwischenstand ... mittagessen 

[Beta-User]

@DasQ: SlowRF darf SlowRF bleiben, und der Kasten TCP/IP sollte immer noch um die unteren als Beispiele herum gehen; dazu fehlen ein paar bereits genannte Dinge (v.a. HM-IP; da stolpern viele Anfänger drüber...)

MQTT_BRIDGE und MQTT_GENERIC_BRIDGE hat Maui ja bereits erklärt, wobei m.E. das Beispiel mit dem sonoff nicht optimal ist, weil der (vermutlich) bereits selbst MQTT spricht (wenn z.B. mit tasmota geflasht). Es geht aber gerade (auch) darum ein beliebiges Device (z.B. ein CUL_HM oder ZWave-Gerät) aus FHEM heraus MQTT-fähig zu machen (um es in einer anderen HA-Lösung zu nutzen, oder als F2F-Ersatz). Früher brauchte man da für jedes einzelne FHEM-Gerät je ein MQTT_BRIDGE-Gerät, seit ca. Anfang 2018 macht das eben MQTT_GENERIC_BRIDGE als zentrale Instanz "one for all" (deswegen sollte man m.E. MQTT_BRIDGE eigentlich nach contrib schieben und gar nicht mehr intensiver besprechen).

[andies]

Ich versuche es mal aus Anwendersicht.

Würde diese Beschreibung dann die Sache treffen?

In FHEM kommunizieren das Server-device (in dem Beispiel oben ist das mybroker) direkt mit dem (externen oder internen) MTTQ-Broker. Jedes MQTT-fähige Gerät benötigt dann ein entsprechendes FHEM-device, in dem Readings angelegt und verändert werden und von dem aus Befehle an den Broker abgesetzt werden, die dieser dann an das MQTT-fähige Gerät verteilt. Das bedeutet, dass die Signale und Befehle verschiedener MQTT-fähiger Objekte ohne Bezug zueinander von FHEM verarbeitet werden.

Es kann sinnvoll sein, innerhalb von FHEM diese Signale und Befehle der verschiedenen MQTT-fähigen Geräte zu bündeln, damit einfachere Befehlsstrukturen innerhalb von FHEM möglich werden und die Verarbeitung der Information leichter von statten geht. Zu diesem Zweck kann man sich eine MQTT-Bridge installieren, die dann diese Aufgaben übernimmt. Eingerichtet wird die Bridge mit dem Befehl
 ?Mit welchem denn?

Das Modul MQTT_GENERIC_BRIDGE kann seit November 2018 mit allen drei IO-Modul-Varianten zusammen eingesetzt werden, also sowohl mit MQTT2_SERVER bzw. MQTT2_CLIENT oder MQTT (00_MQTT.pm)...

Dann trage ich das nämlich ins Wiki ein.

[andies]

Es geht aber gerade (auch) darum ein beliebiges Device (z.B. ein CUL_HM oder ZWave-Gerät) aus FHEM heraus MQTT-fähig zu machen

Ach so!!! Das Ding brückt beliebige FHEM-Befehle in MQTT?

(Kann ich mal ein Beispiel kriegen, wo das sinnvoll ist? Ich habe ein beliebiges device, das nicht MQTT kann. Ich brücke das zum Broker und das spricht jetzt MQTT. Und dann? Ich bin doch außerhalb von FHEM, wozu das?)

[DasQ]

so ganz hab ichs noch nicht gerafft wie ich das mit der bridge visualisieren soll.

wir wollten das glaub eh in einer zweiten/dritten... grafik aufbauen

soll jetzt hier in die grafik, noch der broker in die interface spalte? das wär dann halt "allgemein"
und den part mqtt2, bridge, device usw. in die zweite grafik

****edit ********
Aktuelle Bilder im andern Thread

[Beta-User]

"Befehle" finde ich den falschen Ausdruck.
Beide BRIDGE-Module ermöglichen es, z.B. einen CUL_HM-Aktor von "außerhalb" ein- oder auszuschalten oder eben z.B. ein Reading zu publishen. Die GENERIC_BRIDGE erweitert dazu schlicht die globale Attribute-Liste, so dass dann sende- und empfangsseitig einfach "überall" die entsprechenden Attribute gesetzt werden, das war's schon (und es gibt einen Thread von hexenmeister mit ganz vielen Beispielen; der ist auch mehrfach verlinkt...).

Und bitte: wir sind betriebsblind auf FHEM fixiert, es gibt aber Leute, die gerne eine andere Visualisierungslösung nutzen, und (afaik) z.B. HASS arbeitet rein MQTT-basiert (es gibt zu den Themen auch einen längeren Thread). Oder man haut auf dem MQTT-Weg Meßdaten raus in die weite Welt, verbindet FHEM-Instanzen (MQTT ist vergleichsweise tolerant gg. Verbindungsabbrüche...)

Die Terminologie "Broker" ist übrigens veraltet, afaik. Man sollte immer Server schreiben (und ggf. MQTT2_SERVER schreiben, wenn man eine bestimmte Softwarelösung meint).

Würde diese Beschreibung dann die Sache treffen?Dann trage ich das nämlich ins Wiki ein.

M.E. nein, jedenfalls ich verstehe so schlicht nicht, was gemeint ist...

Technisch:
- "In FHEM" kommuniziert das IO-Modul mit seinenClient-Modul-Devices im Sinne des zweistufigen Modulkonzepts, nur nach außen wird als Protokoll ein bestimmter TCP/IP-Layer verwendet (MQTT). Ist das IO-Modul MQTT2_SERVER, braucht man keinen weiteren Server (Broker), dann hat man nur MQTT-Clients (wie tasmota-geflashte ESP's, den zigbee2mqtt-Dients usw.).
- Wie man Nachrichten miteinander zu einem "virtuellen Ort" (einem FHEM-Device, gedacht als "define"-Anweisung), ist praktisch beliebig. Ich würde das als reine Zweckmäßigkeitsfrage bewerten. Man kann nämlich z.B. eine Message ohne weiteres auch an mehrere (FHEM-interne) Clients verteilen (machen wir z.B. bei den Milight so für einzelne Bulbs und Gruppen) oder Devices anlegen, die Informationen aus vielen Quellen bündeln uswusf.

Was die Grafik angeht: Was ist mit bridge gemeint? Ich hatte die HUEBridge genannt und versucht zu erläutern, dass die und die CCU3 ein Unterfall eines TCP/IP sprechenden Geräts sind, also der Farbkasten TCP/IP so groß sein sollte, dass die beiden samt MQTT da umschlossen sind (das Wort MQTT würde ich dabei aber etwas aus dem Interface-Bereich raus nach rechts rausragen lassen, das hat ja keinen definierten physischen Ort, wo sich das zwingend befindet wie eine typische CCU3 oder eine HUEBridge)

[Maui]

Würde diese Beschreibung dann die Sache treffen?Dann trage ich das nämlich ins Wiki ein.

Ich würde auch eher nein sagen. Man versteht nicht was gemeint ist.
Aber wo denn eintragen? Ein neuer Wiki Eintrag über die GB?
Ist das denn jetzt schon so sinnvoll, wenn quasi das ganze Thema MQTT hier noch in der Diskussion ist?!
Mein Beispiel mit dem Wetter ist ja etwas dem MQTT "beigebracht" wird.

Beispiel-define

Code: [Auswählen]

defmod mqttGB MQTT_GENERIC_BRIDGE
attr mqttGB IODev mqtt


[andies]

- "In FHEM" kommuniziert das IO-Modul mit seinenClient-Modul-Devices im Sinne des zweistufigen Modulkonzepts, nur nach außen wird als Protokoll ein bestimmter TCP/IP-Layer verwendet (MQTT). Ist das IO-Modul MQTT2_SERVER, braucht man keinen weiteren Server (Broker), dann hat man nur MQTT-Clients (wie tasmota-geflashte ESP's, den zigbee2mqtt-Dients usw.).

OK. Kann man dann entsprechend sagen

Verwendet man andere Visualisierungslösungen statt FHEM oder möchte man nicht MQTT-fähige Objekte MQTT-fähig machen, kann es sinnvoll sein, sich einer generic MQTT Bridge zu bedienen. Diese Bridge erweitert die globale Attribute-Liste, so dass auch in nicht MQTT-fähigen Devices entsprechende Sende- und Empfangsattribute gesetzt werden können.

Schwere Geburt...

[fhem-hm-knecht]

Es wäre wichtig zu unterscheiden bezüglich
native IOs und externe Soft/Hardware

als Beispiel Bild

[Beta-User]

@andies: Generell bin ich mit den heutigen Änderungen im Wiki-Artikel überwiegend nicht sehr glücklich.

Vielleicht wäre es eine Idee, den überarbeiteten Textvorschlag erst mal hier zu posten? Dann kann man das diskutieren. Dauert zwar länger, ist aber bei einem zwischenzeitlich so zentralen Protokoll halt ggf. notwendig.

Kritikpunkte:
- Der Begriff "Broker" ist veraltet, man sollte das also auch nicht mehr in einem aktualisierten Wiki-Artikel häufiger als notwendig verwenden.
- Die Warnung bzgl. des Loop-Bauens stand da nicht umsonst, bitte daher etwas mehr "Respekt", bevor was rausfliegt (man kann zu diskutierenden Entfernen-Text auch in Fußnoten verbannen oder erst mal auskommentieren).
- hexenmeister nutzt afaik selbst z.B. gar keine MQTT_DEVICE-Geräte mehr als Clienst zu 00_MQTT... (sondern macht alles mit GB+dummy, weil er es einfacher zu konfigurieren findet)
- Was die "richtige" oder empfehlenswerte Variante angeht: Das ist nicht wiki-like, und wenn, sollte man wenigstens so konsequent sein und dann die nicht mehr empfohlene Vorgehensweise "nach hinten" verbannen. So ist es erst recht "Kraut und Rüben", um manche Zeitgenossen zu zitieren .

Just my2ct.

Generell habe ich jedenfalls keine Lust, hinterher alles wieder zu reparieren.


Was GB und Wiki angeht, wäre vermutlich ein eigener Artikel ok (mal wieder ausdrücklich gegen die "Ein-Artikel-Fraktion!).
ABER: es gibt diesen (m.E. tollen) Thread von hexenmeister. Man sollte respektieren, dass er als Modulautor diesen Weg gewählt hat und dann dort im Wesentlichen nur die allg. Funktionsweise erläutern und auf den Thread verweisen (nur meine Meinung).
(Ich hätte vermutlich schon lange einen angelegt, aber zu wenig Erfahrung, um das "mit Hand und Fuß" zu machen. Und über Dinge,  von denen ich nicht annehme, dass ich sie gedanklich durchdrungen habe, schreibe ich prinzipiell keine Wiki-Artikel, sondern überlasse das denen, die wissen, was sie tun... )

OK. Kann man dann entsprechend sagen.

Jein.
Zum einen: Was ist ein "Objekt"? Wir sprechen von Geräten (=define!), oder?

Warum man MQTT als Transportschicht nutzt, ist m.E. völlig irrelevant, und nicht jede andere Visualisierungslösung "kann MQTT". Was bleibt ist: Ich habe ein beliebiges FHEM-Device, das noch nicht MQTT spricht und will dem jetzt "MQTT beibringen". Wie mache ich das? (Antwort: MQTT_(GENERIC_)BRIDGE)

Und da ich GB nur kurz angetestet habe, will ich zu dem 2. Satz keine Wiki-fähige Aussage machen (s.o.).

Es wäre wichtig zu unterscheiden bezüglich
native IOs und externe Soft/Hardware

als Beispiel Bild

Die Unterscheidung in native IO's und externe Soft-/Hardware finde ich gut.
Für MQTT würde ich dann oben allerdings MQTT2_SERVER schreiben und unten MQTT/MQTT2_CLIENT. (Ist leider alles verdammt lang, aber Abkürzen verwirrt da, oder?)

[DasQ]

hab jetzt nochmals von vorn bis hinten überflogen und hau jetzt mal einfach ein ersten entwurf für MQTT raus.

edit doofe erste idee .. ggf wird jetzt einleuchtender