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?
