The sensor is power-saving because it powers up, when the reed switch is triggered, sends the state of the switch to ha and then shuts down after 30 seconds.
My aim is to create a notification when the window is open longer than 10 minutes. This fails because the sensor is “unavailable” after 30 seconds.
The solution might be to store the last state and to recall this state after 10 minutes, but how can I do this in an automation?
Most probably there have been some comparable issues dealt with here, but I did not find an approriate solution.
One way to ‘store the last state’ is using a triggered template binary sensor, triggering an update only on the change to ‘on’ or ‘off’ instead of all state changes. Then you can base your automation off of that sensor
I added the last 10 lines of this yaml-code, but siince then I am getting errors and cannot restart ha. Does anyone see the wrong code?
template:
# Berechnung des Zisternen-Füllstands in Prozent; time_pattern sorgt dafür, dass nur alle 5 Minuten eine Messung erfolgt (alle durch 5 teilbaren Minuten)
# die unique_id der beiden Sensoren habe ich selbst vergeben, da es ohne diese Angabe zu Fehlermeldungen kam
- trigger:
- platform: time_pattern
minutes: "/5"
sensor:
- name: "Fuellstand_Zisterne_in Prozent"
unique_id: fuell_103
unit_of_measurement: "%"
state: >
{{ ( states('sensor.fuellstand_zisterne_geglaettet') | float | round(3) / 3.1 * 100) | float | round(0) }}
- name: "Fuellstand_Zisterne_in_Liter"
unique_id: fuell_102
unit_of_measurement: "l"
state: >
{{ ( states('sensor.fuellstand_zisterne_geglaettet') | float | round(3) / 3 * 5200) | float | round(-1) }}
# stores the state of binary_sensor.reed_switch in the entity "FensterWC_Zustand" as soon as reed-switch state changes
- platform: state
entity-id:
- binary_sensor.reed_switch
from: "unavailable"
to: "off"
binary_sensor:
- name: "FensterWC_Zustand"
state: {{ states('binary_sensor.reed_switch') }}
You need to declared your second trigger and indent it properly:
template:
# Berechnung des Zisternen-Füllstands in Prozent; time_pattern sorgt dafür, dass nur alle 5 Minuten eine Messung erfolgt (alle durch 5 teilbaren Minuten)
# die unique_id der beiden Sensoren habe ich selbst vergeben, da es ohne diese Angabe zu Fehlermeldungen kam
- trigger:
- platform: time_pattern
minutes: "/5"
sensor:
- name: "Fuellstand_Zisterne_in Prozent"
unique_id: fuell_103
unit_of_measurement: "%"
state: >
{{ ( states('sensor.fuellstand_zisterne_geglaettet')
| float(0) | round(3) / 3.1 * 100) | float | round(0) }}
- name: "Fuellstand_Zisterne_in_Liter"
unique_id: fuell_102
unit_of_measurement: "l"
state: >
{{ ( states('sensor.fuellstand_zisterne_geglaettet')
| float(0) | round(3) / 3 * 5200) | float | round(-1) }}
# stores the state of binary_sensor.reed_switch in the entity "FensterWC_Zustand" as soon as reed-switch state changes
- trigger:
- platform: state
entity-id:
- binary_sensor.reed_switch
from: "unavailable"
to: "off"
binary_sensor:
- name: "FensterWC_Zustand"
state: {{ states('binary_sensor.reed_switch') }}
Yes, thank you, I got it working now.
The state is stored when opening the window, thats what I wanted to achieve. But it is even stored although the window is closed in the meantime. I will play around with the “state” - platform to solve this.
Thanks for yout help, I always need these initial ideas.
Your code is working fine, thanks for this!
And I tried out what happens within the 30 seconds: Its a pity, but the state change is not registered by the template binary sensor. So the window is closed in real life, but is shown as still open in ha.
If it’s an problem for you, the from: is optional… I left it in because you had it in your original. You can use not_from: instead to reject specific from_states like “unknown” but capture those from “unavailable”, “on”, and “off”. That should cover the quick open/close issue.
They are not shown explicitly anywhere in the UI, but their existence and use is documented. You have to use yaml to use them. However, you do not need to edit your automation entirely in yaml if you don’t want to… you can edit individual triggers and/or conditions in yaml while using the UI editor by clicking the 3-dot/kebab menu for the individual trigger element and clicking “Edit in YAML”.
I’m aware of the “Edit in YAML”, my normal flow is building the basics using the GUI and then fine tune using the YAML. But I wasn’t aware there’s more options but what the GUI offers.
My fault … The typical RTFM problem one runs into if being too enthusiastic about GUI driven solutions.
This “not_from” really allowed me to get rid of some ugly YAML lines.