Seit fast zwei Jahren steuere ich die Heizungen unserer Wohnung nun schon mit Max!-Heizungsthermostaten. Wie ich das mache habe ich hier und da beschrieben. Ich denke es ist nun an der Zeit, einmal ein Resümee zu ziehen und ein paar weitere Erfahrungen hinzuzufügen.

Bitte werft auch einen Blick auf meinen Blogpost Energiekosten durch smarte Thermostate sparen mit FHEM!

Im Großen und Ganzen läuft das System sehr zufriedenstellend. Natürlich hat man damit etwas mehr Wartungsaufwand als mit einem Thermostat, an dem die Heizung einfach auf- oder zugedreht wird. Aber dafür ergibt sich doch eine Menge Einsparpotential schon allein dadurch, dass das Thermostat das Ventil automatisch herunter regelt oder gar abstellt, wenn der interne Temperatursensor die eingestellte Wunschtemperatur misst. Und der Komfortgewinn dadurch, im Obergeschoss die Heizung aufzudrehen ohne dahin laufen zu müssen ist sowieso unbezahlbar ;-).

Nicht so recht anfreunden konnte ich mich mit der Max!-Software. Dieses Java-Monstrum habe ich zwar dank eines Tipps unter meinem Linux-Desktop ans Laufen gebracht [1], doch profitiert man von der Max!-eigenen Fernsteuerung nur dann, wenn alle Daten auch in der Cloud gespeichert werden. Das habe ich abgestellt und steuere wie in den anderen Artikeln beschrieben meine Heizung per FHEM.

Für die mobile Steuerung nutze ich auf Android das Max! Remote von Johannes Utzig. Diese Software greift direkt auf den Max! Cube zu, ohne die Cloud zu nutzen. Für den Zugriff aus der Ferne bringt sie praktische Links direkt zum VPN-Zugang mit.

IST-Temperatur und Duty-Cycle

Die Max!-Thermostate kennen viele Einstellungen und liefern viele Daten. Diese können über den 868MHz-Kanal ausgelesen und gesetzt werden. Hierbei sind zwei wichtige Regeln zu beachten:

Erstens gibt es eine gesetzliche Regelung, die dafür sorgt, dass der Funkkanal nicht überlastet wird. Jedes Gerät darf nur 1% einer Stunde (also 36 Sekunden) Daten versenden. Diese Begrenzung heißt Duty Cycle und wird unter [2] ganz gut erklärt. Sind die 36 Sekunden Sendezeit erreicht, so kann das betreffende Thermostat nicht mehr mitspielen.

Der Duty Cycle kann im Max!Cube via FHEM ausgelesen werden. Ich habe mir das kleine, oben zu sehende Widget gebaut, damit ich den Duty Cycle immer im Blick habe. Zumindest hilft es zu verstehen, warum gerade nichts mehr passiert ;-).

Der zweite Punkt ist, dass die Thermostate nicht von sich aus senden. Nur dann, wenn sie getriggert werden, versenden sie auch Daten wie zum Beispiel die IST-Temperatur oder die Ventilstellung. Dies macht sich FHEM zu Nutze. Das Modul MaxScanner [3] schaltet die Thermostate abwechselnd vom Modus „Auto“ in den Modus „Manuell“ und triggert damit die Übermittlung der Daten. Diese Abfrage kann natürlich nicht sekundenaktuell sein (siehe Duty Cycle), aber so alle 3-5 Minuten erhält man durchaus einen Wert. Genauer beschreibe ich das Vorgehen hier.

Das untenstehende Diagramm zeigt in den bunten Linien die von den Thermostaten gemessenen Raumtemperaturen. Der graue Block ist die Summe aller Ventilstellungen. Hier sieht man deutlich – und das erfreut doch das Herz des Nerds – wie die Thermostate den Durchfluss beim Erreichen der Wunschtemperatur nach unten regulieren.

Gehe zurück zu los … Reset

Aber es hat einen guten Grund, weswegen ich gerade jetzt diesen Blog-Beitrag schreibe: Es sind die ersten kalten Tage, Batterien in den Thermostaten mussten ersetzt werden und die Wochenprogramme der Thermostate passen nicht mehr zu denen in FHEM oder in der Max!-Software. Manchmal ist es aber doch zum Haare raufen und dann gibt es Momente, in denen ich die Suche nach den Gründen für ein Fehlverhalten einfach aufgebe und einen Reset mache. Vermutlich muss das auch sein, denn das Problem liegt offensichtlich zwischen dem Max!Cube und den Thermostaten. Darin läuft halt auch nur Software ;-).

Für den kompletten Reset nutze ich die Max!-Software (Pinguine bitte kurz unter [1] weiterlesen). Das Vorgehen ist folgendes:

1. In der Max!-Software alle Thermostate entfernen.
2. Bei jedem einzelnen Thermostat einen Werksreset durchführen (Batterien entfernen, alle drei Taster drücken, Batterien wieder einlegen und warten, bis „rES“ angezeigt wird.
3. Alle Thermostate Stück für Stück mit der Max!-Software wieder anlernen (Neues Gerät hinzufügen, am Thermostat den ‚Boost‘-Taster lange drücken, typischerweise nach 3-4 Sekunden ist das Thermostat gefunden.).

Der unter Schritt 3 vergebene Name ist für FHEM irrelevant, das macht ein Mapping zum Thermostat aufgrund dessen eindeutiger ID. Sobald diese mit dem Max! Cube gepaired ist, können Daten ausgetauscht werden. Sehr wohl relevant ist der Raumname, in dem ein Thermostat angelegt wird, jedoch für das Max! Remote auf meinem Handy.

Und noch zwei kleine Hints: Solange die Max!-Software aktiv ist, können weder Max! Remote noch FHEM auf die Thermostate zugreifen. Und alle Thermostate, die in ein und demselben Raum angelegt werden, werden immer gekoppelt. Die wo auch immer (Thermostat, Fensterkontakt, FHEM, Max! Remote, …) eingestellte Temperatur gilt dann für alle Thermostate. Muss man einfach wissen ;-).

Konfiguration per FHEM

Die Feineinstellungen nehme ich dann wieder mit FHEM vor. Die Max!-Software ist mir hier einfach zu viel auf bunt und zu wenig auf funktional gebaut. Je Thermostat setze ich die folgenden Werte:

• minimale Temperatur und maximale Temperatur
• Temperatur bei offenem Fenster
• Komfortzone und Eco-Bereich
• Wochenprogramm

Zum Einen lässt sich eine minimale Temperatur mit der Max!-Software nicht setzen, zum Anderen kommt mir hier immer wieder der Duty-Cycle in die Quere. In FHEM werden einzelne Befehle in die unscheinbare Befehlszeile ganz oben im Web-Interface eingegeben oder in einer Shell via „perl fhem.pl 7072 <Befehl>“ ausgeführt. Die Befehle sind dann zum Beispiel:

set heizung_bad comfortTemperature 20
set heizung_bad ecoTemperature 17.5
set heizung_bad maximumTemperature 30
set heizung_bad minimumTemperature 5
set heizung_bad weekProfile Mon 5,0:05,5,22:30,5 Tue 5,0:05,5,22:30,5 Wed 5,0:05,5,22:30,5 Thu 5,0:05,5,22:30,5 Fri 5,0:05,5,23:30,5 Sat 5,0:05,5,23:30,5 Sun 5,0:05,5,22:30,5

Abgesehen vom Wochenprogramm (weekProfile) ist das ja ganz einfach zu verstehen. Aber auch dieses ist gar nicht so kompliziert: Die Wochentage werden auf Englisch angegeben, danach folgt die initiale Temperatur, wiederum gefolgt von beliebig vielen Uhrzeit-Temperatur-Schaltanweisungen. Im oben stehenden Beispiel wird also der Montag mit 5° gestartet. Danach wird jeweils um 0:05 Uhr und um 22:30 Uhr auf 5° gestellt. Der Schaltzyklus um 0:05 Uhr ist empfohlen, weil die Initialtemperatur nicht immer für voll genommen wird. Der Zyklus um 22:30 Uhr dient als ein weiteres Beispiel.

Alles neu, ganz von alleine, per Skript

Um mir das Leben zu vereinfachen, habe ich mir ein kleines Skript dazu geschrieben. Für jedes einzelne meiner 10 Thermostate habe ich all die oben angegebenen Befehle untereinander in eine Datei geschrieben – eben so wie sie oben stehen. Das Skript kann hier heruntergeladen werden: set_heizung,sh.gz. Als Parameter erwartet es die Datei mit den Befehlen – ohne Leerzeilen, ohne Kommentare. Ich war zu faul, diese auszusortieren.

Das Skript arbeitet nun jeden einzelnen Befehl ab. Dabei wird jedoch vorher geprüft, ob der Duty Cycle zu höchstens $DUTY_MAX (im Skript: 80%) gefüllt ist. Die Ausführung des Skripts dauert zwar drei bis vier Stunden für meine 10 Thermostate, passiert jedoch gänzlich ohne mein Zutun. Die Ausgabe zeigt auch an, ob jeder einzelne Befehl erfolgreich geschrieben werden konnte.

Weiterführende Informationen

[1] Max!-Software unter Linux einrichten
[2] Duty Cycle in den FAQs von eQ-3
[3] http://www.fhemwiki.de/wiki/MAX!_Temperatur-Scanner