Home Assistant Templates / Statistik und Sensoren

 

Durch die Hilfe von Home-Assistant Templates können die Daten von verschiedenen Sensoren umgewandelt, kombiniert oder mit eigenen Formeln versehen werden. Templates ermöglichen das Erstellen von Logikblöcken für den Einsatz in eigenen Sensoren, Bedingungen oder für das Anpassen bestimmter Werte in Lovelance Cards. Als Syntax wird Jinja2 verwendet, eine voll funktionsfähigen Template-Engine für Python.

Wo können Templates verwendet werden?

Templates können in den folgenden Home-Assistant-Komponenten eingesetzt werden:

Entwicklerwerkzeuge

Am einfachsten können neue Templates unter Entwicklerwerkzeuge / TEMPLATE getestet werden:

Wer einen neuen Sensor auf Basis eines Templates erstellen will, kann dies in den Einstellungen unter "Geräte & Diense", "HELFER ERSTELLEN" und "Template": 

Template-Sensor: Helfer

Ursprünglich wurden Template-Sensoren in der configuration.yaml-Datei hinterlegt. In aktuellen Home Assistant Versionen können die Templates komfortabel als Helfer in der Home Assistant Oberfläche angelegt werden. Die Helfer zeigen beim Erstellen bereits die berechneten Werte oder eventuelle Syntaxfehler.

Menüpunkt: Einstellungen, Helfer erstellen -> Template: 

Zur Auswahl stehen die Optionen für einen binären Sensor, also "Ein" und "Aus", oder einen beliebigen anderen Sensor:

Zur Erstellung, siehe auf dieser Seite: Template Beispiele

Automatisierungen

Die angelegten Template-Sensoren könnten in einer Automatisierung verwendet werden, oder alternativ bieten diese die Möglichkeit direkt einen Template-Block in den Auslösern oder Bedingungen zu hinterlegen:

Innerhalb der Automatisierungen können Templates als Auslöser, Bedingung und in den Bedingungen von Aktionen verwendet werden:

siehe auch: Home Assistant Automatisierung - Möglichkeiten & Basics

Template Beispiele

Als konkretes Beispiel für einen Template-Sensor könnte aus dem Datum und die Uhrzeit für den nächsten Sonnenaufgang die Uhrzeit als eigene Entität zur Verfügung gestellt werden. Der integrierte Sensor für den Sonnenaufgang steht in folgendem Format zur Verfügung:  2023-09-12T07:40:21.796007+00:00. Für das Extrahieren der Uhrzeit, kann folgendes Template eingesetzt werden:

{{
as_timestamp(states.sun.sun.attributes.next_rising) | 
timestamp_custom('%H:%M')
}}

"as_timestamp" wandelt dabei den Wert ("states.") des Sensors "sun.sun.attributes.next_rising" in einen Unix-Timestamp um. Ein Pipe "|" an die Funktion "timestamp_custom" wandelt den Timestamp zurück in "Stunden":"Minuten": '%H:%M'. Wie bereits erwähnt kann das Template in den Entwicklerwerkzeugen getestet werden:

Eingesetzt als Template-Sensor, zeigt auch dieser eine Vorschau des Ergebnisses:

Beim Speichern des Template-Sensors wird ein neuer Sensor mit der ID: sensor.Name, hier "sensor.sonnenaufgang" angelegt und steht als eigene Entität in Home Assistant zur Verfügung. 

Template - Cheat Sheet

Hier ein paar Beispiel-Templates:

was Template
Sonnenaufgang
{{ as_timestamp(states.sun.sun.attributes.next_rising) | timestamp_custom(' %H:%M') | replace(" 0", "") }}
Sonnenuntergang
{{ as_timestamp(states.sun.sun.attributes.next_setting) | timestamp_custom(' %H:%M') | replace(" 0", "") }}
Sonne: Sonnenaufgang - Sonnenuntergang
{{ as_timestamp(states.sun.sun.attributes.next_rising) | timestamp_custom(' %H:%M') | replace(" 0", "") }} - 
{{ as_timestamp(states.sun.sun.attributes.next_setting) | timestamp_custom(' %H:%M') | replace(" 0", "") }}
Tageslicht in Stunden pro Tag
{%set sr = (as_timestamp(states.sun.sun.attributes.next_rising) | timestamp_custom('%H:%M')).split(":") %}  
{%set ss = (as_timestamp(states.sun.sun.attributes.next_setting) | timestamp_custom('%H:%M')).split(":") %} 
{{ ((ss[0] | int * 60 + ss[1] | int - sr[0] | int * 60 + sr[1] | int) / 60) | round(2) }}
Test ob nach Sonnenaufgang
{{ as_timestamp(now()) | timestamp_custom('%H%M') | float  > (states.sun.sun.attributes.next_rising |as_timestamp) | timestamp_custom("%H%M", True) | float }}
Test ob nach Sonnenuntergang
{{ as_timestamp(now()) | timestamp_custom('%H%M') | float  > (states.sun.sun.attributes.next_setting |as_timestamp) | timestamp_custom("%H%M", True) | float }}
verbleibendes Tageslicht in Stunden
{% set now = (as_timestamp(now()) | timestamp_custom('%H:%M')) %}
{% set sr = (as_timestamp(states.sun.sun.attributes.next_rising) | timestamp_custom('%H:%M')) %}  
{% set ss = (as_timestamp(states.sun.sun.attributes.next_setting) | timestamp_custom('%H:%M')) %} 
{% set start = now if now > sr else sr %}
{% if now < ss %}
{{ (((ss.split(":")[0] | int * 60 + ss.split(":")[1] | int) - (start.split(":")[0] | int * 60 + start.split(":")[1] | int)) / 60) | round(2) }}
{% else %}
0
{% endif %}
Leistung (Watt) aus Strom (I) und Spannung (U)
{% set V = states('sensor.meter01_voltage_l1') | float %}
{% set A = states('sensor.meter01_current_l1') | float %}
{{ ( 0.9 * A * V) | round(0)}}
Über den Stromverbrauch der Heizungssteuerung -  gemessen mit einer Zigbee Steckdose - kann ich feststellen, welche Aktion die Heizung gerade durchführt.

Der folgende Sensor ändert den Status anhand des Stromverbrauchs der Heizungssteuerung und kann damit z.B. in einer Lovelance-Card als Information eingeblendet werden:

{% set value = states('sensor.heating_active_power') | float %}
          {{ "aus" if value < 10 else 
          "Pumpen" if value < 58 else 
          "Warmwasser" if value < 70 else 
          "Pumpen" if value < 125 else 
          "Heizen" }}
Zeit seit der letzten Statusänderung in Minuten länger als x Minuten (im Beispiel 30 Minuten)

 

Um festzustellen, wann der Status eines Sensors zuletzt geändert wurde, setze ich für meine Heizung folgendes Template ein.

{{
(((as_timestamp(now()) - 
as_timestamp(states.switch.relay_heizung_puffer_kalt.last_changed)) / 60) | int) 
  > 30
}} 

Das Template prüft, ob die letzte Statusänderung vor mehr als 30 Minuten ("> 30") stattgefunden hat. Ich verwende das Template in den Automatisierungen damit meine Heizung nicht kurz nach dem Einschalten durch eine bestimmte Statusänderung wieder deaktiviert wird.

 

"Nicht Verfügbar"- Wert vorgeben: 0

Um die Zahl 0 anstelle von "nicht verfügbar" für eine Entität zu verwenden, kann eine einfache if-Abfrage mit "is_number" verwendet werden:

{% set pumpen = states('sensor.heizung_pumpe_eg_active_power') | float if states('sensor.heizung_pumpe_eg_active_power') | is_number else 0   %}
{{ pumpen  }}

Vorherigen Wert im Template-Sensor verwenden

Mithilfe des folgenden Templates kann ein Template-Sensor (hier sensor.lastavailablestate) den letzten Wert zurückgeben, der nicht "unavailable" war: 

{% if states('sensor.sometimes_unavailable')  != 'unavailable'%}
    {{ sensor.sometimes_unavailable }}
{% else %}
    {{ states('sensor.lastavailablestate') }}
{% endif %}

Neben den Template-Sensoren gibt es in Home-Assistant zusätzliche Helfer-Sensoren für bestimmte Daten:

bestimmte Helfer

Riemann Summenintegralsensor (vormals Platform:Integration) hinzufügen

Um aus einem Momentanwert den Verbrauch zu bestimmen, kann ein sogenannter Riemann Summenintegralsensor hinzugefügt werden. Damit kann aus bestimmten Verbrauchswerten: Watt der komplette Verbrauch als Wh (Watt-Stunden) summiert werden:

Der Verbrauch wird summiert:

Um den summierten Verbrauch wieder auf eine bestimmte Zeitspanne zu beziehen, kann die "Platform Integration" als „utility_meter“ verwendet werden:

Verbrauchszähler hinzufügen (vormals Utility_Meter)

Der Verbrauchszähler verwendet den Gesamtverbrauch und unterteilt diesen in bestimmte Zeitspannen: z.B. stündlich (hourly) oder (täglich) daily:

Statistics Platform

Mithilfe der Statistics Platform können bestimmte historische Werte repräsentiert werden, als Beispiel die Summe bestimmter Werte. Aktuell müssen diese in der configuration.yaml-Datei hinzugefügt werden, da es dafür noch keine Helper-Funktionen in der GUI gibt, lediglich einen Feature Request: https://community.home-assistant.io/t/make-a-statistics-helper/610340:

sensor:
  - name: rain_weather_24
    platform: statistics
    entity_id: sensor.rain_weather
    state_characteristic: sum
    max_age:
      hours: 24

sum_differences verwendet die Unterschiede zwischen den Werten bei einem fortlaufenden Zähler: 

sensor:
  - name: powerplug_24
    platform: statistics
    entity_id: sensor.powerplug_summation_delivered
    state_characteristic: sum_differences	
    max_age:
      hours: 24

Ein weiteres Beispiel ist die durchschnittliche Temperatur der letzten 24 Stunden

sensor:
  - name: aussen_temperature_24
    platform: statistics
    entity_id: sensor.aussen_temperature
    state_characteristic: mean
    max_age:
      hours: 24

SQL Integration

Zudem können die Daten für bestimmte Sensoren direkt die SQL-Integration aus der Datenbank gelesen werden. So können zum Beispiel Statistik-Daten auch im Nachhinein abgefragt werden, ohne zuvor einen entsprechenden Sensor anlegen zu müssen.

Beschreibung SQL-Query für die SQL-Integration, als Spalte in der Integration wird "val" über "as val" vorgegeben: 
Delta-Wert (Produktion) eines Energy-Sensors gestern (aus der LTS-Statistik-Tabelle gelesen)
SELECT (Max(state) - Min(state)) as val FROM statistics 
WHERE metadata_id = (SELECT id FROM statistics_meta 
WHERE statistic_id = 'sensor.household_energy') and 
created_ts > (SELECT unixepoch(datetime(date('now'),'-2 days'))) and 
created_ts < (SELECT unixepoch(datetime(date('now'),'-1 days')))
Delta-Wert (Produktion) eines Energy-Sensors heute bis jetzt (aus der Statistik-Short_Term-Tabelle gelesen)
SELECT (Max(state) - Min(state)) as val 
FROM statistics_short_term 
WHERE metadata_id = (SELECT id FROM statistics_meta 
WHERE statistic_id = 'sensor.household_energy') and 
created_ts > (SELECT unixepoch(datetime(date('now')))) and 
created_ts < (SELECT unixepoch(datetime(datetime('now'))))
Delta-Wert (Produktion) eines Energy-Sensors gestern bis zur selben Zeit (aus der Statistik-Short_Term-Tabelle gelesen)
SELECT (Max(state) - Min(state)) as val FROM statistics_short_term 
WHERE metadata_id = (SELECT id FROM statistics_meta 
WHERE statistic_id = 'sensor.household_energy') and 
created_ts > (SELECT unixepoch(datetime(date('now'),'-1 days'))) and 
created_ts < (SELECT unixepoch(datetime(datetime('now'),'-1 days'))) 
ORDER BY id DESC ;
gestern: kleinster Wert eines Sensors (aus der States-Tabelle gelesen)
SELECT min("state") as val FROM states 
WHERE metadata_id = (SELECT metadata_id FROM states_meta 
WHERE entity_id = 'sensor.byd_available_capacity') and 
last_updated_ts > (SELECT unixepoch(datetime(date('now'),'-1 days'))) and 
last_updated_ts < (SELECT unixepoch(datetime(date('now'))))
kleinster Wert, z. B. der tiefste Batterieladestatus von gestern.
SELECT CAST(state AS INTEGER) as val FROM states 
WHERE metadata_id = (SELECT metadata_id FROM states_meta 
WHERE entity_id = 'sensor.byd_battery_box_premium_hv_ladezustand') and 
last_updated_ts > (SELECT unixepoch(datetime(date('now'),'-1 days'))) and 
last_updated_ts < (SELECT unixepoch(datetime(date('now')))) 
order by val limit 1

Für den Ladezustand meiner Batterie (in Prozent) funktionierte weder Max, noch ein normales Order, da z.B. 100 kleiner als 42.2 interpretiert wurde.
Als Lösung habe ich state über CAST als Integer interpretiert, sortiert und mit limit 1 wird dann der kleinste Wert ausgegeben.

Batterieladestatus gestern zur selben Zeit
SELECT * FROM states 
WHERE metadata_id = (SELECT metadata_id FROM states_meta 
WHERE entity_id = 'sensor.byd_battery_box_premium_hv_ladezustand') and 
last_updated_ts > (SELECT unixepoch(datetime(datetime('now'),'-1 days'))) 
order by last_updated_ts limit 1

Für Select * kann der Wert über "state" in der Integration verwendet werden:

letzter Zeitpunkt eines Sensors mit einem bestimmten Wert als Unix Timestamp
SELECT last_updated_ts as val FROM states 
WHERE metadata_id = (SELECT metadata_id FROM states_meta 
WHERE entity_id = 'sensor.fronius_storage_chast') and
state = "FULL"  
order by last_updated_ts DESC limit 1
letzter Zeitpunkt eines Sensors mit einem bestimmten Wert als Datum / Uhrzeit
SELECT datetime(last_updated_ts, 'unixepoch', 'localtime') as val FROM states 
WHERE metadata_id = (SELECT metadata_id FROM states_meta 
WHERE entity_id = 'sensor.fronius_storage_chast') and
state = "FULL"  
order by last_updated_ts DESC limit 1
Delta-Wert (Produktion) eines Energy-Sensors seit dem ein anderen Sensors zuletzt einen bestimmten Wert hatte (aus der Statistik-Short_Term-Tabelle gelesen)
SELECT (Max(state) - Min(state)) as val 
FROM statistics_short_term 
WHERE metadata_id = (SELECT id FROM statistics_meta 
WHERE statistic_id = 'sensor.household_energy') and 
created_ts > (
    (SELECT last_updated_ts as val FROM states 
    WHERE metadata_id = (SELECT metadata_id FROM states_meta 
    WHERE entity_id = 'sensor.fronius_storage_chast') and
    state = "FULL"  
    order by last_updated_ts DESC limit 1
)) and 
created_ts < (SELECT unixepoch(datetime(datetime('now'))))
positive Bewertung({{pro_count}})
Beitrag bewerten:
{{percentage}} % positiv
negative Bewertung({{con_count}})

DANKE für deine Bewertung!

Aktualisiert: 23.04.2024 von Bernhard | Translation English |🔔 | Kommentare:0
Preview Home Assistant Schnee-Erkennung PV-Anlage

Home Assistant Schnee-Erkennung PV-Anlage

erstellt: 22.01.2024 von Bernhard

Bei einer PV-Anlage steigt die Spannung mit der Anzahl der PV-Modulen, auch bei schlechten Lichtverhältnissen. Anders, wenn bestimmte Module teilweise oder komplett von Schnee bedeckt sind. Diese Tatsache habe ich mir zunutze gemacht und in Home Assistant eine Schnee-Erkennung zusammengestellt. Warum? Um die PV-Vorhersage für den nächsten Tag zu korrigieren, und die Steuerung für die Heizung entsprechend anzupassen. ... weiterlesen


Home-Assistant + DIY Mikrocontroller + ESP Home (Docker) | Home Assistant | HA Verlauf: mehr als 10 Tage? Long Time Statistic (LTS)

Fragen / Kommentare


Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu Mehr Details