Allgemeine Informationen > Wiki

Artikelstruktur zu MQTT-Themen

(1/26) > >>

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:


--- Zitat von: Beta-User am 18 Juni 2019, 15:36:23 ---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"...

--- Ende Zitat ---

--- Zitat von: andies am 18 Juni 2019, 12:40:59 ---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?
--- Ende Zitat ---
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:

--- Zitat von: andies am 18 Juni 2019, 16:20:55 ---Mein Blickwinkel wäre: Wiki ist für Anfänger, die etwas verstehen und dann einrichten wollen. Für die würde ich schreiben.

--- Ende Zitat ---
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: ---Kurzübersicht:

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

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

--- Ende Code ---

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

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln