Energie zu sparen ist das Gebot der Zeit. Persönlich finde ich, dass das Gehabe von Russlands Führung – wie ein Brennglas – dieses sowieso drastische Problem ‚lediglich‘ verschlimmer hat – Lediglich, weil die Rohstoffe wie Erdgas ja sowieso zu Ende gehen werden. Spätestens jetzt ist es an der Zeit, Alternativen und erneuerbare Energiequellen zu nutzen. Wenn man in einer Mietwohnung oder einer Eigentümergemeinschaft oder – so wie ich 🙃 – in beiden wohnt, dann hat man dazu leider nicht die Chance. Getrieben durch die derzeitigen Preisexplosionen bleibt uns Mietern und Mieterinnen also dann nur der Weg, sparsam mit dem sprichwörtlich teuren Gut Energie umzugehen. Wie können wir also Energiekosten durch smarte Thermostate sparen? Auch wenn ich speziell über mein Setup schreibe, so sind einige der folgenden Tipps doch auch allgemein gültig. Denke ich zumindest.
Ich habe hier und da ja schon Blogbeiträge darüber geschrieben, wie ich alte MAX! Heizkörperthermostate mittels FHEM „smart“ gemacht habe. Eine Kategorie im Know-How-Bereich meiner Website beschäftigt sich auch damit. Seit meinen letzte Blogs ist aber nun einiges an Zeit vergangen und ein Update tut mal wieder Not. Ich bin seitdem in eine neue, kleinere Wohnung gezogen und habe lange Zeit gar keine Lust gehabt, die Thermostate wieder einzusetzen. Nun habe ich es aber doch wieder gemacht.
Es ist eine interessante Frage, ob man überhaupt Energiekosten durch smarte Thermostate sparen kann. Die Frage beginnt schon an dem Punkt, was eigentlich so ’smart‘ an einem Thermostat ist. Die normalen Heizkörperthermostate werden ja auf Zahlen gestellt und man erliegt schnell der Idee, dass bei einer Einstellung auf 3 ein Ventil immer halb offen ist. Dann hätte man die Dinger aber nicht ‚Thermostate‘ nennen müssen 😉. Eigentlich ist so ein Standardthermostat schon an sich eine sehr smarte Angelegenheit. In diesem Video wird das super dargestellt:
Prinzipiell ist ein ganz normales Thermostat also schon smart genug, wenn man selbst nur schlau genug ist, es richtig einzustellen. Dennoch gibt es ein paar Szenarien, in denen ein digitales Thermostat noch etwas mehr ‚Smartness‘ hinzufügen kann:
Die drei ersten Punkte sind durchaus ein Grund, über ein heute als ’smartes Thermostat‘ beworbenes digitales Thermostat nachzudenken. Allerdings sollte man sich einer Sache bewusst sein: Nur weil das Thermostat jetzt eine Temperatur anstelle einer Zahl zwischen 1 und 5 anzeigt, spart es noch lange keine Energiekosten! Bei falscher Bedienung oder wenn Batterien leer werden kann auch gut mal das Gegenteil der Fall sein.
Wie bei allem modernen technischen Schnick-Schnack kann man sich auch hier rasend schnell in unnötigen Details verlieren. Das habe ich auch oft genug getan – auch trotz besten Vorsätzen eben hier wieder. Darum empfehle ich sehr, das Ziel fest im Auge zu behalten. Dafür muss das Ziel natürlich definiert sein. Und es sollte einfach genug sein. Mein Ziel ist folgendes:
Sinnvoll ist auch, die einzelnen Schritte irgendwo zu dokumentieren. Damit wird es später deutlich einfacher, eventuelle Fehler zu erkennen.
So ein smartes Thermostat heißt ja ’smart‘, weil es Dinge selbstständig tut. Es ist also sehr wichtig gleich zu Beginn sicherzustellen, dass das Ding kein Eigenleben aufgrund alter Einstellungen entwickelt. Vor allem bei meinen alten Thermostaten ist das ein Risiko. Darum habe ich alle Thermostate zunächst auf die Werkseinstellungen zurückgesetzt. Bei meinen MAX!-Thermostaten geht das wie folgt:
Jetzt sollte zumindest kurz ‚rES‘ für Reset im Display zu sehen gewesen sein. In der Folge zeigt der kleine Motor im Thermostat einmal was er kann, indem er wie wild auf und ab fährt. Dabei wird ‚InS‘ für Initialisierung angezeigt. Irgendwann ist der Motor still und das Display zeigt nur noch ‚InS‘ an. Dann muss der ‚Boost‘-Button oder die Drehscheibe ein bis zwei Mal betätigt werden, bis das Display ‚AdA‘ für Adaptieren anzeigt. Dann dauert es noch eine Weile und final zeigt das Thermostat eine Temperatur an. Ab diesem Moment regelt der kleine Motor im Thermostat die Ventilöffnung so, dass die angezeigte Temperatur erreicht wird.
Lustig: Das entspricht jetzt der Funktionsweise eines normalen Thermostats. Mehr nicht.
Smarte Thermostate benötigen meist irgendeine Basisstation, mit der sie kommunizieren. Irgendwie gelangen sie dann darüber (oder eben auch direkt) ins WLAN. Es wäre ja nun albern, auf der einen Seite Energie zu sparen und auf der anderen Seite ein zusätzliches Gerät aufzubauen, was Energie verbraucht. Darum steuere ich meine Thermostate über einen Docker-Container mit der Software FHEM, welcher auf meinem sowieso aktiven QNAP NAS läuft. FHEM selbst könnte gewiss etwas weniger nerdig sein, aber es tut seinen Dienst.
Ich habe einen Know-How-Artikel darüber geschrieben, wie ich den Docker-Container eingerichtet habe. In einem anderen Artikel beschreibe ich, wie ich die Thermostate eingebunden habe. Was mir viel Kopfzerbrechen bereitet hat, war das Funknetz. Hier gibt es Regeln, wie viel gefunkt werden darf. Im MAX!-Modul von FHEM werden diese mit sogenannten ‚Credits‘ oder einem ‚Duty-Cycle‘ umgesetzt. Einfach gesprochen heißt das, dass der Funkkanal über eine gewisse Zeit ruhen muss, bis er wieder Daten übertragen darf. Die ‚Credits‘ sind sozusagen Punkte, die FHEM dafür anspart. Jeder Befehl kostet dann wieder ein paar dieser Punkte und die Anzahl darf nie kleiner als Null werden. Hier beschreibe ich, wie ich in meinem Setup damit umgegangen bin. Dieses kleine Widget half mir sehr dabei zu sehen, wie viele Befehle denn noch in der Queue stehen und wie viel Café ich noch trinken muss, bis endlich alle Befehle abgearbeitet sind.
Unabhängig vom Thermostat empfehle ich unbedingt, die Grundeinstellungen des Thermostats nach dem Einbinden zu prüfen. Vor allem das Wochenprogramm hat es in sich: Es definiert Schaltzeiten, zu denen das Thermostat aktiv wird. Diese passen selbstredend nie zu dem, was man eigentlich möchte. Um tatsächlich Energiekosten durch smarte Thermostate sparen zu können, habe ich mein Wochenprogramm ausschließlich mit Abschaltvorgängen bestückt: Abends um 22:00 Uhr und noch einmal um 0:00 Uhr stellt sich das Thermostat auf 5° C, also es geht aus. Früher hatte ich so einen Abschaltzeitpunkt noch auf Werktagen um 9:00 Uhr liegen – derzeit arbeite ich aber eh‘ immer im Home-Office.
Die drei mit ‚heizungWohnzimmer…‘ beginnenden Thermostate sind miteinander assoziiert, also miteinander verbunden. Die Verbindung besteht direkt zwischen den Thermostaten, wird aber dennoch einzig und allein über die Steuerungssoftware eingerichtet. In FHEM habe ich dazu je Thermostat einmal den ‚associate‘-Befehl mit den jeweils beiden anderen Thermostaten angewandt. Jedes Thermostat ist also mit allen anderen Thermostaten im Raum assoziiert. Wenn ich nun bei einem Thermostat die Temperatur ändere, dann ändert sich diese auch bei den beiden anderen. Dies gilt aber nur, wenn ich die Temperatur direkt am Thermostat ändere. Ändere ich sie per Schaltzeitpunkt oder über die Software, so wird diese Änderung nicht übertragen. Darum habe ich mir ein virtuelles Thermostat gebaut, in dem alle Informationen zusammenlaufen:
|
1 2 3 4 5 6 7 8 9 10 |
defmod setHeizungWohnzimmer dummy attr setHeizungWohnzimmer setList state:slider,5.0,0.5,25.0 attr setHeizungWohnzimmer webCmd state attr setHeizungWohnzimmer readingList desiredTemperature state temperature valves attr setHeizungWohnzimmer room MAX attr setHeizungWohnzimmer event-min-interval state:1200,desiredTemperature:1200,temperature:1200,valves:1200 attr setHeizungWohnzimmer event-on-change-reading state,desiredTemperature,temperature,valves attr setHeizungWohnzimmer alexaName Heizung Wohnzimmer attr setHeizungWohnzimmer genericDeviceType thermostat attr setHeizungWohnzimmer homebridgeMapping TargetTemperature=state::desiredTemperature,minValue=5,maxValue=25,minStep=0.5 |
Sieht komplex aus, ist es aber gar nicht. Zeile eins definiert ein Dummy-Device, also ein rein virtuelles Gerät. In den folgenden beiden Zeilen definiere ich einen Slider, mit dem die Temperatur eingestellt werden kann. Die vierte Zeile bestimmt, was das virtuelle Gerät alles kann: die Ziel-Temperatur (desiredTemperature), den state als Trigger für eine Aktion, die gemessene Raumtemperatur (temperature) und die Ventilstellung (valves). Will man nichts mit Alexa und Co. machen, kann man hier schon aufhören.
Jetzt muss noch definiert werden, dass eine mit dem Slider eingestellte Temperatur auf alle Thermostate übertragen wird. Dafür nutze ich einen Notify-Befehl:
|
1 2 3 4 5 6 7 8 9 |
defmod setHeizungWohnzimmerStateNotify notify setHeizungWohnzimmer:.* {\ if ( looks_like_number($EVENT) )\ {\ fhem('set setHeizungWohnzimmer desiredTemperature '.$EVENT);;\ fhem('set heizungWohnzimmerFernseher desiredTemperature '.$EVENT);;\ fhem('set heizungWohnzimmerSitzecke1 desiredTemperature '.$EVENT);;\ fhem('set heizungWohnzimmerSitzecke2 desiredTemperature '.$EVENT);;\ }\ } |
’setHeizungWohnzimmerStateNotify‘ ist der Name des Befehls und er wird ausgeführt, wann immer sich im virtuellen Thermostat ’setHeizungWohnzimmer‘ etwas ändert. Wenn diese Änderung eine Zahl ist (dann ist die Bedingung ‚looks_like_number‘ wahr), werden die drei echten Thermostate eingenordet. Die ‚desiredTemperature‘ des virtuellen Thermostats ist hier ein getrennter Wert, um über die aktuelle Einstellung immer Bescheid zu wissen. Wenn ich am Thermostat eine Veränderung vornehme, dann gleichen sich die Dinger zwar untereinander ab, sagen dem virtuellen Thermostat aber nicht Bescheid. Darum kümmert sich folgendes Notify:
|
1 2 3 |
defmod setHeizungWohnzimmerNotify notify heizungWohnzimmer.*:desiredTemperature:.* {\ fhem('set setHeizungWohnzimmer desiredTemperature '.$EVTPART1);;\ } |
Würde ich hier den State-Wert des virtuellen Thermostats ändern, dann würde dieses Notify wieder Änderungen an den anderen Thermostaten auslösen und ich hätte einen exponentiell wachsenden Loop an Befehlen generiert. Der Konjunktiv ist hier meiner Eitelkeit geschuldet: Selbstredend ist mir das passiert 😅.
Damit habe ich nun ein virtuelles Thermostat im Wohnzimmer, welches mir immer die aktuell eingestellte Temperatur eben dort anzeigt und über welches ich alle drei tatsächlichen Thermostate steuern kann.
Dieses Setup verrät mir bisher aber noch nicht viel darüber, wie offen die Ventile sind. Genau das ist aber der Wert, der über den Energieverbrauch bestimmt. Hier gibt es eine Spezialität mit den MAX!-Thermostaten: Diese verraten aktuelle eingestellte Werte nur dann, wenn ein Wert geändert wird. Es gibt ein in FHEM aktivierbares Modul namens MAX! Scanner, welches ich auch lange Zeit genutzt habe. Dieses Modul ändert zyklisch Einstellungen am Thermostat und triggert somit das Auslesen der aktuellen Werte. Der Scanner darf bei assoziierten Thermostaten aber nur mit einem der Thermostate verbunden sein. Und auch bei diesem sorgte er bei mir immer wieder für putzige Effekte, wie Temperatursprüngen nach oben oder unten. Darum habe ich das Modul deaktiviert und nach einem anderen Weg gesucht.
Das Scanner-Modul ist so umfangreich, weil es viele Fälle aus dem Wochenprogramm und der aktuell eingestellten Temperatur abzufangen versucht. Ich nutze all dies aber gar nicht. Was ich herausgefunden habe ist, dass das Setzen der einstellbaren Minimaltemperatur genügt, um die aktuellen Werte auszulesen. Dazu habe ich mir die folgende At-Routine geschrieben:
|
1 2 3 4 5 6 |
defmod triggerHeizungWohnzimmerUpdate at +*00:10:00 {\ my $minTemp = '5.0';;\ fhem('set heizungWohnzimmerFernseher minimumTemperature '.$minTemp);;\ fhem('set heizungWohnzimmerSitzecke1 minimumTemperature '.$minTemp);;\ fhem('set heizungWohnzimmerSitzecke2 minimumTemperature '.$minTemp);;\ } |
Diese setzt die Minimaltemperatur meiner Thermostate alle 10 Minuten auf 5°C. Diese Änderung genügt, um den Stand der Ventile als Rückmeldung zu erhalten. Mit einer weiteren At-Routine frage ich diesen Stand alle 5 Minuten ab:
|
1 2 3 4 |
defmod setHeizungWohnzimmerUpdate at +*00:05:00 {\ my $valves = ReadingsVal('heizungWohnzimmerFernseher','valveposition',0) + ReadingsVal('heizungWohnzimmerSitzecke1','valveposition',0) + ReadingsVal('heizungWohnzimmerSitzecke2','valveposition',0);;\ fhem('set setHeizungWohnzimmer valves '.$valves);;\ } |
Warum alle 5 Minuten? Weil auch andere Events die Rückmeldung triggern. Die Definition des ‚event-on-change-reading‘ im virtuellen Thermostat sorgt dafür, dass nur bei einer tatsächlichen Änderung von Einstellungen Werte gespeichert werden. Mit dieser Routine habe ich nun im Wert ‚valves‘ des virtuellen Thermostat immer den Öffnungsstand der drei Thermostate zwischen 0 und 300 (dreimal 100%) stehen.
Um nun einen wirklichen Überblick über meine Heizung zu erhalten, erstelle ich mir ein Diagramm wie es hier dargestellt wird. Die rote Temperaturlinie entnehme ich dafür meinem Netatmo-Thermometer. Im Screenshot oben sieht man ja, dass die via FHEM ausgelesenen Werte aus den Thermostaten eher so jenseits von gut und böse liegen können. Die Balken kurz nach 8:00 Uhr zeigen, wann die Heizungsventile geöffnet waren. Dann gibt es noch die Ausreißer der ‚Desired Temperature‘-Linie nach unten: Das sind zum Einen vermutlich Fehler der alten Thermostate, zum Anderen auch Fehlalarme der Temperatursturzerkennung.
Das oben dargestellte Diagramm scheint zu zeigen, wie ich Energiekosten durch smarte Thermostate sparen kann. Ich glaube allerdings, dass es täuscht. Letztendlich zeigt es mir nur an, wann die Ventile geöffnet waren. Bei einem herkömmlichen Thermostat kann man das einfach nicht so leicht darstellen.
Dennoch gibt es mir zumindest einen besseren Überblick über meinen Energieverbrauch. Typisch ist ja, dass man nur einmal im Jahr von den tatsächlich aufgelaufenen Kosten erfährt. Dank dieses Diagramms sehe ich nun quasi ‚live‘, wie viel Energie ich gerade verbrauche und kann es auch direkt beeinflussen.
Das Verhältnis zwischen Aufwand und Nutzen ist natürlich nicht wirklich ausgewogen. Aber ich hatte Lust darauf und damit kam es mir nicht so sehr darauf an. Vielleicht hilft es ja dem Einen oder der Anderen weiter 🙃.