MAX!-Thermostate in FHEM einbinden

Ich hatte vor mittlerweile 7 Jahren schon einmal einen Beitrag dazu geschrieben, doch dieser ist nun schon etwas in die Jahre gekommen. Außerdem habe ich in diesem Artikel sehr viel auf der Kommandozeile gemacht. Hier beschreibe ich, wie man MAX!-Thermostate in FHEM einbinden kann, ohne die Kommandozeile zu bemühen. Außerdem gehe ich auf ein paar Fallstricke ein, die ich immer wieder mitgenommen habe 🙃.

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

Vorbereitung

Um überhaupt MAX!-Thermostate in FHEM einbinden zu können, ist ein sogenannter CUL oder ein MAX! Cube notwendig. Diese beiden Geräte übersetzen Befehle in das Protokoll der Thermostate und kommunizieren mit diesen. Der Max!Cube ist dabei ein ans LAN angeschlossener Würfel, der früher im Basispaket der Thermostate enthalten war. Ich habe für mich selbst realisiert, dass mich dieser Cube mehr nervt als das er mir hilft. Viele Dinge funktionierten darin nicht zuverlässig und ich musste immer wieder auf die alte MAX!-Software zugreifen. Der CUL-Stick ermöglicht es mir, nun alles per FHEM zu erledigen. Insbesondere seit die Produktion und der Support für MAX!-Komponenten eingestellt sind, ist das auch der sinnvollere Weg.

Anmerkung: Hier sind einige Hinweise zum Flashen des CULs zu finden. Dort steht auch, wie ein MAX! Cube mit CUL-Firmware versehen werden kann.

Ein USB-CUL wird von FHEM sofort gefunden und ist auch gleich als Gerät im Web-Interface vorhanden. Bei mir heißt es schlicht „CUL_0“. Dem Gerät muss nun noch beigebogen werden, dass es mit MAX!-Geräten sprechen muss. Unten auf der Geräte-Seite im Web-Interface können Attribute für das Gerät hinterlegt werden. Hier muss der „rfmode“ auf „MAX“ gesetzt werden. Ein Klick auf „attr“ überträgt das Ganze. Alternativ kann auch einfach in der weißen Befehlszeile ganz oben im Web-Interface attr CUL_0 rfmode MAX  eingetragen und mit Enter bestätigt werden.

Der CUL an sich ist „nur“ die Hardware. Die eigentliche Kommunikation übernimmt ein Gerät der Art „CUL_MAX“. Dieses muss nun noch angelegt werden. Das geht am schnellsten, indem in die weiße Zeile ganz oben define CULMAX0 CUL_MAX 123456  eingetragen wird. Damit ist nun ein Gerät names „CULMAX0“ vorhanden, dem analog zum CUL das Attribut attr CULMAX0 IODev CUL_0  gegeben wird. Damit weiß dieses Gerät nun, über welche Hardware es kommunizieren muss.

MAX!-Thermostate in FHEM einbinden

Um nun endgültig MAX!-Thermostate in FHEM einbinden zu können, müssen diese zunächst auf deren Werkseinstellungen zurückgesetzt werden. Das empfehle ich ganz dringend, weil sonst gern mal sehr merkwürdige Dinge passieren. Damit das Zurücksetzen funktioniert, muss das Thermostat an der Heizung montiert sein. Der Vorgang an sich ist sehr einfach:

1. Batterien entnehmen
2. alle Tasten auf dem Thermostat gleichzeitig drücken und gedrückt halten, während die Batterien wieder eingesetzt werden
3. wenn auf dem Thermostat „rES“ angezeigt wird noch einmal bis 5 zählen (nur bei einigen Firmware-Versionen nötig)
4. Tasten loslassen

Jetzt startet das Thermostat neu und konfiguriert sich. Während der kleine Motor im Thermostat hörbar rotiert, wird zunächst „InS“ angezeigt. Nach einer Weile ist der Motor ruhig. Dann muss ein bis zwei Mal der „Boost“-Button gedrückt werden. Danach erscheint für eine ganze Weile „AdA“ im Display und der Motor begleitet das ganze mit einem einschläfernd monotonen Summen. Wenn alles geklappt hat, ist danach die Temperatur zu sehen.

Nun folgt die eigentliche Verbindung mit FHEM. Im Gerät „CULMAX0“ kann der Befehl set CULMAX0 pairmode 60  aufgerufen werden. Der versetzt FHEM nun für 60 Sekunden in einen Modus, in dem es genau ein neues Thermostat aufnehmen kann. Auf dem Thermostat muss dafür nun die Taste „Boost“ für 5 Sekunden gedrückt gehalten werden. Danach fängt das Gerät an, von 30 nach unten zu zählen. Nach wenigen Sekunden sollte der Countdown verschwinden und ein „AC“ im Display die erfolgreiche Verbindung bestätigen. Nun sollte es im FHEM-Raum „Max“ ein neues Gerät geben.

Es ging nicht

Das kommt leider gar nicht so selten vor 🥴. Typische Dinge, die schief gegangen sein könnten:

• Häufigstes Problem: Es sind nicht genügend Credits vorhanden.
• Die 60 Sekunden Zeit, die uns FHEM gegeben hat, haben nicht ausgereicht. Man kann hier auch 300 Sekunden (5 Minuten) oder gar 600 Sekunden (10 Minuten) auswählen und sich dann vor dem Drücken des „Boost“-Buttons noch einen Café kochen.
• Die Entfernung zum Gerät ist zu groß. Ich habe mir hier früher mit einem geflashten MAX! Cube geholfen, den ich per LAN näher am Gerät platzieren konnte.
• Der CUL hängt. Er kann mit set CUL_0 reopen  neu initialisiert werden.

Im Zweifel sollte der Reset-Prozess noch einmal wiederholt werden.

Grundeinstellungen

Die Thermostate können nun mit diversen Einstellungen versehen werden. Neuerdings kann man set MeinThermostat saveConfig <Name>  Einstellungen speichern. Ich hatte die brillante Idee, dies für ein Thermostat zu machen und die gespeicherte Konfiguration dann auf alle anderen Thermostate mittels set MeinAnderesThermostat restoreDevice <Name>  zu übertragen. Es erscheint zwar kein Fehler, aber das Chaos im Netz war danach perfekt. Lasst also die Finger davon! Das ist vermutlich nur sinnvoll, um die Einstellungen eines Thermostats zu sichern.

Jede Übertragung zum Thermostat kostet Credits. Das sollte beachtet werden. Viele Einstellungen kosten also viel Zeit. Vor allem das Übertragen des Wochenprofils benötigt sehr viel Zeit.

Wert, die ich auf meinen Thermostaten eingestellt habe, sind:

• ecoTemperature und comfortTemperature
• minimumTemperature und maximumTemperature
• windowOpenDuration und windowOpenTemperature

Außerdem setze ich noch zwei Attribute, die nur veränderte Werte (on-change) höchstens alle 12 Minuten (720 Sekunden) ein Event auslösen lassen. Damit wird auch definiert, dass Events nur von den aufgezählten Readings ausgelöst werden:

Wochenprofil

Man neigt dazu, dies mit einem „brauch ich nicht“ abzutun. Aber nein, man braucht es. Meine Thermostate haben verschiedene Schaltzeiten nach einem Reset und weil ich nicht will, dass es per lustigem Zufallsprinzip mal hier und mal da warm wird, muss ich die Profile nach jedem Reset gleichziehen. Früher war das noch einigermaßen komplex. Heute gibt es dafür ein einfach zu bedienendes Modul, das via defmod Heizungsplan weekprofile  aktiviert werden kann. Wichtig: „einfach“ ist nicht dasselbe wie „hübsch“ 😅. Aber es erfüllt seinen Zweck:

• Ein Klick auf die Zahnräder erlaubt es, die Schaltzeiten und die Temperaturen einzustellen. Konfigurationen eines Tages können auf alle anderen übertragen werden.
• Das ‚+‘-Zeichen fügt ein weiteres Profil hinzu, ‚-‚ löscht eines.
• Der Pfeil ‚–>‘ überträgt das Profil an ein oder mehrere gewählte(s) Profil(e).

Achtung: Das Übertragen kostet eine Sendeeinheit je Tag, siehe Credits.

Zusammenfassung

Im Raum „MAX“ sollte nun das Thermostat zu sehen sein. Mit dem Drop-Down-Menü kann ich eine Temperatur wählen, die FHEM direkt zum Thermostat überträgt. Je Thermostat gibt es ein FileLog. Im Laufe der Zeit kann dieses durchaus etwas größer werden.

Im Screenshot sind zwei typische Dinge zu sehen, die mich ein wenig ärgern:

• Das Thermostat ‚MAX_28de72‘ war irgendwo noch als ‚associate‘ gespeichert und taucht nun immer wieder als Zombie auf.
• Die Thermostate in meiner Sitzecke scheinen wohl den Zombie zu suchen: Der (rf error) meint, dass diese wie wild senden.