2021.7: sensors in numeric_state above/below

[Troon]

The release notes say:

Referencing other entities in triggers and conditions

A small, but possibly helpful, change to our script and automations. You can now reference other entities for the above/below values of numeric state triggers and conditions. Both sensors and number entities can be used.

This doesn’t work as I expected, as I found out when I woke up to a cold hot water tank this morning. I created a couple of test automations to check the behaviour:

- alias: Test on
  id: b9fd928a-8749-428c-92d2-1540da5cb424
  trigger:
    - platform: numeric_state
      entity_id: input_number.test_sensor
      below: input_number.test_threshold
  action:
    - service: homeassistant.turn_on
      entity_id: input_boolean.test_trigger

- alias: Test off
  id: 34535ac7-e711-4882-8f6f-90948093c1ea
  trigger:
    - platform: numeric_state
      entity_id: input_number.test_sensor
      above: input_number.test_threshold
  action:
    - service: homeassistant.turn_off
      entity_id: input_boolean.test_trigger

and a card:

The trigger fires as expected when the sensor value changes to cross the threshold value, but if it’s the threshold value that moves, the trigger doesn’t fire.

This seems a bit pointless to me — was that the intended behaviour? I’ve reverted to a template trigger on my hot water automation.

[Tinkerer (aka DubhAd on GitHub)]

Have you opened an issue about that? It may well be a bug.

[koying (Chris B)]

I’m not sure changing the threshold value is meant to trigger the automation, really.
At least, it’s not explicit in the note.

[Troon]

@Tinkerer

Have you opened an issue about that?

I have now. 2021.7: changes to entities in numeric_state above/below are ignored · Issue #52784 · home-assistant/core · GitHub

@koying

I’m not sure changing the threshold value is meant to trigger the automation, really.
At least, it’s not explicit in the note.

It isn’t explicit, no. However, I struggle to see the benefit of allowing a variable threshold value if changes to it are ignored.

[koying (Chris B)]

It’s not that they would be ignored, but it’s not either that altering it should trigger the automation.
Next time the actual trigger is activated, i.e. the next time the state changes, the latest value will be used

[Troon]

If that is the intent, it should be made crystal-clear in the documentation. People get confused all the time about numeric_state only firing if the entity crosses the static threshold — this change makes it even more confusing as the values cross (“moving the goalposts”) but the trigger doesn’t fire.

[koying (Chris B)]

I don’t know, just thinking out loud here

[tom_l]

@Troon

if it’s the threshold value that moves, the trigger doesn’t fire.

Yep I noted the same thing when helpers were introduced for conditions. Made a post that I cant find. Even mentioned it in the beta release but got no response. I went back to using templates.

EDIT: I remembered incorrectly, this was about triggers.

2021.2: Z-Wave... JS!

I’ve been playing around with the newly added ability of using input numbers for threshold values in numeric state triggers. trigger: # - platform: template # OLD CONFIG # value_template: "{{ states('sensor.cpu_temperature')|float >= states('input_number.rack_fan_on_temp')|int }}" - platform: numeric_state # NEW CONFIG entity_id: sensor.cpu_temperature above: input_number.rack_fan_on_temp However it looks like I will be sticking with the template trigger as this monitors bot…

[Troon]

Thanks. I’m not so sure it is an edge case, as it suggests two values can be reliably compared. In my application, I monitor the “state of charge” of my hot water tank, and have a “target” schedule to decide when the boiler should run.

I had ass-u-med that using the target as the above/below would work, triggering when I adjusted the target up to above the current status. It doesn’t, though, so back to templates here too for now.

[tom_l]

I agree. Ignore my old comment.

[petro]

It seems that a listener should be created for all entities involved. If not, seems pretty useless IMO. Might be a harder change than normal though. Either way, a issue is a good first step.