"unavailable" in automatisierung abfangen

R

RudiP

Well-known member
Folgender Trigger
Code: 
alias: Waschmaschine fertig
description: ""
triggers:
  - trigger: numeric_state
    entity_id:
      - sensor.waschmaschine_leistung
    for:
      hours: 0
      minutes: 1
      seconds: 0
    below: 5
conditions: []
Wenn die Leistung des Steckdose 1 Minute unter 5 Watt ist, dann soll getriggert werden. Klappt soweit auch.
Problem ist aber, wenn die Steckdose "unavailable" wird, weil z.B. die Netzwerkverbindung nicht klappt und dann wieder kommt, dann wird der Trigger auch ausgelöst.
Eine Bedingung hilft mir da ja nicht weiter, weil zu dem Zeitpunkt, wo der Trigger auslöst, ist die Steckdose ja wieder da.
Im Trace sieht das dann so aus.
Code: 
this:
  entity_id: automation.waschmaschine_fertig
  state: 'on'
  attributes:
    id: '1759868544108'
    last_triggered: '2025-10-13T09:33:58.435814+00:00'
    mode: single
    current: 0
    friendly_name: Waschmaschine fertig
  last_changed: '2025-10-14T10:04:03.531143+00:00'
  last_reported: '2025-10-14T10:04:03.531143+00:00'
  last_updated: '2025-10-14T10:04:03.531143+00:00'
  context:
    id: 01K7H2TK2B1VZD0GQ2EGA6GXN0
    parent_id: null
    user_id: null
trigger:
  id: '0'
  idx: '0'
  alias: null
  platform: numeric_state
  entity_id: sensor.waschmaschine_leistung
  below: 5
  above: null
  from_state:
    entity_id: sensor.waschmaschine_leistung
    state: unavailable
    attributes:
      state_class: measurement
      unit_of_measurement: W
      device_class: power
      friendly_name: Waschmaschine Leistung
    last_changed: '2025-10-14T20:28:52.582114+00:00'
    last_reported: '2025-10-14T20:28:52.582114+00:00'
    last_updated: '2025-10-14T20:28:52.582114+00:00'
    context:
      id: 01K7J6JNF6YXN61QVWGSCS51B7
      parent_id: null
      user_id: null
  to_state:
    entity_id: sensor.waschmaschine_leistung
    state: '0.0'
    attributes:
      state_class: measurement
      unit_of_measurement: W
      device_class: power
      friendly_name: Waschmaschine Leistung
    last_changed: '2025-10-14T20:30:04.171012+00:00'
    last_reported: '2025-10-14T20:30:04.171012+00:00'
    last_updated: '2025-10-14T20:30:04.171012+00:00'
    context:
      id: 01K7J6MVCBTBRHWCS1MFB0FF0Y
      parent_id: null
      user_id: null
Man sieht klar "from state unavailable" to state 0.0

Ich möchte jetzt auch nicht noch mehr Automatisierungen, die dann durch das "unavailable" getriggert werden und die andere Automatisierung so lange stoppt und auch keine Automatisierung, die bei "unavailable" einen Helfer setzt, der dann noch als Bedingung abgefragt werden müsste.
Ich denke, zu viele Automatisierungen für ein und die selbe Sache machen es unübersichtlich und nach 6 Monaten weiß keiner mehr, wie das ganze zusammengearbeitet hat.

Hat jemand eine Idee, wie man das sonst abfangen könnte ?
 
Hallo @RudiP,

wie ist Dein WLAN Empfang für die Steckdose?
Notfalls mal einen Repeater dazwischen hängen auf der Strecke um den Empfang zu verbessern. (Test wenn möglich).
 
Zuletzt bearbeitet:
Darum gehts nicht.
Stell Dir vor, nachts um 03:00 Uhr wackelt dein WLAN mal aus irgendwelchen Gründen oder die Verbindung zum Server von denen wackelt mal kurz oder oder oder.
Dann fängt Alexa an zu plärren, weil das der tiefere Sinn hinter dieser Automatisierung ist.
Deswegen muß alles, was nicht eindeutig darauf schließen lässt, das die Waschmaschine fertig ist, ausgeschlossen werden.

Aktuell versuche ich das mittels einem Template zu lösen, habs aber noch nicht getestet.
Code: 
- sensor:
    - name: Waschmaschine Pwr
      unique_id: Waschmaschine_Pwr
      unit_of_measurement: "Wh"
      device_class: energy
      state_class: total_increasing
      state: >
        {{ states('sensor.waschmaschine_leistung')|float(0) }}
Der Gedanke ist, das hier immer "0" geliefert wird, auch wenn der state irgendwas anzeigt, was nicht nummerisch ist.
 
RudiP schrieb:
Der Gedanke ist, das hier immer "0" geliefert wird, auch wenn der state irgendwas anzeigt, was nicht nummerisch ist.
Zum Vergrößern anklicken....

Würde das nicht
RudiP schrieb:
Wenn die Leistung des Steckdose 1 Minute unter 5 Watt ist, dann soll getriggert werden.
Zum Vergrößern anklicken....
auch das auslösen?

Ich würde auch mit einem weiteren Sensor arbeiten, der den realen Wert von sensor.waschmaschine_leistung gibt wenn dieser numerisch ist, und ansonsten den "eigenen" (damit gemerkten), womit unavailable-Zeiten überbrückt werden könnten.
 
Zuletzt bearbeitet von einem Moderator:
Nival schrieb:
Würde das nicht

auch das auslösen?
Zum Vergrößern anklicken....
Soll es ja auch auslösen.
Wenn die Waschmaschine läuft, werden immer mehr als 5 Watt verbraucht. Wenn die fertig ist, sinkt der Verbrauch unter 5 Watt und dann wird ausgelöst.
Dummerweise aber eben auch, wenn von "unavailable" auf "0 Watt" gewechselt wird und DAS muß eben verhindert werden.
Und das macht meines Wissens nach das Template mit dem "float(0)". Wenn der Sensor irgendwas liefert, was nicht in float gewandelt werden kann, wie ein unavailable, dann wird halt 0 ausgegeben.
Die Automatisierung reagiert aber ja nur auf Wechsel. Wenn also immer 0 anliegt, wird die nicht getriggert. Kommt da mal kurz was anderes und dann wieder 0, dann wird getriggert.
Nival schrieb:
Ich würde auch mit einem weiteren Sensor arbeiten, der den realen Wert von sensor.waschmaschine_leistung gibt wenn dieser numerisch ist, und ansonsten den "eigenen" (damit gemerkten), womit unavailable-Zeiten überbrückt werden könnten.
Zum Vergrößern anklicken....
Öhm, schau mal den ersten Post. Da nutze ich ja genau diesen Sensor und es funktioniert aus den genannten Gründen nicht.
 
RudiP schrieb:
Öhm, schau mal den ersten Post. Da nutze ich ja genau diesen Sensor und es funktioniert aus den genannten Gründen nicht.
Zum Vergrößern anklicken....
Missverständnis.

Ich meine (in der template.yaml) sowas:
YAML: 
  - name: "check_numeric"
    state: >
      {% if states('input_text.xyz') | float(1) == states('input_text.xyz') | float(0) %}
        {{ states('input_text.xyz') }}
      {% else %}
        {{ this.state }}
      {% endif %}
und anstelle meines Helfers input_text.xyz eben Deinen sensor.waschmaschine_leistung verwenden.

Dieser Sensor gibt immer und ausschließlich eine Zahl aus, und wenn von sensor.waschmaschine_leistung grade keine Zahl kommt, dann bleibt er bei dem letzten bekannten Zahlenwert.

Also ab von einem initialen unknown, ist klar, könnte man this.state noch auf | float(0) setzen für den Fall.

Aber, war nur ne fixe Idee fürs "hübsch", wenn Deine Lösung schon funktioniert ist ja auch prima :)
 
Ob meine Lösung funktioniert werden die nächsten Tage zeigen.
Deine Lösung hätte einen Vorteil.
Wenn Waschmaschine läuft und sagen wir mal 100 Watt braucht, ist ja eigentlich alles klar.
Wenn jetzt die Steckdose, warum auch immer, die Verbindung verliert, liefert meine Lösung ja sofort 0, Alexa plärt los, das die Waschmaschine fertig ist, was aber ja gar nicht stimmt.
Deine Lösung würde einfach den letzten Wert weiter schicken, bis ein neuer Wert kommt. Das wäre natürlich deutlich besser.
Baue ich gleich mal ein und teste es dann.

EDIT: "this" ist unbekannt. Kann er nix mit anfangen. Hmmm
 
Zuletzt bearbeitet:
Also es scheint soweit zu funktionieren Nival, nur ein Reload "schnelles Neuladen" löst die Automatisierung sofort aus, weil vom Zustand "unavailable" zu "0.0" gewechselt wird.
Mein Code sieht aktuell so aus.
Code: 
- sensor:
    - unique_id: check_numeric_waschmaschine
      name: "check_numeric_waschmaschine"
      state: >
        {% if states('sensor.waschmaschine_leistung') | float(1) == states('sensor.waschmaschine_leistung') | float(0) %}
          {{ states('sensor.waschmaschine_leistung') }}
        {% else %}
          {{ this.state }}
        {% endif %}
Der Vergleich schaut ja nur, ob ein Wert in eine Zahl umgewandelt werden kann. Wenn nicht, wäre der Vergleich "1 = 0", was fehlschlägt und dann "this.state" wieder geben würde, ansonsten halt die Zahl.
Aber was steht in "this.state" drin, das konnte ich noch nicht heraus finden.
 
RudiP schrieb:
Aber was steht in "this.state" drin, das konnte ich noch nicht heraus finden.
Zum Vergrößern anklicken....
Der letzte Wert, den der Sensor hatte, bevor der Vergleich fehl schlug.

Also - ich habe das ja mit einem Helfer umgesetzt.
456 war der Wert des Sensor, dann habe ich abc eingeben in den Helfer, der Vergleich schlägt fehl, der Sensor bleibt bei 456. Dann 789 in den Helfer eingeben, der Vergleich passt, der Sensor wechselt auf 789. Dann wieder xyz in den Helfer eingegeben, Sensor bleibt bei 789.

An dieser Stelle ein "schnelles Neuladen" setzt den Sensor auf unbekannt, da der Helfer keinen numerischen Wert hatte. Den Helfer auf 456 gesetzt, der Sensor wechselt ebenfalls darauf. An dieser Stelle ein "schnelles Neuladen" lässt den Sensor auf 456, da der Helfer den Wert zur Verfügung hatte.

Sieht dann, wie oben beschrieben, so aus:
1760878496160.png

Ich schätze, Dein Waschmaschinensensor liefert dann mit kurzer Verzögerung den Wert, deshalb das unavailabe zwischendrin.


Evtl. könnte man das stattdessen trigger-based machen, und unavailable / unknown als trigger ausschließen, dann sollte es den Wert behalten... :unsure: ja doch, sieht gut aus:
1760879179712.png
Da entfällt das "Unbekannt" bei schnellem Neuladen, wenn der Helfer keinen numerischen Wert hat.

YAML: 
- trigger:
    - trigger: state
      entity_id: input_text.xyz
      not_to:
        - unavailable
        - unknown
  sensor:
    - name: "trigger_check_numeric"
      state: >-
        {% if states('input_text.xyz') | float(1) == states('input_text.xyz') | float(0) %}
          {{ trigger.to_state.state }}
        {% else %}
          {{ this.state }}
        {% endif %}

Okay, eleganter wäre vermutlich, hier schon bei dem Vergleich trigger.to_state.state herzunehmen, aber ich habe keine Lust auf noch nen Neustart jetzt um das zu überprüfen, das überlasse ich Dir :D
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Neueste Beiträge

Letzte Anleitungen

Statistik des Forums

Themen
7.253
Beiträge
70.693
Mitglieder
7.693
Neuestes Mitglied
henry96

Teilen

Zurück
Oben