How to store and recall state of windows sensor in automation

Configuration
1

I am using a tinkered window sensor. It is a copy of the github-project of gadjet. (GitHub - gadjet/Window-Door-sensor-Version-5: Version 5 of the Window/Door sensor project this time with ultra low current consumption)

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.

Can anybody help?

2

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

3 Likes
4

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') }}
5

These are the comments which Studio Code Server shows me, when I open the configuration.yaml with this editor:

  • platform: state Missing property “entity-id”
    entity-id: Property entity-id is not allowed
    …
    state: Incorrect type. Expected “string”
6

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') }}
7

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.

8

My understanding of your original post was the following:

Window opens > sensor wakes up and pushes 'open/on' state > 30 sec > sensor goes 'unavailable'
Window closes > sensor wakes up and pushes 'closed/off' state > 30 sec > sensor goes 'unavailable'

That can be addressed as follows:

  - trigger:
      - platform: state
        entity-id:
          - binary_sensor.reed_switch
        to:
          - "on"
          - "off"
        from: unavailable
    binary_sensor:
      - name: "FensterWC_Zustand"
        state: "{{ trigger.to_state.state }}"

Regarding the from: value… what happens if the window is opened but reclosed within the 30 second window before it becomes unavailable?

9

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.

Work in progress…

10

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.

  - trigger:
      - platform: state
        entity-id:
          - binary_sensor.reed_switch
        to:
          - "on"
          - "off"
        not_from: unknown
    binary_sensor:
      - name: "FensterWC_Zustand"
        state: "{{ trigger.to_state.state }}"
1 Like
11

That works indeed, yeah! You are ingenious, thank you for your kind help!
I never thought this to be so easy

12

Dammit … am I too dumb to reach for the “not_from” or is that available it using YAML only?

13

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”.

14

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. :slight_smile:

1 Like