Just trying to clarify how to create multiple trigger based templates. By which I don't mean multiple triggers in a template. I mean multiple entities, each created from a trigger template.
For any other template, like sensors, the YAML would start something like this:-
template:
- sensor:
- name: SomeName
etc.
and any additional sensors would follow as:-
- name: SomeOtherName
etc.
with no need for another - sensor: section heading. But when it comes to trigger based templates it's not so clear.
The docs show this:-
template:
- triggers:
- trigger: state
entity_id: sensor.desk_height
number:
- name: SomeName
etc.
How does one add another of those. There's no obvious - section under which another can be added.
Should one actually add another - triggers: section, so:-
template:
- triggers:
- trigger: state
entity_id: sensor.desk_height
number:
- name: SomeName
etc.
- triggers:
- trigger: state
entity_id: sensor.desk_length
number:
- name: SomeOtherName
etc.
This does group them, each under their own - triggers: section, but that is repeated for each one, rather than just a single section with multiple entries as is the case with all other templates. It just seems entirely inconsistent, hence why I'm hoping someone can clarify this.
That's one way to do it, but it's just as valid to do:
template:
- sensor:
- name: SomeName
etc.
- sensor:
- name: SomeOtherName
etc.
Yes, if the two template entities use different triggers it's best to add a new item to the template list. Technically, you could combine them in one item configuration, but it's rarely worth doing because the templates get way more complicated.
If they use the same trigger you can just add another item to the number/sensor/etc list.
#both of these number entities update based on the same trigger
template:
- triggers:
- trigger: state
entity_id: sensor.desk_height
number:
- name: SomeName
etc.
- name: SomeOtherName
etc.
#You can even have one set of triggers affect different entity types
template:
- triggers:
- trigger: state
entity_id: sensor.desk_height
- trigger: state
entity_id: sensor.desk_length
number:
- name: SomeName
etc.
binary_sensor:
- name: SomeBinaryName
etc.
Yes true, but it is valid to eliminate any extra - sensor headings - and is even recommended I believe, but could be wrong on that.
However that seems not possible for - triggers: which is inconsistent and made me wonder if my understanding was correct.
I was originally thinking about an 'included' triggers file, to keep separate from 'sensors', binary_sensors' etc, each in their own files, but that would not seem possible as each trigger template would still require their own - triggers section which would result in:-
- triggers:
- triggers:
etc.
which I don't think is valid.
In the end I am using 'dir_list_merge' so all files in the templates folder require their 'section heading' at the top and for the triggers file that can include multiple - triggers headings, so looks like that will work.
As I said, there is inconsistency which made me doubt my understanding. Thanks for the clarification.
Merging triggers is valid. It's not something I use much in Trigger-based template entity configs, but I have tested it with them and it does work. FWIW, I tested it in files in a packages folder with in situ triggers... I haven't tested it with !include or dir_list_merge. So, YMMV.
Two comments. You keep using the word "section" but I don't think of it that way. Maybe this is obvious (so apologies), but it's a YAML list of dictionaries. So, rewriting your example from your first post:
template:
- number:
- name: SomeName
triggers:
- trigger: state
entity_id: sensor.desk_height
variables:
foo: bar
- sensor:
- name: SomeName
triggers:
- trigger: state
entity_id: sensor.desk_length
- binary_sensor:
- name: SomeName
triggers:
- trigger: state
entity_id: sensor.desk_length
(I often write mine like that just because I like seeing the name and ids first.)
Second, take a look at packages @Didgeridrew linked to. Instead of separating out by type of sensor into different files, packages lets you group related code in one place.
Yes sorry, 'section' is probably not the technically correct term, but I still find YAML definitions of terms puzzling. I am certainly more familiar with it than when I started with Home Assistant, but YAML is taking me longer to get to grips with than any other programming language I have used in the past. In fact, technically it's not even a programming language, but it is used as such.
However, I do like the idea of defining the template by its type (sensor:, number: etc.) and put the triggers: inside each, as you show. That would allow me to keep all 'types' in their own file, some with triggers: and some without. Actually makes more sense than having a separate triggers file.
Packages are not something I've looked into as deciding what code is 'related' strikes me as another rabbit hole to avoid. What I think is related today, might appear to not be so tomorrow and it seems problematic if you want to re-use code in different unrelated situations.
That last doesn't look right to me, as it seems like the triggers: section/group should be indented further.
This is why I said the layout for trigger based templates seems inconsistent with all other template entities and I'm still trying to understand all the ramifications.
Just to clarify, by related I meant more "task" or "function". For example, I have packages for HVAC, security, irrigation, pump operation, etc.
Since you are asking about template sensors you already found a need for their help -- which is why they are called "helpers" in the UI. The packages simply make it so you can group those helpers, scripts and automations are all in one place. Currently the UI doesn't provide for that kind of grouping. They also make writing automations much better and easier to debug, but that's another discussion.
I was questioning whether it is a problem placing - sensor first and specifying state: as based on the response_variable which is only created by the actions: that appear later in the YAML.
I am not entirely clear about what YAML evaluates when so it's a bit trial and error for me still and asking those who know is hugely helpful. So I appreciate the answers.
Okay that's what I thought you were asking... so, the answer is that the order doesn't matter in that instance.
Order mostly matters in lists, like the list of actions in an action sequence or the list of conditions. But other places, like the list of triggers, the order has very little consequence.
There are a couple places where order can have an impact in a dictionary. The most common of these would be when assigning values to variables. Those values are assigned sequentially, so you can use previously defined variables in later variable definitions.
