Trigger.to_state.state not anymore working

Tags: #<Tag:0x00007f738ffc8a00> #<Tag:0x00007f738ffc88c0>

Hi,

I have a little automation which warns me if the temperature in a given room is too high or too low. It worked smoothly since a couple of months, though since a few weeks, the message text is not anymore updated with the temperature itself. Has something changed with one of the last updates to Home Assistant?

1. Correct message when being triggered (example: temperature at 19 degrees):
“Too low temperature of 19°C. Are the windows open?”

2. Since a few weeks I get instead:
“Too low temperature of unavailable°C. Are the windows open?”

3. And here is the template code I had been using so far:

  - service: persistent_notification.create
    data_template:
      title: "Room too cold:"
      message: "Too low temperature of {{ trigger.to_state.state }}°C. Are the windows open?"

4. Important: The sensors DO work: They report their numbers as expected in the UI and the message is triggered rightly upon the sensor changing its temperature to the trigger value. So the issue is not the sensor not being available, but the template not being able to show the value of the sensor.

Anyone having a clue why trigger.to_state.state is not anymore working? I searched for the update log, could though not find anything of relevance pointing me to a new code being needed.

Thank you so much as always!

Cheers
Thomas

Please post your entire automation. Without that we can only guess at what might be wrong.

It’s possible that the sensor that triggers this automation never reported a state of unavailable in the past, but is doing that now (and possibly only momentarily). So trigger.to_state.statemay not be the culprit, it’s simply reporting the sensor’s state.

But, like pnbruckner said, it’s all guesswork until you provide us with more information (the full automation and the configuration of whatever entities that trigger it).


EDIT
I’m using 0.113 and can confirm that there’s nothing wrong with trigger.to_state.state.

Apologies for the late reply & thank you for offering your help! Here is the full automation which is giving me the headache. Any help or hint is highly appreciated:

####################################################################################
# Temperaturwarnung (zu niedrig)
####################################################################################
     
- id: '9'
  alias: Warnung zu niedrige Temperatur
  trigger:
  - for:
      minutes: 5
    platform: template 
    value_template: "{{ (states('sensor.temperature_19')|int < 18) or (states('sensor.temperature_2')|int < 18) or (states('sensor.temperature_22')|int < 18) or (states('sensor.temperature_31')|int < 18) or (states('sensor.temperature_34')|int < 18) or (states('sensor.temperature_37')|int < 18) or (states('sensor.temperature_40')|int < 18) or (states('sensor.temperature_43')|int < 18) or (states('sensor.temperature_50')|int < 18) or (states('sensor.temperature_55')|int < 18) or (states('sensor.temperature_58')|int < 18) or (states('sensor.temperature_61')|int < 18) or (states('sensor.temperature_64')|int < 18) or (states('sensor.temperature_67')|int < 18) or (states('sensor.temperature_70')|int < 18) }}"    
  action:  
  - service: persistent_notification.create
    data_template:
      title: "Raum zu kalt:"
      message: "Der {{ trigger.to_state.attributes.friendly_name }} berichtet eine zu niedrige Temperatur von {{ trigger.to_state.state }}°C. Sind die Fenster offen?"

If one of the sensors in your template trigger changes to ‘unavailable’, that will cause the template to become true, because 'unavailable'|int results in the value 0, which is less than 18. If you don’t want a sensor, whose state has temporarily become “unavailable” to trigger your automation, then provide a different default for the int filter. (The “default” default value is zero.) E.g.:

states('sensor.temperature_19')|int(18) < 18

Now, if the state of sensor.temperature_19 becomes “unavailable”, the int filter will return 18, and since 18 is not less than 18, it won’t be true.

The other issue with your template trigger is that it will only fire for the first sensor that changes to a value less than 18. If another sensor changes to a value below 18, while the first one stays under 18, the template will still render true, so the trigger won’t fire again. For a template trigger to fire again the template has to change from true to false and back to true.

2 Likes

Hi Phil,

Ah, that is a smart approach to avoid the “unavailable” state to trigger the automation. Thank you, I am baking that in.

And for the other piece: Never thought about this. I need to think through this; maybe I split up the automation into 1 automation per sensor, or I find a way to shift after triggering back to “false”. Enough food for thought, I think this will help me finalizing this piece of code.

Thanks again!

Cheers
Thomas

Would a Numeric State Trigger reject a state-change to unavailable or would it also convert it to 0?

- id: '9'
  alias: Warnung zu niedrige Temperatur
  trigger:
  - platform: numeric_state
    entity_id:
    - sensor.temperature_19
    - sensor.temperature_2
    - sensor.temperature_22
    - sensor.temperature_31
    - sensor.temperature_34
    - sensor.temperature_37
    - sensor.temperature_40
    - sensor.temperature_43
    - sensor.temperature_50
    - sensor.temperature_55
    - sensor.temperature_58
    - sensor.temperature_61
    - sensor.temperature_64
    - sensor.temperature_67
    - sensor.temperature_70
    below: 18
    for:
      minutes: 5
  action:  
  - service: persistent_notification.create
    data_template:
      title: "Raum zu kalt:"
      message: "Der {{ trigger.to_state.attributes.friendly_name }} berichtet eine zu niedrige Temperatur von {{ trigger.to_state.state }}°C. Sind die Fenster offen?"

So two things.

First, by changing to that it’s effectively handling each sensor separately, which the template trigger as written does not do. (It could be broken out into multiple template triggers, but that would just be silly.)

Second, a numeric state trigger will only fire on a state that can be interpreted as a number. If it can’t be interpreted as a number, that “resets” the trigger (i.e., forgets that it already fired, if it had, and is then primed to fire on the next state that it can interpret as a number and meets the conditions – i.e., in this case below 18 for 5 minutes.)

Also, I should mention, the trigger maintains an “already fired” flag, and timer, for each entity. So writing it that way is exactly the same as if each entity was in its own numeric state trigger with the same parameters.

I have resorted to using the “event” trigger by default whenever I need to trigger on more then one entity. My primary goal was to be able to use wildcards (actually, as with most of the stuff I learn here, I read that solution in other topic, suggested by pnbruckner).

Maybe this would also help in this scenario?

Honestly I don’t think that’s a good habit to get into. It’s not multiple entities that make using existing triggers problematic. It has more to do with how you want an automation to trigger, but even more so on the behavior of the entities used in the trigger.

Pretty much all existing trigger types are ultimately based on a state_changed event. But in some cases how they respond to those events are not quite what is needed. So by using the state_changed event directly in an automation you’re effectively building your own, custom trigger.

As far as if it would help here, that’s not quite clear, because I’m not sure the requirements are quite clear either.

Thanks for the explanation.

I wonder if tombaloo is aware of that.

I can’t pretend to know how they want this to work, but if I were faced with a similar situation, I would want each temperature sensor to be an independent trigger.

That’s how I’d want each trigger to behave: unavailable doesn’t cause the action to be executed but does reset the trigger.

Well I did say…

So possibly.


I guess it depends. This effectively defeats the “crosses the threshold” behavior many want & expect. E.g., if the value goes from 17, to unavailable, to 17, that will cause another trigger on the transition back to 17 (which is below 18.)

If it were me, I’d want the numeric state trigger to 1) completely ignore non-numeric values (possibly writing a warning), and 2) only trigger when a threshold is actually crossed (i.e., requires having seen a numeric value that does not meet the criteria and then a numeric value that does meet the criteria), neither of which it does today.

Good point. I agree it’s non-standard behavior to re-trigger after crossing the threshold. I guess there may be applications where this behavior is an advantage. However, I suspect this is not one of them; it would be seen as an unexpected source of repeated triggers that produce excess notifications.

I’ve considered for a while proposing a change to the numeric state trigger along the lines I described above. However, although this would probably make it work the way people expect, and might fix some odd behavior people never figured out, it might also break automations that depend on the way it currently works. Since I’ve had enough things to do I just never went there.

I did notice (finally a light went up in my head :-)) This is far more complex (yet exciting) than I had thought. I think I definitely will go along the path of having multiple triggers along the lines from Phil and Taras. For now I will enjoy the next couple of hot days, yet once the thunderstorms arrive (or wave #2 hits us…), I will be implementing this.

THANKS again. Super helpful!