Artikelstruktur zu MQTT-Themen

[Beta-User]

Thread zur Diskussion, ob und welche Anpassungen an den Artikeln rund um das MQTT-Protokoll sinnvoll und zielführend wären.

Hier eine Zusammenstellung der bisherigen Argumente und Fragen dazu:

Als ersten Vorschlag würde ich sehen, die Diskussion an einer Stelle zu führen (Wiki-Bereich), wobei man die Vorfrage, ob es zu jedem Modul einen Wiki-Eintrag geben sollte, evtl. gesondert (dort) führen sollte. Bisher scheint das so üblich gewesen zu sein, daher sind (nur) 4-5 (Modul-) Artikel fast schon wieder "sparsam"...

Ich zitiere mal aus einem anderen Thread mit folgenden Vorschlägen:
[...]
Ich zähle derzeit die folgenden Einträge
MQTT
MQTT Einführung
MQTT Einführung Teil 2
MQTT Einführung Teil 3
MQTT2 CLIENT
MQTT2 DEVICE
MQTT2-Module - Praxisbeispiele
und das muss ja nicht sein. Kann ich denn einfach Seiten löschen? Mein Vorschlag wäre nur eine Seite zu behalten und den Rest dort zu integrieren:Zitat MQTT mit den Unterabschnitten Einführung (alle drei Teile, umstellen, sortieren)
 MQTT2 mit den Unterabschnitten  CLIENT und DEVICE, evtl MQTT Mosquitto kürzer oder gar löschen, ist ja nicht mehr aktuelle
  Praxisbeispiele
Mein Vorschlag wäre das umzustrukturieren:Wie ist die Meinung?

Nachtrag noch: Es gibt auch noch weitere Artikel (https://forum.fhem.de/Smileys/default/wink.gif) . Zumindest: https://wiki.fhem.de/wiki/MQTT_DEVICE
 https://wiki.fhem.de/wiki/MQTT_(Modul)
In den zweiten habe ich eben noch eine Hinweisbox auf MQTT2_CLIENT als Alternative reingebastelt sowie ein paar "Kleinigkeiten" zu MQTT_GENERIC_BRIDGE.

Ich sehe durchaus Verbesserungsmöglichkeiten, aber m.E. ist das Zusammenfassen nur in Teilbereichen möglich/sinnvoll, der Rest sollte sich eher aus einer sinnvollen/vollständigeren Verlinkung der Artikel untereinander ergeben.

Das Hauptproblem scheint mir zu sein, dass viele die Zusammenhänge der "Modulfamilien" untereinander nicht sehen und dann versuchen, Dinge miteinander zu verquicken, die so nicht vorgesehen sind.

[andies]

Mein Blickwinkel wäre: Wiki ist für Anfänger, die etwas verstehen und dann einrichten wollen. Für die würde ich schreiben.

[Beta-User]

Mein Blickwinkel wäre: Wiki ist für Anfänger, die etwas verstehen und dann einrichten wollen. Für die würde ich schreiben.

Da sind wir (weitgehend) beieinander. Das Wiki sollte auch für Anfänger verständlich sein.
Es darf aber auch gerne mehr drinstehen für die, die eine Referenz suchen für Dinge, die in der cref keinen Platz mehr gefunden haben oder nur kurz angerissen wurden.
Das mit der Verständlichkeit für Anfänger ist aber m.E. keine Sache, die mit der Zahl der Artikel direkt zusammenhängt, sondern eher mit der Strukturierung (da kann man sicher manches verbessern).

Um es konkreter zu machen, mal ein kurzer Aufriss der diversen Problemlagen (mit Schwerpunkt MQTT2):
Für MQTT2 war die Intention hinter den "Praxisbeispielen", das besonders einfach (auch zum einfachen copy/paste) zu machen und darzustellen. Aber wenn es "vollständig" sein soll, müßte man auch MQTT2_CLIENT aufnehmen, was aber in mehrfacher Hinsicht schwierig ist: Zum einen benötigt man dann für "autocreate" eine sinnvolle BridgeRegexp (und damit (im Prinzip) ein "spezielles" MQTT2_DEVICE), wobei die Konfiguration der bridgeRegexp aber in dem Moment richtig schwierig wird, wenn man keine "default"-Topic-Pfade mehr verwendet (wie in "manchen" Videos empfohlen). Dagegen wird User von MQTT2_SERVER so ein Abschnitt verwirren; die werden in der Regel denken, es sei "sicherer", einfach präventiv so ein Device anzulegen (was dann erst recht zu Problemen führen dürfte...).

In den Praxisbeispielen (oder was ähnlichem) dann jeweils eine Alternativkonfiguration mit MQTT_DEVICE zu zeigen, dürfte ebenfalls verwirren, die Frage, wie man von der einen in die andere Welt "übersetzt", ist ein Spezialfall, und die, die die eine Welt kennen, haben mit der anderen (noch) nichts (mehr) am Hut. Da stellt sich dann die zusätzliche Frage, wer welche Teile redigiert?

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.

Und dann JSON: Erklär mal jemanden, dass man auf der einen Seite ein spezielles Device braucht (expandJSON), MQTT2_.* das aber mehr oder weniger out-of-the-box empfangsseitig "kann" und viele bekannte Geräte auch sendeseitig via attrTemplate einfach so zu konfigurieren sind...

Wie meistens, steckt der Teufel im Detail, "an sich" ist das alles "eigentlich" recht einfach...

[andies]

ich muss gestehen, dass ich die verschiedenen Varianten nie verstanden habe. Da gibt es im Wiki ein paar Zeichnungen, die aber mehr verwirren. Ein Beispiel:

Code: [Auswählen]

Kurzübersicht:

a) MQTT-Gerät<=> MQTT2_SERVER <=> MQTT2_DEVICE

b) MQTT-Gerät <=> (externer) MQTT-Server<=> MQTT2_CLIENT <=> MQTT2_DEVICE

Etwas tiefer steht dann noch MQTT mitten drin, warum fehlt das hier? Der Client in b) ist doch nur da, weil der Server extern ist (richtig?) - warum steht dann extern in Klammern? Das ist doch notwendig, dass der extern ist. Dieser Zusammenhang sollte auch erläutert werden.

Am besten, wir überlegen mal, wo man anfängt und welche Struktur sinnvoll ist.


Gesendet von iPad mit Tapatalk Pro

[Beta-User]

Hmm, die "Zeichnung(en)"...

Da stehen die Bezeichnungen "hinten" jeweils eigentlich für FHEM-Module/-Definitionen.

Also: MQTT2_SERVER ist ein MQTT-Server (früher: Broker genannt), und in einer FHEM-Instanz muß es für MQTT2_DEVICE ein passendes IO-Modul geben, also entweder eine MQTT2_SERVER- oder MQTT2_CLIENT-Definition.
"Lustig" wird das ganze, wenn man auf eine andere FHEM-Instanz mit MQTT (Protokoll) lauscht: Da kann man dann auch mit 00_MQTT.pm oder MQTT2_CLIENT Daten von dem FHEM empfangen, das einen MQTT2_SERVER definiert hat (es ist ein Broker!).

Mit "(externem)" Server ist also nur soviel gemeint: Es darf kein MQTT2_SERVER in derselben FHEM-Instanz sein, alles andere ist "extern"...

Wenn unten "MQTT" in "klassischer Einbindung" auftaucht, ist 00_MQTT.pm gemeint.

Das kann man sicher besser "zeichnen", und auch die Unterscheidung zwischen MQTT als Protokoll und MQTT (als IO-Modul) kann vermutlich besser dargestellt werden.

Übrigens gibt es auch noch eine Kategorienseite MQTT (da stand mal der Text von "MQTT" drin, um "alles beieinander zu haben", das wurde dann aber wegen anderer Wiki-Vorgaben ausgelagert (siehe Artikelhistory und dieser ganz ähnliche Thread, den ich ihne große Resonanz vor längerem mal gestartet hatte: https://forum.fhem.de/index.php/topic,93343.msg859803.html#msg859803)).

[andies]

Wollen wir mal einen Nagel in die Wand schlagen? Also erstens alle drei Einzelseiten zu MQTT (Einführung Teil I usw) in eine Seite integrieren? Und dann schauen wir mal, wo wir da weitermachen ? Da wäre dann auch das eine oder andere stilistisch anzupassen.

[Beta-User]

Hm, also:

Diese Artikelserie stammt von Rince, ich kann zu den Inhalten v.a. "hinten raus" wenig sagen, weil z.B. meine Arduinos alle MySensors sprechen, nicht MQTT . Ich hatte die damals gegengelesen und hätte auch manches stilistisch anders gemacht, aber a) hatte ich damals nur theoretische Kenntnisse in MQTT und b) war es ausdrücklich anders gewollt gewesen. Von daher: Bitte mit Rince klären, ich bin da recht leidenschaftslos, aber eben in Teilen auch reichlich kenntnislos.

Grundsätzlich finde ich die Aufteilung in drei Teile zwar nicht zwingend, aber es waren auch andere Schwerpunkte in den einzelnen Teilen, und dass es mehrere Teile sind und wie sie nacheinander zu lesen, ist an der Benennung unschwer zu erkennen. Vielleicht würde es mehr Sinn machen, die entsprechend zu benennen? Arduino-Programmierung gehört m.E. nicht in einen Hauptartikel zu MQTT, das verwirrt vermutlich heute nur noch...

M.E. kann manches ggf. sogar raus (auch da wiederhole ich mich eventuell zu vor ein paar Jahren), weil es nicht FHEM-spezifisch ist. Wer allg. etwas über MQTT erfahren will, sollte eigentlich außerhalb nachlesen...
Wegen der Nägel:
Mach doch mal eine Stichwortliste, welche Themen abzufrühstücken wären und wo die dann systematisch deiner Ansicht nach einzusortieren sind (Artikel, Abschnitt usw.).

Vielleicht noch ein "Artikelchen", was in dem Zusammenhang "interessant" ist: https://wiki.fhem.de/wiki/Sonoff

[andies]

Vielleicht noch ein "Artikelchen", was in dem Zusammenhang "interessant" ist: https://wiki.fhem.de/wiki/Sonoff

Kenne ich ;-)

Ich mache mal eine Liste und stelle die hier rein. Können wir von hier aus Rince erreichen?

[Beta-User]

Kenne ich ;-)

...hatte ich vorher nicht abgeprüft...

Ist aber evtl. ein Beispiel, dass es uU. Sinn macht, die Themen da aufzugreifen, wo sie auftreten (und dann ggf. von dort auf den "richtigen" nächsten Artikel zu verlinken; das kann aaO. ggf. verbessert werden (ungeprüft)).

Ich mache mal eine Liste und stelle die hier rein. Können wir von hier aus Rince erreichen?

"von hier aus" vermutlich nicht, aber ihn in dem im MQTT-Bereich angepinnten Beitrag (der auf die Serie direkt Bezug nimmt und damit ggf. entwertet würde), sollte es möglich sein, ihn dazu (nochmal) einzuladen, sich ggf. zu eventuellen Änderungen zu äußern.

Dass m.E. das reine Zusammenfassen von langen Artikel zu noch längeren m.E. nicht zwangsläufig sinnvoll ist, hatte ich ja bereits geäußert, und auch dem Vermengen von MQTT-"classic" mit MQTT2 in jedem Artikel stehe ich sehr skeptisch gegenüber. Was ggf. Sinn macht, ist an noch mehr Stellen auf eine Stelle zu verlinken, in der deutlich wird, dass man sinnvollerweise entweder die eine Variante oder die andere wählen sollte und was wie "familienmäßig" zusammengehört. Da ist man aber recht schnell bei Wertungsfragen, und die haben im Wiki nicht wirklich was verloren (per Definition).

[DasQ]

Mqtt ist ja die „Basis“ und gehört allgemein gehalten als basiskategorie
Mqtt2 ist ein Synonym für eine implementation in Fhem. Also Unterkategorie oder modulkategorie.
Explizit baut das eine auf das andere auf und das gilts rüberzubringen.
Da verwirrt es den Laien zunächst als erstes wenn dann noch der mqtt2-Client mit ins Spiel kommt.
Der für sich wiederum auf eine untermodulkategorie unter mqtt2 darstellen, aber auch nicht zwingend für mqtt2 Funktionalität benötigt wird.

[Maui]

Ich sehe das verlinken von einem Artikel zum nächsten kritisch.
Für Einsteiger ist MQTT eh schon ein Brett vom einrichten her und dann kommt man auch schnell aus dem Tritt wenn überall Verlinkungen sind.
Die Frage ist ja auch, wie viel wirklich im Wiki abgebildet werden muss.
Wenn zB nur 1 Artikel mit Einleitung und Abschnitten wie MQTT, MQTT2 und MQTT GB vorhanden wäre dann würde das vermutlich dem (MQTT) Einsteiger reichen. Und zum nachgucken später gibt es ja die cref. (Die Phasenweise auch ein halbes Wiki ist siehe DOIF)

[Beta-User]

@Maui:
Welche Module kennst du bzw. hast du im Einsatz?
Was macht "MQTT" für dich zum "Brett"? Kannst du das näher beschreiben?

Was den Umfang der Darstellung in der cref angeht, ist DOIF im doppelten Sinne m.E. kein gutes Beispiel, da a) die englische kaum hinreichend ist, um das zu nutzen und b) so ausufernd ist, dass es schwierig ist, darin was zu finden... (Bitte nicht hier vertiefen, ist ein anderes Thema).

So wie ich das verstanden habe, soll die cref es ermöglichen, ein entsprechendes FHEM-Device einzurichten und zu betreiben. MMn. erfüllen alle MQTT(2)-Module diese Vorgabe ohne weiteres. Wer also "sauber" vorgeht und erst die cref durchsucht, wird wissen, dass er drei IO-Module zur Auswahl hat und was wie zusammengehört... (Das entspricht nur leider nicht der Realität...)

Das Wiki sollte dort (Einrichten) dann ansetzen und ggf. Beispiele und weiterführenden Code beinhalten.

Dazu gehören dann Dinge wie Arduino-Programmierung, tasmota und zigbee2mqtt.

Generell für die Diskussion hier würde ich anregen, MQTT (oder besser noch MQTT-Protokoll) als Begriff für die Art der Datenübertragung zu verwenden, 00_MQTT für das betreffende IO-Modul, MQTT-Module für die Module, die 00_MQTT als IO nutzen,  MQTT2 entsprechend für die neuere FHEM-Modul-Familie und zuletzt MQTT(2) für alle FHEM-MQTT-Module.

[DasQ]

Dein letzten Absatz peil ich nicht. Warum zweimal IO

• Mqtt (protokoll)
• 00_MQTT IO
• MQTT2
• usw.

[Beta-User]

Dein letzten Absatz peil ich nicht. Warum zweimal IO

• Mqtt (protokoll)
• • 00_MQTT IO
  • • MQTT2
    • usw.

Hmm, also grundsätzlich gehe ich mal davon aus, dass das 2-stufige Modulkonzept verinnerlicht ist, das u.a. auch hinter der Verarbeitung des MQTT-Protokols in FHEM steckt!?

Da gibt es dann 3 (!) IO-Module, die vom Typ her als IODev in den Client-Devices gültig sind. Das ergäbe folgende "Struktur" (die gerne statt des kritisierten "Bildchens" in den MQTT-Artikel rein darf):
- Mqtt (protokoll)
  -- 00_MQTT (IODev)
    --- MQTT_DEVICE
    --- (MQTT_BRIDGE = imo. veraltet)
    --- MQTT_GENERAL_BRIDGE (jeweils iVm. beliebigen anderen FHEM-Devices)
  -- 00_MQTT2_SERVER (IODev)
    --- MQTT2_DEVICE
    --- MQTT_GENERAL_BRIDGE
  -- 00_MQTT2_CLIENT (IODev)
    --- MQTT2_DEVICE
    --- MQTT_GENERAL_BRIDGE 

Es macht aber vermutlich wenig Sinn, 3x die MQTT_GENERAL_BRIDGE zu behandeln, und (fast) keinen Sinn, MQTT2_DEVICE doppelt (mit Ausnahme des "MQTT2-Brücken-devices", das heute schon im Artikel zu MQTT2_CLIENT zu finden ist...).

Und MQTT als Protokoll macht dann als Oberuntergliederung m.E. wenig Sinn, oder?
(Es sei denn vielleicht, man macht mit
- MQTT-Server-Typen weiter:
- MQTT-Server-Typen
  -- MQTT2_SERVER
  -- mosquitto
  -- ... ("was auch immer sonst nocht kreucht")
)

[DasQ]

drum reden wir hier drüber  ... aber das mit listen(menu) struktur veranschaulicht nunmal besse, als nur zu theoretisieren.

das wenn man, wie du bereits gemacht hast, minimalisiert, wird doch ne recht einfache und übersichliche und vorallem logische struktur.