MQTT Bridge
Der CCU-Jack kann eine Verbindung zu anderen MQTT-Servern bzw. anderen CCUs mit installiertem CCU-Jack aufbauen. Dies ermöglicht vielfältige Anwendungsmöglichkeiten:
- Senden aller Wertänderungen von allen oder bestimmten CCU-Datenpunkte an einen externen MQTT-Server
- Empfang von Steuersignalen von einem externen MQTT-Server
- Direkte Kopplung von zwei oder mehr CCUs
- Kopplung von zwei oder mehr CCUs über einen zentralen MQTT-Server
Durch die virtuellen MQTT-Geräte des CCU-Jacks können beliebige MQTT-Nachrichten erzeugt werden und auch auf beliebige MQTT-Nachrichten reagiert werden. Die virtuellen Geräte können direkt in CCU-Programmen angesteuert und auch abgefragt werden.
Es kann nur eine Brücke zu einem anderen Server aufgebaut werden. Eine Vernetzung von mehreren MQTT-Severn kann über eine Baumstruktur oder einem zentralen Server erfolgen. Eine verschlüsselte Verbindung mit TLS zu einem anderen MQTT-Server ist noch nicht möglich.
Für die MQTT-Brücke müssen die Verbindung zu dem zweiten MQTT-Server, die eingehenden und die ausgehenden Topics konfiguriert werden. Zurzeit erfolgt die Konfiguration in der Datei ccu-jack.cfg (siehe dazu auch Add-On Installationsdetails und CCU-Dateitransfer und Konsolenzugriff). Die Konfigurationsdatei darf nur geändert werden, wenn der CCU-Jack gestoppt ist.
| Konfigurationsoption | Bedeutung |
|---|---|
| MQTT.Bridge.Enable | Ein- oder Ausschalten der MQTT-Brücke (true oder false) |
| MQTT.Bridge.Address | IP-Adresse oder Host-Name des entfernten MQTT-Servers |
| MQTT.Bridge.Port | Port des entfernten MQTT-Servers |
| MQTT.Bridge.Username | Benutzername für den entfernten MQTT-Severs |
| MQTT.Bridge.Password | Passwort für den entfernten MQTT-Severs |
| MQTT.Bridge.ClientID | Identifizierung des lokalen MQTT-Clients |
| MQTT.Bridge.CleanSession | Sitzungsdaten löschen (s.a. MQTT-Spezifikation) |
| MQTT.Bridge.Incoming | Eingehende Topics (siehe unten) |
| MQTT.Bridge.Outgoing | Ausgehende Topics (siehe unten) |
Dies ist ein Konfigurationsbeispiel. Es sind nur Optionen aufgelistet, die für die Konfiguration der MQTT-Brücke relevant sind:
{
"MQTT": {
"Bridge": {
"Enable": true,
"Address": "192.168.0.100",
"Port": 1883,
"UseTLS": false,
"CACertFile": "",
"Insecure": false,
"Username": "Benutzername",
"Password": "Passwort",
"ClientID": "Haupt-CCU",
"CleanSession": true,
"Incoming": [],
"Outgoing": []
}
}
}Mit den Konfigurationseigenschaften MQTT.Bridge.Incoming und MQTT.Bridge.Outgoing wird festgelegt, welche lokalen Topics an den entfernten Server versendet und welche Topics vom entfernten MQTT-Server empfangen werden sollen. Jeder Eintrag in MQTT.Bridge.Incoming bzw. Outgoing muss folgende Eigenschaften besitzen:
| Eigenschaft | Bedeutung |
|---|---|
| Pattern | MQTT-Suchmuster (optional mit den Platzhaltern # und +) |
| LocalPrefix | Lokales Präfix für die Topics |
| RemotePrefix | Präfix für die Topics vom entfernten MQTT-Server |
| QoS | Quality-of-Service (0, 1, oder 2; s.a. MQTT-Spezifikation) |
Eingehende Topics werden wie folgt behandelt:
Auf dem entfernten MQTT-Server wird das Topic aus den Eigenschaften RemotePrefix und Pattern zusammengesetzt und abonniert. Bei der Übertragung wird das RemotePrefix durch das LocalPrefix ersetzt. Auf dem lokalen MQTT-Server wird nun die MQTT-Nachricht mit dem geänderten Topic publiziert.
Ausgehende Topics werden wie folgt behandelt:
Auf dem lokalen MQTT-Server wird das Topic aus den Eigenschaften LocalPrefix und Pattern zusammengesetzt und abonniert. Bei der Übertragung wird das LocalPrefix durch das RemotePrefix ersetzt. Auf dem entfernten MQTT-Server wird nun die MQTT-Nachricht mit dem geänderten Topic publiziert.
Die eingehenden und ausgehenden Topics dürfen sich nicht überlappen, da ansonsten eine MQTT-Nachricht unendlich zwischen den Servern hin und her geschickt wird.
Für eine gesicherte Verbindung sind zusätzlich folgende Konfigurationsoptionen zu setzen:
{
...
"UseTLS": true,
"CACertFile": "/path/to/cacerts.pem",
"Insecure": false,
...
}Für eine gesicherte Verbindung zu einer entfernten CCU mit installiertem CCU-Jack muss die Datei /etc/config/server.pem der entfernten CCU auf die lokale CCU kopiert werden (z.B. nach /usr/local/addons/ccu-jack) und mit der Option CACertFile referenziert werden.
Die Überprüfung des Server-Zertifikats kann für Testzwecke durch Setzen der Option "Insecure": true temporär deaktiviert werden.
Die CCU ist im überlagerten MQTT-Server unter dem Topic-Prefix charly/ zu finden. Die Topics mit den Mustern charly/+/set/# und charly/+/get/# können auf dem überlagerten MQTT-Server publiziert werden, die Wertaktualisierungen sind unter dem Topic charly/+/status/# abonnierbar.
...
"MQTT": {
"Port": 1883,
"PortTLS": 8883,
"BufferSize": 0,
"WebSocketPath": "/ws-mqtt",
"Bridge": {
"Enable": true,
"Address": "mein-externer-mqtt-server",
"Port": 1883,
"BufferSize": 0,
"UseTLS": false,
"CACertFile": "",
"Insecure": false,
"Username": "charly",
"Password": "geheim",
"ClientID": "charly",
"CleanSession": true,
"Incoming": [
{
"Pattern": "+/set/#",
"LocalPrefix": "",
"RemotePrefix": "charly/",
"QoS": 0
},
{
"Pattern": "+/get/#",
"LocalPrefix": "",
"RemotePrefix": "charly/",
"QoS": 0
}
],
"Outgoing": [
{
"Pattern": "+/status/#",
"LocalPrefix": "",
"RemotePrefix": "charly/",
"QoS": 0
}
]
}
},
...Im folgenden Konfigurationsbeispiel werden alle Topics einer zweiten CCU abonniert und erscheinen mit dem Präfix remote-ccu/recv/ auf dem lokalen MQTT-Server. Werden auf dem lokalen Server MQTT-Nachrichten mit dem Topic-Präfix remote-ccu/send/ publiziert, so erscheinen sie auf dem entfernten Server ohne dieses Präfix.
...
"Incoming": [
{
"Pattern": "#",
"LocalPrefix": "remote-ccu/recv/",
"RemotePrefix": "",
"QoS": 0
}
],
"Outgoing": [
{
"Pattern": "#",
"LocalPrefix": "remote-ccu/send/",
"RemotePrefix": "",
"QoS": 0
}
]
...Autor dieses Handbuchs ist Mathias Dzionsko. Dieses Handbuch steht unter folgender Lizenz:
