State triggers: Add a shorthand to only conside "value" state changes

Feature Requests
1

The state trigger is a cumbersome one.

Take a plain

     - platform: state
       entity_id: sensor.foobar

  1. It will trigger both on state changes, obviously, but also on attribute changes.
    Although it’s documented, it’s probably not what the default should be.
    The “workaround” is also documented: add any of “to/from/not_to/not_from”, even with an empty value.

  2. It will also trigger on “unavailable/unknown” states.
    Although technically logical, you probably don’t want any of your automations (besides technical ones) to trigger on an hiccup.
    A workaround is to write something like

     - platform: state
       entity_id: sensor.foobar
       not_from:
         - unavailable
         - unknown
       not_to:
         - unavailable
         - unknown

which is cumbersome, or to code lengthy templates, which not the most efficient, anyway. I don’t even consider UI, here.

Both also makes so that you cannot trigger only on any attribute changes of “real” values.

Not the most obvious when the expected result for a newcomer would just be: I want a trigger when my binary sensor goes from “on” to “off” and vice-versa :wink:

My suggestion would be to add a switch to the state platform trigger to only consider “value” state changes, e.g.

     - platform: state
       entity_id: sensor.foobar
       real_state_only: true

that would ignore “unavailable/unknown” when considering the state change.

2

(Disclaimer: I haven’t tested this particular combination I’m about to propose since I don’t trigger on attribute changes. However the condition definitely works)

Hi @koying would adding

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

when your trigger is set to this

- platform: state
  entity_id: sensor.foobar

accomplish what you need?

I’m not 100% sure whether the trigger.from_state.state will be captured without a from in your trigger though.
Technically, it should then allow you to trigger on attribute changes, but only on “real” states.

3

That works (although already quite verbose and not newcomers-friendly) if you have only one trigger (or only state ones), but becomes cumbersome (again) if you have multiple, including non-state ones.

Question is not really “can we do it?”. Us, veterans, know we can, but how to do it in a straightforward way, both to be newbie friendly, and to avoid walls of repetitive code :wink:

One of the problem is that you do, willingly or not, if you don’t add code to the trigger…

4

I don’t - all my state triggers have to/from (or both) defined, but I don’t want to derail this thread.

Back on track, this FR might be a duplicate of this, but I’ll leave it up to you to decide whether it is or not.

There is also this related WTH which was resolved by the addition of has_value, though I don’t believe this is exposed in UI.

5

Yep, it is :slight_smile:

1 Like
6

for the record, this functionality is provided. just add

 to:

to the trigger, and it will only trigger on state changes and not on attributes changes.

quoting the docs:

If you want to trigger on all state changes, but not on attribute changes, you can to to null (this would also work by setting from, not_from, or not_to to null):

automation:
  triggers:
    - trigger: state
      entity_id: vacuum.test
      to:
7

I know, I indicated it in point 1) :wink:
For the record, it will also trigger on “unknown/unavailable” that way.

1 Like
8

(I missed that line… sorry)

1 Like
9

If you all believe it’s a dup, flag it or close it,

10

We peasants cannot actually close a thread, even our owns, afaik :wink: