After updating to 2022.6 I jumped into reconfiguring my manually defined sensors and found inconsistency between the syntax of mqtt: and template: integrations
Since both formats have been changed recently I wonder, why they differ.
I understand that a hyphen prefixing the sensor of the template means there is a collection of entity types passed to template integration.
Why it doesn’t apply the same way to mqtt? And finally why after all those years of having inconsistent yaml definitions between various integration, brand new formats also introduce those inconsistencies?
Is there any justification for such a choice?
The difference is because of trigger-based template entities. In the template integration you can define a trigger and then specify binary sensors, sensors, selects, etc that are updated based on that trigger. Because of that you may need more then one block of binary sensors, sensors, etc.
Mqtt has no equivalent for this. All Mqtt entities are the same - when their topic(s) change then they change. So it is a dictionary and there is exactly one block for each type of entity
Thank you for the answer, but I don’t think that the existence of trigger-based templates must lead to the inconsistent structure of configuration.
BTW this inconsistency can be seen even in the template alone:
Look how differently are defined domains for trigger-based and state-based templates.
It could go 2 possible ways to achieve consistency:
Domains defined in trigger-based template and mqtt could have been listed as collection, or
domains under template could have landed into an additional category (ie state or whatever better name) then listed the same way as in mqtt and trigger.
I have to stress the meaning of the question: why does it introduce the inconsistency in listing domains. I have another example, this time from my package.
It does not because we all understand data structures. It’s a dictionary vs a list. Both have benefits and limitations. Template requires it because a trigger needs to pair with the domain it’s triggering, MQTT does not. No reason to over complicate the MQTT section.
That’s just how the author of that doc choose to do the example to show you can have as many sections (list elements) as you want. This is also valid:
# Example configuration.yaml entry with two sections
template:
# Define state-based template entities
- sensor:
...
binary_sensor:
...
# Define trigger-based template entities
- trigger:
...
sensor:
...
binary_sensor:
...
It’s YAML so the only rule is that a single object can’t have two identical keys. If it bugs you that binary_sensor is separated into a different list element unnecessarily feel free to submit a PR.
The schema for HA’s config is actually very forgiving. This is valid, HA will make it into a list for you behind the scenes:
template:
binary_sensor:
...
But of course if you do that then its impossible to have some template entities with a trigger. Because now you’ve made template into a dictionary so you can’t have two identical keys.
So to answer your question - I find it very helpful since it allows me to separate some of my template entities from the others and define separate triggers for them. If you have an alternate suggestion for how to do this in a way that you feel is more intuitive then feel free to create a PR.
