Template Sensor -> Bei Ausfall vorigen Wert nehmen?

S-d · 28. Oktober 2024 um 18:56

Hallo Zusammen,

wie in diesem Thread beschrieben, kämpfe ich aktuell mit Verbindungsabbrüchen bei meinem Balkonkraftwerk Wechselrichter.

Leider ist das technische Problem WR seitig nicht so ohne weiteres zu beheben. Ich beobachte das ganze jetzt seit einem Monat, es sind immer wieder 13s dauernde, damit sehr kurze, Aussetzer. Mal nur einmal täglich, an anderen Tagen dann aber alle 5 min.

Jetzt habe ich mir überlegt, dass ich doch einfach einen Template Sensor aus der Wechselrichter Leistung erstellen könnte, der bei einem Ausfall kleiner 30s den vorigen Leistungswert weiter nutzt, bis wieder ein neuer Wert gemeldet wird.

Wenn der Ausfall mal länger als 30s dauern sollte, soll dann ein Wert von 0 genommen werden.

So müssten alle Fälle gut abgedeckt sein, auch wenn die Leistung dann tatsächlich auf 0 fällt, bzw. Abends der WR über nacht dauerhaft ausgeht.

Wie müsste das Template für so einen Sensor aussehen?

Sorry, bin im Templaten leider noch nicht so versiert…

Update:
Ich habe heute mal Chat GPT bemüht.
Herauskam dieses Template:

{% set current_time = as_timestamp(now()) %}
{% set last_updated_time = as_timestamp(states.sensor.solar_gesamtleistung.last_updated) %}
{% if states('sensor.solar_gesamtleistung') not in ['unavailable', 'unknown'] %}
  {{ states('sensor.solar_gesamtleistung') }}
{% elif current_time - last_updated_time < 30 %}
  {{ states('sensor.solar_gesamtleistung', '0') }}
{% else %}
  0
{% endif %}

Habe mal versucht die Funktion soweit nachzuvollziehen, scheint das zu machen was ich möchte. Mir ist im Code nur nicht ganz klar was die ‘0’ am Ende der elif schleife macht.

Wäre super wenn da mal jmd einen Blick drauf werfen könnte ob das so passt.

by HarryP: Zusammenführung Doppelpost (bitte “bearbeiten” Funktion nutzen)

Bacardi · 29. Oktober 2024 um 21:43

Moin,
Dein Thema ist nicht ganz trivial und ich bin mir auch nicht sicher ob das wirklich Aussetzer abfängt in Deinem Sinne. Aber es ist ein Anfang.

Meine Kommentare wären:

last_updated_time: Wird dieser Timestamp überhaupt sauber/auswertbar geliefert, wenn ein Aussetzer vorliegt? Wenn nicht, würde diese Zeile zu einem Fehler führen.
30 wären Sekunden nicht Minuten, besser (30 * 60)
{{ states(‘sensor.solar_gesamtleistung’, ‘0’) }} verstehe ich nicht - ich dachte bei Aussetzern innerhalb von 30 min soll der vorige Wert erhalten bleiben?
states(‘sensor.solar_gesamtleistung’) not in [‘unavailable’, ‘unknown’] würde ich erweitern in

states('sensor.solar_gesamtleistung') | lower not in ['none', 'unavailable', 'unknown']

Gutes Gelingen!

S-d · 30. Oktober 2024 um 07:23

Danke für deine Rückmeldung - ja da ich leider noch nicht wirklich versierter Templater bin, musste ich so einmal starten. Es hat auch einige Anläufe gebraucht bis ich ChatGPT soweit hatte…

Inzwischen läuft die PV wieder und somit kann ich nun vergleichen.
Auf den ersten Blick schaut es ganz gut aus. Wenn der Sensor Verfügbar ist, werden zumindest schon einmal korrekte Ist Werte geliefert.
Auch als heute nacht der Sensor naturgemäß nicht verfügbar war, wurde 0 als Leistungswert ausgegeben, scheint also zu klappen.

Heute gab es erst einen Aussetzer, auch dieser wurde entsprechend geglättet, dazu die beiden Screenshots im Anhang - einmal der Ausgangssensor mit Lücke und einmal mein geglätteter Sensor ohne Lücke.

Zu deinen Kommentaren:

das hatte ich mich auch gefragt, wenn es so wie beschrieben nun funktioniert, sollte das ja klappen oder?

tatsächlich sind 30 Sekunden gewünscht - die Ausfälle betragen max. 15-20s

Darüber bin ich auch gestolpert, oder heißt die 0 nach dem Komma, dass dies ein Rückfallwert ist, wäre dann aber unnötig, da von den Bedingungen oben gedeckt. Aktuell ist die 0 noch drin und es funktioniert wie oben, ich nehme diese aber mal raus.

EDIT: Chat GPT hat es auf Nachfrage so bestätigt - die 0 würde als Standardwert greifen, wenn der sensor der PV Leistung einen ungültigen Zustand hat, das wird aber ja bereits ganz oben geprüft und wäre somit doppelt - schadet warsch. nicht, ist aber auch nicht nötig - so zumindest mein Verständnis.

Danke für den Hinweis, kannst du mir noch kurz erklären was diese Änderung und der Begriff “lower” bewirken?

Vielen Dank für die Hilfe!

Bacardi · 30. Oktober 2024 um 07:43

Ein schönes Feedback und ich freue mich, daß es funktioniert.
ChatGPT nutze ich auch sehr gern aber man muß nur sehr aufpassen - manchmal kommt Müll aber manchmal auch gute Hinweise.

Ich lese gerade für mich die Doku über State Objects und probiere etwas herum. Das finde ich so gut an diesem Forum, es triggert etwas. In diesem Fall war es Dein last_updated.

Zu der Frage mit dem | lower

Ich bin mir bei meinen Sensoren nicht immer sicher, ob sie den Status wirklich in kleinen Buchstaben liefert und mit dem lower gehe ich auf sicher, daß State und Listeneinträge vergleichbar sind.

crypton · 30. Oktober 2024 um 08:04

EDIT: Chat GPT hat es auf Nachfrage so bestätigt - die 0 würde als Standardwert greifen, wenn der sensor der PV Leistung einen ungültigen Zustand hat, das wird aber ja bereits ganz oben geprüft und wäre somit doppelt - schadet warsch. nicht, ist aber auch nicht nötig - so zumindest mein Verständnis.

Das ist dann mal ein Beispiel dafür, das ChatGPT nicht die richtige Antwort liefert. In der Doku ist zu lesen:

states can also be used as a function, states(entity_id, rounded=False, with_unit=False) , which returns the state string (not the state object) of the given entity, unknown if it doesn’t exist, and unavailable if the object exists but is not available.

Die 0 hinter dem Komma bedeutet rounded=0, also wird nicht gerundet!

S-d · 30. Oktober 2024 um 08:42

Super Danke! Somit passt die 0 zwar zufällig, da Rundung nicht benötigt wird. Chat GPT hatte aber unrecht - auf den Hinweis war der Bot ganz kleinlaut

Danke dir, klingt nach einem sinnvollen Zusatz - werde ich einarbeiten!

EDIT:

Jetzt bin ich noch über einen Protokolleintrag gestolpert.

Logger: homeassistant.helpers.event
Quelle: helpers/event.py:352
Erstmals aufgetreten: 06:58:26 (3 Vorkommnisse)
Zuletzt protokolliert: 07:56:16

Error while dispatching event for sensor.solar_gesamtleistung to <Job track state_changed event {‘sensor.solar_gesamtleistung’} HassJobType.Callback <bound method TrackTemplateResultInfo._refresh of <TrackTemplateResultInfo {Template<template=({% set current_time = as_timestamp(now()) %} {% set last_updated_time = as_timestamp(states.sensor.solar_gesamtleistung.last_updated) %} {% if states(‘sensor.solar_gesamtleistung’) not in [‘unavailable’, ‘unknown’] %} {{ states(‘sensor.solar_gesamtleistung’) }} {% elif current_time - last_updated_time < 30 %} {{ states(‘sensor.solar_gesamtleistung’, ‘0’) }} {% else %} 0 {% endif %}) renders=1526>: <RenderInfo Template<template=({% set current_time = as_timestamp(now()) %} {% set last_updated_time = as_timestamp(states.sensor.solar_gesamtleistung.last_updated) %} {% if states(‘sensor.solar_gesamtleistung’) not in [‘unavailable’, ‘unknown’] %} {{ states(‘sensor.solar_gesamtleistung’) }} {% elif current_time - last_updated_time < 30 %} {{ states(‘sensor.solar_gesamtleistung’, ‘0’) }} {% else %} 0 {% endif %}) renders=1526> all_states=False all_states_lifecycle=False domains=frozenset() domains_lifecycle=frozenset() entities=frozenset({‘sensor.solar_gesamtleistung’}) rate_limit=None has_time=True exception=None is_static=False>}>>>
Error while dispatching event for sensor.solar_gesamtleistung to <Job track state_changed event {‘sensor.solar_gesamtleistung’} HassJobType.Callback <bound method TrackTemplateResultInfo._refresh of <TrackTemplateResultInfo {Template<template=({% set current_time = as_timestamp(now()) %} {% set last_updated_time = as_timestamp(states.sensor.solar_gesamtleistung.last_updated) %} {% if states(‘sensor.solar_gesamtleistung’) not in [‘unavailable’, ‘unknown’] %} {{ states(‘sensor.solar_gesamtleistung’) }} {% elif current_time - last_updated_time < 30 %} {{ states(‘sensor.solar_gesamtleistung’, ‘0’) }} {% else %} 0 {% endif %}) renders=1550>: <RenderInfo Template<template=({% set current_time = as_timestamp(now()) %} {% set last_updated_time = as_timestamp(states.sensor.solar_gesamtleistung.last_updated) %} {% if states(‘sensor.solar_gesamtleistung’) not in [‘unavailable’, ‘unknown’] %} {{ states(‘sensor.solar_gesamtleistung’) }} {% elif current_time - last_updated_time < 30 %} {{ states(‘sensor.solar_gesamtleistung’, ‘0’) }} {% else %} 0 {% endif %}) renders=1550> all_states=False all_states_lifecycle=False domains=frozenset() domains_lifecycle=frozenset() entities=frozenset({‘sensor.solar_gesamtleistung’}) rate_limit=None has_time=True exception=None is_static=False>}>>>
Error while dispatching event for sensor.solar_gesamtleistung to <Job track state_changed event {‘sensor.solar_gesamtleistung’} HassJobType.Callback <bound method TrackTemplateResultInfo._refresh of <TrackTemplateResultInfo {Template<template=({% set current_time = as_timestamp(now()) %} {% set last_updated_time = as_timestamp(states.sensor.solar_gesamtleistung.last_updated) %} {% if states(‘sensor.solar_gesamtleistung’) not in [‘unavailable’, ‘unknown’] %} {{ states(‘sensor.solar_gesamtleistung’) }} {% elif current_time - last_updated_time < 30 %} {{ states(‘sensor.solar_gesamtleistung’, ‘0’) }} {% else %} 0 {% endif %}) renders=1902>: <RenderInfo Template<template=({% set current_time = as_timestamp(now()) %} {% set last_updated_time = as_timestamp(states.sensor.solar_gesamtleistung.last_updated) %} {% if states(‘sensor.solar_gesamtleistung’) not in [‘unavailable’, ‘unknown’] %} {{ states(‘sensor.solar_gesamtleistung’) }} {% elif current_time - last_updated_time < 30 %} {{ states(‘sensor.solar_gesamtleistung’, ‘0’) }} {% else %} 0 {% endif %}) renders=1902> all_states=False all_states_lifecycle=False domains=frozenset() domains_lifecycle=frozenset() entities=frozenset({‘sensor.solar_gesamtleistung’}) rate_limit=None has_time=True exception=None is_static=False>}>>>
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/components/sensor/init.py”, line 662, in state
numerical_value = float(value) # type:ignore[arg-type]
^^^^^^^^^^^^
ValueError: could not convert string to float: ‘unavailable’

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/helpers/event.py”, line 352, in _async_dispatch_entity_id_event
hass.async_run_hass_job(job, event)
File “/usr/src/homeassistant/homeassistant/core.py”, line 937, in async_run_hass_job
hassjob.target(*args)
File “/usr/src/homeassistant/homeassistant/helpers/event.py”, line 1308, in _refresh
self.hass.async_run_hass_job(self._job, event, updates)
File “/usr/src/homeassistant/homeassistant/core.py”, line 937, in async_run_hass_job
hassjob.target(*args)
File “/usr/src/homeassistant/homeassistant/components/template/template_entity.py”, line 436, in _handle_results
self.async_write_ha_state()
File “/usr/src/homeassistant/homeassistant/helpers/entity.py”, line 1005, in async_write_ha_state
self._async_write_ha_state()
File “/usr/src/homeassistant/homeassistant/helpers/entity.py”, line 1130, in _async_write_ha_state
self.__async_calculate_state()
File “/usr/src/homeassistant/homeassistant/helpers/entity.py”, line 1067, in __async_calculate_state
state = self._stringify_state(available)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/helpers/entity.py”, line 1011, in _stringify_state
if (state := self.state) is None:
^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/components/sensor/init.py”, line 664, in state
raise ValueError(
ValueError: Sensor sensor.pv_gesamtleistung_geglattet has device class ‘power’, state class ‘measurement’ unit ‘W’ and suggested precision ‘None’ thus indicating it has a numeric value; however, it has the non-numeric value: ‘unavailable’ (<class ‘str’>)

Es scheint als hätte der Sensor den State “unavailable” angenommen, anstelle eines nummerischen Wertes - so verstehe ich die Meldung. Das wundert mich, da ja eigentlich genau das nicht passieren soll - es war zu der Zeit als die Lücke im Ursprungssensor auftetaucht ist, die dann ja durch den Template Sensor auch geschlossen wurde.
Kann sich da jmd. einen Reim drauf machen?

Bacardi · 30. Oktober 2024 um 16:25

In dem Fehler sehe ich daß der | lower Befehl noch nicht eingefügt war.
Es könnte sein, daß der Status mit “U” geliefert wurde und so nicht abgefangen wurde.

S-d · 30. Oktober 2024 um 18:15

Danke für den Hinweis, das ist richtig - die Fehlermeldung war noch vom Morgen, da habe ich die Anpassung noch nicht gemacht. Kam aber genauso auch Nachmittags nach der Anpassung nochmal.

Habe daher einfach mal den Fehler von Chat GPT prüfen lassen, folgendes kam als Antwort:

Die Fehlermeldung deutet darauf hin, dass der Sensor an einer Stelle einen Wert „unavailable“ erhält, obwohl Home Assistant für diesen Sensor eine numerische Ausgabe erwartet. Dies ist besonders problematisch, wenn der Sensor eine „device class“ wie power hat, da Home Assistant in diesem Fall davon ausgeht, dass der Wert eine Zahl ist.

Ursachenanalyse:

Die Bedingung im Code prüft nicht vollständig, ob der Wert des Sensors immer eine Zahl ist. Die Meldung besagt, dass Home Assistant versucht, den Zustand „unavailable“ in einen numerischen Wert zu konvertieren, was zu einem Fehler führt.

Wenn Home Assistant davon ausgeht, dass der Sensor eine numerische Ausgabe liefert, akzeptiert es keine nicht-numerischen Werte wie „unavailable“.

Dazu diese Code Anpassung:

state: >
          {% set current_time = as_timestamp(now()) %}
          {% set last_updated_time = as_timestamp(states.sensor.solar_gesamtleistung.last_updated) %}
          {% if states('sensor.solar_gesamtleistung') | lower not in ['none', 'unavailable', 'unknown'] %}
            {{ states('sensor.solar_gesamtleistung') | float(0) }}
          {% elif current_time - last_updated_time < 30 %}
            {{ states('sensor.solar_gesamtleistung') | float(0) }}
          {% else %}
            0
          {% endif %}

Stimmt das, also dass der float Befehl gefehlt hat?
Wäre meinem beschränkten Verständnis nach zumindest plausibel.

Bacardi · 30. Oktober 2024 um 18:19

Float ist gut und morgen weißt Du ob gut genug

S-d · 31. Oktober 2024 um 10:20

Hehe das stimmt, ich teste mal - falsch ist es meinem Verständnis nach jedenfalls mal nicht. Ich berichte!

Update:
Jetzt bin ich doch ein wenig ratlos.
Habe heute mal draufgeschaut, jetzt wird bei jedem Ausfall der Sensor auf 0 gesetzt (auch innerhalb der 30s Grenze), ist aber nach einem Blick auf den Code auch logisch.

Ich habe ja die Abfrage, dass wenn current time- last updated time unter 30s soll er den ursprungswert nehmen, dann kickt ihn aber die Abfrage ob er unavailable ist raus und setzt auf 0 - das ist ja nicht das gewünschte Verhalten.

Es fehlt also noch die Speicherung des letzten Wertes, daher habe ich auch hier nochmal mit Chat GPT gespielt, mit folgendem Ergebnis:

{% set current_time = as_timestamp(now()) %}
{% set last_updated_time = as_timestamp(states.sensor.solar_gesamtleistung.last_updated) %}
{% set last_value = states('sensor.solar_gesamtleistung') | float(0) %}
{% if states('sensor.solar_gesamtleistung') | lower not in ['none', 'unavailable', 'unknown'] %}
  {{ states('sensor.solar_gesamtleistung') | float(0) }}
{% elif current_time - last_updated_time < 30 %}
  {{ last_value }}
{% else %}
  0
{% endif %}

Kann da nochmal jmd. einen Blick drauf werfen, ob das so mit last value passt?

by HarryP: Zusammenführung Doppelpost (bitte “bearbeiten” Funktion nutzen)

Bacardi · 31. Oktober 2024 um 10:47

{% set last_value = states('sensor.solar_gesamtleistung') | float(0) %}

float(0) setzt bereits den Wert auf 0 wenn unavailable und deshalb kommt es gar nicht mehr zu der Prüfung

{% if states('sensor.solar_gesamtleistung') | lower not in ['none', 'unavailable', 'unknown'] %}

setze mal nur | float

Theoretisch kannst Du es auch hier machen weil die invaliden Stati werden ja bereits abgefangen

{{ states('sensor.solar_gesamtleistung') | float(0) }}

Jetzt wird es spannend und auch das war auch der Grund warum ich oben vermutete, daß Dein Fall nicht trivial ist.

Erhoffst Du mit last_value den Vorgänger Wert zu erhalten?

Im oberen Konstrukt hat last_value immer den momentanen Wert entweder eine Watt Zahl oder den Invaliden Status aber nicht den Vorgänger Wert.

EDIT:
Den müßte man sich entweder über eine Automatisation zwischenspeichern oder über ein Konstrukt wie Du es hier siehst

S-d · 31. Oktober 2024 um 10:53

Ja das habe ich inzwischen auch gemerkt…

Ja genau, ich fasse das Ziel nochmal kurz zusammen - nicht das es im Prozess verloren geht

Ziel ist es die kurzen Unterbrechungen die mein PV Wechselrichter manchmal hat zu Glätten. Da es sich dabei stets um sehr kurze Unterbrechnungen unter 20s handelt, habe ich die Grenze von 30s gesetzt.

Somit soll der Wert vor der Unterbrechung (also bevor der Wechselrichter auf unavailable geht) gespeichert werden.

Dieser Wert soll für den Fall das der Wechselrichter unavailable ist für eine maximale Dauer von 30s gehalten werden, dauert der Ausfall länger (bspw. Weil Abends die Sonne weg ist und damit der Wechselrichter naturgemäß auf unavailable geht - oder weil mal das WLAN komplett ausfällt etc.) soll der Sensor den Wert 0 annehmen.

Damit kann ich dann sicherstellen, dass kurze Verbindungsabbrüche gut überbrückt werden, längere Ausfälle dann aber korrekterweise nicht fälschlicherweise eine weitere PV Erzeugung ausgegeben, die nicht vorhanden ist.

EDIT:

Okay auch alles nicht ganz einfach.

Aber dann müsste das doch möglich sein über eine Automation, ohne das jetzt bereits final durchdacht zu haben wäre aber doch ein Ansatz, das Template grundsätzlich so zu belassen wie wir es hier bereits entwickelt haben, dann aber in der Abfragescheleife einen Input Number Helfer zu verwenden und diese Input Number per Automation den letzten Wert speichern zu lassen.

Also so eine Automation:

alias: Speichere letzten gültigen PV Wert
description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.solar_gesamtleistung
conditions:
  - condition: template
    value_template: >-
      {{ states('sensor.solar_gesamtleistung') | lower not in ['none',
      'unavailable', 'unknown'] }}
actions:
  - action: input_number.set_value
    metadata: {}
    data: {}
    target:
      entity_id: input_number.letzter_gultiger_pv_wert
    data_template:
      value: "{{ states('sensor.solar_gesamtleistung') | float(0) }}"
mode: single

Sollte doch passen oder?
In der Automation wird nun bei jeder Änderung des Ausgangssensors getriggert, unter Bedingungen geprüft ob der Sensor nicht unavailable ist und dann der Input Number Wert befüllt. Dieser müsste dann doch stehen bleiben, bis wieder ein neuer gültiger Wert geschrieben wird - und damit der Ausgangssensor wieder erreichbar ist.

Diesen Input Number Helfer habe ich dann in das Sensor Template gepackt. Klingt für mich passend, ich hoffe ich habe nichts übersehen.

Bacardi · 31. Oktober 2024 um 11:50

Ja das geht in die richtige Richtung und ist den nächsten Versuch wert. Ich bin gespannt.

PS1: Nichts ist hier für umsonst schon allein wegen den Lerneffekten.

PS2: Ich hatte bis vor Kurzem auch den Vorgänger Stromverbrauch über eine Automatisation erfaßt und nur wenn Nachfolger +/- 20 W war, wurde er angezeigt aber dann sah ich den genialen/performance schonenderen Ansatz eines Template Trigger / Action hier und habe ihn seit ca. 10 Tagen am Laufen. Falls, Deine Automatisation und auch die Glättung dann funktioniert und Du noch Lust hast, versuche es ruhig.

S-d · 31. Oktober 2024 um 12:38

Ja da gebe ich dir absolut Recht.

Das habe ich gesehen, aber noch nicht richtig verstanden. Damit würde ich dann ja doch wieder alles in einem Template unterbringen oder doch nicht?

Bacardi · 31. Oktober 2024 um 15:01

Speziell in der configuration.yaml.

Da hatte ich dann ChatGPT auch die Frage gestellt: what is the difference between using your template trigger and an automisation doing the same?
Ich denke, daß eine Automation ressourcenhungriger ist und auch DB Statistik mehr beansprucht wobei letzteres gezielt für die Automatisation ausgeschlossen werden kann.

Ich denke, gehe erst einmal den Weg über die Automatisation bis die Logik stimmt und Du Deine Glättung hast. Dann kannst Du immer noch etwas effizienter werden.

EDIT
So etwas könnte ich mir später vorstellen.

template:
  - trigger:
      - platform: state
        entity_id:
          - sensor.solar_gesamtleistung
    sensor:
      - name: Solar Gesamtleistung geglaettet
        unique_id: solar_gesamtleistung_geglaettet
        state_class: measurement
        device_class: power
        unit_of_measurement: "W"
        state: >
          {% set current_time = as_timestamp(now()) %}
          {% set last_updated_time = as_timestamp(states.sensor.solar_gesamtleistung.last_updated) %}
          {% set old = trigger.from_state.state %}
          {% set new_value = trigger.to_state.state %}
          {% set last_value = 0 %}
          {% set invalid_states = ['unavailable', 'unknown', 'none'] %}
          {% if new_value | lower not in invalid_states %}
            {% set last_value = new_value | float %}
          {% elif current_time - last_updated_time < 30 %}
            {% set last_value = old | float(0) %}
          {% endif %}
          {{last_value}}

Sollte die Lösung später funktionieren, würde ich die Statistik Deines Sensors sensor.solar_gesamtleistung deaktivieren um die DB nicht unnötig zuzumüllen.

PS Beim Umschreiben meiner Lösung an Deine hier ist mir sogar noch ein Fehler bei mir aufgefallen - so haben wir beide etwas davon

LutzAlbers · 1. November 2024 um 10:28

Hier meine Lösung für ein ähnliches Problem (ich frage hier auf ungültige Werte ab, kann man leicht adaptieren:

  - sensor:
      - name: "IAM-T1 Humidity Cleaned"
        unique_id: "iam_t1_humidity_clean"
        unit_of_measurement: "%"
        state_class: "measurement"
        state: >
            {% if (states('sensor.esphome_web_cd2e34_iam_t1_humidity')|float) > 0 and (states('sensor.esphome_web_cd2e34_iam_t1_humidity')|float) < 5000  %}
              {{ states('sensor.esphome_web_cd2e34_iam_t1_humidity')|float|round(0) }}
            {% else %}
              {{ this.state }}
            {% endif %}

S-d · 1. November 2024 um 12:01

Danke für den Ansatz, hier verstehe ich aber die Funktion nicht, wo werden da die Abfragen gemacht?

LutzAlbers · 1. November 2024 um 12:25

Du kannst das if-statement einfach durch eines der anderen oben austauschen

S-d · 1. November 2024 um 12:29

sorry, hab mich evtl. blöd ausgedrückt. Mir ist nicht klar, wo der vorige Wert zwischengespeichert wird, der dann bei einem ausfall genutzt werden soll.

Bacardi · 1. November 2024 um 12:52

Ich denke, das gibt der Template Code nicht her. Der Code arbeitet wie Dein obiger nur mit momentan Werten, die bei 0-5000 Werten bereinigt/gerundet werden. Aber danke dennoch!

Thema		Antworten	Aufrufe
Status "unbekannt" von Sensor mittels Template abfangen? Allgemein templating , yaml	3	107	5. November 2024
Regelmäßig Ausreißer (Wert statt Differenz) bei Tasmota Energie Allgemein strom , heizung , templating , yaml	34	197	18. August 2026
Berechnung Verlustleistung Wechselrichter: Probleme mit Sensorerstellung (if, elif, else) Allgemein templating , yaml , statistik	2	72	3. April 2026
"If" Abfrage ohne ELSE Allgemein templating , yaml	7	165	17. August 2025
Sensor Status "unavailable" - letzten Status setzen? Allgemein	31	4320	10. Dezember 2024

Template Sensor -> Bei Ausfall vorigen Wert nehmen?

Verwandte Themen