Artikelstruktur zu MQTT-Themen

[andies]

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

Nein, damit meinte ich zum Beispiel eine Sonoff-Lampe, eine Blitzwolf-Steckdose oder was auch immer.

[DasQ]

hab jetzt mal ein entwurf auf grundlage der skizze von @fhem-hm-knecht gemacht.

das mit den pfeilen ist nach wie vor unglücklich, ich wollte aber doppelte komponennten vermeiden


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

[Beta-User]

Nein, damit meinte ich zum Beispiel eine Sonoff-Lampe, eine Blitzwolf-Steckdose oder was auch immer.

Dann war es (vermutlich) doppelt falsch, jedenfalls, wenn man annimmt, die firmware auf den "Objekten" wäre tasmota (oder ESPEasy im MQTT-Mode). Die sprechen nämlich nativ MQTT! Dafür _kann_ man auch dummy+GB verwenden, aber das ist nicht der "Einsteigermode". Der ist für nativ MQTT sprechende "Objekte" MQTT(2)_DEVICE, je nach IO.

Was mich wundert: Das sollte nach der ganzen Diskussion hier doch eigentlich sonnenklar sein!?! Da es nicht so ist: Bitte vorerst die Hände von den Wiki-Artikeln lassen, es macht definitiv keinen Sinn, im Dusteren von Farbe zu reden! (Ist nicht böse gemeint, mir ist schon klar, dass du was verbessern willst; aber (richtig!) erklären geht halt nur, wenn ein Mindestmaß an Verständnis da ist).

@DasQ: Das sieht ganz gut aus, ich muß mir das mal ausdrucken und ggf. ein paar Anmerkungen in Ruhe einfügen (das sind aber eher noch Kleinigkeiten, ich will aber dann nichts wesentliches vergessen haben).
@All bzg. 1-wire: das sollte dann oben mit OWX stehen und unten bei OWServer dann vorneweg 1-wire?
(Ich habe das (@OWX) schon länger nicht mehr in Benutzung, aber wg. Konsistenz wäre es gut, wenn da jemand "Farbsichtiges" was dazu sagen könnte...)

Insgesamt zu dem Schaubild: Vielleicht würden ein paar Fußnoten besser sein als allzuviel Text in der Grafik?

[DasQ]

zuerst muss mal fachlich passen, danach mach ich hübsch und verständlich.
ne legende hatte ich schon die ganze zeit im hinterkopf, aber die gleichzeitig zu pflegen ist 2much.

als anhang noch ein export als svg, skalierbar, schön klein von der dateigrösse, html5 konform

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

[Maui]

Ich Klinke mich jetzt erstmal hier2 Wochen aus, da Urlaub.

Gruß

[andies]

anhang

Ich beschreibe mal, was mich irritiert: In der Grafik sind mehrere Geräte zu sehen, die FHEM-devices oder physische Geräte darstellen. Was aber ist dann MQTT (in der blauen Wolke): Ein Gerät? Ein Server (früher: Broker)? Die Sprache?

Weiter sehe ich anscheinend zwei Server (früher Broker) in dem Bild, einmal extern und einmal MQTT2_Server. Aber gehen die beide nur gleichzeitig? Ich dachte das wäre ein entweder-oder? Wie ist die Relation zwischen MQTT2-Server und MQTT2-Client? Müsste die MQTT-Wolke nicht dazwischen (ok, ich weiß ja nicht, was sie genau abbildet)?

Tja, wir kriegen das wohl so nicht hin. Ich kann nur eines tun: Fragen stellen. Mehr mache ich besser nicht mehr.

[DasQ]

Mqtt in der Wolke, ist das Protokoll. (Habe ich bewusst nicht dazu geschrieben, will den Laien nicht mit unnötigen Informationen verwirren)

Wie gesagt ist ein Entwurf und er soll ja ganz genau das, das jemand fragen stellt.
Wenn das jetzt schon die letzte Fassung gewesen wär, wärs einfach gewesen.

Ich wollt im zweiten .png im letzten posting, die Konstellation der Kommunikation über die Bridge darstellten. Einmal die Variante „nicht mqtt gerät“ und einmal die Variante „2. mqtt Server“.
Da ich selber aber garkeine GB nutze, hab ich versucht aus euren Erklärungen das zu visualisieren. Sollte das so nicht technisch korrekt sein, muss ich das halt noch berichtigen.
Ich war/bin der Meinung das Brigde intern mit dem MQTT-Server spricht und nicht über das Protokoll (Wolke).

Mir ist klar das das ohne Text zusehr verwirrt. Hab ich aber bewusst so gemacht, damit man ggf eine eindeutige Legende dazu packt, die das dann erklärt.
Die Gratwanderung zwischen einfach verständich und am besten mehrer Dinge pro Grafik zu erschlagen, ist hier mein Ansatz. ... sollte das so klappen gibt’s halt drei oder mehr Grafiken.

Muss zu meiner schade gestehen, ich hab GenericBridge und Bridge zu einem gemacht. Wird umgehend geändert.

[Beta-User]

Schwere Geburt...

Also: ich habe jetzt den Artikel https://wiki.fhem.de/wiki/MQTT_Einführung mal überarbeitet, dass alle FHEM-Module da drin an der richtigen Stelle wiederzufinden sein sollten. Da sind zwar noch ein paar "Kleinigkeiten", z.B. was die Verwendung des Begriffs "Client" angeht, aber jetzt wollte ich erst mal nachhorchen, ob das jetzt soweit erst mal halbwegs verständlich ist.

M.E. könnte das noch geringfügig redaktionell überarbeitet werden (Sicherheit...), und dann (ohne den "Sonoff-Teil",) ggf. ergänzt um die Dinge, die heute zusätzlich in https://wiki.fhem.de/wiki/MQTT stehen als neuer "MQTT"-Artikel fungieren. (Dann würde man aus der alten "Einführung" einfach weiterleiten).

Was noch fehlt, wäre eine sinnvolle Darstellug zu MQTT_BRIDGE und (v.a.) GB, es sollte dann ggf. nur jemand, der die GB auch nutzt, diesen Teil nochmal beisteuern oder zumindest redigieren.

Was die Frage angeht, wieviele Server denn nun "erforderlich" sind: Mindestens einer. Es kann aber durchaus mehrere Server geben, nur müssen die eben unterschiedliche Ports nutzen, sofern sie auf dieselbe Netzwerkadresse lauschen (sonst können die auch alle denselben Port offen haben). Und man kann jede Art des MQTT-Clients (vermutlich sogar MQTT2_SERVER) mit jeder Art Server kombinieren (unter mosquitto läuft das afaik unter dem Stichwort "bridgeing") . Das Protokoll selbst ist eben simpel, und jeder, der Software für irgendeinen Client schreibt, darf im Prinzip machen, was er will, was die topic-Struktur und die payload angeht (und viele reichen diese "Macht" an die user weiter ); das macht es eben unübersichtlich.

Grafiken: muß ich mir noch ansehen, aber das dauert für den MQTT-Teil vermutlich noch etwas, und zum anderen mache ich die Tage mal einen gesonderten Thread betr. den ganzen Artikel auf, wenn nicht jemand schneller ist.

[Beta-User]

Grafiken: [...] zum anderen mache ich die Tage mal einen gesonderten Thread betr. den ganzen Artikel auf, wenn nicht jemand schneller ist.

Done: https://forum.fhem.de/index.php/topic,101736.0.html

Was Diskussionen über die zentrale Grafik angeht, sollten wir m.E. dort weitermachen (die MQTT hier, das wird heute aber nichts mehr von meiner Seite).

In dem https://wiki.fhem.de/wiki/MQTT_Einführung gibt' jetzt auch noch ein paar weitere Aspekte und eine (hoffentlich) klarere Gliederung auch der Nebenthemen; sollte damit bis auf etwas Feinschliff demnächst zu MQTT werden dürfen?

[DasQ]

Also würde doch ein allgemeines Schaubild nur für mqtt ala domoticz, Sinn machen.
Und jeweils eins für mqtt(2)-Client, mqtt(2)-Bridge und mqtt(2)-GenericBridge.


Der letzte Link von dir zum Wiki zur Einführung, scheitert am Umlaut ü.
Link kopieren und händisch im Browser einfügen

[Beta-User]

Visualisieren ist gut, aber was den Inhalt angeht, habe ich es anscheinend immer noch nicht gut genug erklärt .

Wenn, benötigen wir als Basis 2,5 Versionen:
Version 1: Bereich A+B => MQTT2_SERVER, Bereich C1 => MQTT2_DEVICE, Bereich C2 => MQTT_GENERIC_BRIDGE (+ je 1 ZWave- und 1 CUL_HM-Device)Version 2a: Bereich A => mosquitto, Bereich B => MQTT2_CLIENT, sonst MQTT2_DEVICE, MQTT_GENERIC_BRIDGE (+ je 1 ZWave- und 1 CUL_HM-Device) wie oben
Version 2b: Bereich A => mosquitto, Bereich B => MQTT (Modul), Bereich C1 => MQTT_DEVICE, Bereich C2 => MQTT_GENERIC_BRIDGE (+ je 1 ZWave- und 1 CUL_HM-Device)

Kurz: MQTT(2)_DEVICE sind gleichberechtigte Clients zum jeweiligen IO neben MQTT_GENERIC_BRIDGE, das eine ganz andere Aufgabe erfüllt (nämlich nicht-MQTT-Geräte MQTT-fähig zu machen).
MQTT_BRIDGE LASSEN wir bitte einfach WEG (es sei denn, hexenmeister äußert sich gegenteilig). Es ist irrelevant und hinreichend im Text beschrieben (mMn).

[DasQ]

hier mal ein schuss ins blaue

wie soll man die interne verarbeitung in fhem zwischen den einzelnen modulen visualiseren

[Beta-User]

Hmm, also, anbei mal eine Handskizze, in welche Richtung m.E. das obere zu verändern wäre (bei der ich leider gleich A_00_MQTT2_CLIENT_general_bridge vergessen hatte... Die bitte als oberstes der MQTT2_DEVICE-Elemente einfügen, den Namen EXAKT SO in eine Klammer unter den Typ, und bitte auch die Schreibweise nicht "verbessern"):

Das wäre ein erster Schritt, um erst mal die Basisfunktionsweise von MQTT@MQTT2_CLIENT zu veranschaulichen. Da meine Sauklaue schlecht zu lesen ist, ein paar Klarstellungen (und bitte ausnahmsweise bitte mal möglichst nichts interpretieren oder "verbessern"!):

- Der gepunktete Rahmen um den "MQTT-Kasten" (da wo jetzt nur mosquitto drin steht) muß auch um die "nativen Devices" gehen; da es auf der Ebene auch Subscriptions geben _kann_, gehört da jeweils noch ein gepunkteter/gestrichelter Subscription-Pfeil zu jedem Publish. Bitte die oberen Bereiche so aufteilen, dass der MQTT-Kasten etwa gleich groß ist wie der Bereich mit den "non-MQTT"-Devices (sollte man vermutlich mit "hardware devices without native MQTT communication ability" oder so ähnlich überschreiben)

- Den (FHEM) "Server-Kasten" unten deutlich verbreitern und den "Module"-Kasten darin ebenfalls bis weit nach rechts ziehen (der wird dann sehr viel größer; die Legende aus der Ausgangsgrafik darf am linken Rand so bleiben).

- In diesen "Module"-Kasten kommt dann eine kleine Box mit "MQTT2_CLIENT" (die kann etwa so groß sein wie die Box mit label "MQTT2 Server" in der Systemüberischt und auch in derselben Farbe und sollte ziemlich oben innerhalb der Module-Box direkt unterhalb des mosquitto-Elements stehen mit pub/sub-Pfeilen dazwischen).

- Darunter kommen dann MQTT2_DEVICE-Elemente, die jeweils intern mit dem MQTT2_CLIENT-IO-Device kommunizieren (=> andersfarbige Doppelpfeile), als erstes bitte das "vergessene" A_00_MQTT2_CLIENT_general_bridge-Gerät (das ist auch eine Bridge, aber wieder für was ganz anderes, siehe Wiki zu MQTT2_CLIENT, und nein, ich beabsichtige nicht, dessen Funktionsweise hier zu erklären; es sollte nur eben da sein). Du könntest aber den Rahmen von diesem einen MQTT2_DEVICE etwas anders machen als bei allen anderen (gestrichelt), es ist nur ein optionales (aber sinnvolles) Hilfs-Device).

- Der freie Raum ist Absicht und sollte nicht gefüllt werden; es sollte nur möglich sein, ein MQTT_GENERIC_BRIDGE-Element nach rechts unten zu setzen mit einem internen Doppelpfeil zu MQTT2_CLIENT. (Bitte das aber erst mal weglassen, nach den bisherigen Erfahrungen scheint diese MQTT_GENERIC_BRIDGE alle mehr zu verwirren als notwendig! Das brauchen vermutlich >80% aller MQTT-Nutzer gar nicht...)

(Wenn das dann paßt:
- Variante 1: MQTT2_SERVER (diese Schreibweise!) statt MQTT2_CLIENT:
-- Beschriftung ändern, mosquitto raus, stattdessen den Kasten so vergrößern, dass er den gesamten Raum einnimmt, den mosquitto _und_ MQTT2_CLIENT vorher eingenommen haben (wird also sehr groß), Farbgebung usw. aus dem Modul-Format. (Optimalerweise sollten dann auch die beiden anderen Rahmenboxen da dann drumrumgehen (der gestrichelte MQTT-Rahmen sollte aber darüber liegen "as is"); das ist aber Kosmetik...)
-- Das A_00_MQTT2_CLIENT_general_bridge-Gerät sollte dringlich aus diesem Schaubild raus, der Rest rutscht also ggf. nach oben (oder auch nicht).

- Variante 2: MQTT (Modul):
Im Prinzip wie MQTT2_CLIENT, aber "MQTT (Modul)" als IO-Beschriftung und jeweils "MQTT_DEVICE" statt "MQTT2_DEVICE", aber zwingend ohne das A_00_MQTT2_CLIENT_general_bridge-Gerät.

- Variante 3 (zur Erläuterung von MQTT_GENERIC_BRIDGE auf Basis der Variante 1 für MQTT2_SERVER)
-- ein MQTT_GENERIC_BRIDGE-Element nach rechts unten setzen mit einem internen Doppelpfeil zu MQTT2_SERVER; das darf "überbreit" werden.
-- Darüber (gedanklich) zwei Säulen nebeneinander für ZWave und Homematic (@CUL_HM):
--- ZWave: Drei Elemente in den Modulkasten: Ganz oben ZWDongle, darunter zwei ZWave (Device-) Boxen; jeweils interne Kommunikationspfeile links zum ZWDongle, rechts zum MQTT_GENERIC_BRIDGE-Device; in den "Hardware-Kasten" oben rechts dann zwei ZWave-Geräte mit "Luftschnittstellen-Doppel-Pfeilen" zum ZWDongle
--- HomeMatic: Dasselbe "in grün", nur mit HMUARTLGW statt ZWDongle, und CUL_HM statt ZWave (Device-) Boxen; oben rechts dann zwei BidCoS-Geräte mit "Luftschnittstellen-Doppel-Pfeilen" zum HMUARTLGW

Statt mit A, B, C würde ich hier dann ZW-1 und ZW-2 bzw. HM-1 und HM-2 vorschlagen, um die Entsprechung der realen Hardware mit FHEM-Geräten zu verdeutlichen?

[DasQ]

ok, jetzt ist ne inspiration da.

wie gesagt, das sind keine "verbesserungen" oder kreativen ergüsse die ich da mach, das sind ganz einfach fehler.
zum einen hab ich von einigen der hier genannten systeme, kaum bis garkein plan. zum andern, nutz ich ja "nur" native mqtt2.

mir fallen da zum teil soviel fehlerchen auf bei mein veröffentlichten "entwürfen", dass ich mich ab und zu frag, was hat mich da geritten.
egal, ziel ist, das anschliessend eine allgemeinverständliche, einfache grafik dabei rauskommt. die dem laien mal zuächst etwas erklärt und dann keine(wenige) fragen offen lässt. (so hat man es mir beigebracht)
jetzt hier der weg, fernmüdlich, über ein forum, zumeinst unidirektional oder monodirektional, is zäh 
dauert halt ein wenig, die hauptsach ist, was am ende dabei rauskommt. und noch haben wir "nur" entwürfe.


btw. ich zieh mir jetzt erstmal deine skizze rein, versuch aus deim text klar zukommen und wenn ich dann noch fragen hab, abrbeiten wir am aktuellen stand weiter.

 
und ganz nebenbei, vielleicht hab ich ja noch die ein oder andere überaschung in petto.

[Beta-User]

ok, jetzt ist ne inspiration da.

Das klingt verheißungsvoll .

wie gesagt, das sind keine "verbesserungen" oder kreativen ergüsse die ich da mach, das ist alles noch brainstorming.
zum einen hab ich von einigen der hier genannten systeme, kaum bis garkein plan. zum andern, nutz ich ja "nur" native mqtt2.

Ist "im Prinzip" ja ok, nur habe ich auf Basis deiner letzten Grafik jetzt eine ziemlich konkrete Vorstellung, wie das (korrekterweise) auszusehen hat , und habe auch entsprechende Hardware (nur - wie gesagt - MQTT_GENERAL_BRIDGE nicht im Einsatz)...

[...] was hat mich da geritten [...]
 
und ganz nebenbei, vielleicht hab ich ja noch die ein oder andere überaschung in petto.

Manchmal bringt uns deine Kreativität auch weiter, das ist im Prinzip schon ok, aber andere Male frage ich mich, wie oft ich dasselbe wiederholen muß. Da kommst du mir sehr "volatil" vor (und ich muß gegen teilweise sogar unberechtigte Frustimpulse kämpfen) ...
Aber ich habe eben auch die Erfahrungen gemacht, dass du zum einen wirklich super Ideen bringst, auf die ich im Leben nicht selbst/von allein gekommen wäre, und zum anderen hilft mir die Diskussion häufiger, wenigstens etwas besser zu verstehen, was andere nicht verstehen (mir aber sonnenklar ist, warum auch immer)...

Von daher ist es völlig ok, wenn du dir die Zeit nimmst, die du brauchst und auch nochmal gründlich drübersiehst, was bisher so geschrieben wurde (und schon im Wiki steht, wenn auch unter dysfunktionalen Verlinkungen von hier weg ).

In der Sache noch:
- Bitte möglichst keine Produktbilder (copyright...)
- In der Hardware-Sektion darf m.E. gerne (in Klammer mit "z.B. ") auch jeweils eine konkrete Produktbezeichnung stehen (von was gängigem, von mir aus vielleicht (Homematic) ein HM-SEC-RHS (Fenster-Drehgriff-Kontakt) und ein HM-LC-Dim1TPBU-FM (Unterputzdimmer), (ZWave) FGS-221 (1-fach-Switch) und Eurotronic Spirit Thermostat (ich hoffe, die beiden letzten ergeben jeweils wirklich nur ein FHEM-Device).
(Bitte nichts mehrkanaliges, was zusätzliche Devices innerhalb FHEM anlegt, das wird sonst (an der Stelle ( !)) zu kompliziert).