Stupid templating question I'm having a mental block with

Configuration
21

It tests for from_state because from_state is used in the test for from_state. :point_right: :point_left:

I can confirm that changing an entity’s name via the Entity Registry will produce a state-change. I used this automation:

- alias: 'test 99'
  trigger:
    platform: state
    entity_id: light.test
  action:
    service: light.toggle
    entity_id: light.patio

and changed the light’s name from Test to Tester (via Entity Registry) and it caused the automation to trigger and toggle the patio light.

I’m still adjusting to Home Assistant’s way of doing things. In Premise, I can selectively trigger off any one of an entity’s properties (changes to a light’s powerstate, brightness, name, description, platform, etc). Alternately, I can trigger off all of them (changes to any property). I never used this kind of ‘all properties’ trigger … but this is the default for Home Assistant.

22

No, that would be silly. It tests that trigger.from_state is not None (and the same for trigger.to_state) so that it can test if trigger.from_state.state != trigger.to_state.state without causing an error. You can’t reference trigger.from_state.state if trigger.from_state is None (i.e., does not contain a State Object.)

That’s not true, at least for a State Trigger. If you don’t specify the from: and to: options, then it is true in that scenario. But if you specify either from: or to: or both, then it will only trigger if the “state” actually changes and meets the specified conditions. (I quote “state”, because, unfortunately, in HA, the term “state” is overloaded. It is used to refer to an entire State Object, including attributes, as well as a State Object’s state field. The term attribute, BTW, is also overloaded. Leads to much confusion. :frowning:)

23

just as an example for regular Hue motion binary_sensors with a few attributes:

35

which makes it quite necessary to rules these out…at least when a trigger only for state: 'on' is desired

24

That’s exactly the point. Without specifying from: or to: it defaults to reporting changes for all of the entity’s properties. This is the opposite of how Premise works where I’d have to explicitly specify that I want to listen for changes to all properties. The default is to listen for changes to a single chosen property (like a light’s powerstate or brightness, etc) … and you don’t have to test if some property or object exists or not. It’s a different approach and, because I have years of experience with Premise, I find myself forgetting that Home Assistant is a different beast.

I have to agree with you that the nomenclature’s choices are, to be charitable, unfortunate.

In Premise, the nomenclature adheres to tried-and-true Object-Oriented language. An ‘entity’ is called an ‘object’ and an object has properties (and methods). The value of a light’s brightness property is 0.75 and the value of its powerstate property is true. Unlike Home Assistant, there’s no catch-all term called state (which can represent different things depending on the entity). Anyway, just mentioning it to explain why I’m having a little trouble making the conceptual shift to Home Assistant.

25

Yep, I can certainly understand that. Luckily I only used SmartThings before HA, so anything was way better! :wink:

You hide it well (considering your very helpful contributions on this site)!

26

Probably not all that well in this thread … where I effectively poo-pooed the need for the ‘belt and suspenders’ condition. Sorry about that. However, now that I have a better understanding of what a (unconstrained) State Trigger listens for (i.e. pretty much everything), that condition is looking mighty reasonable to me now.

1 Like