It’s not a move! It’s an addition to templates. I don’t know where you got this “move” from. This is a trigger template, it’s not the same as the template entities.
Very useful thank you - so from my example:
wan:
friendly_name: "Internet Connection"
value_template: "{% if is_state('binary_sensor.WAN_Check_BBC', 'off') and is_state('binary_sensor.WAN_Check_OpenDNS', 'off') %}Offline{% else %}Online{% endif %}"
restart with:
wan:
unique_id: wan
friendly_name: "Internet Connection"
value_template: "{% if is_state('binary_sensor.WAN_Check_BBC', 'off') and is_state('binary_sensor.WAN_Check_OpenDNS', 'off') %}Offline{% else %}Online{% endif %}"
then transitions to the new format as
- name: "Internet Connection"
unique_id: wan
state: "{% if is_state('binary_sensor.WAN_Check_BBC', 'off') and is_state('binary_sensor.WAN_Check_OpenDNS', 'off') %}Offline{% else %}Online{% endif %}"
2 Likes
Sure, it is the new Template platform, which for binary sensors and regular sensors is moved to Template - Home Assistant from: Template - Home Assistant and Template - Home Assistant
and yes, its got the additional trigger section, which is cool.
That works although keep in mind you don’t actually see unique_id anywhere, its just a unique ID shoved into the entity registry. I would personally just generate a UUID value like wan_10de553fcd6f47569fdb75abe8e4664b. Just to eliminate any risk of accidently picking the same ID twice.
1 Like
I liked the changes to template, already migrated and improved existing templates with the new triggers and auto off, thanks a lot!
Templates are really powerful in HA and I think the next proper step will be to make templates similar to the Helpers (added and managed through the UI), we could even preview the result similar to how the developer tab works.
But now, don’t you have to remember where the individual sensors are created - are they now in the "templates.yaml’, “sensors.yaml/binary_sensors.yaml”?
Before all sensors were in sensors.yaml or binary_sensors.yaml. If I am looking for one of that type of sensor I know what section to look in whether it was a template sensor or not.
Now you can have both sensors and binary_sensors uinder the same templates.yaml. So now I have to remember if the sensor was created with a template or not in order to figure out what section to look in - templates.yaml or sensors.yaml.
If the goal was to add a trigger template sensor then it would have made more sense to just add the trigger template sensor under the existing template sensor config.
I don’t see how creating an entire new domain that mixes and matches other already existing domains under it was helpful from an organization standpoint.
2 Likes
There is no reason to transition… Literally keep what you already have. Ask yourself the following question:
Do I want to have a binary sensor based on a trigger or event? If yes, then use the new template integration.
It’s not a “new” format. It’s the format for the trigger templates. What everyone is referring to as “old” is not old. It’s the other type of template sensors and they are NOT going away.
They did not move. They are trigger templates not to be confused with binary_sensor and sensor templates. Please stop making it seem like it moved, you are confusing people.
2 Likes
and we can not use them in packages unfortunately , though I truly don’t understand what Frenck says here template sensor in package · Issue #50157 · home-assistant/core · GitHub
1 Like
I mean if you want this you can still do it:
template:
- sensor: !include sensor.yaml
binary_sensor: !include binary_sensor.yaml
Organize your YAML however you want, there’s lots of ways to split the config. Personally I prefer packages so this new mechanism is a plus to me, I can have all my template sensors in one place within each feature-specific package.
listen, I will stop, but since we are advised to re-write our existing (non trigger) template sensors and binary sensors in to the new template: integration format, I don’t believe I am the one confusing people.
Well that’s interesting. Crap, going to have to follow along with that. I moved everything into packages but it was awkward. In my packages I had to make template.yaml files like this:
binary_sensor:
...
sensor:
...
Doing this didn’t work even though it is as the documentation described:
- binary_sensor:
...
sensor:
...
It didn’t bother me since I didn’t have any reason to make subgroups of sensors yet but I was planning to after I got everything moved over. Guess I won’t be able to yet.
Who advised you? No one… You’re taking a comment from 123 and snowballing it.
that’s a bold statement looking at the history of these same types of other bold statements…
But even if that’s the case all it does is just adds to the confusion with little to no benefit to the users.
It was literally designed to allow event streams & webhooks create sensors. You guys are being ridiculous.
But that way you still need to remember where the sensor/binary_sensor was actually created. Which will be based on if it contains a template or not.
It’s not an “organizational” problem but more of a real world “now where did I create that sensor?” problem.
as a matter of fact I had been discussing this with Balloob… and after I asked him if the now called legacy format would be taken out, he assured me that wouldn’t be the case.
but, we all know that happened before, and it’s now officially called legacy in the docs… who btw also recommend us to do so.
So it’s better to spread rumors about something that’s not happening? Real classy.
Good question. I haven’t used a template in name but it stands to reason the template’s result will become the entity’s object_id (after conversion to a slug, meaning only alphanumeric characters and underscores).
This presents the interesting possibility of an all-too-dynamic template causing the entity’s object_id to change frequently. I don’t think you could ever reliably refer to that entity in a service call or template because its object_id wouldn’t be permanent. 
2 Likes
from the docs linked here:
This format still works but is no longer recommended. Use modern configuration.
4 Likes
Is it possible to have a mix of legacy and modern sensors setup? I am asking because I have a few sensor yaml files and I wanted to try out the modern approach however after setting up a standalone yaml file for it and reloading I couldn’t get the new modern sensors recognized. I am not sure if my file is incorrect or you just can’t mix and match them.