Im vorigen Beitrag wurde das Skript für die SessionID besprochen. Diese wird nun benötigt um die Heizungsventile zu steuern. Auslöser der Steuerung sind dabei die Fenstersensoren der HomematicIP. Die Verbindungslogik befindet sich in der CCU3, der Zentrale des HomematicIP-Systems.

Die CCU3 ist natürlich speziell dafür konzipiert, innerhalb der HomematicIP-Geräte für Verbindung zu sorgen. Sobald irgendetwas Externes dazukommt, benötigt man eine der unzähligen Erweiterungen der großen Community. Die Erweiterung meiner Wahl ist für diesen Anwendungszweck der CUx-Daemon. Absichtlich verkinke ich hier nicht gleich die Downloadadresse dieses Softwarestückes, sondern eine zwar alte aber trotzdem sehr gute Einführung in das Thema: „Mit dem CUx-Daemon nahezu unbegrenzte Möglichkeiten“ von digitaldad.

Die CCU stellt alle möglichen Komponenten mit ihren Parametern zur Verfügung. Will man jedoch ein Gerät oder einen Anschluss außerhalb der HomematicIP-Familie ansprechen, benötigt man ein virtuelles Gerät. Genau das ist der Sinn und Zweck des CUx-Daemons, der jetzt gemäß der verlinkten Einführung auf der CCU installiert werden sollte, wenn das Projekt weiter verfolgt werden soll.

Sofern man der Anleitung folgt, bekommt man einen virtuellen Taster, der unter anderem folgenden Kanal bereitstellt, was man im unteren Teil der Statusinformation im CUx-Daemon-Fenster auslesen kann:

CUX2801001:1

Das ist schon mehr oder weniger der ganze Zauber an der Sache. Dieser Kanal bzw. Anschluss ermöglicht uns die Kommunikation beispielsweise mit einem anderen Server. Doch, – der Reihe nach …

Der Fensterkontakt in der CCU3:

Ich gehe hier davon aus, dass der Fensterkontakt (bei mir ist es ein HmIP-SWDO-2) bereits an die CCU3 angelernt ist und passend bezeichnet wurde:

Ich habe diesen Fensterkontakt mit „Fenster Bad“ bezeichnet. Grundsätzlich ist die erste Zeile das Grundgerät und darunter werden eingerückt die einzelnen Kanäle gezeigt. Der eigentliche Aktor ist in diesem Fall Kanal 1 und damit die eingerückte Zeile. Jeder Kanal kann beliebig benannt werden.

Unser Fensterkontakt kennt die Zustände „offen“ und „geschlossen“. Diese beiden Zustände werden je in eine Anweisung unter „Programme und Zentralenverknüpfung“ aufgenommen:

mit dem Skript:

string url="'http://192.1xx.xxx.xxx/PHP/Fritz/Fritz_HK_Bad_Off.php'";
dom.GetObject("CUxD.CUX2801001:1.CMD_EXEC").State("wget -q -O /dev/null " # url);

… und …

mit dem Skript:

string url="'http://192.1xx.xxx.xxx/PHP/Fritz/Fritz_HK_Bad_Komfort.php'";
dom.GetObject("CUxD.CUX2801001:1.CMD_EXEC").State("wget -q -O /dev/null " # url);

Jeweils in der ersten Zeile liegen Pfad und Name des angesprochenen Skriptes. In der zweiten Zeile wird dann das Skript auch wirklich angesprochen. Ich gehe an dieser Stelle nicht weiter auf die einzelnen Parameter und auf die Bedienlogik der CCU-GUI  ein, da das zu weit führen würde. Der geneigte Leser findet im Internet ausreichend Informationen dazu. Beispielsweise sei auch diese Quelle sehr empfohlen. Aber man sieht hier den virtuellen Kanal, den ich oben mit CUx-Daemon erzeugt habe. 

Die Skripte:

Im vorhergenden Beitrag wurde die Funktion zur Ermittlung der SessionID in ein eigenes File gelegt. Das eigentliche Skript zur Temperaturänderung eines AVM-Heizungsventils kam noch gar nicht zur Sprache. Aber jetzt:

Grundvorraussetzung ist natürlich ein kleiner Server, der überhaupt die Ausführung von Skripten erlaubt. Da heute aber beispielsweise NAS-Geräte schon eine große Verbreitung haben und auch mit einem einfachen Raspberry Pi leicht ein solcher Server eingerichtet werden kann, sollte das kein Hindernis sein. So ein kleiner Server kann zudem noch viele andere Aspekte steuern und bereitstellen: Musik, Filme, Fotos, Haussteuerung, Wetterstation usw.. Auf diesem Server richtet man sich ein Verzeichnis „PHP“ ein und legt bestenfalls darunter noch weitere Ordner ein, die der Übersichtlichkeit dienen. Bei mir liegt in diesem PHP-Verszeichnis der Ordner „Fritz“. Erst dort liegen dann die php-Skripte zur Steuerung der Ventile. In den beiden oben gezeigten Skripten findet man diese Struktur wieder.

Die Skripte selbst orientieren sich an der Definition AVMs. Die Quelle für die Befehle findet man hier.

<?php

// Fritz_HK_Bad_Off.php
// Abschalten HK Bad


// Session ID mit Funktion in der eigenen Funktionen-php holen

include('Fritz_Funktionen.php');

$ses_id = get_sid();


// IDs der Geräte

$thermostat = "0xxxxxxxxxxx"; //HKBad

// Hier kommt dann das eigentliche Kommando an einen Heizkörperthermostat
// einstellbar von 8°C bis 28°C in 0,5°-Schritten. 8°C entspricht 16. 10°C entspricht 20, an = 254, aus = 253

// Solltemperatur setzen
$temp_soll_ist_step = file_get_contents('http://192.1xx.xxx.xxx/webservices/homeautoswitch.lua?switchcmd=sethkrtsoll&ain='.$thermostat.'&param=253&sid='.$ses_id);

return ;

Über ein include wird bekannt gemacht, wo die aufgerufenen Funktionen liegen. Das ist in diesem Fall nur die Funktion get_sid().

Es ist eine gute Idee um die Wiederverwendbarkeit des Codes zu erhöhen, solche Werte wie die Geräte-Id des Heizkörperventils in deine Variable zu legen. Code für ein anderes Ventil ist dann schnell geschrieben, weil man die betreffenden Daten leicht wiederfindet.

Dann kommt auch schon die Anweisung, um in diesem Fall das Ventil mit dem Parameter 253 zu schließen. Die IP-Adresse ist die Adresse der FRITZ!Box an der die Ventile per DECT hängen. Der Aufbau des Datenpakets hinter dem Fragezeichen ist gemäß oben genannter Quelle recht simpel. Der gewünschte Befehl wird genannt (Setzen der Solltemperatur mit sethkrtsoll), die Adresse des ansprochenen Ventils (ain mit $thermostat), der Sollwert (param mit 253 für vollständiges Schließen, die SessionID). Hier kommt kein Passwort oder Userid vor!

Das Skript für das Öffnen des Ventils ist nur einen Befehl länger:

<?php

// Fritz_HK_Bad_Komfort.php
// Komforttemperatur für HK Bad


// Session ID mit Funktion in der eigenen Funktionen-php holen

include('Fritz_Funktionen.php');

$ses_id = get_sid();


// IDs der Geräte

$thermostat = "0xxxxxxxxxxx"; //HKBad

// Hier kommt dann das eigentliche Kommando an einen Heizkörperthermostat
// einstellbar von 8°C bis 28°C in 0,5°-Schritten. 8°C entspricht 16. 10°C entspricht 20, an = 254, aus = 253

// Komforttemperatur auslesen
$temp_komfort_step = file_get_contents('http://192.1xx.xxx.xxx/webservices/homeautoswitch.lua?switchcmd=gethkrkomfort&ain='.$thermostat.'&sid='.$ses_id);

// Solltemperatur setzen
$temp_soll_ist_step = file_get_contents('http://192.1xx.xxx.xxx/webservices/homeautoswitch.lua?switchcmd=sethkrtsoll&ain='.$thermostat.'&param='.intval($temp_komfort_step).'&sid='.$ses_id);


return ;

Neu ist hier lediglich das Auslesen der Solltemperatur aus dem Ventil. Mit diesem Wert als Parameter setzt das Skript die neue Temperatur.

Das ist eigentlich schon die gesamte Steuerung. Man kann da natürlich noch viel verbessern und auch weitere Ideen umsetzen. Ich bin ganz froh darüber, dass AVM die Steuerung offenlegt und damit solche Sachen Plattformübergreifend ermöglicht.

Einen Haken hat die Sache aber und das wirst Du gemerkt haben, wenn Du das Skript aufgerufen hast. Wenn das Skript die neue Wunschtemperatur übermittelt, bekommt in Wahrheit nur die FRITZ!Box etwas davon mit. Die Ventile holen (Stand Feb.2025 beim 301er) nur alle 15 Minuten neue Informationen bei ihrer FRITZ!Box ab. Beim 302er soll das wohl auf 5 Minuten reduziert worden sein. Zwei Gründe gibt es dafür. Erstens legt die DECT-Richtlinie fest, dass kein Gerät ständig funken darf. Zweitens will man die Batterien im Ventil schonen. Im Mittel wird die Temperatur also beim 301er nach 7,5 Minuten aktuallisiert. Ob es wirklich notwendig ist, eine schnellere Reaktion zu haben? … und dann kann man noch das Ventil zum sofortigen Reagieren zwingen, indem man irgendeine Taste auf dem Ventil drückt: Fenster öffnen => „OK“ am Ventil drücken => Ventil regelt herunter.

Für ein einziges Ventil im Haus lohnt sich die Sache vermutlich nicht. Aber wenn man nun das ganze Haus damit ausstattet (Ventile und Fenstersensoren) kann man schon eine Einsparung erreichen, wenn man die Investition über Jahre gegenrechnet. Die Fenstersensoren eignen sich aber auch hervorragend um damit eine Alarmanlage zu realisieren. Bei geschickter Steuerung würde das Öffnen eines Fensters oder einer Tür zum Alarm führen. Eine Sirene und ein Schalter sind dafür aber noch zusätzlich notwendig. Die CCU3 übernimmt die Steuerung.

Sollten Fragen offen bleiben, schreibt mir gerne. Ich bemühe mich immer, schnellstmöglich zu antworten.