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"...
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?
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_DEVICE)
https://wiki.fhem.de/wiki/MQTT_(Modul (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.
Mein Blickwinkel wäre: Wiki ist für Anfänger, die etwas verstehen und dann einrichten wollen. Für die würde ich schreiben.
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.
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...
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:
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
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)).
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.
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
Zitat von: Beta-User am 21 Juni 2019, 06:36:02
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?
Zitat von: andies am 21 Juni 2019, 07:47:51
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)).
ZitatIch 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).
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.
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)
@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.
Dein letzten Absatz peil ich nicht. Warum zweimal IO
Zitat von: DasQ am 22 Juni 2019, 10:01:21
Dein letzten Absatz peil ich nicht. Warum zweimal IO
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")
)
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.
Hmmm, das war mit den "Bildchen" in https://wiki.fhem.de/wiki/MQTT (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 (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...
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 ::)
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.
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...)
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)
Ich mach nachert mal ein ersten Entwurf.
ZitatBasis könnte die von hier sein:
wie meinst denn des? die grafik original oder als template
Die Grafik oben auf der verlinkten Seite...
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
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), ....)
ich bin doch ein alter postings recycler ... hatte das oben editiert. ;)
ich bau die änderungen im "fhem systemübersicht" gleich nach dem abendessen ein
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)
weis nicht ob des jetzt ne gute idee war, bin aber der meinung es gehört das protokoll auch mit rein.
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...)
zwischenstand (für heut feierabend) :)
Die Pfeile sind Bohhässlich ... die werden aufjedenfall noch ordentlich (bin etwas eingerostet)
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...
Zitat von: Beta-User am 18 Juni 2019, 16:48:06
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.
Ich muss noch mal ganz auf Anfang. Kann mir jemand mal erklären, wozu es diese Generic_Bridge gibt? Das ist im Wiki auch nicht so erklärt, dass ich es verstehe.
Ich schreibe auch mal die Hauptseite sprachlich um.
Noch einmal, was ich nicht verstehe. Im Wiki steht
ZitatBriges und Devices unterscheiden sich wie folgt. Eine Bridge ist ein Gerät, das bereits in FHEM angelegt wurde und nur mit MQTT verbunden werden soll. Ein Device existiert noch nicht in FHEM und soll erst angelegt werden.
Wieso? Ein Device wird doch auch über das IODev mit MQTT verbunden und das device muss doch angelegt werden, damit es in FHEM ein device wird?! Sonst ist es gar nichts.
Thx Beta Bau ich nachert um. Ich dürft auch gern freihandskizzen machen (abfotografieren und Posten) oder in die Bildchen von mir mit paint oder was auch immer drin rumeditieren, ich mach das dann schon ordentlich ::)
Zitat von: andies am 23 Juni 2019, 10:10:09
Ich muss noch mal ganz auf Anfang. Kann mir jemand mal erklären, wozu es diese Generic_Bridge gibt? Das ist im Wiki auch nicht so erklärt, dass ich es verstehe.
Ich schreibe auch mal die Hauptseite sprachlich um.
Ich versuche es mal aus Anwendersicht.
Im Thread zu der GENERIC_BRIDGE (GB) wird es im Grunde auch erklärt.
Die GB sammelt und verteilt alle MQTT-Meldungen. Sowohl empfangend als auch sendend.
Ein Beispiel. Du hast ein tasmota Gerät (sonoff zb) und willst das in FHEM mit DOIF beim Klicken/Schalten... mit bestimmten Aktionen belegen. Durch die GB kannst du mit mqttSubscribe und mqttPublish einfach den PowerState lesen und ein Schalten senden. Du hast dadurch alles was du brauchst in einem Device.
Das gleiche geht natürlich mit dummy.
Oder wofür ich sie hauptsächlich nutze. Als RFHEM Ersatz.
Ich habe ein Device beliebigen Types auf einem meiner 3 Fhem Instanzen. Alle 3 fhems haben eine GB definiert und das MQTT-IoDev zeigt bei allen auf mein MQTT-Server.
Nun habe ich zb die Wettervorhersage auf einer Instanz und möchte die Readings in der Hauptinstanz haben da ich dort (fast) alle Logik abhandle.
In Fhem 2 (neben) sei ein Device mit wea_Ort und einigen Readings. Dort ein
mqttPublish
*:topic={"$base/$device/$name"}In Fhem 1 (Haupt) definiere ich ein dummy mit dem gleichen Namen.
Nun reicht mir als Attribut
mqttSubscribe
*:topic={"$base/$device/$name"} und beim nächsten update bekomme ich alle Readings auf mein hauptDevice.
Möchte ich es jetzt ebenfalls in Fhem 3 sehen, so reicht mir ebenfalls ein subscribe.
Ein Event-on-change-Reading .* ist natürlich sinnvoll auf Fhem 2.
Jetzt habe ich ein wenig ausgeholt aber ich hoffe so konnte man es verstehen.
Gruß
Maui
zwischenstand ... mittagessen ::)
@DasQ: SlowRF darf SlowRF bleiben, und der Kasten TCP/IP sollte immer noch um die unteren als Beispiele herum gehen; dazu fehlen ein paar bereits genannte Dinge (v.a. HM-IP; da stolpern viele Anfänger drüber...)
MQTT_BRIDGE und MQTT_GENERIC_BRIDGE hat Maui ja bereits erklärt, wobei m.E. das Beispiel mit dem sonoff nicht optimal ist, weil der (vermutlich) bereits selbst MQTT spricht (wenn z.B. mit tasmota geflasht). Es geht aber gerade (auch) darum ein beliebiges Device (z.B. ein CUL_HM oder ZWave-Gerät) aus FHEM heraus MQTT-fähig zu machen (um es in einer anderen HA-Lösung zu nutzen, oder als F2F-Ersatz). Früher brauchte man da für jedes einzelne FHEM-Gerät je ein MQTT_BRIDGE-Gerät, seit ca. Anfang 2018 macht das eben MQTT_GENERIC_BRIDGE als zentrale Instanz "one for all" (deswegen sollte man m.E. MQTT_BRIDGE eigentlich nach contrib schieben und gar nicht mehr intensiver besprechen).
Zitat von: Maui am 23 Juni 2019, 12:16:55
Ich versuche es mal aus Anwendersicht.
Würde diese Beschreibung dann die Sache treffen?
Zitat
In FHEM kommunizieren das Server-device (in dem Beispiel oben ist das mybroker) direkt mit dem (externen oder internen) MTTQ-Broker. Jedes MQTT-fähige Gerät benötigt dann ein entsprechendes FHEM-device, in dem Readings angelegt und verändert werden und von dem aus Befehle an den Broker abgesetzt werden, die dieser dann an das MQTT-fähige Gerät verteilt. Das bedeutet, dass die Signale und Befehle verschiedener MQTT-fähiger Objekte ohne Bezug zueinander von FHEM verarbeitet werden.
Es kann sinnvoll sein, innerhalb von FHEM diese Signale und Befehle der verschiedenen MQTT-fähigen Geräte zu bündeln, damit einfachere Befehlsstrukturen innerhalb von FHEM möglich werden und die Verarbeitung der Information leichter von statten geht. Zu diesem Zweck kann man sich eine MQTT-Bridge installieren, die dann diese Aufgaben übernimmt. Eingerichtet wird die Bridge mit dem Befehl
?Mit welchem denn?
Das Modul MQTT_GENERIC_BRIDGE kann seit November 2018 mit allen drei IO-Modul-Varianten zusammen eingesetzt werden, also sowohl mit MQTT2_SERVER bzw. MQTT2_CLIENT oder MQTT (00_MQTT.pm)...
Dann trage ich das nämlich ins Wiki ein.
Zitat von: Beta-User am 23 Juni 2019, 12:45:11
Es geht aber gerade (auch) darum ein beliebiges Device (z.B. ein CUL_HM oder ZWave-Gerät) aus FHEM heraus MQTT-fähig zu machen
Ach so!!! Das Ding brückt beliebige FHEM-Befehle in MQTT?
(Kann ich mal ein Beispiel kriegen, wo das sinnvoll ist? Ich habe ein beliebiges device, das nicht MQTT kann. Ich brücke das zum Broker und das spricht jetzt MQTT. Und dann? Ich bin doch außerhalb von FHEM, wozu das?)
so ganz hab ichs noch nicht gerafft wie ich das mit der bridge visualisieren soll.
wir wollten das glaub eh in einer zweiten/dritten... grafik aufbauen
soll jetzt hier in die grafik, noch der broker in die interface spalte? das wär dann halt "allgemein"
und den part mqtt2, bridge, device usw. in die zweite grafik
****edit ********
Aktuelle Bilder im andern Thread
"Befehle" finde ich den falschen Ausdruck.
Beide BRIDGE-Module ermöglichen es, z.B. einen CUL_HM-Aktor von "außerhalb" ein- oder auszuschalten oder eben z.B. ein Reading zu publishen. Die GENERIC_BRIDGE erweitert dazu schlicht die globale Attribute-Liste, so dass dann sende- und empfangsseitig einfach "überall" die entsprechenden Attribute gesetzt werden, das war's schon (und es gibt einen Thread von hexenmeister mit ganz vielen Beispielen; der ist auch mehrfach verlinkt...).
Und bitte: wir sind betriebsblind auf FHEM fixiert, es gibt aber Leute, die gerne eine andere Visualisierungslösung nutzen, und (afaik) z.B. HASS arbeitet rein MQTT-basiert (es gibt zu den Themen auch einen längeren Thread). Oder man haut auf dem MQTT-Weg Meßdaten raus in die weite Welt, verbindet FHEM-Instanzen (MQTT ist vergleichsweise tolerant gg. Verbindungsabbrüche...)
Die Terminologie "Broker" ist übrigens veraltet, afaik. Man sollte immer Server schreiben (und ggf. MQTT2_SERVER schreiben, wenn man eine bestimmte Softwarelösung meint).
Zitat von: andies am 23 Juni 2019, 12:53:18
Würde diese Beschreibung dann die Sache treffen?Dann trage ich das nämlich ins Wiki ein.
M.E. nein, jedenfalls ich verstehe so schlicht nicht, was gemeint ist...
Technisch:
- "In FHEM" kommuniziert das IO-Modul mit seinenClient-Modul-Devices im Sinne des zweistufigen Modulkonzepts, nur nach außen wird als Protokoll ein bestimmter TCP/IP-Layer verwendet (MQTT). Ist das IO-Modul MQTT2_SERVER, braucht man keinen weiteren Server (Broker), dann hat man nur MQTT-Clients (wie tasmota-geflashte ESP's, den zigbee2mqtt-Dients usw.).
- Wie man Nachrichten miteinander zu einem "virtuellen Ort" (einem FHEM-Device, gedacht als "define"-Anweisung), ist praktisch beliebig. Ich würde das als reine Zweckmäßigkeitsfrage bewerten. Man kann nämlich z.B. eine Message ohne weiteres auch an mehrere (FHEM-interne) Clients verteilen (machen wir z.B. bei den Milight so für einzelne Bulbs und Gruppen) oder Devices anlegen, die Informationen aus vielen Quellen bündeln uswusf.
Was die Grafik angeht: Was ist mit bridge gemeint? Ich hatte die HUEBridge genannt und versucht zu erläutern, dass die und die CCU3 ein Unterfall eines TCP/IP sprechenden Geräts sind, also der Farbkasten TCP/IP so groß sein sollte, dass die beiden samt MQTT da umschlossen sind (das Wort MQTT würde ich dabei aber etwas aus dem Interface-Bereich raus nach rechts rausragen lassen, das hat ja keinen definierten physischen Ort, wo sich das zwingend befindet wie eine typische CCU3 oder eine HUEBridge)
Zitat von: andies am 23 Juni 2019, 12:53:18
Würde diese Beschreibung dann die Sache treffen?Dann trage ich das nämlich ins Wiki ein.
Ich würde auch eher nein sagen. Man versteht nicht was gemeint ist.
Aber wo denn eintragen? Ein neuer Wiki Eintrag über die GB?
Ist das denn jetzt schon so sinnvoll, wenn quasi das ganze Thema MQTT hier noch in der Diskussion ist?!
Mein Beispiel mit dem Wetter ist ja etwas dem MQTT "beigebracht" wird.
Beispiel-define
defmod mqttGB MQTT_GENERIC_BRIDGE
attr mqttGB IODev mqtt
Zitat von: Beta-User am 23 Juni 2019, 13:27:19
- "In FHEM" kommuniziert das IO-Modul mit seinenClient-Modul-Devices im Sinne des zweistufigen Modulkonzepts, nur nach außen wird als Protokoll ein bestimmter TCP/IP-Layer verwendet (MQTT). Ist das IO-Modul MQTT2_SERVER, braucht man keinen weiteren Server (Broker), dann hat man nur MQTT-Clients (wie tasmota-geflashte ESP's, den zigbee2mqtt-Dients usw.).
OK. Kann man dann entsprechend sagen
Zitat
Verwendet man andere Visualisierungslösungen statt FHEM oder möchte man nicht MQTT-fähige Objekte MQTT-fähig machen, kann es sinnvoll sein, sich einer generic MQTT Bridge zu bedienen. Diese Bridge erweitert die globale Attribute-Liste, so dass auch in nicht MQTT-fähigen Devices entsprechende Sende- und Empfangsattribute gesetzt werden können.
Schwere Geburt...
Es wäre wichtig zu unterscheiden bezüglich
native IOs und externe Soft/Hardware
als Beispiel Bild
@andies: Generell bin ich mit den heutigen Änderungen im Wiki-Artikel überwiegend nicht sehr glücklich.
Vielleicht wäre es eine Idee, den überarbeiteten Textvorschlag erst mal hier zu posten? Dann kann man das diskutieren. Dauert zwar länger, ist aber bei einem zwischenzeitlich so zentralen Protokoll halt ggf. notwendig.
Kritikpunkte:
- Der Begriff "Broker" ist veraltet, man sollte das also auch nicht mehr in einem aktualisierten Wiki-Artikel häufiger als notwendig verwenden.
- Die Warnung bzgl. des Loop-Bauens stand da nicht umsonst, bitte daher etwas mehr "Respekt", bevor was rausfliegt (man kann zu diskutierenden Entfernen-Text auch in Fußnoten verbannen oder erst mal auskommentieren).
- hexenmeister nutzt afaik selbst z.B. gar keine MQTT_DEVICE-Geräte mehr als Clienst zu 00_MQTT... (sondern macht alles mit GB+dummy, weil er es einfacher zu konfigurieren findet)
- Was die "richtige" oder empfehlenswerte Variante angeht: Das ist nicht wiki-like, und wenn, sollte man wenigstens so konsequent sein und dann die nicht mehr empfohlene Vorgehensweise "nach hinten" verbannen. So ist es erst recht "Kraut und Rüben", um manche Zeitgenossen zu zitieren >:( .
Just my2ct.
Generell habe ich jedenfalls keine Lust, hinterher alles wieder zu reparieren.
Was GB und Wiki angeht, wäre vermutlich ein eigener Artikel ok (mal wieder ausdrücklich gegen die "Ein-Artikel-Fraktion!).
ABER: es gibt diesen (m.E. tollen) Thread von hexenmeister. Man sollte respektieren, dass er als Modulautor diesen Weg gewählt hat und dann dort im Wesentlichen nur die allg. Funktionsweise erläutern und auf den Thread verweisen (nur meine Meinung).
(Ich hätte vermutlich schon lange einen angelegt, aber zu wenig Erfahrung, um das "mit Hand und Fuß" zu machen. Und über Dinge, von denen ich nicht annehme, dass ich sie gedanklich durchdrungen habe, schreibe ich prinzipiell keine Wiki-Artikel, sondern überlasse das denen, die wissen, was sie tun... :P )
Zitat von: andies am 23 Juni 2019, 14:13:35
OK. Kann man dann entsprechend sagen.
Jein.
Zum einen: Was ist ein "Objekt"? Wir sprechen von Geräten (=define!), oder?
Warum man MQTT als Transportschicht nutzt, ist m.E. völlig irrelevant, und nicht jede andere Visualisierungslösung "kann MQTT". Was bleibt ist: Ich habe ein beliebiges FHEM-Device, das noch nicht MQTT spricht und will dem jetzt "MQTT beibringen". Wie mache ich das? (Antwort: MQTT_(GENERIC_)BRIDGE)
Und da ich GB nur kurz angetestet habe, will ich zu dem 2. Satz keine Wiki-fähige Aussage machen (s.o.).
Zitat von: fhem-hm-knecht am 23 Juni 2019, 14:28:31
Es wäre wichtig zu unterscheiden bezüglich
native IOs und externe Soft/Hardware
als Beispiel Bild
Die Unterscheidung in native IO's und externe Soft-/Hardware finde ich gut.
Für MQTT würde ich dann oben allerdings MQTT2_SERVER schreiben und unten MQTT/MQTT2_CLIENT. (Ist leider alles verdammt lang, aber Abkürzen verwirrt da, oder?)
hab jetzt nochmals von vorn bis hinten überflogen und hau jetzt mal einfach ein ersten entwurf für MQTT raus.
edit doofe erste idee .. ggf wird jetzt einleuchtender
Zitat von: Beta-User am 23 Juni 2019, 14:37:39
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.
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
Zitat von: andies am 23 Juni 2019, 15:00:03
Nein, damit meinte ich zum Beispiel eine Sonoff-Lampe, eine Blitzwolf-Steckdose oder was auch immer.
:o 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?
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
Ich Klinke mich jetzt erstmal hier2 Wochen aus, da Urlaub.
Gruß
Zitat von: DasQ am 23 Juni 2019, 16:11:12
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.
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.
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.
Zitat von: Beta-User am 24 Juni 2019, 12:15:48
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 (https://wiki.fhem.de/wiki/MQTT_Einf) 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?
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 ;)
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).
hier mal ein schuss ins blaue ;)
wie soll man die interne verarbeitung in fhem zwischen den einzelnen modulen visualiseren
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?
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. 8)
Zitat von: DasQ am 25 Juni 2019, 13:35:44
ok, jetzt ist ne inspiration da. ::)
Das klingt verheißungsvoll :) .
Zitatwie 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 :P , und habe auch entsprechende Hardware (nur - wie gesagt - MQTT_GENERAL_BRIDGE nicht im Einsatz)...
Zitat[...] was hat mich da geritten [...]
und ganz nebenbei, vielleicht hab ich ja noch die ein oder andere überaschung in petto. 8)
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) ;D ...
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 (https://wiki.fhem.de/wiki/HM-Sec-RHS_Funk-Fenster-Drehgriffkontakt) (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).
Zitat von: Beta-User am 24 Juni 2019, 15:07:38
In dem https://wiki.fhem.de/wiki/MQTT_Einführung (https://wiki.fhem.de/wiki/MQTT_Einf) 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?
So, jetzt dürft ihr Rückmeldung geben zum aktuellen Stand. Der Einführungs-Artikel besteht (aus Kompabilitätsgründen) jetzt nur noch als Weiterleitung zu https://wiki.fhem.de/wiki/MQTT. Da steht (imo) jetzt alles wesentliche drin, was man so im Zusammenhang mit FHEM und den diversen Modulen kennen sollte.
Ein paar Kleinigkeiten sind noch offen, die sind aber m.E. nicht tragisch, (aber in Teilen außerhalb meines aktuellen Erfahrungshorizonts). Die Stellen sind entsprechend gekennzeichnet, wer also mag und kann, darf die gerne ergänzen, dto für Schreibfehler, kaputte links usw.).
Ansonsten dürft ihr jetzt nach Herzenslust wieder kritisieren und mitteilen, was denn nicht verständlich ist, umständlich geschrieben usw...
(Mal ab davon, dass Details zu Arduin-Programmierung imo wirklich nichts im zentralen Artikel verloren haben; das könnt ihr euch sparen, werde jedenfalls ich da nicht im Detail reinbauen... (und dies nicht mangels Kenntnis/Erfahrung; das habe ich @ESP8266 schon vor längerem mal gemacht :P ).
Die Grafiken wären dann zukünftig jeweils bei der Einbindung in FHEM (IO-Beschreibung) zu finden (MQTT2_SERVER, MQTT2_CLIENT, MQTT) wenn sie denn dann fertig sind.
Aus gegebenen Anlass (ohne das ich jetzt ins Wiki geschaut habe, ob's das schon gibt):
wunschwikiartikel -> attrTemplate (allgemein oder explizit MQTT)
Zu einen die Templates zeigen, zum andern die templates erklären und zu guter letzt, Hardware bezogen Fallstricke, bekannte Fehler Quellen ( z.b. Sowas (https://forum.fhem.de/index.php/topic,101713.msg953589.html#msg953589) )
***edit***
So jetzt hab ich nachgesehen und das hätt ich besser nicht gemacht. ::)
Ich glaub das mit den templates wird ein eigner Thread... das posting hier von mir am besten schnell vergessen oder nur im Hinterkopf halten.
mir ist eben (s.o.) aufgefallen das SonOff (https://wiki.fhem.de/wiki/Sonoff) im wiki, auch MQTT behandeln.
in wie weit das nun doppelt im wiki behandelt werden muss, lass ich mal dahingestellt, es verwirrt aufjedenfall den laien.
vielleicht sollte man das auch noch splitten/aufteilen sinnvoller gestalten.
im prinzip ist es, wie du @Beta-user oben schon gesagt hast, wie mit dem Arduino, eigentlich gehört der so auch nicht ins MQTT-FHEM-wiki.
erster entwurf auf deiner grundlage
Zitat von: DasQ am 30 Juni 2019, 11:25:27
erster entwurf auf deiner grundlage
Das sieht super aus. Nur eine kleine Frage: Das Wort "Module" (Mehrzahl) suggeriert bei mir .pm-Dateien. Sind das nicht eigentlich FHEM-devices, die da stehen?
hab ich mir auch gedacht, als ichs hochgeladen hab ... ;) ::)
ich kann ja den kasten "module" aufteilen und unten ein eigenen kasten für die FHEM-devices machen.
Mal eine Teilantwort:
Das Diagramm paßt ziemlich gut, evtl. sollte man den "Module"-Kasten oben deutlicher auch um MQTT2_CLIENT laufen lassen? Denn: Es sind tatsächlich so 2 .pm involviert, darunter mehrere Instanzen von MQTT2_DEVICE. Für 00_MQTT.pm+MQTT_DEVICE wäre es so ok (will heißen: erst Kopie machen und so anpassen), für MQTT2_CLIENT fehlt m.E. eine Instanz: das "Sortier"-Device auf Basis des A_00_MQTT2_CLIENT_....
Da der Bereich in der "Basisgrafik" auch so überschrieben ist, ist das m.E. ok, hier etwas "unscharf" zu sein, eine Unterscheidung zwischen "Module" und "FHEM-Device" würde ich nicht vornehmen, evtl. nur eine Art "Doppelbeschriftung", vielleicht "Module bzw. FHEM-Geräte" (zu "Gerät" gibt es einen Artikel, der den üblichen Sprachgebrauch von Device erläutert).
Es wäre evtl. die Frage, ob man den Server-Block nicht auch hier nach links packt und dann von links nach rechts andordnet statt oben/unten (und dann MQTT/Non-MQTT übereinander). Da aber die Verbindungen passen (vielleicht mit der Einschränkung, dass uU. der Arduino nur publisht, und afaik alle anderen genannten wirklich immer bidirektional arbeiten).
"Lemdkr" lese ich zum ersten Mal, muß man das kennen?
(Zur Funktionsweise des A_00...: Das Teil ist eine Art "Helfer"-Device für autocreate. Es generiert aus dem Topic-Tree einer Nachricht, für die es noch keinen Abnehmer gibt eine CID, die dann zur Zuordnung zu einem bestehenden oder ggf. dann neuen Device dient... Ganz ähnlich dem, was die zigbee-Bridge oder die MiLight-Bridge-Devices auch tun, nur dass dort eben kein entfernter Dienst dahinter steht, sondern "typische"Topic-Strukturen analysiert werden. Zur etwas abweichenden Formatierung hatte ich schon was geschrieben...)
Was die verteilten Infos zu sonoff&Co angeht:
Wenn die Basisdinge deutlich erklärt sind, genügt in Schritt 1 m.E. mal ein Hinweis/link zu den jeweiligen Stellen in den Grundlagenartikeln, ggf. verbunden mit einem kurzen (!) Hinweis, dass das ggf. eben nur eine Variante beschreibt.
Das mit den attrTemplates würde ich zwischenzeitlich dann auch in einen eigenen Artikel auslagern wollen. Gibt ja zwischenzeitlich mehrere Module, für die entsprechende files im svn sind. Aber bitte: nicht alles auf einmal...
(Meine persönliche Devise: Wenn ich irgendwo was anfange, dann mit dem Ziel, das auch fertig machen zu können/wollen (von Randthemen wie hier SSL evtl. abgesehen). Das führt zwar uU. zu einem Flickentepich, ist aber m.E. besser, wie wenn dann überall nur noch Baustellen sind; letzteres ist dann m.E. auch nicht übersichtlicher...).
Grafik an sich gefällt mir
Den ganz bösen Typo noch ändern
Ähm, diese nachträglichen Änderungen von Beiträgen sind ganz schön verwirrend.
Also die Herausnahme von MQTT2_DEVICE aus "Module" ist m.E. sachlich falscher, als mehrere Instanzen in "Module" zu haben. Wenn nicht jemand gute Argumente liefert, warum das so sein soll, bitte ändern (ggf. unter Berücksichtigung meiner vorherigen Anmerkung zur Namensgebung, die noch ohne Kenntnis der aktualisierten Grafik erfolgte).
@Hary: Danke für den Hinweis auf den Typo; da hatte ich wohl die Wunschlesebrille auf...
@Beta-User das hat sich mit uns etwas überschnitten.
Zitat von: Beta-User am 30 Juni 2019, 12:33:55
"Lemdkr" lese ich zum ersten Mal, muß man das kennen?
Wir haben zu 3. versucht dein text aus dem anfangs PDF zu interpretieren und sind einhellig auf Lemdkr gekommen. ;D :D
Ganz ehrlich, ich konnts nicht lesen. Was steht da oben rechts in deim PDF?
und jetzt mit dem MQTT_CLIENT, hab ich noch nicht ganz verstanden. Kannst mir des in des Bild rein editieren/schreiben?
;)
***edit****
ach jetzt hab ich glaub verstanden was du willst, mit dem links nach rechts. änderung kommt in ner halben stunde.
Leuchte paßt ;D , dafür bitte aber nochmal:
- Der "Module"-Kasten muß auch um die MQTT2_DEVICEs rum, darf aber zusätzlich mit "/FHEM-Geräte" beschriftet sein.
- Bitte alle MQTT_CLIENT-Texte durch MQTT2_CLIENT ersetzen (Überschrift und Modul)! Wenn hier allgemein von irgendeinem Kommunikationsteilnehmer in MQTT die Rede ist, ist die Schreibweise MQTT-Client (die Großbuchstaben haben da - wie sonst auch - eine Bedeutung...). Und MQTT2_CLIENT ist ein ganz spezieller Fall eines MQTT-Clients (ähnlich wie "MQTT" als einer Instanz von 00_MQTT.pm).
- In diesem Schaubild mit MQTT2_CLIENT brauche ich bitte dieses "spezielle" weitere MQTT2_DEVICE-Gerät, das ich bereits mehrfach erwähnt hatte...
Allgemein habe ich den Verdacht, dass der aktualisierte Artikel immer noch nicht verständlich zu sein scheint, (oder nicht gelesen wurde), da sollten sich die (begrifflichen und logischen) Zusammenhänge eigentlich draus erschließen...
(Liegt es an der Hitze, oder warum habe ich den Eindruck, dass in einem Neudreh von "Täglich grüßt ..." bin und immer wieder dasselbe schreibe, und schon wieder einen Zwischenedit nicht mitbekommen habe ;D ?)
Ohne Edit: Wenn du statt MQTT_CLIENT jetzt 00_MQTT.pm schreibst und die Module-Box anpaßt, ist das (bis auf die Pfeile) soweit ok.
Nur für MQTT2_CLIENT brauche ich das weitere MQTT2_DEVICE (und die sollten dann auch den "2"-er drin haben!)
:)
links nach rechts ?
(sollte das ok sein, bau ich deine letzten änderungen da ein)
(und gleich wieder den ersten fehler entdeckt ... den server hab ich falsch zusammengeschraubt)
(ich glaub es wird wieder zu warm) ::)
Optisch so ähnlich (Beschriftungen sind immer noch zu ändern!), nur:
- Den MQTT-Teil im Server in die besagte alles inkludierende "Module/FHEM-Geräte-Box" und drehen, so dass das IO (MQTT2_CLIENT bzw. 00_MQTT.pm) rechts steht.
- die beiden anderen Blöcke übereinander, "non-MQTT" unten (da kann es auch andere Verbindungen zwischen FHEM und dieser Art Aktor/Sensor geben (für diese Grafik wäre es aber an sich egal)
Dazu evtl. den Mosquitto-Kasten innerhalb MQTT nach unten links, und Zigbee2mqtt rechts unten ("dahinter"), damit die Verbindung dann von dort aus nach unten in den "non-MQTT"-Kasten leichter darzustellen ist.
so?
Noch nicht ganz :) ...
Anbei zwei Scans, Erläuterungen dazu:
Fang bitte erst mit der MQTT2_CLIENT-Version an (aber noch nicht (1) einarbeiten, da das der Punkt ist, der die 00-MQTT.pm-Version von der MQTT2_CLIENT-Version unterscheidet):
A Grundlayout:
- (3) Die Server-Box darf etwas kleiner werden, die MQTT-Box und die non-MQTT-Box jeweils größer, Mosquitto darf etwas weiter nach links, dafür die HUE-Bulb (4)/Zigbee-Boxen etwas nach rechts, die non-MQTT-Box sollte nicht in einer "Achtung"-Farbe gehalten sein (5). (Ja, es entsteht relativ viel freie Fläche in der non-MQTT-Box... Genau das ist beabsichtigt!)
-- "FHEM-Modul" sollte FHEM-Modules/FHEM-Devices belabelt werden (wenn Englisch, dann ganz, (6)) und die Farbgebung des Hintergrunds (zur Systemübersicht unverändert) das dunklere Blau bleiben (2).
-- Ob man eine Box für FHEM-Devices in der Modules-Box braucht? finde ich tendenziell nicht, aber wenn, gehört der Rahmen auch um MQTT2_CLIENT
- Die Farbgebung des Hintergrunds der einzelnen Devices würde ich einheitlich halten, aber nicht unbedingt weiß, optional einheitlich zu den Sensoren/Aktoren in den MQTT/non-MQTT-Boxen. "...CLIENT" wäre dabei ein Sonderfall, das könnte denselben Hintergrund haben wie die Mosquitto-Box (?)
Wenn das soweit ist, bitte melden. Was dann (u.A., zu MQTT_GENERIC_BRIDGE kommen wir später) als nächstes folgt:
B 00_MQTT.pm-Variante
Wenn wir das soweit haben, können wir die 00_MQTT.pm-Variante finalisieren. Da wäre nur die Überschrift zu ändern in "FHEM MQTT communication (using 00_MQTT.pm)", das IO-Device mit "MQTT (00_MQTT.pm)" zu belabeln und statt MQTT2_DEVICE müßte MQTT_DEVICE stehen (2. Seite des pdf).
C Finalisieren der MQTT2_CLIENT-Variante:
- da fehlt dann noch das "spezielle" MQTT2_DEVICE "A_00_MQTT2_CLIENT_general_bridge"
-- Farbgebung wie das IO (MQTT2_CLIENT)
-- Anordnung: entweder über die anderen MQTT2_DEVICE-Geräte (Rest rutscht nach unten) oder untendrunter (im Moment fände ich drunter fast besser, im pdf ist es noch andersrum...
Hoffe, so kannst du mit meinen "handschriftlichen" Anmerkungen halbwegs was anfangen...
schau dir des mal an, ich hab bei den grössen von den non-mqtt`s jetzt nix geändert, weil ichs nicht ganz verstanden hab. aber das kannst mir ja am neuen entwurf sagen.
:)
Das ist ziemlich nahe an meinen Vorstellungen!
Funktional ist alles so i.O. (nur wie besprochen erst mal noch ohne das fehlende weitere Gerät betr. MQTT2_CLIENT).
Zu "Mosquitto":
- Die Box - könnte vielleicht etwas kleiner werden und zur unteren linken Ecke hin schrumpfen (30%-halbe Größe würde reichen);
- Dahinter ein Stern ("Mosquitto*"), unten dann eine Erläuterung (darf wieder sehr klein sein): "*or other external MQTT server software". Mosquitto ist eine Lösung unter vielen, vgl. z.B.http://www.steves-internet-guide.com/mqtt-hosting-brokers-and-servers/...
Wegen der Größe usw. nochmal der Versuch einer Erläuterung: Ich will diese Mosquitto-Box (deren Fläche) dann in dem MQTT2_SERVER-Schaubild dann einfach von diesem mit "vereinnahmen" lassen (Die Darstellung der Flächen soll also deutlich machen, dass funktional die Gleichung diese ist: MQTT2_CLIENT+Mosquitto=MQTT2_SERVER). Das würde übrigens noch einfacher gehen, wenn die MQTT2_CLIENT-Box auch nur so hoch wäre wie die Mosquitto-Box...
Ob das dann noch gut aussieht, mit den sehr geordneten Boxen rechts v. Mosquitto und links v. M2-C, ist eine andere Frage, aber das wäre m.E. nicht so tragisch. Geht ja vorrangig um's verstehen.
Zu non-MQTT:
In diese Box sollen dann im Rahmen der Erläuterung zu MQTT_GENERIC_BRIDGE weitere Aktor-Boxen rein, die dann aber keine Verbindung nach oben haben werden, sondern nach links zum (FHEM-) Server (ohne MQTT). Das werden 4 Stück werden (2xZWave (z1 und z2), 2x "XY Protocol Actor/Sensor x(1|2)"), mit je einem Interface pro Protokoll in der FHEM-Server-Box.
Ergo wäre es gut, die beiden vorhandenen "D2" und "D3" gleich etwas nach rechts zu verschieben (das können wir dann aber auch auf dem weiteren Schaubild tun).
Hallo,
was ich mich Frage:
Tasmota - Sonoff
sollte man nicht eher schreiben
Tasmota / ESPEasy
DEVICES
Weshalb ein Sonoff-Gerät erwähnen wenn doch eigentlich irgendein ESP-Gerät gemeint ist das Tasmotarisiert wurde.
Sonoff ist doch nur ein Hersteller.
Ja und ESPEasy wurde bisher ignoriert, warum ?
Gruß
Thomas
Im Prinzip könnte mach schlicht ESPx-Controlled-device schreiben. Damit ist dann vom 8266-32 alles abgedeckt und die Dinger stecken ja in all diesen Produkten.
Sonoff, Shellys, espeasy, whatever... alles baut auf esp microcontroller auf
Zitat von: TomLee am 03 Juli 2019, 12:04:25
sollte man nicht eher schreiben
Tasmota / ESPEasy
DEVICES
Im Prinzip gebe ich dir recht...
Nachdem ich das jetzt nochmal hin und her betrachtet habe: Im Ergebnis neige ich dazu, nur noch "Tasmota" da reinzuschreiben, oder wir müssen noch (geringfügig) mehr ändern...
Richtig ist: sobald diese firmware auf einem Gerät läuft, ist es völlig egal, von welchem Hersteller die Hardware mal war (korrekte template-Einstellung (auf dem Gerät) vorausgesetzt).
Das gilt "im Prinzip" ganz genauso für ESPEasy. Nur: Historisch ist die Haupteinbindung hier nicht via MQTT, sondern mit den separaten Modulen. Man müßte also klarstellen, dass der MQTT-Mode gemeint ist (?). (Der läuft auch afaik nicht automatisch, sondern man muß das als user einstellen).
Dies gilt ähnlich auch für Shelly, nur dass dort der MQTT-Weg jedenfalls nicht "exotisch" ist (ca. 1:3, wenn man die FHEM-statistics Seite zugrunde legt)
Wenn, dann sollte man also zu ESPEasy und Shelly einen "*" setzten und in die MQTT-Box den Zusatz schreiben "* MQTT mode enabled".
Zitat von: DasQ am 03 Juli 2019, 12:28:16
Im Prinzip könnte mach schlicht ESPx device schreiben. Damit ist dann vom 8266-32 alles abgedeckt und Dinger stecken ja in den Produkten.
Auch richtig, aber vielleicht "zu technisch" gedacht. Schon jetzt kann man in Threads lesen "ich habe aber eine Blitzwolf/sonoff/Obi...", wenn man nach der Tasmota-Version fragt und "tele" im topicstring liest. Viele (lassen?) flashen und haben dann diese Feinheiten schon wieder vergessen.
Andererseits würde klarer, dass es weitere, ganz andere firmwares gibt, die was anderes tun (z.B. die MiLights steuern...)
Bin da aber recht leidenschaftslos, was das Thema angeht... Letztlich wird es nie perfekt sein, schon gleich nicht über der Zeit (gibt es nicht schon andere Hersteller/Chipsets, die von Tasmota unterstützt werden?).
ja dann machen wir einen kasten als hardware variante, mit den gebräuchlisten hersteller (sonoff, shelly, obi, ...) und einen als software variante (espeasy, tasmota, milight, selfmade, ...)
Bitte aber nicht verkünsteln; ich fürchte, das wird sonst eher verwirrend (und MiLight war nur als Beispiel für dich als "Wissenden" gedacht, die Techik ist nichts, wofür man werben müßte...).
Dann eher eine Box (oder zwei nebeneinander/einen Stapel) mit langem Text über beide/alle wie "Device w/ firmwares in MQTT Mode, e.g. Tasmota, Shelly or ESPEasy" (und zwei davon mit A und B belabelt).
Zitat von: Beta-User am 03 Juli 2019, 11:52:36
Das würde übrigens noch einfacher gehen, wenn die MQTT2_CLIENT-Box auch nur so hoch wäre wie die Mosquitto-Box...
schau dir nochmals das bild von meiner
Zitat« Antwort #65 am: 30 Juni 2019, 12:19:55 »
an. ich würde wieder auf diese anordnung der MQTT2_DEVICEs zurück gehen, das macht in dem oben genannten zusammenhang ein logisch besseres bild.
wär gut wenn wir das kurzfristig entscheiden, dann bau ich auf dem template auf.
Fand den Fluß von links nach rechts besser (bzw. zurück) und so ist die M2_S-Box optisch m.E. zu groß (muß das ggf. insgesamt überdenken, ob das Rausragen in die MQTT-Box rüber da Sinn macht; andererseits: s.u.). (Dass auch die alte Grafik "im Prinzip" gepaßt hat, hatte ich ja geschrieben ;) ).
In jedem Fall sollte die "FHEM-Server-Box" unverändert bleiben, das mit dem veränderten Umlauf ist irgendwie "eckig". Mit der Vereinnahmung der mosquitto-Fläche sollte eine Art "Übergriffigkeit" angedeutet werden, die in der Sache sogar richtig ist: der M2_S muß nicht zwangsläufig jeden MQTT-Verkehr auch FHEM-intern weiterverarbeiten, sondern kann auch "ganz normal" eine Kommunikation zwischen anderen, externen MQTT-Clients ermöglichen, ohne dafür weitere M2-Devices anzulegen (=>autocreate aus).
Dass unten in der Module-Box ggf. Raum bleibt (oder leicht geschaffen werden kann), ist beabsichtigt. Wir müssen da später (bei M_G_B) 7 Geräte in einer bestimmten logischen Anordnung unterbringen...
na ich hab jetzt so ein wenig das Problem, das ich erst zum ,,Schluss" die maximal mögliche Fläche benutzen, aber jetzt schon abschätzen muss wieviel Platz das braucht. Von daher sollte man zunächst vielleicht das grundlayout so anpassen das auch alles rein passt. Verstehst wie ich mein?
Der mqtt2-Server gehört ja in den FHEM-Server Kasten mit rein. Logisch aber auch den Platz des externen mqtt einnimmt. So quasi ein zwitter :o
Ich könnte natürlich, den mqtt2server so platzieren(ohne Transparents), das er im fhemserver Kasten ist und aber transparent in den mqtt überlappend hineinragt, oder gestrichelt ihn so verlängere.
Zitat von: DasQ am 04 Juli 2019, 08:05:02
na ich hab jetzt so ein wenig das Problem, das ich erst zum ,,Schluss" die maximal mögliche Fläche benutzen, aber jetzt schon abschätzen muss wieviel Platz das braucht. Von daher sollte man zunächst vielleicht das grundlayout so anpassen das auch alles rein passt. Verstehst wie ich mein?
Also: Am meisten Einzelelemente wird das Schaubild zur Kombi MQTT2_CLIENT (M2C) mit MQTT_GENERIC_BRIDGE (MGB) enthalten.
Da fehlen im Vergleich zur in «
Antwort #79 am: Gestern um 11:21:35 » enthaltenen Grafik folgende Elemente:
- ein (?) MQTT2_DEVICE (M2D) mit bridgeRegexp. Ich versuch's mal noch etwas näher zu erläutern: das steht eigentlich "quer" zu den übrigen M2D, oder noch genauer: eine beliebige Anzahl in beliebiger Kombination von M2D kann eine beliebige Zahl von bridgeRegex-Ausdrücken "attributiert" haben, die dann für "autocreate" als "Hilfsmittel" dienen, um das/die "richtige/n" "Abnehmer (M2D) für eine MQTT-Message von außen zu finden... Wenn du eine Idee hast, wie das/dieser Kauderwelsch grafisch umzusetzen ist: feel free ;D . (Vielleicht: Stehend als eine Art (optisch im Hintergurnd stehender) Filter zwischen die M2D's und M2(C|D), teilweise von den M2D's überdeckt, Beschriftung dann M2D: bridgeRegexp, e.g. @A_00_MQTT2_CLIENT_general_bridge)? Das würde dann übrigens auch für M2S passen, allerdings würde ich dort den "e.g."-Teil weglassen, weil die Aufgabe des A_00... genau die ist, die (von Mosquitto "überschriebenen") ClientID's der eigentlichen, ursprünglichen Sender zu "erraten"; diese kennt M2S ja schon besser...).
- Unten:
Da fehlen wie gesagt 7 Elemente. Diese sind:
-- MGB
-- je zwei ZWave und x1 und x2 (als beliebiges Devices eines beliebigen Protokolls) und die beiden zugehörigen IO-Devices, also ZWDongle und XY-IO
Zur Anordnung: Der "Verarbeitungspfad" (beispielhaft für ZWave+M2C) geht von "non-MQTT" (=ZWave Z1) <=> ZWDongle <=> ZWave (FHEM-Device) <=> MGB <=> M2C <=> Mosquitto
Meine Idee war, das zum einen so zu gestalten, dass man einerseits sieht, dass evtl. noch was fehlt, andererseits nicht gleich auf der FHEM-Server-Seite sehr viel Platz zu reservieren für Themen, die ggf. nur noch von einem eher kleineren Teil der User effektiv benötigt werden. Man "braucht" MGB nur, wenn man genau diesen obigen Datenpfad haben will. Das war eigentlich mit '"reine" FHEM-Devices zu "verMQTTen" gemeint', das ich hier (sinngemäß) schon mehrfach geschrieben hatte
Zitat
Der mqtt2-Server gehört ja in den FHEM-Server Kasten mit rein. Logisch aber auch den Platz des externen mqtt einnimmt. So quasi ein zwitter :o
Ich könnte natürlich, den mqtt2server so platzieren(ohne Transparents), das er im fhemserver Kasten ist und aber transparent in den mqtt überlappend hineinragt, oder gestrichelt ihn so verlängere.
Zwitter finde ich eigentlich ganz passend :D . "Transparent reinragend" klingt jedenfalls ganz gut; wie gesagt/versucht anzudeuten: die Fläche für M2D sollte nicht gar zu umfangreich sein (auch Mosquitto ist ja "lightweight" ;) , und muß in MQTT zwar einigermaßen Zentral, aber nicht zu groß dargestellt werden).
weil mir der obere entwurf absolut nicht gefällt, hier mal ein neuer entwurf auf basis von HIER (https://www.mqtt.com/features)
die neue basis soll so allgemein gehalten als möglich. sprich ich stell mir vor das die erläuternden texte in die bildbeschreibung kommt.
so könnte man sich hersteller unabhänig auf die grafik beziehen. also je nach anwendungsfall, nutzt man die grafik im wiki und vergibt dann passend zu den "buchstaben" erläuterung zum hersteller.
Gefällt mir aus mehreren Gründen weniger, auch wenn ein paar Dinge gut sind (angefangen bei den Pikrogrammen, die sind hübsch!):
- Durch die andere Ausrichtung und die fehlende Verortung im FHEM-Serverbereich ist m.E. die gedankliche Brücke zum "allgemeinen Schaubild" praktisch nicht zu schlagen. Wir sollten daber bei der grundsätzlichen Ausrichtung von links nach rechts bleiben. Die Alternative wäre hier, deutlich zu vereinfachen, aber dann müßten z.B. die ganzen MQTT2_DEVICE-Piktogramme trotzdem in die "FHEM"-Box (wie auch immer die dann intern aussähe).
- Die gedankliche Brücke wird weiterhin dadurch durchbrochen, dass plötzlich ein neuer Block im FHEM-Server auftaucht (MQTT2_CLIENT). Da tue ich mich schwer, das zu erklären bzw. im Moment fehlt mir jede Idee dazu...
- (MQTT2_DEVICE-Piktogramme müssen (!) in die "FHEM"-Box, optimalerweise irgendwie in "Module", aber was dieses letztere Detail angeht, lasse ich dann ggf. mit mir reden, wenn jemand Argumente liefert; zum ersten Teil ist ein ominöser Kreispfeil jedenfalls keine hinreichende Klammer: Die MQTT2_DEVICE-Instanzen "leben" nur in FHEM, nicht außerhalb).
- D2-D5 müßten E1-E4 sein, oder übersehe ich was? (Oder anders gefragt: Wo ist der Bezug zu D1?)
- Der Bereich, der jetzt D3-D5 "oben" beheimatet, sollte benachbart sein zu einem anderen freien Bereich, der für "normale" Devices (nicht-MQTT) reserviert ist, die wir dann via MQTT_GENERIC_BRIDGE "verMQTTen", also wieder vom Server (IO-Bereich) aus gut zu erreichen ist...
- mosquitto ist mir persönlich optisch zu dominant. Wenn wir den optisch rausheben wollen (der MQTT-Server ist für MQTT schon zentral, keine Frage...), dann lieber durch Farbe.
Grundsätzlich: M.E. wollen wir vorrangig nicht MQTT als Technik erläutern, sondern die Frage, wie die Schnittstelle von FHEM zu MQTT aussieht. Und da ist FHEM genauso "groß" wie alles, was extern liegt (m.E.). Darüber können wir gerne diskutieren, ob die Haltung die richtige ist, ich versuche damit nur plastisch zu machen, was mir im Kopf dazu rumgeht...
also die bezeichnungen von D1 - Dx ist aus deinem entwurf!
dann zur ausrichtung sprechen eben mehr gründe für dieser ausrichtung als für eine von links nach rechts.
- hochkant ist besser für mobil fähigkeit (mobile first)
- flussdiagramme werden i.d.R. hochkant erstellt
- logisch kann es auch von oben nach unten laufen, hauptsache hochkannt
- es entsteht optisch der eindruck eines baumwuchs oder auf dem kopf stehende pyramide
- im web wird eben rauf und runter gescrollt und nicht nach links und rechts
im alten entwurf stört mich am meisten, das die optischen übergänge nicht gegeben sind. und dabei erinner ich an dein wunsch den morquitto gegen den mqtt2 server/client auszutauschen, der dreisatz hat mich persönlch schier zur verzweiflung gebracht da des optisch einfach kacke ausschaut.
also wollte ich eine etwas luftigere, einfachere grafik gestalten. wir haben bei der systeminfo gesehn, das zuviel input eben genau das gegenteil erzeugt.(in mein augen ist die andere grafik kaput getuned).
und das allerwichtigste,
ES IST EIN ENTWURF .... also gesprächsgrundlage zum brainstormen.
wie man dann versucht plastisch rüber zu bringen wie was zusammen gehört steht auf einem anderen blatt. und ach ja dieses blatt wurde schon tausendfach beschrieben, spich es gibt sogar zum teil genormte symboliken/flussdiagramme/programmablaufplan/nassi-shneiderman/whatever da müssen wir also das rad nicht neu erfinden.
hält man sich nur ansatzweise an bestehende konvetionen, erreicht man in mein augen die breiteste masse und der rest kanns ergooglen.
kästelchen mit pfeilchen dazwischen ist jetzt nicht das grosse problem zu zeichnen, aber das es dann auch verstanden wird, das ist was anderes. (für mich war das die logische 1zu1 skizze aus dem bild in « Antwort #78 am: 03 Juli 2019, 11:21:35 » (https://forum.fhem.de/index.php/topic,101549.msg954966.html#msg954966))
die grösse der kästen rührt einzig und allein daher, das man an einem kleinen kasten, weniger "verbindungen anbringen" kann, als an einen breiten. das hat nix mit "hervorheben" zu tun. das ist einzig und allein ein platzproblem und das wünsch ich mir, das man die optischen probleme des zeichners erkennt. ich kann die verbindungen auch bündeln, das schaut aber dann wieder *würg* aus
btw. war dann auch noch aus schludrigkeit (entwurf) ein fehler drin.
OK, Entwurf, und ich will auch nicht ausschließen, dass das mit D1 auf meinem M..haufen gewachsen ist ;D ... Ist/war trotzdem falsch/irreführend. Die Xn-Geräte gehören logisch zusammen, weil irgendwo eine Hardware oder ein Dienst eine "Bridge" zu vielen anderen macht (war übrigens auf dem zitierten und von mir als prizipiell i.O. gelobten Bild in #78 noch korrekt).
Das mit dem mobilen Scrollen leuchtet mir ein; damit müßten wir aber die Ausgangszusammensetzung innerhalb des FHEM-Server aufgeben - das finde ich aber nicht allzu schlimm. Dann sollten wir aber mit der Optik des ursprünglichen Bilds im Bereich "FHEM Server" ganz brechen, oder?
Ob man das als Flußdiagramm sehen will? Weiß nicht, es ist da nicht wirklich so, dass man "oben" was reingießt und "unten" kommt was raus, von daher finde ich hier "hin und her" passender, aber das ist zweitrangig...
OK ist auch, wenn die MQTT-Kommunikationspfeile dann bei der MQTT2_SERVER-Variante nicht mehr auf ein Objekt außerhalb des FHEM-Servers zeigen, sondern auf das entsprechende Modul-Objekt innerhalb des FHEM-Servers. Das "Raum greifen" war eine optische Idee (die wir im übrigen eigentlich sowieso ziemlich weitgehend wieder verworfen hatten), weil ohne das scheinbar nicht so recht klar war, welche Funktionen der MQTT2_SERVER hat, aber das geht auch anders darzustellen.
Was Konventionen usw. angeht, mache ich mich gerne schlau, wüßte dann aber gerne, wo ich eine für "Gelegenheitsuser" wie mich geeignete Intro dazu finde (Flußdiagramme mit visio habe ich schon erstellt, aber hier geht es m.E. um was anderes, da sollten eher die IT-üblichen Konventionen passen). Bis dato bin ich davon ausgegangen, dass wir über ein erweitertes "FHEM-Übersichts-Modell" reden, und da sollten die Dinge dort ihren entsprechenden Platz haben. (Ob der "normale User" sich das dann ergoogelt, wage ich mal zu bezweifeln; oft ist "man" ja schon nicht in der Lage, konkret gegebenen Links einfach mal zu folgen - wie jüngst "unser" Kandidat mit der GenericBridge, der partout den m.E. recht ordentlichen Beispiel-Thread nicht finden wollte...).
Und m.E. brauchen wir die Grafik hier auch nicht "kaputt" zu tunen. Hier haben wir es mit mehreren Grafiken zu tun, die aufeinander Bezug nehmen, aber nicht ganz gleich sein müssen. Es wäre mir auch lieber, wir könnten den relativ raumgreifenden Teil MQTT_GENERIC_BRIDGE erst mal weg lassen, und dann z.B. in einer auf die Basis aufbauenden Variante den "bekannten Rest" verkleinern und dadurch Raum schaffen, für den Rest würde eigentlich als "Actuators & Sensors" A, B und C1-C3 (eine typische Bridge wie zigbee2mqtt & 2 Zigbee-Geräte) reichen.
Nochmal: Der Vorschlag mit den Piktogrammen ist gut und schön plastisch, wegen mir müssen da keine konkreten Beispiele rein (bzw. nicht viele).
[Hier OT]
Wir können gerne nochmal den Versuch unternehmen, die andere Grafik auch zu entschlacken. Das gilt insbesondere, wenn das mit gängiger Symbolik ginge...
Aber solange es relativ konkret ist, was die "Actuators & Sensors" angeht, muß es auch dort eben akkurat passen/viele Details beinhalten.
[/OT]
du mir ist wurscht wie der server aussieht, hab da eh mit einem "server" pictogramm geliebäugelt, also eher so in richtung towerpc ... mal schaun, vielleicht bastel ich da was FHEM eigenes angelehnt an die "bestehende" server grafik.
und ich wollte eben genau von der systeminfo wieder ein wenig weg, weil weniger ist mehr. bissi bunt, dezente symbolik rest logik.
anbei bin ich über die FHEM internen svg-icons gestolpert und hab die dann gleich für unsere zwecke missbraucht.
Ähm, V. 1_3 war mir irgendwie entgangen...
Ein Tower-PC Icon finde ich nicht unbedingt zwingend, da der FHEM-Server und der Mosquitto ja auf derselben Murmel hausen können.
Mal ausgehend von V. 1_3:
Unten eine Box mit dem FHEM-Pictogramm (gerne groß im Hintergrund) ohne Überschrift? Da sollte dann MQTT2_CLIENT oben drinstehen (als Box), aber nicht größer (eher kleiner) wie die mosquitto-Box darüber, und mit den "gekreisten Pictogrammen" in der FHEM-Box und dem Kreispfeil von und zur MQTT2_CLIENT-Box.
Als Idee (tb discussed): Unten drin dann noch eine "Frontend"-Box, die mit einem neuen Element darunter kommuniziert ("Browser")? Dann hätten wir den "üblichen Datenfluß aus Sicht des Anwenders"?
mt dem frontend und browser muss ich mal schaun ... bzw. brauch ich nen hit
Sieht aufgeräumt aus :) .
Oben ist es fast ok, aber alles, was "durch" D durchgeht, sollte auch einen "D"-Kenner haben, nicht "E" (in der vorherigen gab es ein "danebenstehendes" "D1"-Gerät, das war der Punkt, auf den ich dort hinweisen wollte...).
Dann ist nicht ganz klar, warum sich die MQTT-Kommunikationslinien von B und C vereinen. Sollte m.E. so sein, dass da jedes "für sich" kommuniziert.
Unten würde ich die FHEM-Box wirklich groß machen (darf optisch weiter so durchscheinend sein). Oder gibt es einen "allgemeinen" Grund, warum die "virtuellen" Geräte außerhalb sein sollten?
(Wenn die "Browser"-Kommunikation da irgendwie noch zwischen den MQTT2_DEVICE-Icons durchgeht (zum FHEM-Server), wird das sonst verwirrend, oder?)
so in etwa?
und achja, bevor fragen auftauchen, die fehlenden "leitungen" fehlen bewusst. ;)
:) Kommt ziemlich gut hin.
Dein Eindruck?
also von mir aus immer super :D, das müssen andere augen beurteilen, da bin ich voll und ganz kritik fähig.
für das bündeln der "leitungen" im mqtt2_server wär ich für ein vorschlag offen.
Hmm, also:
- weiß noch nicht, ob ich im MQTT-Bereich ein "B"-Device mit nur einer Verbindung so top finde. Kann es zwar geben, ist aber die Ausnahme; wenn, paßt das Reglersymbol m.E. nicht, das wäre dann ein reiner Sensor, der nur publisht.
- D4 (=Lampe) oben wäre m.E. typischerweise bei zigbee auch ein bidirektionales Device
- Die Boxen um Frontend und MQTT(2)-Client/Server müssen m.E. auch nicht sein. Nur die Rahmenlinien aller Devices bzw. Funktionsblöcke im FHEM-Bereich sollten einheitlich sein (die inneren Boxen sind derzeit noch ohne abgerundete Ecken, und ob es dieselbe Farbe ist, kann ich nicht richtig erkennen).
- Was die Kommunikationspfeile zu MQTT2_SERVER angeht, fände ich mehrere (hier: 4) nicht schlecht. Tatsächlich wird ja für jede Verbindung eine (temporäre) Instanz aufgemacht (was den einen oder anderen auch schon verwirrt hat...), das wäre dann leichter zu erläutern (aber zugegebenermaßen optisch unübersichtlicher). Und eine Direktverbindung zwischen MQTT-Devices (die nicht zugleich Server sind) gibt es nicht; das wäre dann auch klarer. Bei insgesamt 4 Verbindungen geht das aber m.E. grade noch (auf eines der Devices A/B/C könnten notfalls wir auch verzichten, dto. auf 2 der 4 zigbee-"Satelliten").
ich hab jetzt nicht alle änderungen von dir eingebaut um weiter zu layouten
schau dir des mal an
Soweit ok, bis auf die Verbindungen oben im zigbee-Bereich.
Was das "Frontend" angeht: Das muß nicht ganz so groß sein (? darf schon, bin da unentschlossen), aber m.E. sollte etwas Platz zwischen den MQTT2_DEVICE-Icons und dem Frontend sein. Beides ist zwar "in FHEM", hat aber darüber hinaus eigentlich keine engere Verbindung; das Frontend ist halt eine Möglichkeit (unter vielen), Anweisungen an ein MQTT2_DEVICE-Gerät zu geben, mehr aber auch nicht...
Daneben könnte (bitte nur den Gedanken mitdenken, aber nicht zeichnen...) auch Alexa oder sonst eine Sprachsteuerung stehen (mit "Manipulationspfeil") oder ein internes "at" ganz ohne "Verbindung nach außen".
???
:)
Für mich passen die beiden soweit. Wie soll ich den fragenden Smiley deuten? Fragen von deiner Seite dazu?
Was da in der MQTT2_CLIENT-Fassung nicht abgebildet ist, ist das A_00...MQTT2_DEVICE. Stelle mal zur Diskussion, ob man nicht "irgendein" Element an den linken Pfeil von MQTT2_CLIENT zu den Devices anfügt, oder einen (klein gehaltenen) Text (z.B.: "optional: bridgeRegexp"). Würde dann auch zu MQTT2_SERVER passen, nur ist es da nicht sooo essentiell und mit einem konkreten template-Namen verbunden. Ist zwar klar, dass das keiner auf das erste Mal versteht, aber so kann man es wenigstens "lokalisieren"?
Was 00_MQTT.pm angeht: Das wäre vom Layout her (ohne bridgeRegexp-Zusätze!) identisch zu der jetzigen Fassung für MQTT2_CLIENT, nur sollte unter "MQTT" (das MQTT2_CLIENT ersetzt) ein (klein gehaltener) Klammerzusatz mit dem vollen Modulnamen sein, um Verwirrungen möglichst vorzubeugen. (Und die Devices sind dann von einem anderen TYPE => MQTT_DEVICE).
So ganz kann ich dir nicht folgen, kannst mir das kurz reinmalen?
Ich nehme an, das bezieht sich auf das bridgeRegexp-Thema?
Scan anbei, der Text darf gerne sehr klein sein, wenn du da lieber einfach einen Stern hinmachen willst, auch gut. Wie gesagt: Ich bräuchte halt irgendeinen "Aufhänger", um die Funktionsweise des bridgeRegexp-Attributs erläutern zu können.
Wenn zu 00_MQTT.pm was unklar ist, bitte melden.
so ich hoff mal nicht zuviel neue fehler eingebaut. musste aber etwas gradziehen. ;)
Das mir der Animation ist ganz nett, ich habe nur noch keine rechte Idee, wie das im Artikel gut rüberzubringen ist, aber da werde ich mir was überlegen, denke ich doch...
In der Sache noch ein paar Kleinigheiten:
- der bridgeRegexp-Hinweis darf m.E. noch kleiner werden, und bridgeRegexp sollte auch mit kleinem "b" beginnen (das ist der Name eine Attributs).
- Er gehört auch _nur_ zur MQTT2-Welt und ist im Schaubild von 00_MQTT.pm falsch
Weitere Nebenaspekte:
Im Schaubild zu 00_MQTT.pm bin ich mir nicht sicher, ob man den vollen Modulnamen da so reinschreiben sollte. Geht zwar, und es sollte auch erkennbar sein, dass das gemeint ist, aber was die konkrete Umsetzung angeht, ist es halt "anders" als bei den anderen. Ursprünlgich hatte ich mal einen Klammerzusatz angeregt, aber das ist vermutlich nicht so einfach unterzubringen. Wie wäre es mit einem * und unten einer Fußnote? (Ist aber insgesamt nicht sooo wichtig).
So ganz verstehe ich auch nicht, warum dort (in dem 00_MQTT.pm-Schaubild) nur noch von "Device" die Rede ist, und nicht von MQTT_DEVICE. Den Ansatz, das (auch in dem GIF) optisch mehr hervorzuheben, finde ich an sich ok, aber irgendwie ist das m.E. inkonsistent. Vielleicht wäre es eine Idee, die oben angedachte Fußnote zu erweitern und die Info da reinzuschreiben? (Bin unschlüssig, weil das die im Moment sehr klare und gute Optik irgendwie vermasselt; notfalls geht das auch so...)
Das mit dem gif war nur mal zum zeigen das des geht.
Wie man da die verschiedenen Zustände markanter erkennbar macht ist ein kleines (z.b. Pro Frame eine fette Nummer oben in der Ecke, oder ne wechselnde überschrift, oder oder)
the next
und achja, Device heisst nur, weil so der "standard" icon so aussieht ... MQTT "heisst" ja eigentlich schon das Symbol(pictogram)
:)
...paßt für mich so, wie gesagt, die Benennung ist an der Stelle nicht sooo dramatisch wichtig, war "nur" eine Konsistenzfrage...
Lädst du das wieder ins Wiki?
is online https://wiki.fhem.de/wiki/Spezial:Dateien
baust du`s in den artikel ein?
Thx.
"Auf die Schnelle" habe ich mal eine Gallerie reingebastelt (und einen "Fehler" verbessert, was zusätzliche Perl-Module angeht). Ist aber noch nicht fertig, da fehlen noch einige Erläuterungen und optisch geht es auch besser...
Wie schaut es jetzt mit MQTT_GENERIC_BRIDGE aus?
Bekommst du das auf Basis des bisher geschriebenen hin? (Ich würde mich auf MQTT2_CLIENT beschränken, und dann "irgendwas" (openHAB?) auf den mosquitto hören lassen...? (Oder lieber als FHEM2FHEM-Ersatz darstellen?)
na eigentlich ists ein "stern" ich dacht da an mindestens 2 fhem (eins client2, eins server2)(ggf. 3 fhem mit 00_MQTT.pm) und einem extern broker und dann noch das www (IOT,IFTTT,NodeRed...)
wenn verstehst was ich mein
dazwischen angedeutet "(standard)topics" als subscribe und publish
ich überleg mir was.
Hmm, das mit dem Stern finde ich "an sich" nicht schlecht, aber es wird sehr schnell unübersichtlich, wenn wir alle Kobinationsmöglichkeiten da reinpacken wollen => weniger ist mehr, es geht (erst mal?) um's Prinzip; wer das verstanden hat, wird schon von alleine kreativ werden, der Rest sollte es eh' lassen (just my2ct).
Von daher sollten wir entscheiden:
- Entweder ein FHEM2FHEM mit MQTT (nur zwei Instanzen, eine mit MQTT2_SERVER, eine mit MQTT2_CLIENT) oder
- (ich zitiere sinngemäß Rudi: Wer vornehmlich MQTT "für was anderes nutzt", sollte einen externen Broker nehmen) dann wirklich einen Mosquitto in der Mitte, gerne zwei FHEM-Instanzen, angebunden aber nur mit MQTT2_CLIENT (oder vielleicht einem "beliebigen" Interface-Modul?!?) und einer "Wolke", in der sich vage "external MQTT-based HA-software like IFTTT or NodeRed" befindet?
schnellschuss
Edit unfug
Ähm, soll es um MQTT_GENERIC_BRIDGE gehen oder die Frage, was eine bridgeRegexp macht?
Letzteres kann ich bequem anhand der Grafiken von heute 11:12 Uhr erläutern, da ist no action required.
Auf MQTT_GENERIC_BRIDGE paßt jedenfalls diese Grafik gar nicht, und eine Diskussion über MQTT-Server zu MQTT-Server-Kommunikation sollten wir besser gleich gar nicht erst aufkommen lassen... Schau dir vielleicht nochmal die Anmerkungen zum "Freischaufeln" einer "Achse" für "nicht-MQTT-Devices" in diesem Thread an, sonst ist es vermutlich besser, ich liefere dir sowas wie eine Handskizze ::) .
Omg Schnellschuss ohne Hirn .... ja klar generic Bridge, ich sekel.
Ja ich glaub dann wär ne grobe Skizze hilfreich.
...zu Schnellschuß noch: Das MQTT2_CLIENT-Ding hat doch auch noch zu viele Verbindungen zum (Mosquitto-) Server. Da gehört nur eine hin... (Da war wohl der Wunschlesemodus aktiviert ::) ).
Dann mal eine meiner berüchtigten Handskizzen anbei.
Das ist nur der Spur nach...
Was zum Ausdruck kommen soll: Die ZWave bzw. Zigbee-Devices kommunizieren ganz normal mit den zugehörigen IO's (hier aber jetzt eine HUEBridge statt zigbee2mqtt für Zigbee!).
Diese werden dann in FHEM mit der MQTT-GENERIC_BRIDGE verbunden (eigentlich je einzeln), und die (und auf diesem Schaubild nur die) kommuniziert dann mit dem MQTT-IO.
Sind die Daten dann mal in MQTT-Form beim Server, kann man "ganz normal" mit jeder Art MQTT-Client darauf zugreifen.
Wenn du das um ein "MQTT-FHEM2FHEM" ergänzen willst, käme in die Wolke oder als separater Client zum Server dann ein weitere FHEM dazu, da könntest du dann auch "Kopie-Devices" der Elemente X, Y, D1 und D2 reinbauen (das sind dann aber technisch gesehen typischerweise MQTT(2)_DEVICE-Instanzen).
zum einen lag ich doch nicht ganz falsch, ich hab halt dummerweise dem mqtt2zigbee als "symbol unten versehentlich mit eingebaut" und dann auch noch die bridge total verwürfelt benannt. (kein plan was mich da geritten hat)
egal.
ich hab jetzt trozdem mein ersten denkansatz weiter verfolgt und das mal jetzt wie im bild verteilt angeordnet. (mal gschwind zusammengeschustert(man möge über alt zu grober schnitzer hinweg sehen, das kann ein dummer zufall sein))
btw. ist mir persönlich wichtig, das rüberkommt was die bridge intern tut. und dann müsste wie ich das bis jetzt verstanden habe, ein übersetzten aus devicetypischen protokollen in das mqtt-protokoll.
das wollte ich durch die sprechbalsen "andeuten" ist aber völlig aus der luft gegriffen (also topic und der binärcode pseudocode)
der obere teil der grafik ist einfach nur "unangefasst" das können wir dann noch anders "richtiger" gestalten. bzw. den inhalt der kästchen ändern
Also...
Zum unteren Teil:
- Das Basislayout kann man "im Prinzip" so machen. Die Geräte einfach irgendwie um den Server zu gruppieren, ist vermutlich die einfachste Variante, den Rest kann man mit Text erklären.
- Als IO darf aber bitte nicht MQTT2_SERVER da stehen (ich wiederhole mich, liegt wohl an der Hitze, dass diese eindeutige Ansage nicht ankam....)
- Das mit den beiden Sprechblasen finde ich nicht gut. Wenn du von binärem Code kommst (Lampe), mußt du konsequenterweise wirklich ein IO dazwischen setzen, das aus dem binären Code FHEM-interne Daten macht, die an die (z.B. ZWave-) Client-Devices weitergegeben werden, und dort als Readings (samt Events) auftauchen. Die Bridge macht dann aus den Readings-Events Topic/Payload-Paare und wirft die über das jeweilige MQTT-IO an den Server (bzw. die Clients, die dran lauschen); umgekehrt funktioniert die Kette dann genauso. Meine Meinung daher: Ganz oder gar nicht... (tendiere zu gar nicht, wenn das Schaubild so einfach bleiben soll). Weiteres Argument: Die Kommunikationspfeile unterscheiden sich entsprechend. Was du tun könntest: die Farbe zwischen dem MQTT-IO und der GenericBridge in Grün/Rot halten (von mir aus sogar gestrichelt, es wird mWn tatsächlich topic/payload jeweils nur durch das IO geschoben...)
- Es ist daher auch nur _eine_ Kommunikation zwischen MQTT-IO und GenericBridge, die beiden anderen Pfeilpaare gehören weg.
Zum oberen Teil (wolltest du ja eh' noch überarbeiten):
- Paßt schlicht gar nicht. Den Mosquitto-Server zentral anordnen, der Rest kommuniziert sternförmig mit diesem.
- das FHEM oben mit dem MQTT2_SERVER sollte weg (hatte ich doch deutlich gesagt, oder: KEINE MQTT-Server<->MQTT-Server-Diskussion hier!).
Und, vor allem: üblicherweise will man darüber keine FHEM2FHEM-Verbindung realisieren, sondern die "Daten für was anderes" nutzen => fehlt komplett...Da das aber der eigentliche Zweck der ganzen Konstruktion MQTT_GENERIC_BRIDGE ist, darf das gerne auch optisch dominieren :D .
Zitat von: Beta-User am 26 Juli 2019, 09:38:08
- Als IO darf aber bitte nicht MQTT2_SERVER da stehen (ich wiederhole mich, liegt wohl an der Hitze, dass diese eindeutige Ansage nicht ankam....)
wieso nicht?
nicht das ich jetzt krampfhaft an dem server festhalten will. aber wenn der mit "vielen" kommuniziert, könnten die vielen ja selbst entscheiden was sie an information haben wollen.
Zitat von: Beta-User am 26 Juli 2019, 09:38:08
- Das mit den beiden Sprechblasen finde ich nicht gut. Wenn du von binärem Code kommst (Lampe), mußt du konsequenterweise wirklich ein IO dazwischen setzen, das aus dem binären Code FHEM-interne Daten macht, die an die (z.B. ZWave-) Client-Devices weitergegeben werden, und dort als Readings (samt Events) auftauchen. Die Bridge macht dann aus den Readings-Events Topic/Payload-Paare und wirft die über das jeweilige MQTT-IO an den Server (bzw. die Clients, die dran lauschen); umgekehrt funktioniert die Kette dann genauso. Meine Meinung daher: Ganz oder gar nicht... (tendiere zu gar nicht, wenn das Schaubild so einfach bleiben soll).
zum einen wollte ich da dann tatsächliche werte/daten die im ansatz erkennen lassen um welches device es geht. drum der begriff pseudocode. also im tatsächlichen format, aber allgemein gehalten.
Zitat von: Beta-User am 26 Juli 2019, 09:38:08
Weiteres Argument: Die Kommunikationspfeile unterscheiden sich entsprechend. Was du tun könntest: die Farbe zwischen dem MQTT-IO und der GenericBridge in Grün/Rot halten (von mir aus sogar gestrichelt, es wird mWn tatsächlich topic/payload jeweils nur durch das IO geschoben...)
- Es ist daher auch nur _eine_ Kommunikation zwischen MQTT-IO und GenericBridge, die beiden anderen Pfeilpaare gehören weg.
welche pfeilpaare?
Zitat von: Beta-User am 26 Juli 2019, 09:38:08
Zum oberen Teil (wolltest du ja eh' noch überarbeiten):
- Paßt schlicht gar nicht. Den Mosquitto-Server zentral anordnen, der Rest kommuniziert sternförmig mit diesem.
- das FHEM oben mit dem MQTT2_SERVER sollte weg (hatte ich doch deutlich gesagt, oder: KEINE MQTT-Server<->MQTT-Server-Diskussion hier!).
warum soll das garnicht passen? onetomany ist eine der herausragenden features in mqtt und das kommt bis dato nirgens rüber, sind aber in mein augen die wirklich intresanten feature.
und in eim der postings hier im thread wirds ja auch genau so beschieben. vielleicht wirds eindeutig wenn man die daten was man unten reinschiebt, auch oben ankommend visualisiert. wie gesagt, nur angedeutet, den kompletten weg einer x-beliebigen "information" eines sonsors/aktors von der quelle zum ziel.
so würde man auch verstehen warum das ganze.
jetzt seh ich hier nur, das geht, aber brauchen tut man das eigentlich nicht wirklich, gibt ja zich andere wege. mir fehlt also irgendwo der explizie vorteil, für was das ganze.
Zitat von: Beta-User am 26 Juli 2019, 09:38:08
Und, vor allem: üblicherweise will man darüber keine FHEM2FHEM-Verbindung realisieren, sondern die "Daten für was anderes" nutzen => fehlt komplett...Da das aber der eigentliche Zweck der ganzen Konstruktion MQTT_GENERIC_BRIDGE ist, darf das gerne auch optisch dominieren :D .
jow eben ... Daten für "was" anderes? also wenn wir an der stelle wie oben beschrieben mit "tacheles" formatiertem pseudocode arbeiten würden, könnt man oben das "was" auch visualisieren.
Der Reihe nach:
Ausgangspunkt (für MQTT_GENERIC_BRIDGE) ist: Jemand will Daten, die in einem nicht-MQTT-Format vorliegen, aus FHEM in diesem Format "exportieren".
Dafür liegt der Grund in der ganz überwiegenden Zahl der Fälle mMn. darin, dass vorwiegend ein völlig anderes Umfeld (nicht-FHEM) "bedient" werden sollt, und FHEM nur ein Teilelement von irgendwas größerem ist. Damit ist für mich das Kriterium "vorwiegend für was anderes" im Sinne dieses Beitrags erfüllt, und der Anwender weiß genau, was er tut und bezweckt:
Zitat von: rudolfkoenig am 23 Dezember 2018, 10:39:18
[...] Meiner Ansicht nach ist mosquitto zu bevorzugen, wenn die MQTT Daten ueberwiegend fuer was Anderes (nicht FHEM) verwendet werden, oder MQTT zweckentfremdet wird (wie z.Bsp. fuer Musikuebertragung). MQTT2_SERVER ist dafuer da, um den Anfaenger die Anbindung von MQTT Geraeten in FHEM einfacher zu machen. Also wenn man es nicht besser weiss, dann sollte man MQTT2_SERVER verwenden.
Damit ist für mich MQTT2_SERVER aus diesem Schaubild schlicht raus, es wird ein anderer MQTT-Server verwendet... (Dass es auch mit MQTT2_SERVER im Zentrum im Prinzip auch gehen müßte, ist klar, aber eben nicht typisch).
Du kannst auch gerne einen weiteren MQTT-Server mit dem ersten brücken, wenn du unbedingt zwei Server auf dem Schaubild haben willst. Aber zum einen ist es nicht notwendig und könnte den einen oder anderen auf den Gedanken bringen, dass man mehrere Server braucht, nur weil es auf dem Schaubild ist. Und das wäre falsch. Und der Anwenderkreis, der dieses feature nutzen will, wird wissen, dass es geht, und braucht daher "unseren Schubs" nicht...
In jedem Fall: MQTT2_SERVER ist nicht Mosquitto, und mir ist jedenfalls bislang kein Fall bekannt, in dem jemand einen MQTT2_SERVER mit einem weiteren MQTT-Server "gebrückt" hätte. Deswegen akzeptiere bitte einfach die schlichte Ansage: MQTT2_SERVER hat auf dem Schaubild nichts verloren. (Wenn du das ausgetestet hast und Wiki-mäßig sauber darstellen kannst: feel free. Ich werde mich damit jedenfalls nicht rumschlagen.)
WENN wir eine (verbindungsabbruchs-tolerante!) FHEM2FHEM-Alternative auf dem MQTT-Weg zeigen wollen, machen wir dafür bitte ein separates Schaubild (MQTT2_SERVER auf der einen Seite, MQTT2_CLIENT auf der anderen). ABER: das hat im Kern wieder nichts mit der MQTT_GENERIC_BRIDGE zu tun, auch wenn diese dabei häufig zum Einsatz kommen dürfte. Daher wenn, dann separat..
Zitat von: DasQ am 26 Juli 2019, 10:29:42
zum einen wollte ich da dann tatsächliche werte/daten die im ansatz erkennen lassen um welches device es geht. drum der begriff pseudocode. also im tatsächlichen format, aber allgemein gehalten.
So finde ich es jedenfalls aus den genannten Gründen inkonsistent.
Zitatwelche pfeilpaare?
Die in der unteren Box zwischen (heute noch...) MQTT2_SERVER und MQTT_GENERIC_BRIDGE. Da sind heute 3 blau/rote Paare, also zwei zu viel, und m.E. nicht in den optimalen Farben.
Zitat
und in eim der postings hier im thread wirds ja auch genau so beschieben. vielleicht wirds eindeutig wenn man die daten was man unten reinschiebt, auch oben ankommend visualisiert. wie gesagt, nur angedeutet, den kompletten weg einer x-beliebigen "information" eines sonsors/aktors von der quelle zum ziel.
Es ist ok, wenn du "oben" in einem "anderen FHEM" Kopien von A-D auftauchen läßt; sollten dann aber als Kopie zu erkennen sein.
Zitatjetzt seh ich hier nur, das geht, aber brauchen tut man das eigentlich nicht wirklich, gibt ja zich andere wege. mir fehlt also irgendwo der explizie vorteil, für was das ganze.
Es gibt wie immer viele Wege zum Ziel.
Es gibt m.E. "nur" einen Vorteil, den kann man aber schlecht visualisieren: Es ist MQTT ;) .
- Dafür gibt es einfache Visualisierungs-Frontends wie openHAB u.a. (?)...
- Die Datenübertragung ist - richtig konfiguriert - sehr tolerant gegen Verbindungsabbrüche.
That's all...
Reicht doch, oder?
Hallo zusammen,
habe heute nochmal etwas an den Artikelchen rumgeschraubt und v.a. auch das für viele ominöse Thema bridgeRegexp mal versucht aufzuarbeiten. In der allg. MQTT-Darstellung war das etwas schwierig, ich hab's daher in die "Praxisbeispiele" übernommen und beim Rest dann hin-und herverlinkt, feedback wäre willkommen.
Ansonsten würde ich dazu tendieren, dass das in der Form jetzt insgesamt kurz aber ausreichend ist (abgesehen von dem MQTT_GENERIC_BRIDGE-Thema, das ggf. mit einem Schaubild noch etwas besser zu illustrieren wäre).
@DasQ: bist du wieder einigermaßen handlungsfähig? Dann wäre neben dem MQTT_GENERIC_BRIDGE-Schaubild bitte vor allem vorab noch das mit den mehrfachen Verbindungen bei MQTT2_CLIENT zu berichtigen (sollte bitte nur eine zum Server sein).
Danke vorab!
Zitat von: Beta-User am 04 Oktober 2019, 13:27:39
@DasQ: bist du wieder einigermaßen handlungsfähig? Dann wäre neben dem MQTT_GENERIC_BRIDGE-Schaubild bitte vor allem vorab noch das mit den mehrfachen Verbindungen bei MQTT2_CLIENT zu berichtigen (sollte bitte nur eine zum Server sein).
Danke vorab!
DONE
hat etwas gedauert, sorry.
Nachdem hier ja längere Zeit Ruhe war, und mir jemand am WE die Basis für eine erste Fassung des Artikels https://wiki.fhem.de/wiki/OpenMQTTGateway zugespielt hatte, will ich hier auch nochmal anknüpfen:
Zitat von: Beta-User am 14 Dezember 2020, 10:42:56
Ich hätte in dem Zusammenhang eine Bitte zurück:
Irgendwann habe ich mal angefangen, unter dem Arbeitstitel "Praxisbeispiele" alles zu sammeln, was mir so an MQTT2_DEVICE im Lauf der Zeit über den Weg gelaufen war. Gestartet hatte das mit MiLight (bitte keine Leuchtmittel kaufen, das war keine Empfehlung...!), dann kam zigbee2mqtt dazu und seitdem ganz viel anderes. Zwischenzeitlich ist es so, dass die MQTT2-Device-Großfamilie so umfangreich ist, dass man für jede Familie eigentlich einen eigenen Zweig im Wiki aufmachen sollte, um auf Spezialitäten einzugehen.
Ergo würde ich gerne auch den zigbee2mqtt-Zweig aus den Praxisbeispielen im Wiki raus haben und wäre (im Interesse aller, die neu in das Thema einsteigen) sehr meinerseits sehr dankbar, wenn sich dafür ein Freiwilliger fände, der das übernimmt. Man braucht dazu kein "crack" zu sein, sondern "dürfte" einfach aufschreiben, was einem so an Problemchen aufgefallen ist, das ganze evtl. eine Spur weniger "kurz&knapp", damit frustrierende Erlebnisse wie diese hier (https://forum.fhem.de/index.php/topic,116622.0/topicseen.html) Einsteigern möglichst erspart bleiben...
(OT: Dasselbe gilt btw. für Tasmota und Shelly; zu Shelly fehlen z.B. nähere Infos rund um diese Problemstellungen bzw. deren Lösung: https://forum.fhem.de/index.php/topic,116658.msg1110215.html#msg1110215; (https://forum.fhem.de/index.php/topic,116658.msg1110215.html#msg1110215;) [...])
Vielleicht findet sich für die einzelnen Teile jeweils jemand, der sich die Dinge mal vornehmen möchte?
Ich fände es auch immer noch klasse, wenn mal jemand "alle" Attribute von einem Shelly1pm-MQTT2_DEVICE "einsteigerfreundlich" erläutern würde. MAn. wäre das hilfreich...
UND: Ganz lieben Dank an die, die das mit dem Ausgliedern aus "Praxisbeispiele" für diverse Mitglieder der MQTT2-Großfamilie schon umgesetzt haben!
So bald 2 Jahre vergangen, wollte mich wieder zurück melden.
Hab ein Haus gekauft und bin fleissig am Renovieren. Viel neues Zeug ist dazu gekommen und jetzt wo es wieder etwas dunkler geworden ist, kann ich auch an meim Fhem weiter basteln. (Muß zu meiner schande gestehen, ich muss ganz von Vorn anfangen)
werd jetzt also öfters für hilfe zur verfügung stehen, wenn ich nicht selber dumme fragen stellen muß.
Grüße Andy
Auch wenn es hier OT ist: Wilkommen zurück!