Variables in trigger-bases template sensors

[busman]

Trimmed for my question:

@HappyCadaver

template:
  - unique_id: my_unique_id
    triggers:
       ...
    sensor:
      - name: sensor one
    switch:
      - name: switch one

I understand the YAML allows this, and thus it doesn’t make sense to have “this” global. But I’m trying to get a clear understanding:

1. What was the use-case in mind to allow multiple sensors to share a trigger? Is there an advantage of this vs. having the switch defined separately and use the same trigger or (perhaps more likely) have the switch trigger off of sensor.sensor_one state change?

2. Can a template in the switch: block reference updated states('sensor.sensor_one')? Is there an order of processing of the various entity domains listed?

3. I guess this is easy to test, but does using unique_id on the config block and no unique_id in the entity block result in _1 and _2 unique ids?

I know this has been discussed elsewhere but I still find it unintuitive that keys of attributes work as (and thus override) variables of the same name. (When I want to reference an attribute multiple times I define it in variables.)

[petro]

@busman

What was the use-case in mind to allow multiple sensors to share a trigger?

1 source updates multiple entities. Rest, command_line, snmp, file, etc.

@busman

Is there an advantage of this vs. having the switch defined separately and use the same trigger or (perhaps more likely) have the switch trigger off of sensor.sensor_one state change?

more triggers, things moving through the event loop.

@busman

Can a template in the switch: block reference updated states('sensor.sensor_one')? Is there an order of processing of the various entity domains listed?

yes, but it will likely be inconsistent.

@busman

I guess this is easy to test, but does using unique_id on the config block and no unique_id in the entity block result in _1 and _2 unique ids?

there’s no such thing as _1 _2 unique ids, I’m assuming you’re mixing this up with entity_ids?

[busman]

@petro

yes, but it will likely be inconsistent.

So, by inconsistent it means you can’t depend on the behavior? Therefore, don’t reference the other entities.

@petro

there’s no such thing as _1 _2 unique ids, I’m assuming you’re mixing this up with entity_ids?

No, I meant when you do a config-level unique_id. I always add mine to the sensor block, but then saw that example where it was at the config-level only. Maybe that was just an incomplete example?

template:
  - unique_id: my_unique_id
    sensor:
      - name: sensor one
    switch:
      - name: switch one

where the entity doesn’t have a unique id what ends up on the entities if they share the config-level one. The docs says for the config-level one: “This is prefixed to all unique IDs of all entities in this block.”

[petro]

Then those entities don’t have a unique_id.

[busman]

Yeah, I should have just tested… Thanks!

[slimak]

@busman

What was the use-case in mind to allow multiple sensors to share a trigger?

I think I have a good example where this works well: a Modbus sensor that reads a large amount of data at once (say, battery data + solar panel data). It’s then very natural for two template sensors to be under a single state trigger for that Modbus sensor.

[HappyCadaver (Rick Furtado)]

@busman

Maybe that was just an incomplete example?

It is a very incomplete example, I was just trying to show maxym that you can have multiple entities in a trigger based template entity.