WTH does "unavailable" to "0.0" trigger the numeric state

Archive Month of "What the heck?!" 2022
1

My trigger is set-up for a numeric state below 4. When the state goes from “unavailable” to “0” it fires the automation. I have a template condition setup to check the from_state which prevents the automation from going forward. Not the most user friendly.

Thinking that any non-number from_state should not trigger the numeric state. Only number to number.

from_state:
    entity_id: sensor.sonoff_plug_8_current
    state: unavailable
  to_state:
    entity_id: sensor.sonoff_plug_8_current
    state: '0.0'
2

Don’t forget to vote yourself. I have trouble with this too, mostly in threshold sensors. Maybe it is a bug because I did not experience problems with this before.

3

Huh. I actually have a new issue with numeric_state triggers myself - I wonder if it’s related.

I’ve had some automations set up for years that never triggered any warnings and now I’m getting warning on startup and automation reload. Automation seems to run correctly though.

WARNING (MainThread) [homeassistant.components.homeassistant.triggers.numeric_state] Error initializing '[Presence] Someone Heading Home' trigger: In 'numeric_state' condition: entity proximity.jphone_home state 'not set' cannot be processed as a number

I haven’t found anything in the release notes related to this though.

4

Warnings about invalid triggers were added recently, so it’s always been bad. You’re now just getting information about it.

1 Like
5

Ah, well that would explain it then. A case of no news was not good news! Guess I missed where that changed.

I understand what’s happening (proximity sensor can be ‘not_set’ which is not numeric), I guess I just always assumed the numeric_state trigger kind of accounted for non numeric states on it’s own. And now that I’ve tested it, I see I’m also getting the warnings if the value goes non-numeric during runtime.

Any suggestions on how to accomplish this automation and avoid the warnings? I thought about using a template sensor overload the proximity sensor that always has a numeric state, but if I provide -1 or 0 as a default state that could result in undesired triggers. Other than the warnings it works fine. I’m not getting the false triggers that OP is because of the condition, so that isn’t an issue.

trigger:
    - platform: numeric_state
      entity_id:
        - proximity.jphone_home
        - proximity.sphone_home
      below: 4 # km
  condition: "{{ state_attr(trigger.entity_id,'dir_of_travel') == 'towards' }}"
6

I’d just ignore the warning, it’s a warning after all and not an error. You can filter it out with logger as well. FWIW, I have a ton of warnings in my logs that I ignore because it doesn’t impact the system.

7

I’ve always been stupidly anal about configuring things to avoid warnings and errors on startup and reloads but I think I’m going to have to take your advice on this one and tap out with a log filter because I can’t think of any way to avoid it here. Thanks for looking petro!

8

You can avoid it with a template, but what’s the point. It’s not stopping the automation from triggering.

- plaftform: template
  value_template: >
    {% set entities = 'proximity.jphone_home', 'proximity.sphone_home' %}
    {{ expand(entities) | selectattr('state', 'is_number') | selectattr('attributes.dir_of_travel', 'eq', 'towards') | list | count > 0 }}
9

I’d have to duplicate the automation for each entity to use a template trigger like that. Right now it’s a parallel mode with trigger.entity_id references in the action. So filtering the log warnings it is!

I am curious now if numeric_state triggers could be improved to intrinsically ignore non-numeric states now though.

Also it has never dawned on me that you can create an actual list without using brackets. For some reason I’ve always done this {% set entities = ['proximity.jphone_home', 'proximity.sphone_home'] %}

Always something new to learn.

10

You can get the triggering entity out of the trigger, same way. Automation Trigger Variables - Home Assistant

However it might require you to move the template into a template sensor that outputs the count to trigger on both people.

You could also just split out the triggers and still use trigger.entity_id

- plaftform: template
  value_template: >
    {{ expand( 'proximity.sphone_home' ) | selectattr('state', 'is_number') | selectattr('attributes.dir_of_travel', 'eq', 'towards') | list | count > 0 }}
- plaftform: template
  value_template: >
    {{ expand('proximity.jphone_home') | selectattr('state', 'is_number') | selectattr('attributes.dir_of_travel', 'eq', 'towards') | list | count > 0 }}
1 Like
11 
- plaftform: template
  value_template: >
    {{ expand('proximity.jphone_home') | selectattr('state', 'is_number') | selectattr('attributes.dir_of_travel', 'eq', 'towards') | list | count > 0 }}

Well dang, dunno why I couldn’t think of this. Everything remains the same except the condition is redundant now.

Guess I was just really stuck on using numeric_state trigger. I actively try to avoid template trigger if I can for no particular logical reason. I just counted 'em and I only have 10 template triggers in a total of 771 automations.

Anyway, the kick in the ass to the right solution is very much appreciated. My anal retentiveness can rest a little easier now.

12

If you take the time to learn templates you can reduce that 771. I only have 56 automations. They are all parallel and act upon different entities. It does force me to have more scripts though at 95. Either way, my entire house is automated and the overhead for fixing things is pretty low, but everything is templated.

1 Like