Stuck on ignoring triggers from unavailable or unknown state

Configuration
1

I have read various other queries on this but I just cannot get my trigger template to work with the trigger.from_state condition in the value template. I do not want to use this condition on other triggers I use in my automation so I can’t move it out of the trigger value template into the conditions section.

The trigger in the value template is meant to trigger lighting when the light sensor drops below a certain level but it triggers again when the sensor is already below the threshold when the sensor returns from an unavailable or unknown state. I only want it to trigger when the sensor level drops from a valid higher level across the threshold.

I must be making a mistake in the code but when the “trigger.from_state.state not in [‘unavailable’, ‘unknown’ ]” is in the trigger value template, it never triggers.

alias: Test trigger
description: ""
triggers:
  - trigger: template
    value_template: >-
      {{ states('sensor.lightsensor_illuminance') | is_number and
      states('sensor.lightsensor_illuminance') | float < 150 and
      trigger.from_state.state not in ['unavailable', 'unknown' ] }}
conditions: []
actions: []
mode: single
2

You don’t get a trigger state object until after the trigger completes. i.e. after your trigger template is evaluated. So trigger.from_state.state will always be unknown in your template

Try this instead:

alias: Test trigger
description: ""
triggers:
  - trigger: numeric_state
    entity_id: sensor.lightsensor_illuminance
    below: 150
conditions: 
  - condition: template
    value_template: "{{trigger.from_state.state not in ['unavailable', 'unknown' ] }}"
actions: []
mode: single
3

Thanks I was not aware about the trigger state object.

Now that I am trying the way you suggested I am coming against another issue. The trigger.from_state.state is returning the previous numeric status of the sensor but where it has been offline it is returning nothing at all rather than the expected unavailable (or unknown).

If I looked at the previous state in “states” it was unavailable but this is not being returned. I have tried adding “None” and “none” and even “” but the test is never true.

If I change the test to a numeric function it works unless there is the nil return when I get the error message “Error: In ‘template’ condition: UndefinedError: ‘None’ has no attribute 'state’”

4

Try this

  - condition: template
    value_template: "{{trigger.from_state.state not in ['unavailable', 'unknown' , ''] }}"
5

That is just the same and that test is seen as true.

6

Share the exact code you are using (all the triggers and conditions sections of your YAML)

7

The exact code I am using is the trigger code suggested by Tom_I above. I have nothing else added as I do not want anything else to interfere with the trigger problem.

8 
  - condition: template
    value_template: "{{ trigger.from_state.state | int(none) is not none }}"

Or simply this:

  - condition: template
    value_template: "{{ trigger.from_state.state | is_number }}"
9

Maybe I’m missing something obvious, but why isn’t not_from: available in a numeric_state trigger?

10

The is_number condition when there is no previous numeric status returns:

Error: In ‘template’ condition: UndefinedError: ‘None’ has no attribute ‘state’

11

That error message implies the trigger object doesn’t exist or it does but has no properties.

How are you testing the automation?

Please post the automation’s trace when the sensor’s previous value is not a number. Download the trace file and copy-paste its JSON contents, ensuring its formatting is preserved.

The trace file’s details will help expedite a solution.

NOTE

If you need instructions for downloading and posting a trace file, they are available here.

12 
alias: Test trigger
description: ""
triggers:
  - trigger: template
    value_template: >-
      {% set last_val = states('sensor.lightsensor_illuminance')|float %}
      {% if is_number(last_val) %}
      {{ states('sensor.lightsensor_illuminance')|float < 150 }}
      {% endif %}
conditions: []
actions: []
mode: single

I think that this might work.

13

What leads you to believe last_val will contain the sensor’s last (previous) value?

Because the states() function will return the sensor’s current value. There’s no function designed to return an entity’s previous state value.

14

It should attempt to set the value of the sensor right before it checks the value of the sensor. You can try it and see if it works for you.

15

The states() function gets the entity’s current state value from the state machine.

The trigger object can contain previous/current state values but not the states() function.

16

I made a helper number and a test automation for this. I used the developer tools to set the value of the number to a string so I could test seeing not a number. It seemed to function as the OP described their use case. But there could still be issues because I didn’t test it extensively.

17

After hours of trying different things I seemed to have solved the issue.

I have modified the condition to:

{{trigger.from_state.state not in ['unavailable', 'unknown', null ] }}

It is the addition of the null without any quotation/apostrophe marks that makes it work. I could see the previous trigger state was null in the trace download. Using quotation/apostrophe marks on null similar to “unavailable” and “unknown” prevents the condition from working. I have no idea why one state needs quotation/apostrophe marks and the other states don’t.

1 Like
18

  • Your condition contains a reference to trigger.from_state.state.

  • The condition I suggested contains a reference to trigger.from_state.state.

Both templates reference the exact same property of the trigger object.

Assuming the exact same testing scenario, it’s seemingly impossible for one version to report “None has no attribute state” but not the other version.

Pop this into the Template Editor and the result is not an error message but false.

{{ none | is_number}}

none is Jinja2’s representation for the null object.

The fact the trace revealed that trigger.from_state.state had a state property (with a value of null) casts suspicion on the earlier test that reported it did not even have a state property.