Heizungsregelung mit Schedy

Meine Heizkörper (via Fernwärme) werden seit einigen Jahren von Homematic Thermostaten vom Typ HM-CC-TC geregelt, die mit dem Stellantrieb HM-CC-VD zusammenarbeiten. Dabei handelt es sich um das erste Modell, welches für Homematic verfügbar war, leider mit einigen Kinderkrankheiten und Einschränkungen behaftet:

  • Es lässt sich nur ein Zeitprofil je Thermostat hinterlegen
  • Von der Zentrale aus lässt sich nur die Temperatur anpassen – weder der Betriebsmodus noch das Zeitprofil kann man in CCU Skripten oder auch via Home Assistant anpassen (Ausnahme: CCU Gerätekonfiguration sowie FHEM)
  • Das Einstellrädchen für die Temperatur funktioniert wenig bis gar nicht
  • Beim Wechsel von einem kleinen Öffnungsgrad zur vollständigen Schließung hat der Stellantrieb zu wenig „Wumms“, um den Stift wirklich reinzudrücken, und der Heizkörper bleibt trotz 0° Öffnung noch aktiv – bei 80°C Vorlauftemperatur (Fernwärme) reicht das, um über Nacht das Zimmer in eine gemütliche Sauna zu verwandeln…

An den Fenstern habe ich jeweils Drehgriffkontakte HM-SEC-RHS verbaut, die bislang direkt mit den Thermostaten verknüpft waren und somit autark die Temperatur bei geöffnetem Fenster abgesenkt haben. Auch die sind nicht fehlerfrei: Die Konstruktion des Batteriefachs und die Versorgung über zwei Knopfzellen sorgt regelmäßig für Wackelkontakte (Tipp: durch doppelt hohe Knopfzelle CR1/3N ersetzen!), auch die Antennenposition scheint suboptimal.

FHEM war – im Gegensatz zur Homematic CCU – in der Lage, jederzeit den Betriebsmodus und sogar das Zeitprofil des Thermostats zu ändern, so dass ich via FHEM Skript einfach unterschiedliche Zeitprofile bei An- und Abwesenheit in die Thermostate geladen habe. Die eigentliche Temperaturregelung haben die Thermostate dann autark durchgeführt.

Klingt soweit gut – hat aber leider nie verlässlich funktioniert. Beim Übertragen der Zeitprofile kam es immer wieder zu Fehlern, die FHEM zwar festgestellt, aber nicht automatisch korrigiert hat, so dass ich immer mal wieder mollig geheizte Zimmer bei Abwesenheit oder auch ein kühles Bad am Morgen hatte. Nicht schön.

Beim Wechsel von FHEM auf Home Assistant stellte sich dann schnell Ernüchterung ein: Über Home Assistant ist hier nicht mehr möglich als über die CCU selbst, das bedeutet: Einstellen der aktuellen Temperatur, das war’s. Nach einigen Versuchen, mithilfe der Home Assistant Automatisierungen selbständig eine Heizungsregelung zu implementieren, bin ich dann per Zufall auf Schedy gestoßen: Einer App für den AppDaemon (lässt sich als Hass.io Add-On installieren), die beliebige Thermostate und Fensterkontakte integriert und flexibel nach Zeitprofilen ansteuert.

In Verbindung mit den HM-CC-TC gab es noch keine Klippe zu umschiffen: Deren Home Assistant-Implementierung ist fehlerhaft und signalisiert die Unterstützung sog. HVAC-Modes „off“ und „heat“. In der Realität kann das Thermostat damit aber nicht umgehen – es kann nichts außer auf die vorgegebene Temperatur zwischen 6°C und 30°C heizen – und jeder Versuch, die Heizung darüber ein- oder auszuschalten, führt zu Fehlern, die Schedy dann natürlich zu Fall bringen. Glücklicherweise gibt es aber einen Workaround: Über eine Konfigurationsoption kann man Schedy dazu anweisen, die HVAC-Modes nicht zu nutzen, und schon funktioniert alles wie gewünscht. Der Beginn der Schedy Konfigurationsdatei (schedy_heating.yaml) sieht daher wie folgt aus:

schedy_heating:
  module: hass_apps_loader
  class: SchedyApp

  actor_type: thermostat
  actor_templates:
    default:
      off_temp: 6
      supports_hvac_modes: false

Als nächstes musste ich mir überlegen, welche Heizprofile es geben sollte, Schedy ist da völlig flexibel konfigurierbar. Ich habe mich zunächst auf die folgenden vier festgelegt:

  • anwesend/zeitgesteuert: Je nach Raum und Zeit wird auf eine angenehme Temperatur geheizt
  • abwesend/zeitgesteuert: Tagsüber wird ein wenig mehr geheizt als nachts, aber dies dient nur dem Schutz gegen Schimmel und gegen Auskühlen
  • durchgehend aktiv: Je nach Raum wird auf eine angenehme Temperatur geheizt, unabhängig von der Uhrzeit (Partymodus)
  • aus: Es wird nicht geheizt bzw. die minimal mögliche Temperatur eingestellt, in diesem Fall 6°C.

Zur Auswahl dient eine input_select Integration in der configuration.yaml:

 input_select:
  heating_mode:
    name: Heizungsmodus
    options:
    - anwesend/zeitgesteuert
    - abwesend/zeitgesteuert
    - durchgehend aktiv
    - aus
    icon: mdi:home-thermometer-outline 

Ob man den Heizungsmodus nun über das Lovelace-Webinterface, eine automatische Anwesenheitserkennung oder über einen Taster umschaltet, bleibt natürlich jedem selbst überlassen. In meinem Falle habe ich mich für die ersten zwei genannten Varianten entschieden.

Der Heizungsmodus wird nun über die Funktion heating_mode() in der schedy_heating.yaml übergeben:

  expression_environment: |
    def heating_mode():
        return state("input_select.heating_mode")

Anschließend folgt die Definition der Zeitprofile, die später den Heizungsmodi und den Räumen zugeteilt werden:

  schedule_snippets:

    ss_aus: 
    - value: 6

    ss_durchgehend_wohnen:
    - value: 22

    ss_durchgehend_sonstige:
    - value: 18.5

    ss_abwesend:
    - value: 18.5
      start: "10:00"
      end: "20:00"
  
    ss_wohnen:
    - value: 22
      rules:
      - weekdays: 1-4,7
        start: "10:00"
        end: "21:30"
      - weekdays: 5,6
        start: "10:00"
        end: "22:00"

    ss_bad:
    - value: 22
      rules:
      - weekdays: 1-5
        start: "5:45"
        end: "10:00"
      - weekdays: 6
        start: "8:00"
        end: "10:00"
      - weekdays: 7
        start: "8:00"
        end: "10:00"
    - value: 18.5
      rules:
      - weekdays: 1-5
        start: "10:00"
        end: "21:30"
      - weekdays: 6
        start: "10:00"
        end: "22:00"
      - weekdays: 7
        start: "10:00"
        end: "21:30"

    ss_sonstige:
    - value: 18.5
      start: "10:00"
      end: "20:00"

Schließlich wird definiert, bei Änderungen welcher Entity Schedy den Zeitplan neu evaluieren soll. In unserem Fall ist das besagte input_select Integration:

  watched_entities:
  - input_select.heating_mode

Nun kommen Regeln, die dem Zeitplan jedes Raumes vorangestellt und angehangen werden sollen. Über diese Regeln wird genauso die Temperaturabsenkung bei offenem Fenster realisiert wie die Aktivierung von Heizungsmodi, die für alle Räume gleich gelten. Für die Details sei hier auf die wirklich sehr gute und ausführliche Schedy-Dokumentation verwiesen.

Neben den besagten Drehgriffkontakten HM-SEC-RHS (liefern open/tilted/closed als State) kommt an meiner Wohnungstür auch ein HM-SEC-SCo (liefert on/off) zum Einsatz. Die Temperaturabsenkung im schedule_prepend Block wurde so gestaltet, dass sie mit beiden Varianten umgehen kann.

  schedule_prepend:
  - x: "Mark(OFF, Mark.OVERLAY) if not (is_empty(filter_entities('sensor', state='open', window_room=room_name))) else Next()"
  - x: "Mark(OFF, Mark.OVERLAY) if not (is_empty(filter_entities('sensor', state='tilted', window_room=room_name))) else Next()"
  - x: "Mark(OFF, Mark.OVERLAY) if not (is_empty(filter_entities('binary_sensor', state='on', window_room=room_name))) else Next()"
  - x: "IncludeSchedule(schedule_snippets['ss_abwesend']) if heating_mode() == 'abwesend/zeitgesteuert' else Next()"
  - x: "IncludeSchedule(schedule_snippets['ss_aus']) if heating_mode() == 'aus' else Next()"

  schedule_append:
  - value: "17"

Schließlich bleibt noch die Zuordnung der Räume zu den Fenstergriffsensoren und den Zeitprofilen:

  rooms:
    sz:
      actors:
        climate.sz_ht_heizung:
      watched_entities:
      - sensor.sz_fg_fenster_state
      schedule:
      - x: "IncludeSchedule(schedule_snippets['ss_sonstige']) if heating_mode() == 'anwesend/zeitgesteuert' else Next()"
      - x: "IncludeSchedule(schedule_snippets['ss_durchgehend_sonstige']) if heating_mode() == 'durchgehend aktiv' else Next()"
    az:
      actors:
        climate.az_ht_heizung:
      watched_entities:
      - sensor.az_fg_fenster_state
      schedule:
      - x: "IncludeSchedule(schedule_snippets['ss_wohnen']) if heating_mode() == 'anwesend/zeitgesteuert' else Next()"
      - x: "IncludeSchedule(schedule_snippets['ss_durchgehend_wohnen']) if heating_mode() == 'durchgehend aktiv' else Next()"
    bz:
      actors:
        climate.bz_ht_heizung:
      watched_entities:
      - sensor.bz_fg_fenster_state
      schedule:
      - x: "IncludeSchedule(schedule_snippets['ss_bad']) if heating_mode() == 'anwesend/zeitgesteuert' else Next()"
      - x: "IncludeSchedule(schedule_snippets['ss_durchgehend_sonstige']) if heating_mode() == 'durchgehend aktiv' else Next()"
    ku:
      actors:
        climate.ku_ht_heizung:
      watched_entities:
      - sensor.ku_fg_fenster_state
      schedule:
      - x: "IncludeSchedule(schedule_snippets['ss_sonstige']) if heating_mode() == 'anwesend/zeitgesteuert' else Next()"
      - x: "IncludeSchedule(schedule_snippets['ss_durchgehend_sonstige']) if heating_mode() == 'durchgehend aktiv' else Next()"
    wz:
      actors:
        climate.wz_ht_heizung:
      watched_entities:
      - sensor.wz_fg_fenster_state
      - sensor.wz_fg_tuer_state
      schedule:
      - x: "IncludeSchedule(schedule_snippets['ss_wohnen']) if heating_mode() == 'anwesend/zeitgesteuert' else Next()"
      - x: "IncludeSchedule(schedule_snippets['ss_durchgehend_wohnen']) if heating_mode() == 'durchgehend aktiv' else Next()"
    wf:
      actors:
        climate.wf_ht_heizung:
      watched_entities:
      - binary_sensor.wf_tk_wohnungstuer_state
      schedule:
      - x: "IncludeSchedule(schedule_snippets['ss_sonstige']) if heating_mode() == 'anwesend/zeitgesteuert' else Next()"
      - x: "IncludeSchedule(schedule_snippets['ss_durchgehend_sonstige']) if heating_mode() == 'durchgehend aktiv' else Next()"

Schließlich ist es noch notwendig, in der customize.yaml die Tür-/Fensterkontakte den einzelnen Räumen zuzuordnen:

sensor.sz_fg_fenster_state:
  friendly_name: Sz Fenster
  window_room: sz
sensor.az_fg_fenster_state:
  friendly_name: Az Fenster
  window_room: az
sensor.bz_fg_fenster_state:
  friendly_name: Bz Fenster
  window_room: bz
sensor.ku_fg_fenster_state:
  friendly_name: Kü Fenster
  window_room: ku
sensor.wz_fg_tuer_state:
  friendly_name: Wz Tür
  window_room: wz
sensor.wz_fg_fenster_state:
  friendly_name: Wz Fenster
  window_room: wz
binary_sensor.wf_tk_wohnungstuer_state:
  friendly_name: Wf Tür
  icon: mdi:door
  window_room: wf

Damit ist die Implementierung vollständig.

Natürlich empfiehlt es sich nicht, direkt mit der vollständigen Konfiguration zu beginnen – lieber erst mit einem Raum, einem Zeitprofil und ohne Fensterkontakte starten und dann die Funktionalität schrittweise erweitern. Ein paar Tage Zeit sollte man dafür schon einplanen, trivial ist das ganze nicht unbedingt – aber es macht Spaß! 😉

Nach Änderungen an der schedy_heating.yaml werden die Änderungen automatisch neu eingelesen. Fehlermeldungen tauchen im Log des AppDaemon (unter Hass.io -> AppDaemon ganz nach unten scrollen und ggf. nochmal REFRESH drücken) auf und sind in der Regel relativ aussagekräftig. Ansonsten findet man im Support-Thread in der Home Assistant Community meist schnell Hilfe.

Ergänzung vom 2020-02-02: Die HM-CC-TC müssen im Modus „Manu“ laufen, nicht im Modus „Cent“ oder „Auto“:

  • Im Modus „Cent“ werden manuelle Änderungen am Thermostat binnen Minuten wieder überschrieben. Die Zentrale gewinnt hier immer.
  • Im Modus „Auto“ steuert der lokale Zeitplan im Thermostat. Den wollen wir aber ja gerade mit Schedy ablösen.
  • Im Modus „Manu“ funktioniert alles wie gewünscht: Manuelle Änderungen am Thermostat sind möglich, werden aber zu den Umschaltpunkten durch Schedy wieder überschrieben.

13 Gedanken zu „Heizungsregelung mit Schedy

  1. Hallo Jens,

    ich verwende auch die etwas älteren Homematic HM-CC-RT-DN (x22) die ich mir selbst ’nur‘ als Bausatz gegönnt habe um weiter einzusparen. Ich möchte damit die Heizung von unserem Altbau-Familienhaus (3 Stockwerke, 3 Wohnungen) auf 1.200m Höhe smart realsieren, da die Heizkosten letztes Jahr untragbar geworden sind.

    Ich kam erst ziemlich spät zur Ernüchterung, dass diese TRV jeweils nur ein Profil speichern können, und um andere Lösungen zu implementieren, wie bspw. das BetterThermostat, jeweils ein Wandthermostat (90€) pro Raum fällig wären.

    Ich habe bis jetzt eigentlich alles selbst erledigen können (proxmox, pfsense, raspberrymatic, homeassistant) aber bei AppDaemon – selbst mit Doku – hängt ich mich am Aufbau etwas auf, mE fehlen da schlicht Schritte bei der config, und würde mich wahnsinnig für deine Hilfestellung bedanken.

    Ich verwende HAOS und habe AppDaemon (4.x) über HACS installiert, python_packages: [„hass-apps“] integriert.

    Die Ordnerstruktur von HAOS
    -addon_configs
    –a0d7b954_appdaemon
    —apps
    —-schedy_heating.yaml
    —compiled
    —dashboards
    —namespaces
    —www
    —appdaemon.yaml
    -addons
    -backup
    -config
    -media
    -share
    -ssl

    Ich versuche deine Konfiguration für 1 Zimmer nachzubauen, und dann schrittweise weiter. Ich versuche deine Anleitung nun zum 3. mal, komme aber leider auf keinen grünen Zweig.

    Wie beim Vorposter Fabian, beziehen sich meine Fragen großteils auf den Strukturaufbau

    – input_select Integration in der configuration.yaml
    welche configuration.yaml? Die von HAOS ersucht, ergibt aber einen Fehler

    – customize.yaml
    wo soll die hin?

    Ich habe die Konfiguration soweit fertig, dass ich hass-apps als python-pkg geladen habe.

    Was hat es mit der hass_apps_loader.py auf sich? Wie bzw. muss ich diese ausführen?

    Wenn du mir bitte Hilfestellung leisten könntest, oder dein Tutorial mit einem einzelnen Raum Schritt für Schritt ausbaust, oder mir entgeltlich privat helfen könntest, ich wäre dir unendlich dankbar.

    Es wird wieder verdammt kalt und die einzige Lösung welche ich gerade realisiert bekomme, ist die Heizkörper manuel auf die gewünschte Temperatur zu stellen und die Wärmepumpe nur zu bestimmten Zeiten laufen zu lassen. Nicht besonders smart oder flexibel.

    Ich wäre dir echt überaus dankbar. Und ich denke so einige Homematic User, denn das scheint tatsächlich bis heute die beste, wenn auch am wenigsten dokumentierte Lösung zu sein.

    Mit besten Grüßen,
    Max

  2. Sehr schön und übersichtlich beschrieben. Im Forum und auf Github wird es ganz schön nerdig, wenn man was sucht.
    Ich werde mal mein schedy nach deinem Muster mit den Snippets umbauen.
    Hoffentlich wird es noch eine Weile unterstützt oder abgelöst durch eine Weiterentwicklung. Nicht das wir plötzlich ohne Heizung da stehen. Die Ersparnis mit diesem System ist spürbar.

  3. ich habe mich jetzt über die offizielle Schedy-Webseite versucht, zu dem Thema schlau zu lesen, hänge aber schon am wesentlichen. Ich habe noch immer nicht verstanden, wie dieses System überhaupt aufgebaut ist.

    App-Deamon läuft bei mir als Docker-Container. Genauso auch HomeAssistant und Zigbee2MQTT (habe Heizkörper-Thermostate über Zigbee).

    wie starte ich jetzt genau Schedy? Ist es einfach nur die eine schedy_heating.yaml im Apps verzeichnis und dann läuft das? Alles wird in diese eine YAML-Datei geschrieben?

    Hast du eventuell von deinem Aufbau (der von den Anforderungen exakt meiner Vorstellung entspricht) vielleicht die Dateien einmal als Download (oder per Email) inkl. der Lovelace-Webinterface Anbindung damit ich mich daran langhangeln kann? Infos zu Schedy sind im Netz leider sehr dürftig, wie ich finde.

    • Wenn du Schedy nach https://hass-apps.readthedocs.io/en/stable/getting-started.html konfiguriert hast, ist es wirklich nur die schedy_heating.yaml, die du editieren musst. Die wird nach jeder Änderung automatisch neu geladen und ausgewertet. Meinen aktuellen Stand habe ich dir hier abgelegt: https://pastebin.com/7DHu4ehQ Ich denke aber nicht, dass dir das groß helfen wird. Meine Lovelace Konfiguration ist zu komplex, als dass ich die mal eben irgendwo ablegen könnte, sorry.

      • um einen funktionierenden Aufbau zu sehen und nachvollziehen zu können kann es vielleicht schonmal helfen.
        Klar, ich muss alles an meine Bedürfnisse anpassen, aber so hab ich schonmal einen Ansatz auf dem ich aufbauen kann.

        ich bin tatsächlich nach der verlinkten Anleitung vorgegangen. Es ist ja auch nahezu die einzigen Dokumentation zu dem Thema, die man so findet. So ganz verbreitet scheint das Thema nicht zu sein…

        Mein erster Gedanke war, die Heizungssteuerung über NodeRed zu steuern, aber auch hier gibt es sehr sehr wenige Beispiele im Netz an denen man sich langhangeln kann. Lichtsteuerung über Bewegungsmelder war dagegen ein Kinderspiel.

        Vielen Dank!

  4. Vielen Dank für den super Beitrag.

    Ich bekomme jedoch immer folgende Fehlermeldung, und ich habe keine Ahnung was ich falsch mache:

    WARNING AppDaemon: No app description found for: /config/appdaemon/apps/hass_apps_loader.py – ignoring

    Hast du noch einen Tip für mich was ich falsch mache? Eine schedy_heating.yaml Datei habe ich noch gar nicht erstellt, weil schon vorher die Fehlermeldung erscheint.

    • Tut mir leid, ich habe keine Ahnung :-/. Ich kann dir nur empfehlen, die Installationsanleitung nochmal Schritt für Schritt nachzuvollziehen.

    • Hm, also das kann ich so nicht bestätigen. Mit FHEM hat die Übertragung der Temperaturprofile bei mir nie verlässlich funktioniert. Mit Schedy läuft es jetzt seit anderthalb Jahren völlig problemlos, inkl. Anwesenheitserkennung, Fenster-auf-Erkennung, Berücksichtigung von Feier- und Urlaubstagen, Arbeiten von Zuhause etc. Ich bin super zufrieden damit.

  5. Vielen Dank für den tollen Beitrag, dieser hat mir den Einstieg in die Thermostatsteuerung doch sehr erleichtert. Insbesondere die Infos zur Nicht-Nutzung der HVAC-Modes hätte ich sonst wahrscheinlich erst nach Tagen gefunden 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert