devi2mqtt
devi2mqtt ist kein eigenes Projekt von mir, sondern der Name meines Docker-Stacks für das Open-Source-Projekt ha-devi-mqtt von Igor Podpalchenko. Es bindet DeviReg Smart-Thermostate von Danfoss für die Fußbodenheizung per MQTT an. Gedacht ist es für Home Assistant, es funktioniert aber genauso gut mit Symcon. Auf dieser Seite beschreibe ich, wie ich es einsetze: Ordnerstruktur, Topic-Anpassung, Portainer-Stack und Einbindung in Symcon.
Die Thermostate haben keine lokale Schnittstelle. Sie sprechen nur mit der Danfoss-Cloud über das Protokoll SecureDeviceGrid. ha-devi-mqtt meldet sich dort wie die App an, liest alle Werte aus und nimmt Steuerbefehle per MQTT entgegen. Der Code geht laut README auf das openHAB-Binding für DeviReg zurück und nutzt die Bibliothek OpenSDG .
DeviReg Smart ──WLAN──> Danfoss-Cloud <──SDG── ha-devi-mqtt ──MQTT──> Broker ──> Symcon
Thermostat (SecureDeviceGrid) (Docker) :1883
Was man bekommt
- Rund 50 Werte pro Thermostat: Raum- und Bodentemperatur, Sollwert, Heizstatus, Betriebsart, Sollwerte für die einzelnen Modi, Wochenplan und Verbindungsstatus
- Steuerung: Solltemperatur, Betriebsart und Schalter lassen sich per MQTT-Befehl setzen
- Einfache Topics: ein Wert pro Topic unter
devi/state/<Seriennummer>/…, Befehle unterdevi/command/<Seriennummer>/… - Fertiges Docker-Image des Autors für
amd64undarm64, läuft also auch auf einem Raspberry Pi
Voraussetzungen
- DeviReg-Smart-Thermostat, eingerichtet in der Danfoss-App
- Docker, bei mir mit Portainer verwaltet
- ein MQTT-Broker im Heimnetz, z. B. die MQTT-Server-Instanz in Symcon
- für die einmalige Kopplung: Java und das JAR aus dem Original-Projekt
Kopplung und Zugangsdaten
Bevor der Container laufen kann, braucht er eine devi_config.json mit dem Schlüssel für die Cloud. Die Datei erzeugt das Discovery-Werkzeug aus dem Original-Projekt. Laut README funktioniert die Kopplung nicht im Docker-Container, sie läuft einmalig direkt mit Java. In der Danfoss-App erzeugt man unter Einstellungen → Haus teilen einen Einmalcode (OTP) und gibt ihn zusammen mit einem frei gewählten Benutzernamen im Discovery-Werkzeug ein. Gekoppelt wird das ganze Haus, nicht ein einzelnes Gerät.
Die genauen Schritte stehen im README des Projekts . Wichtig: Die erzeugte Datei enthält den privaten Schlüssel, mit dem sich die Heizung steuern lässt. Sie gehört an einen sicheren Ort und nur für root lesbar.
Ordnerstruktur auf dem Host
Alle Dienste liegen bei mir unter /opt/services/<name>/, die Konfiguration bleibt außerhalb des Containers. Ein Update des Images überschreibt so nichts.
/opt/services/devi2mqtt/
├── devi_config.json # Zugang zur Danfoss-Cloud und Geräte (aus der Kopplung)
├── mqtt_config.json # MQTT-Broker
└── auto-discovery-templates/ # Templates aus dem Repo, Topic-Präfix angepasst
Die mqtt_config.json ist kurz. Den Broker trage ich mit seiner IP-Adresse ein, nicht mit localhost, denn aus Sicht des Containers wäre das der Container selbst:
{
"host": "<broker-ip>",
"port": "1883",
"user": "<mqtt-benutzer>",
"password": "<mqtt-passwort>"
}
Templates holen und Topic-Präfix anpassen
Beim Start veröffentlicht ha-devi-mqtt für jeden Wert eine Discovery-Nachricht für Home Assistant, standardmäßig unter homeassistant/…. Die Werte selbst liegen ohnehin unter devi/state/…. Damit alles in einem gemeinsamen Zweig landet und im Discovery-Bereich eines eventuell vorhandenen Home Assistant nichts auftaucht, ändere ich den Präfix der Discovery-Topics auf devi/. In jeder Template-Datei betrifft das eine Zeile:
- "topic": "homeassistant/climate/${deviceSN}_devi_thermostat/config",
+ "topic": "devi/climate/${deviceSN}_devi_thermostat/config",
Die Templates gehören zum Original-Projekt, deshalb verteile ich keine angepassten Dateien. Man holt sie sich selbst und passt sie mit einem Befehl an:
git clone https://github.com/igor-podpalchenko/ha-devi-mqtt.git /tmp/ha-devi-mqtt
sudo mkdir -p /opt/services/devi2mqtt
sudo cp -r /tmp/ha-devi-mqtt/auto-discovery-templates /opt/services/devi2mqtt/
cd /opt/services/devi2mqtt
sudo sed -i 's#"homeassistant/#"devi/#' auto-discovery-templates/*.json auto-discovery-templates/autogen/*.json
Ob alles geklappt hat, zeigt ein kurzer Blick auf die Topic-Zeilen. Dort darf kein homeassistant/ mehr stehen:
grep -r '"topic"' auto-discovery-templates | head
Der Portainer-Stack
In Portainer lege ich einen Stack devi2mqtt an, Zugriff nur für Administratoren:
services:
devi2mqtt:
image: podpalch/ha-devi-mqtt:latest
container_name: devi2mqtt
restart: unless-stopped
volumes:
- /opt/services/devi2mqtt/devi_config.json:/app/config/devi_config.json:ro
- /opt/services/devi2mqtt/mqtt_config.json:/app/config/mqtt_config.json:ro
- /opt/services/devi2mqtt/auto-discovery-templates:/app/config/auto-discovery-templates:ro
Die Pfade im Container unter /app/config/ gibt das Dockerfile des Originals vor. Alle Dateien sind nur lesend eingebunden. network_mode: host braucht es nicht, solange der Broker über seine IP-Adresse erreichbar ist.
Prüfen
Die Logs zeigt Portainer unter Containers → devi2mqtt → Logs, auf der Kommandozeile geht es mit docker logs -f devi2mqtt. Nach dem Start sollten sinngemäß diese Zeilen erscheinen:
INFO ConsoleRunner - /app/config/auto-discovery-templates/....json
INFO GridConnectionKeeper - Successfully connected to Danfoss grid
INFO SDGPeerConnector - Connecting to peer ...
INFO SDGPeerConnector - Connection established
Danach lohnt ein Blick in den MQTT Explorer
: Unter devi/state/<Seriennummer>/ sollten die Werte ankommen. Als letzter Test setze ich einen Sollwert über devi/command/<Seriennummer>/set_temperature_target und schaue, ob das Thermostat ihn übernimmt.
Update
Ein Update ist in Portainer schnell erledigt: Stacks → devi2mqtt → Update the stack mit der Option Re-pull image and redeploy. Konfiguration und Templates liegen auf dem Host und bleiben erhalten. Bringt eine neue Version geänderte Templates mit, wiederholt man den Schritt mit git clone und sed.
Einbindung in Symcon
Symcon braucht nur Zugang zum selben Broker, bei mir ist das die MQTT Server-Instanz von Symcon selbst. Die wichtigsten Topics eines Thermostats:
| Topic | Inhalt |
|---|---|
devi/state/<SN>/temperature_current | aktuelle Temperatur |
devi/state/<SN>/temperature_target | Solltemperatur |
devi/state/<SN>/binary_sensor_heating_state | Heizung an/aus |
devi/state/<SN>/select_control_mode | Betriebsart |
devi/state/<SN>/binary_sensor_cloud_connected | Verbindung zur Cloud |
devi/command/<SN>/set_temperature_target | Solltemperatur setzen |
Die vollständige Liste der Werte steht im README des Projekts. Für jeden Wert, den ich in Symcon haben möchte, lege ich unter der MQTT-Server-Instanz ein MQTT Server Device mit dem passenden Topic an. Name, Icon, Darstellung und Archivierung der Variablen legt man in Symcon selbst fest.
So sieht das Ergebnis bei mir in der TileVisu aus. Das Thermostat lässt sich wie in der App bedienen: Betriebsart wählen, Sollwert ändern, Temperaturen der einzelnen Modi anpassen und Funktionen wie Fenstererkennung oder Bildschirmsperre schalten. Dazu kommen Heizzustand, Cloud-Verbindung, die Warnmeldungen des Thermostats, Heizzeit und Verbrauch sowie Raum- und Bodentemperatur im Verlauf.

Hintergrund
Vorher lief ha-devi-mqtt bei mir als systemd-Dienst mit einem selbst gebauten JAR. Mit dem Umzug nach Docker verwalte ich jetzt alle Dienste gleich: ein Stack pro Dienst in Portainer, die Konfiguration zentral unter /opt/services/…. Nach demselben Muster laufen auch meine eigenen Dienste tuya2mqtt
und flights2mqtt
.
Schön wäre, wenn sich der Topic-Präfix im Original-Projekt direkt einstellen ließe. Dann entfiele der Schritt mit sed.
Quellen
- Projekt: igor-podpalchenko/ha-devi-mqtt von Igor Podpalchenko
- Docker-Image: podpalch/ha-devi-mqtt
- Ursprung: openHAB-Binding für DeviReg und OpenSDG
DeviReg und Danfoss sind Marken der Danfoss A/S. Diese Seite beschreibt nur den Einsatz des Open-Source-Projekts und steht in keiner Verbindung zu Danfoss.