Artikelstruktur zu MQTT-Themen

Begonnen von Beta-User, 18 Juni 2019, 15:42:47

Vorheriges Thema - Nächstes Thema

Beta-User

Hmmm, das war mit den "Bildchen" in https://wiki.fhem.de/wiki/MQTT eigentlich beabsichtigt.

Ich habe in diesem Artikel eben noch ein paar Kleinigkeiten verändert bzw. ergänzt, allerdings nicht diese Liste aufgenommen, da das dann wieder nur Text wäre und ggf. dann eher wieder verwirrt. M.E. wäre es besser, wenn wir das grafisch (z.B. ähnlich wie das hier: https://www.domoticz.com/wiki/File:Domoticz-architecture_0.2.png) hinbekämen.
Ist aber m.E. schwieriger wie dort, da man 2-3 Grafiken braucht: eine einfache, nur MQTT2_SERVER in FHEM mit MQTT2_DEVICE und MQTT_GENERIC_BRIDGE als Clients, eine für (mosquitto|2.FHEM mit MQTT2_SERVER) + 00_MQTT + MQTT_DEVICE/MQTT_GENERIC_BRIDGE, zuletzt dasselbe nochmal für (mosquitto|2.FHEM mit MQTT2_SERVER) + MQTT_CLIENT + MQTT2_DEVICE/MQTT_GENERIC_BRIDGE...

Schaubilder malen ist aber nicht meins...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DasQ

lustiger link :D ;D
vermutlich meinst du das https://www.domoticz.com/wiki/MQTT

kannst mir skizzieren was du gern genau hättest? ich bau dir was du willst  ::)
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

LuckyDay

solche Anschauungs Bilder finde ich teilweise besser als Text.
gerade bei MQTT bezüglich der Unterscheidung , und auch der Möglichkeiten zur Umsetzung.

Der WikiArtikel von domoticz finde ich gut, ohne jetzt den Inhalt geprüft zu haben.

Beta-User

Ja, die Grafik aus dem Artikel war gemeint. Der Artikel selbst dürfte auch nicht schlecht sein, aber vermutlich nicht so einfach übertragbar...

Vorschlag zur Grafik (das sagt in der Tat manchmal mehr als x Worte...):

Basis könnte die von hier sein: https://wiki.fhem.de/wiki/System%C3%BCbersicht, (als Hintergrundgrafik etwas "verblasst"?).

Die erste Variante wäre dann mit 1. MQTT2_SERVER und 2a. (mehrere) MQTT2_DEVICEs  sowie 2b. MQTT_GENERIC_BRIDGE als FHEM-interne Clients (und 2+ "anderen" FHEM-Devices als "Clients" zur MQTT_GENERIC_BRIDGE), und tasmota, Shelly, zigbee2mqtt... als "Komponenten", jeweils mit dem Domoticz-"Doppelpfeil" zum MQTT2_SERVER, alles innerhalb des FHEM-Kastens, wobei ich den MQTT2_SERVER grafisch etwas nach rechts in die "Interfaces" reinragen lassen würde und den "FHEM-Kasten" da eine Ausbuchtung haben.

Zweite Variante: wäre dann mit 1. getauscht zu MQTT2_CLIENT (der Rest "links" identisch), aber dann in den originalen FHEM-Kasten verschoben und mosquitto unter Interfaces. Domoticz-Doppelpfeile dann zwischen den externen Komponenten und mosquitto sowie mosquitto und MQTT2_CLIENT.
 
Zuletzt dann Abwandlung zur zweiten Variante: 00_MQTT statt MQTT2_CLIENT, MQTT_DEVICE statt MQTT2_DEVICE.

Nachvollziehbar?
Gut?

(Eigentlich könnte man die Ausgangsgrafik auch mal modernisieren, aber das ist wieder ein anderes Thema...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Maui

Zitat von: Beta-User am 22 Juni 2019, 09:30:04
@Maui:
Welche Module kennst du bzw. hast du im Einsatz?
Was macht "MQTT" für dich zum "Brett"? Kannst du das näher beschreiben?
Zu MQTT bin ich über sonoff und tasmota gekommen. Und da dann (meine zu der Zeit gab es in FHEM auch keine Alternativen) mit mosquitto und MQTT_DEVICE.
Bei einem User Treffen hat mir hexenmeister die GENERIC BRIDGE schmackhaft gemacht.
Bei einer neuen FHEM Instanz bin ich dann mal mit MQTT2_SERVER UND _DEVICE auf Tuchfühlung gegangen. Hat bei tasmota super geklappt aber als Bridge zwischen mehreren Fhem Instanzen hat das autocreate bei mir alle publishes in ein autocreate Device gepackt (da selbe IP?!)
Hab mich dann nicht weiter mit beschäftigt da ich mit der GB durchweg gute Erfahrungen habe.

Okay Brett war vielleicht ein wenig zugespitzt aber ich versuche immer an den DAU zu denken und verglichen mit manchen Modulen wo eine Zeile define ausreicht zur Einrichtung bedarf es im Fall MQTT schon mehr. Wobei MQTT2_SERVER mit autocreate da schon viel abnimmt.

Apropos Bridge, kenne leider die Wiki Artikel nicht so gut, gibt es da schon was bzgl. MQTT als Alternative zu RFHEM bzw. FHEM2FHEM? Und wenn nicht, wie sinnvoll seht ihr das?
Ich nutze es wie gesagt mit GB um meine aktuell 3 Instanzen miteinander kommunizieren zu lassen, wobei ich natürlich nur selektiv Publishe. Der Vorteil ist halt, 1x gepublisht, ist es in allen Instanzen (wenn gewollt)

DasQ

#20
Ich mach nachert mal ein ersten Entwurf.


ZitatBasis könnte die von hier sein:
wie meinst denn des? die grafik original oder als template
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

Beta-User

Die Grafik oben auf der verlinkten Seite...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DasQ

#22
schau mal dir den ersten schuss ins blaue an.

btw. kann ich das auch als grundlage für die ausgangsgrafik nutzen ... also auch wenns total falsch ist, ist das kein problem ;-D
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

Beta-User

Zitat von: DasQ am 22 Juni 2019, 16:52:22
schau mal dir den ersten schuss ins blaue an.
Wo? Hier und im Wiki finde ich nichts...

Zitatbtw. kann ich das auch als grundlage für die ausgangsgrafik nutzen ... also auch wenns total falsch ist, ist das kein problem ;-D
Das sollte bitte in einen gesonderten Thread hier, damit (mindestens) Peter und Christian was dazu sagen können.

Wenn du da was vorarbeiten wolltest:
Der Spur nach würde ich z.B. ZWave ergänzen, dafür "Arduino" rauswerfen (das ist mir zu unspezifisch, aus dem Folgenden ergibt sich, dass wohl firmata gemeint ist, aber das ist sehr speziell => würde ich ganz weglassen) und unter den TCP/IP-Komkonenten dann gleich MQTT als eine von mehreren Optionen ergänzen (da gehören nach meinem Verständnis z.B. noch HTTPMOD, HMCCU und HUEBride als wichtige Vertreter rein... (interaktiv wäre super ::) )); bei MQTT dann aber erst mal ohne den "Schnickschnack" mit den diversen Varianten.

(Dieser Artikel sollte wohl bei Gelegenheit auch mal renoviert werden, da fehlt m.E. ein Abschnitt zu den immer wichtiger werdenden TCP/IP-Interfaces; neben den oben genannten fehlen da z.B. auch noch tradfri-und Xiaomi-Bridge (nebst bluetooth-Variante), ....)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DasQ

#24
ich bin doch ein alter postings recycler ... hatte das oben editiert.  ;)

ich bau die änderungen im "fhem systemübersicht" gleich nach dem abendessen ein


Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

Beta-User

Das untere ist recht gut (einen Schreibfehler bei Komponenten habe ich auf die Schnelle gefunden), aber dass TCP/IP da dazwischen hing, war m.E. kein Fehler und sollte auch (ausschließlich) so bleiben. Lediglich der Kasten kann so groß werden, dass er die drei genannten Beispiele beherbergt. (die anderen Komponenten sind m.E. Hardware). Eventuell auch die betreffende Box übergreifend machen (bis rüber zu Hardware, aber ebenfalls nicht bis ganz rechts, so dass es nur teilweise überlappt, so wie links oder leicht mehr) und dann Mqtt in die Mitte schreiben, HueBridge und HMCCU nach rechts, da "echte" Hardware-Komponenten?
Und wie gesagt: Statt Arduino dann ZWDongle da rein und rechts bei Komponenten ZWave.

Bei dem anderen sollte m.E. das Ausgangsbild (abgeblendet) im Hintergrund bleiben (einschließlich der weiter geltenden funktionalen Einordnung, z.B. zu Interface!) und die weiteren Komponenten mit einer einheitlichen (Box-) Formatierung in den Vordergrund darüber gelegt werden; sonst ist die Frage, warum die einen eine Wolke haben, die anderen aber nicht...

(Meine Güte, ist das schwierig zu beschreiben)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DasQ

#26
weis nicht ob des jetzt ne gute idee war, bin aber der meinung es gehört das protokoll auch mit rein.
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

Beta-User

keine gute Idee, bitte erst mal nicht kreativ sein, sondern 1:1 (und ZWave ist nicht 2.4 GHz, das ist zigbee, und darum ging es nicht...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DasQ

#28
zwischenstand (für heut feierabend) :)


Die Pfeile sind Bohhässlich ... die werden aufjedenfall noch ordentlich (bin etwas eingerostet)
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

Beta-User

#29
Gefällt mich schon viel besser... :)

Die üblichen ABERs (sorry, da sind jetzt auch neue Dinge bei...):
- Bei Interfaces sollte man m.E. HMLan durch HMUARTLGW/CUL ersetzen (sperrig, aber aktuell, darf ruhig klein geschrieben werden...); unter ZWave (das ist die korrekte Schreibweise...) gehört dann ZWDongle, und der Pfeil sollte wohl auch blau werden ("Luftschnittstelle").
- FHZ ist outdated (m.E.), da könnte stattdessen Signalduino links stehen und rechts IT/Lacrosse-Komponenten.

- MQTT ist nach meinem Verständnis ein Unterfall von TCP/IP, das sollte nicht separat stehen, sondern IN den Kasten rein, aber nicht alleine:
TCP/IP sollte dann als Überschrift klar drüber stehen (vielleicht etwas weiter links), darunter dann unterhalb von MQTT mind. noch CCU3 und HUEBridge (in den Interface-Block), jeweils mit passenden Komponenten rechts; also für die CCU3 dann noch HomeMatic UND Homematic-IP (so dass HM dann ggf. 3x auftaucht; ob eine Linie nach oben sinnvoller wäre (oder man den Block insgesamt nach unten packen sollte): unschlüssig...)

Aber bitte, wenn jemand da besseres Wissen hat: Melden...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files