Artikelstruktur zu MQTT-Themen

[DasQ]

So ganz kann ich dir nicht folgen, kannst mir das kurz reinmalen?

[Beta-User]

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.

[DasQ]

so ich hoff mal nicht zuviel neue fehler eingebaut. musste aber etwas gradziehen.

[Beta-User]

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

[DasQ]

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)

[DasQ]

the next

und achja, Device heisst nur, weil so der "standard" icon so aussieht ... MQTT "heisst" ja eigentlich schon das Symbol(pictogram)

[Beta-User]

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

[DasQ]

is online https://wiki.fhem.de/wiki/Spezial:Dateien

baust du`s in den artikel ein?

[Beta-User]

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

[DasQ]

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.

[Beta-User]

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?

[DasQ]

schnellschuss

Edit unfug

[Beta-User]

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

[DasQ]

Omg Schnellschuss ohne Hirn .... ja klar generic Bridge, ich sekel.

Ja ich glaub dann wär ne grobe Skizze hilfreich.

[Beta-User]

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