Logical difference between 'to on' and 'from off to on'

Configuration
1

I’m just writing an automation to detect motion across three sensors and it occurred to me that both

state:
from: 'off'
to: 'on'

and

state:
to: 'on'

seem to work the same.

Is that correct or am I missing a subtle difference in the useage?

2

Some entities have many states. To on could work from any other state to on.

from off to on only works if the previous state is off and the new state is on.

3

to: 'on' will trigger when the state changes to on regardless of what it changes from (so unknown to on will trigger)

to: 'on'
from: 'off'

Will only trigger if the previous state was off (so unknown to on will not trigger)

4

The 1st is only activated if the state is from ‘off’ to ‘on’, the 2nd doesn’t look at the from state. It could also trigger from an ‘unavailable’ to ‘on’.

5

Thanks!

Obvious really. I guess because I don’t have any entities with more than two states I didn’t consider it.

7

So this would be preferable for a two state device then.

8

Yes, I have a light which is on or off, so a two state, but if I remove the power they will become unavailable. So a two state can also be a three state. :wink:

9

I’ve also noticed that when using Amazon Music with a media player (such as Chromecast), the state to ‘playing’ is triggered for every song, so you can get triggered from ‘playing’ to ‘playing’ which can be confusing!

10

At least on Node-RED it can also trigger from “on” to “on”, (yes, I wrote that right) it happens when other properties change, but not the status.

11

Are you sure?
Can it be reproduced without using Amazon Music (as I don’t have one)?

12

I will have to try to see if I can duplicate it. Mostly I don’t care so I haven’t payed a lot of attention to it. Will be a couple days before I can look into it.

13

I tried this evening using the Radio Paradise app casting to a Chromecast 2 Video, and I found that it also triggers from playing to playing. In the case of RP, not every song triggers, but when they play their Station Identification blurb. It’s actually worse with RP, when their station id plays, the Chromecast very briefly shows “idle” status so it goes something like playing -> playing -> playing -> idle -> playing -> playing all in short succession.

14

I mean is it possible to reproduce triggering from a state to the same state with something more widespread so others could test?
Because I don’t think is should trigger, but can’t check.

15

@a3a

I can confirm experiencing what you’ve encountered, namely triggering on a state-change where the previous and new states are identical.

I created an automation that should trigger when a light’s state changes from on -> off or from off -> on. Therefore it cannot contain for: and to: because I’m interested in changes occurring in both directions.

- alias: "Turn on/off mantle"        
  trigger:
    platform: state
    entity_id: light.kitchen
  condition:
  - condition: template
    value_template: "{{ trigger.from_state.state != trigger.to_state.state }}"
  action:
    service_template: "script.mantle_{{trigger.to_state.state}}"

I discovered (empirically) I had to include a condition to only accept triggers that occurred when the ‘from_state’ was not equal to the ‘to_state’. Without the condition, the action would execute even when there was no apparent state-change (i.e. on/off or off/on). This was unexpected; I did not anticipate the possibility that it would trigger if the previous and current states were identical.

I believe an important detail is that the action runs either one of two scripts that can either turn the light on or off. Therefore the action controls the light that triggers the automation and that might influence what is considered to be the ‘from_state’ and the ‘to-state’.

16

If that really happens, its’ it a bug?
I mean, having an automation that triggers with

platform: state
from: 'on'
to: 'on'

But is it possible that in your example the light has more that 2 states (unavailable/unknown as someone described above)?

17

No, not in this case, strictly two states: on and off.

The automation is triggered by the kitchen light’s state-changes.

  • When on it runs script.mantle_on. That script has a 4 second delay then turns the mantle light on.
  • When off it runs script.mantle_off. That script simply turns the mantle light off.

Without the condition, I observed unexpected behavior. The mantle light’s operation suggested script.mantle_on was being executed more often than anticipated. With the condition, the mantle light tuned on only as expected (when kitchen light changed from off to on).

It’s possible there’s another explanation for the unexpected result. Nevertheless, the automation definitely did not work correctly without the condition that rejects identical from and to states.

PS
These are MQTT Lights and they use on_command_type: 'brightness'. That means, according to the documentation, Home Assistant only sends brightness commands to turn the light on/off (as opposed to whatever may be specified in payload_on). I’d have to set them to the default on_command_type: 'last' to see if this setting makes any difference in the way the automation behaves.

18

Weird…
So you think it’s something down to the way automation/HA states work?
Apparently you haven’t investigated it further (after adding that condition) and there is no issue on Github about it?

19

it’s not a bug, there are lots of other properties that can change and could legitimately trigger a state trigger. Any of the attributes or other things could cause a state_changed event without changing the main “state” variable. There is some duplicate event suppresion in HA, but I don’t think the developers expect there to be a complete de-duplication happening and it probably is impossible to implement efficiently in an asynchronous event loop like HA uses as its main process control.

I just wish there were “not_from” and “not_to” keys as that would cover many situations that currently require using a much more verbose template trigger.

I would also like to see attribute state triggers, but I understand that template triggers are a powerful escape hatch and really are all that are needed, the other trigger types are simpler syntax but don’t really add functionality, so in some sense the other trigger types could be considered unneeded bloat in the code base. Everything is a trade-off :slight_smile: