Anwesenheitsbasierte Heizungssteuerung mit Fhem und Homematic HM-CC-RT-DN

Auch wenn es bisher für einen Dezember noch recht mild ist, hier ein Kochrezept für eine anwesenheitsbasierte Heizungssteuerung mit Fhem und dem Homematic Thermostat HM-CC-RT-DN. Die Lösung ist zwar nicht ganz so intelligent wie ein Google Nest schont aber den Geldbeutel.

Bei der Inbetriebnahme des HM-CC-RT-DN zeigt dieses kurz die Firmware an. Gegebenenfalls sollte nach dem Pairing ein Update der Firmware auf Version 1.4 durchgeführt werden.

Zuerst muss das Thermostat mit Fhem gepaart werden. Dazu die CUL oder besser VCCU in den Pairingmodus versetzen:

Auf dem HM-CC-RT-DN die „Boost“-Taste für 3 Sekunden gedrückt gehalten. Beim Pairing ist es wichtig einen Abstand von ca. 1,5-2 m zum CUL zu haben. Falls das Pairing erfolgreich war sollte das Display ein „ACC“ anzeigen. Wichtig ist dass danach ein PairedTo 0x123456 Reading existiert, sonst ist es nicht gepaired.

Nun sollte die korrekte Einrichtung des HM-CC-RT-DN Thermostats mit dem Tool HMInfo überprüft werden.

Für jedes Thermostat sollte das automatische Register auslesen aktiviert werden:

Falls ein Firmwareupdate auf Version 1.4 durchgeführt werden soll kann dies nun geschehen. Das Pairing geht dabei nicht verloren. Zuerst ist die neue Firmware im Fhem-Rootverzeichnis bereitzustellen:

Dann ist das HM-CC-RT-DN in den Bootloadermodus bringen. Dazu die Batterien aus dem Thermostat entnehmen und beim Wiedereinlegen der Batterien die Linke und Rechte Bedientaste am Gerät gedrückt halten, bis „FUP“ im Display erscheint. Nun kann in Fhem das update angestossen werden:

Nun können per HMInfo Temperaturprofile für verschiedene Anwesenheitsmodi gesetzt werden. Standardmäßig liegen diese im Fhem root in Form einer tempList.cfg vor und könnten folgendermaßen aussehen:

entities:Wohnzimmerheizung_Clima
R_0_tempListSat>06:00 17.0 22:00 23.0 24:00 17.0
R_1_tempListSun>06:00 17.0 22:00 23.0 24:00 17.0
R_2_tempListMon>06:00 17.0 22:00 23.0 24:00 17.0
R_3_tempListTue>06:00 17.0 22:00 23.0 24:00 17.0
R_4_tempListWed>06:00 17.0 22:00 23.0 24:00 17.0
R_5_tempListThu>06:00 17.0 22:00 23.0 24:00 17.0
R_6_tempListFri>06:00 17.0 22:00 23.0 24:00 17.0

Unter entities sind die Thermostate aufgeführt für die das Temperaturprofil gültig sein soll.
Das Profil an sich:
06:00 17.0 22:00 23.0 24:00 17.0
bedeutet jeweils:
06:00 17.0 : 00:00 bis 06:00 = 17.0
22:00 23.0 : 06:00 bis 22:00 = 23.0
24:00 17.0 : 22:00 bis 24:00 = 17.0

Da für eine anwesenheitsgesteuerte Heizung Temperaturprofile für jeden Anwesenheitszustand vorgehalten werden müssen, empfiehlt es sich die Temperaturprofile in einem separaten Ordner, bei mir „Temperaturprofile“, zu speichern. Der BasePath kann per:

gesetzt werden. Zur Anlage der entsprechenden Temperaturprofile ziehen wir uns erstmal das aktuelle Temperaturprofil von den Thermostaten:

Dieses kann dann nach Gusto kopiert und verändert werden. Dabei stellt sich sofort die Frage:

Was ist die ideale Schlafzimmertemperatur?

Es darf nicht so kalt sein, dass der Körper im Schlaf gegen Unterkühlung ankämpfen und sich dabei verkrampft. Aber es darf auch nicht zu warm sein, denn dann schwitzt man leicht und deckt sich ab, was wiederum Verkühlungen und Muskelverspannungen nach sich ziehen kann. Im Allgemeinen wird eine Schlafzimmertemperatur von 16 – 18° C empfohlen.

Was ist die ideale Wohnzimmertemperatur?

Die empfohlene Wohnzimmertemperatur liegt zwischen 21 – 23° Celsius.

Folgende Profile sollten angelegt und auf individuelle Schlaf- und Wohnzimmerbenutzung angepasst worden sein:

tempListPresent.cfg
tempListAbsent.cfg
tempListGone.cfg

Sie können nun jeweils per HMInfo gesetzt werden:

Selbstverständlich sollten diese Temperaturprofile abhängig von der Anwesenheit der Bewohner automatisch gesetzt werden. Dazu werden einfach entsprechende Watchdogs definiert:

Es kann sein dass beim restoren der Temperaturprofile der Fehler: „tempList not verified“ auftritt.
Das kann daran liegen dass das Schreiben des Temperaturprofils noch nicht von Fhem verifiziert wurde um Sicherzustellen dass die Übertragung auch fehlerfrei geklappt hat. Das restobren kann ohne Burst modus bis zu 3 Sendezyklen à 3 Minuten dauern. Wenn man dann also direkt nach dem restore ein verify macht, bekommt man eine Fehlermeldung da das Temperaturprofil ja unter Umständen noch nicht vollständig in die Register des Thermostats geschrieben wurden.

FHEM HomeMatic Konfiguration mit HMinfo überprüfen

Immer wenn neue HomeMatic Geräte angelernt wurden sollte die Konfiguration per HMinfo configCheck überprüft werden. Dazu muss zuerst eine entsprechende HMinfo Instanz definiert werden.

Das Ergebnis vom configCheck kann dann z.B. so aussehen:


configCheck done:

missing register list
CUL_HM_HM_WDS40_TH_I_1FC99C: RegL_00:

peer list incomplete. Use getConfig to read it.
incomplete: CUL_HM_HM_WDS40_TH_I_1FC99C:

PairedTo missing/unknown
CUL_HM_HM_WDS40_TH_I_1FC99C

Leider sind diese Fehlermeldungen für den Einsteiger wenig hilfreich und auch die Wikieinträge bringen es nicht auf den Punkt. Daher hier der Versuch einer einfacheren Erklärung und Lösungsvorschlägen:

missing register list

Ursache: Die Registerlisten des Gerätes liegen noch nicht in FHEM vor. Sie müssen erst vom Gerät geholt werden.
Lösung: set deviceName getConfig
und dann den Anlernbutton des Geräts kurz drücken. Die die Befehle in der Warteschlange protCmdPend sollten dann abgearbeitet werden. Die Registerlisten können auch zeitverzögert und im Hintergrund geladen und aktualisiert werden (um nicht das Funkbudget zu überlasten) indem man in den Devices (nicht im Channel!)
attr deviceName autoReadReg 5_readMissing
setzt. Wenn getConfig keine Ergebnisse liefert, dann neu pairen.

peer list incomplete

Ursache: Die Liste der Peers ist nicht vollständig.
Lösung: set deviceName getConfig

Peer not verified. Check that peer is set on both sides

Ursache: Das Peering ist nicht von Sensor nach Aktor UND von Aktor nach Sensor eingetragen.
Lösung: Peering wiederholen set sensorName peerChan 0 actorChannel single
oder die peerList manuell editieren.

trigger sent to unpeered device

Ursache: Der Kanal triggert Peers welche nicht in seiner peerList definiert sind.
Lösung: Peering wiederholen oder peerList manuell editieren.

trigger sent to undefined device

Ursache: Der Kanal triggert Peers welche noch nicht in FHEM definiert sind.
Lösung: Entsprechenden Peer in FHEM definieren

PairedTo mismatch to IODev

Ursache: Im device ist nicht die gleiche hmId hinterlegt wie im IO device
Lösung: set deviceName regSet pairCentral hmId

PairedTo missing/unknown

Ursache: Von dem Device ist nicht bekannt es bereits erfolgreich mit FHEM gepairt ist. Wahrscheinlich fehlt noch die Registerliste 0, s.o.
Lösung: set deviceName getConfig oder neu pairen.

Fhem CUL Hilferuf CUL_0, help me!

Sollten in eurem FHEM log Einträge wie:

2015.08.24 11:00:01 3: CUL_0: Unknown code A0FD086102E9BE30000000A88EF080000::-46.5:CUL_0, help me!
2015.08.24 11:02:43 3: CUL_0: Unknown code A0FD186102E9BE30000000A88EF080000::-46.5:CUL_0, help me!
2015.08.24 11:05:11 3: CUL_0: Unknown code A0FD286102E9BE30000000A88EF080000::-46.5:CUL_0, help me!
2015.08.24 11:07:24 3: CUL_0: Unknown code A0FD386102E9BE30000000A88EF080000::-46.5:CUL_0, help me!
2015.08.24 11:10:27 3: CUL_0: Unknown code A0FD486102E9BE30000000A88EF080000::-46.5:CUL_0, help me!
2015.08.24 11:13:16 3: CUL_0: Unknown code A0FD586102E9BE30000000A88ED080000::-45.5:CUL_0, help me!

auftauchen, bedeutet das soviel wie dass euer CUL eine Nachricht empfangen hat, für die es in FHEM noch keinen Empfänger gibt. In diesem Fall handelt es sich wohl um ein HM-CC-RT-DN eines Nachbars mit HmId 2E9BE3. Die Lösung besteht darin eine virtueller Controller Unit (VCCU) anzulegen, welche sich um diese Nachrichten kümmert. Eine VCCU benötigt wie alle HM Devices eine eindeutige Adresse im CUL_HM Addressbereich. Nach Möglichkeit sollte dafür die sechsstellige hexadezimale HMId eures CUL/CUNO/HMLAN verwendet werden.

Dies sollte bereits reichen um die nervigen Logeinträge zu beseitigen. Die angelegte VCCU kann aber noch viel mehr, zum Beispiel mehrere IODevices per IOList verwalten:

Neue Homematic Geräte sollten nun direkt mit den VCCUs gepairt werden:

Für sicherheitskritische Geräte kann nun ein bevorzugtes IODevice definiert werden

Damit wird CUL_0 bevorzugt genutzt, andernfalls werden die IODevices in der IOList der VCCU durchprobiert.

Für mobile Geräte wie z.B. Fernbedienungen bietet sich die dynamische Auswahl des IODevices aus der IOList des VCCU nach Empfangsstärke an: