MQTT-Bridge Funktionalität

[sbehnsen]

Es wäre schön, wenn man den MQTT Server auch als Bridge konfigurieren könnte. In vielen Systemen gibt es schon einen MQTT Server, and damit könnte man die CCU mit ccu-jack dann direkt an den existierenden MQTT Server hängen. Ebenfalls könnte man damit dann auch einfach mehrere CCUs bestimmte Daten direkt an einen MQTT Server im Internet schicken lassen. Last but not least, wenn die Bridge Konfiguration auch mehrere Remote MQTT Server unterstützt, dann bekommt man auch noch Failover...

[mdzio]

Siehe auch #12.

In der Regel kann ein existierender MQTT-Server bereits als Bridge konfiguriert werden, sodass die Funktionalität im CCU-Jack nicht benötigt wird. Ist das mit dem existierenden MQTT-Server bei Dir möglich?

Die anderen Anwendungsfälle finde ich dann schon interessanter. Deshalb lasse ich diesen Eintrag mal offen, um darüber zu diskutieren.

[bergernetch]

Wie wäre es, wenn man statt einem internen einfach einen externen MQTT server angeben könnte?

[mdzio]

Die Schnittstellen zur CCU sind direkt über eine API an den internen MQTT-Server angebunden. Sie verwenden keinen MQTT-Client und gehen nicht über das Netzwerk. Daher kann leider nicht einfach ein anderer MQTT-Server angegeben werden.

Ich denke aber inzwischen, dass der CCU-Jack MQTT-Bridge Funktionalität bekommen sollte. Dadurch könnten dann auch mehrere CCU einfach miteinander Werte austauschen.

[sbehnsen]

Ja, mit einer externen Bridge sollte man natürlich auch jetzt schon die Daten aus de CCU-Jack "abholen" können. Ich wollte das schon seit einiger Zeit ausprobieren, bin aber noch nicht dazu gekommen. Ich hoffe, dass ich bald mal dazu komme das zu testen.

Vielleicht könnte/solle man allerdings, wenn man dem CCU-Jack Bridge Funktionalität verleiht, doch nochmal darüber nachdenken auch Client mit einzubauen, da die Bridge ja im Prinzip nichts anderes ist als ein Client gegenüber einem anderen MQTT-Server (sprich der Client Code ist dann größtenteils sowieso schon da). Ich denke es gibt viele User, die eigentlich nur dieses Feature gerne hätten und das wäre dann deutlich einfacher zu Konfigurieren (eine Bridge zu konfigurieren ist deutlich aufwendiger, hat aber den unten aufgeführten Vorteil). Im Prinzip wäre das dann eine "einfache" Konfigurationsoption eine Bridge zu konfigurieren, die einfach alle Daten "bridged".

Der großer Unterschied zwischen Client und Bridge ist ja, dass ich mit der Bridge-Config entscheiden kann welche Daten ich "abhole" während ein Client mir ja immer alles an meinem MQTT Server schickt und in 99% der Fälle sind da viele Daten bei die man nicht braucht.

[christoph-morrison]

JFTR

Ich hole mit einer Mosquitto-Bridge Daten von meiner CCU3 ab - und da kann man natürlich nur spezifische Topics abonnieren. Ich mache das nicht, schiebe aber die Topics von der CCU3 in einen neuen Baum auf meinem Mosquitto-Broker.

Die Konfigurationsdatei liegt in /etc/mosquitto/conf.d/ccu3-jack-bridge.conf und enthält nur wenig:

connection ccu3-jack-bridge
address ccu3:1883

topic # both 0 hab/gateways/ccu3/  ""

Auf meinem Broker schreibt die Bridge dann z.B. in hab/gateways/ccu3/device/status/000218A99CB0A4 (ein HMIP-PS Schaltzwischenstecker).

Mit einem beherzten Request nach hab/gateways/ccu3/device/set/000218A99CB0A4/3/STATE mit folgendem JSON

{"v":true}

auf meinem Mosquitto-Broker lässt sich der Aktor auch einschalten, funktioniert also in beide Richtungen.

[Elix-g]

Ich nutze mosquitto als primären MQTT Broker und CCU-Jack unter RaspberryMatic, um meine Homematic-Geräte mit allen Anderen zusammenzubringen. Dabei baut mosquitto eine Bridge zum CCU-Jack auf. Seitens CCU-Jack ist lediglich ein normales User-Konto und sonst keine weitere Konfiguration notwendig. Sämtliche Einstellungen der Bridge erfolgen in mosquitto. Die Bridge funktioniert gesichert mit TLS1.3 einwandfrei in beide Richtungen.

@sbehnsen Warum das Rad zweimal erfinden? Letztlich geht es darum, eine transparente Bridge zwischen zwei Brokern aufzubauen. Im einfachsten Fall werden sämtliche Topics die über Broker B laufen von Broker A abonniert und gleichzeitig schickt Broker A sämtliche seiner Topics an Broker B. Von welcher Seite aus eine Bridge aufgebaut wird, spielt keine Rolle. Fakt ist, dass im Broker der die Bridge aufbaut, sämtliche Funktionalität implementiert haben sollte, um Bridges sinnvoll einsetzen zu können. Das ist ganz schnell ein riesiger Programmieraufwand der betrieben werden müsste. Meiner Meinung nach überflüssig, da mosquitto bereits fast alle erdenklichen Möglichkeiten bietet. Der einzige "Vorteil" wäre, dass der User auf einer grafischen Oberfläche die Bridge einrichtet anstatt über eine Konfigurationsdatei. Dass Letzteres überhaupt nicht aufwendig ist wie du behauptest, hat christoph-morrison in seinem Beitrag gezeigt. Einem User, der solch einen Zweizeiler nicht hinbekommt, ist auch mit einer grafischen Oberfläche nicht zu helfen. Wenn man verstanden hat, wie MQTT funktioniert, sollte man bemerkt haben, wo sämtliche Intelligenz angesiedelt ist, nämlich auf Seiten des Brokers. Ein Client ist dumm und schickt natürlich alles was er hat an den Broker. Der wertet aus und stellt Topics nur den Clients zur Verfügung, die diese abonniert haben. Die Funktionalität von Abonnements ist also komplett auf der Seite des Brokers implementiert. Der Client teilt lediglich mit, welche Topics er zugeschickt haben möchte. Selbstverständlich kann ein Broker, zumindest im Falle von mosquitto so konfiguriert werden, dass von einem Client nur bestimmte Topics angenommen und alle anderen verworfen werden. Dazu braucht es keine Bridge.

[sbehnsen]

mdzio hatte geschrieben, dass er darüber nachdenkt Bridge Funktionalität in den CCU-Jack einzubauen damit mehrere CCU damit untereinander Daten austauschen können. Inwiefern dafür Bedarf besteht kann ich nicht einschätzen. Mein Kommentar bezog sich darauf, darauf, dass man damit (also mit der Bridge Funktionalität in einem MQTT Broker) auch schon quasi einen Client einbaut und es dann ev. auch sehr einfach wäre diesen auch zur Verfügung zu stellen. Für User mit sehr einfachen Anforderungen wäre das hat einfacher, weil man sich vorher weniger Gedanken machen muss welche Daten man wo haben will und wie man das im Zweifelsfall richtig konfiguriert. (Beispiel in einem iobroker sehe ich dann einfach alles und kann mir aussuchen was ich haben will und auch einfach ausprobieren was was ist (...und ja iobroker ist nicht das beste Beispiel, weil man die CCU da auch direkt einbinden kann)). Ansonsten ist mir schon klar wie MQTT funktioniert, und dass es sowieso Sinn macht sich mehr Gedanken darüber zu machen wie man insbesondere mit Bridges das Datenvolumen in Netz klein halten kann. Den MQTT Broker so zu konfigurieren, dass bestimmte Topics nicht angenommen werden (bzw. verworfen werden) verringert den Netzwerk Trafic nicht (das ist also nicht wirklich eine Lösung). Insofern ist es insbesondere in Größeren Systemen sicherlich Sinnvoll mit Bridges zu arbeiten um die Daten gar nicht erst in das Netz zu geben. Für meine Anwendungen hier ist das sowieso der Weg den wir gehen werden. Dazu muss man aber auch vorher ganz genau wissen welche Daten unter welchen Topic geliefert werden und was man wie steuern kann. In meinem Anwendungsfall ist das wie schon gesagt kein Problem, aber wenn man sowieso schon quasi die Client Funktionalität einbaut (damit man eine Bridge machen kann), dann ist der Schritt auch Client anzubieten hat nur noch sehr klein und würde kleineren Anwendern das Leben einfacher machen.

[mdzio]

MQTT-Bridge Funktionalität wird in der nächsten Version enthalten sein.

Hier ist die Dokumentation dazu zu finden.