In meinem Projekt "Alternatives Heizungskonzept" müssen die wesentliche Daten (Sollwert, Istwert, Boost-Status) der Homematic-IP-Thermostate (Wandthermostate oder Radiator-Thermostate)
zu den Reglern der Infrarot-Heizung übertragen werden.
Dies übernimmt die vorhandene CCU-2-Homematic-Zentrale. Sie agiert als Gateway und Nachrichten-Publisher.
Damit profitieren die Regler der IR-Heizung im genannten Projekt von den Sensoren und Settings (Soll-/Istwert, Wochenprogramme , Betriebasrt) der Homematic-Welt und können diese nutzen.
Auf den Einsatz von MQTT oder Cloud-Computing wurde bewusst verzichtet, um möglichst wenig technische Abhängigkeiten zu haben.
Folgende Anforderungsliste sollte erfüllt werden
1. der Gateway (CCU-2) muss keine Information darüber haben, wer die Daten nutzt.
2. Eine Benutzer-Interaktion (Boost-Mode-Änderung) sollte unmittelbar(< 5 Sekunden) an die IR-Regler weitergereicht werden
3. Die Daten werden zyklisch veröffentlich (published)
4. Das Datenformat der übertragenen Nachricht folgt den Grundkonzepten eines MQTT-Systems mit den Elementen Topic und Payload
5. Eine Nachricht wird immer im JSON-Format übertragen.
Die Regler-Hardware ist meist ein Shelly, aber immer mit Tasmota-Firmware, samt Berry-Skript.
Anforderung Nr. 1
Diese wird mit Hilfe von UDP-Multicast-Telegrammen umgesetzt.
In der CCU werden diese mit einem Skript generiert, welches zyklisch und/oder ereignisgesteuert gestartet wird.
UDP-Multicast verwendet eine fixe IP-Adresse und einen dezidierten Port an welchen die Nachricht gesendet wird.
Jeder interessierte Teilnehmer kann einen Multicast-Listener öffnen, um diese Nachrichten zu empfangen.
Anforderung Nr. 2 und Nr. 3
Über das Homematic-Programm "UDP-Publish" wird das Ereignis (Boost) detektiert welches unmittelbar das Multicast-Script startet.
Die Reaktiongeschwindigkeit ist deutlich <5 Sekunden.
Zusätzlich wird das Multicast-Script über einen 30-Sekunden-Timer aktiviert.
Umgesetzt wird UDP-Multicast mit dem Linux-Programm "socat", welches bei Cuxd enthalten ist.
Anforderung Nr. 4 und Nr. 5
Das Multicast-Script der CCU setzt diese Anforderung um. (Siehe Anhang)
Nachfolgend eine Beispiel-Nachricht von der CCU.
{
"topic": "CCU/thermostat",
"payload": {
"DG1": {
"ACTUAL_TEMPERATURE": 19.1,
"SET_POINT_TEMPERATURE": 17.5,
"LEVEL": 0.0,
"BOOST_MODE": false,
"WINDOW_STATE": 0,
"HUMIDITY": 0,
"USAGE": "Arbeiten-2"
},
"DG2": {
"ACTUAL_TEMPERATURE": 18.5,
"SET_POINT_TEMPERATURE": 17.5,
"LEVEL": 0.25,
"BOOST_MODE": false,
"WINDOW_STATE": 0,
"HUMIDITY": 0,
"USAGE": "Schlafen-1"
},
"DG4": {
"ACTUAL_TEMPERATURE": 19.4,
"SET_POINT_TEMPERATURE": 18.0,
"LEVEL": 0.14,
"BOOST_MODE": false,
"WINDOW_STATE": 0,
"HUMIDITY": 0,
"USAGE": "Arbeiten-1"
}
}
}Zum Abschluss
Mit dem Konzept wurde ein Serverless Broker umgesetzt, welcher auf UDP-Multicast basiert.
Die CCU dient hier als Daten-Publisher.
Die Nachrichten können von interessierten IR-Controller abonniert werden.
In Tasmota wurde mit Hilfe von Berry-Skript ein UDP-Multicast-Listener eingerichtet, welcher die Nachrichten der CCU empfangen kann
und an die betroffenen Software-Komponenten (Regler) weiterreicht.
