Allgemeine Informationen > Wiki

Artikelstruktur zu MQTT-Themen

<< < (3/26) > >>

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:

--- Zitat von: DasQ am 22 Juni 2019, 10:01:21 ---Dein letzten Absatz peil ich nicht. Warum zweimal IO


* Mqtt (protokoll)
*
* 00_MQTT IO
*
* MQTT2
* usw.
--- Ende Zitat ---
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  ;D ... 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.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln