But that does not define the resultant entity_id
So I tried : -
template:
- binary_sensor:
bs_fans_permissive:
name: Fan Run Permissive
state: >
{% set tme = states('sensor.time') %}
{% set strt = states('input_datetime.id_fans_on_permissive_on') [0:5] %}
{% set stop = states('input_datetime.id_fans_on_permissive_off') [0:5] %}
{{ strt <= tme < stop }}
icon_template: "{{ 'mdi:fan' if is_state('binary_sensor.bs_fans_permissive', 'on') else 'mdi:fan-off' }}"
… And a few variations on same - All generate errors - What stupid mistake have I made ?
Or does the documentation not allow for specific entity_id generation and just creates ‘something’ from the name ?
An what are those errors?
You know, even experienced HA users need them to pinpoint issues without spending time looking at code character by character…
Chris,
You are quite correct, I made two assumptions
That people would know about this
That I just couldn’t find the related posts as I was using the wrong search terms
My apologies.
It clears configurationn checks as ‘Valid’
I’m running core-2021.11.3 (latest)
The error log throws up : -
The following integrations and platforms could not be set up:
template
Please check your config and logs.
The logs say : -
Invalid config for [template]: [bs_fans_permissive] is an invalid option for [template]. Check: template->bs_fans_permissive. (See /config/packages/switches/switch_fans.yaml, line 11).
17:18:43 – (ERROR) config.py - message first occurred at 17:18:43 and shows up 2 times
Which is highly non-specific and the documentation doesn’t seem to help, I just figure it’s a wrinkle (as it just can’t be that they are deprecating ‘entity_id’ )
Which clearly means that it thinks bs_fans_permissive is part of template rather than being part of binary_sensor. So it indicates your indentation is wrong. Which is correct - your indentation is wrong, but also it’s
template:
binary_sensor:
- unique_id: bs_fans_permissive
name: Fan Run Permissive
state: >
{% set tme as states('sensor.time') %}
{% set strt as states('input_datetime.id_fans_on_permissive_on') [0:5] %}
{% set stop as states('input_datetime.id_fans_on_permissive_off') [0:5] %}
{{ strt <= tme < stop }}
icon: "{{ 'mdi:fan' if is_state('binary.bs_fans_bth_fan', 'on') else 'mdi:fan-off' }}"
I was under the impression that ‘name’ was a more user friendly version of ‘friendly_name’
As shown in the primary documentation example
Also, where in all the update information was the statement that ‘entity_id’ would now be called ‘name’ ?
I must have missed that too
Edit : So ‘entity_id’ is now ‘unique_id’ ???
I thought unique id was the system generated id for GUI generated entities ?
If you give it a unique id, then you can edit the entity_id in the GUI to be whatever you want. It’s not as clean as being able to specify it directly in YAML, but it’s a workaround for you.
No it will still generate an entity_id based on the name you give the sensor, but once it has, you can change it to whatever you want, as long as it has a uniqueid.
I use packages,
I write one package for one room and copy it for each similar room
I then open each ‘copy’ and edit ‘bth1’ to replace it with ‘bth2’ or ‘ensu’ or whatever
All entities of that room are then edited AND created, easy peasy
What you are suggesting is not an easy workaround but a damned awkward workaround where I create 10 or 15 ‘things’ per room then have to record their unique ids, then search the ui for each one then edit the entity_id to what I want.
Clearly this is a work in progress that is insufficiency mature to actually work.
I’ll just go back to the old way of formatting template sensors, that is quick, easy, transferable between platforms and does what I want.
There is a 1-to-1 between the name and the entity_id.
A sensor named Fan Run Permissive will have sensor.fan_run_permissive as entity_id. unique_id is optional. You don’t set one, you are in the exact same situation as with “old” templates.
That’s pretty similar to the original implementation of automations created by the gui about 2.5 years ago. I’d still have to go into the gui 15 times per room (which I am loath to do as it feels half arsed). And adjust those 15 unique id’s as my human readable ‘names’ are far from my code readable ‘entities’. As I like to keep the delineated code structure as far from the users as possible.
I would point out that latter iterations accommodated ‘names’, entity_id’ and unique_id’ and all achievable both from yaml and from the gui
@Burningstone, @tom_l
Your ‘workaround’ is the best of the options (given the ‘recommended’ format)
But I hate having to manage this in two locations (even though I can do it in the same package file) so I guess I’ll just rewrite the whole section back to old style and ‘hope’ they fix the entity id.
It’s lucky I only played with this in one experiment package (which has 37 such entities) rather than all 34 package files.
Thanks to all for your input, but I think this iteration is flawed.
Still, there are benefits to the new method. Like triggered sensors, and one other thing… that seemed important at the time but I have since forgotten.
Can’t believe this new way really is “recommended” because not being able to initially set the entity_id is a step back in my opinion. It forces users to always customize the entities created if they care for entity_ids and has a few other downsides. Meh
Really tend to switch back to the old/“legacy” definition…
