Ich hab mir kürzlich ein Paar smarte Heizkörperthermostate zugelegt die ich nun sinnvoll steuern möchte…
Als ersten schritt habe ich via 2 Helfern (input_number) den Startmonat & den Endmonat für die Heizperiode festgelegt.
Ob sich das aktuelle Datum innerhalb der Heizperiode befindet hab ich mittels if, elif & else ausgewertet.
Ich bekomm es jetzt nur nicht hin einen weiteren Helfer (Input_boolean) mittels dieser Auswertung auf “on” / “true” oder “off” / “false” zu setzen…
Vielleicht hat hier ja jemand den passenden Zündfunken?
Mein Code: (aktuell noch in der Entwicklungsumgebung)
{% if now().month |int >= states('input_number.monat_start_heizperiode') |int %}
{% set state = states('input_boolean.heizperiode') , 'on' %} {# hier isser in der Heizperiode #}
{% elif now().month |int <= states('input_number.monat_ende_heizperiode') |int %}
{% set state = states('input_boolean.heizperiode') , 'on' %} {# hier isser auch in der Heizperiode #}
{% else %}
{% set state = states('input_boolean.heizperiode') , 'off' %} {# hier isser nicht mehr in der Heizperiode #}
{% endif %}
Woran scheitert es genau?
Theoretisch müsste es so funktionieren
{% set state = [states('input_boolean.heizperiode'), states('input_boolean.etwasanderes')] %}
{% if now().month |int >= states('input_number.monat_start_heizperiode') |int %}
{% set state = states('input_boolean.heizperiode') , 'on' %} {# hier isser in der Heizperiode #}
{% elif now().month |int <= states('input_number.monat_ende_heizperiode') |int %}
{% set state = states('input_boolean.heizperiode') , 'on' %} {# hier isser auch in der Heizperiode #}
{% else %}
{% set state = states('input_boolean.heizperiode') , 'off' %} {# hier isser nicht mehr in der Heizperiode #}
{% endif %}
Einsetzen will ich es wie erwähnt in der Heizungssteuerung…
Damit wird eine (von mehreren) Bedingungen gesetzt.
Wie bzw. wo willst du das einsetzen?
Das wäre das nächste problem…
einen input_boolean mit state (siehe code) kann man nicht bei den Templates in der config.yml eintragen. Generiert sofort ne Fehlermeldung…
Wo müsste das also hin damit die erzeugte Entität (Heizperiode an / aus) für Automationen / Script was auch immer verfügbar wird?
Oder wäre es sogar cleverer statt eines input_boolean einfach einen Sensor im template anzulegen und mit den Werten der beiden Helfer zu füttern?
Edit>>
Habs einfach mal gemacht und einen getriggerten binary_sensor in der config.yml angelegt… (Den Gleichnamigen Helfer natürlich vorher gekillt…)
Problem: Der Sensor bleibt auf “Aus” stehen… Hab ich da noch was vergessen einzubauen?
Note: der trigger alle 30s ist nur zum testen… wird später auf alle 24h reduziert…
- trigger:
- platform: time_pattern
# This will update every night
#hours: 0
#minutes: 0
seconds: /30
binary_sensor:
- name: Heizperiode
unique_id: "Heizperiode"
icon: >
{% if is_state("binary_sensor.heizperiode", "on") %}
mdi:radiator
{% else %}
mdi:radiator-off
{% endif %}
state: >-
{% if now().month |int >= states('input_number.monat_start_heizperiode') |int %}
{% set state = states('binary_sensor.heizperiode') , 'on' %}
{% elif now().month |int <= states('input_number.monat_ende_heizperiode') |int %}
{% set state = states('binary_sensor.heizperiode') , 'on' %}
{% else %}
{% set state = states('binary_sensor.heizperiode') , 'off' %}
{% endif %}
Um Deine Frage aus deiner ersten Antwort mal etwas präziser zu beantworten:
Der Oben genannte getriggerte binary_sensor wird in jedem script und jeder automation (als Bedingung) verwendet um zu prüfen ob das aktuelle Datum innerhalb der mittels 2 Helfern (damit schön einstellbar) gesetzten Heizperiode ist. In meinem Fall hab ich das jetzt erstmal auf 10 (Startmonat) & 4 (Endmonat) gesetzt.
Da ich Wechseldienst habe & der Rest der Family eh früh aus dem Haus sind, wird als nächstes geprüft in welcher Schicht ich mich befinde (Früh oder Spätschicht). Das wird wiederum in einen Texthelfer geschrieben.
Geprüft wird das jeden morgen zu einer Uhrzeit wo ich schon längst auf Arbeit bin, der Rest der Familie aber noch schlummert. → Bin ich da schon weg (device tracker) hab ich Frühschicht. Bin ich noch da hab ich Spätschicht.
Das ganze nur Wochentags.
Mit diesem Texthelfer entscheidet eine weitere Automation welches “Heizprogramm” aktiv geschaltet wird.
Erstellt habe ich 3 Heizprogramme: Spätschicht, Frühschicht & Wochenende. Jeweils ausgeführt als eigene Automation die aktiv oder inaktiv geschaltet wird.
Die Einzelnen Heizprogramme werden als Auslöser mit einem time pattern alle 30 min getriggert.
(Als Bedingung natürlich innerhalb der Heizperiode) Und dort werden dann Uhrzeitgesteuert die Scripte für die einzelnen Heizkörper getriggert.
Meine Tochter kommt z.B. zwischen 13 & 14 Uhr nach Hause, also wird 1h vorher ihr Zimmer angefangen zu beheizen. Eine Weitere halbe stunde früher ist das Wohnzimmer dran.
Mein Sohn kommt erst gegen 16 Uhr nach Hause also wird sein zimmer erst gegen 15 Uhr beheizt.
Ach ja: das ganze ist natürlich auch abhängig von der Außentemperatur, die in einem weiteren Helfer auf basis von weather.home oder weather.forecast ermittelt wird und mit einem weiteren Helfer verglichen wird in dem der Schwellwert für die Außentemperatur eingestellt wird…
Also fällt die Außentemperatur unterhalb der eingestellten wertes, ist wieder eine Bedingung für den ganzen kram erfüllt und es wird geheizt…
Heizungssteuerung kann ziemlich komplex werden…
Das ist aber auch noch nicht der letzte Schuss…
Es müssen noch Fensterkontakte mit eingebaut werden (die sich gerade noch im Zulauf befinden) um das ganze sinnvoll abzurunden…
Du brauchst keinen getriggerten binary_sensor, wenn du den eh nur 1x am Tag aktualisieren lassen willst. Durch now() und dein Monat, ist der eh immer aktuell. Ein normaler binary_sensor sollte meiner Meinung nach reichen.
War jetzt aber zum testen (schaltet er sauber? Schaltet er zuverlässig um? etc) aber die sinnvollste Variante… - sonst hätte ich immer nen Tag warten müssen um einen simplen binary_sensor auf korrekte Funktion zu überprüfen…
Aber ob nun getriggert oder nicht… Ist eh nur software… Kann von mir aus auch so bleiben… Frisst kein Brot…
Außerdem hab ich festgestellt, das der binary_sensor 2x getriggert werden muss um 1. den Wert und 2. das andere Symbol umzuschalten… Schon irgendwie merkwürdig… evtl icon & state in anderer Reihenfolge?
→ Nö… Selber Effekt… Zuerst wird der Wert von an nach aus oder umgekehrt gesetzt und beim 2. trigger erst das symbol umgeschaltet…
Frisst kein Brot…