Artikelstruktur zu MQTT-Themen

[DasQ]

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

[Beta-User]

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 .

[DasQ]

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

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

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?

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.

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 .

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.

[Beta-User]

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:

[...] 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..

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.

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

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.

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.

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?

[Beta-User]

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!

[DasQ]

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

[Beta-User]

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:

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 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; [...])

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!

[DasQ]

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

[Beta-User]

Auch wenn es hier OT ist: Wilkommen zurück!