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.
Yes, I use both.
ok, thx. I must have an incorrect setup even though it’s not being caught with the config check
12345678910, let it go let it go, let it go.
But no, must confess I feel really bad about this accusation, and I resent being talked to like this, while always doing an utmost effort to formulate my posts correctly, and re-edit them if necessary, to being to the point, relevant, going forward, and most of all being polite…
I think the long and short of it is that this new arrangement won’t please everyone. What I hope will happen is that those who are short-changed by it will ask for improvements (and hope the development team adopts them). I won’t be part of that effort, because the new way satisfies my needs, but I encourage others to voice their suggestions for improvement.
Way back, when entity_id was eliminated from Template Sensor, we adamantly defended its need. Although it was never restored, bdraco heard us and did refine the new system to be even more efficient. It was still not as fine-grained as what entity_id allowed but pretty darn close (with a few notable exceptions). Fast forward several months and now the Trigger-based Template Sensor gives us even more fine-grained control than entity_id ever did.
1 Like
Then stop perpetuating things by saying things like:
You’re welcome to be upset at me all you want. But my comments are a direct response to your actions which brought another individual saying the exact same thing. All of which, is untrue. Do you want these responses from me to stop? Then stop all this what-if-isms.
Are you saying then that ‘legacy’ is something else than ‘deprecated’? because earlier today you said this about that.
btw:
Yes it is. It even explains it in your definition. Deprecated and legacy have 2 different meanings.
Edit: to clarify:
Deprecated: will ultimately get removed
Legacy: no plans for removal but not the current way of doing things.
1 Like
Damn. This has now really put a damper on the whole release for me. Template sensors are probably a majority of my YAML config so lack of support for their modern config in packages is a real problem. Now I have these crappy choices:
- Move them all to modern config and don’t use trigger template sensors at all. This is where I am now but its not great, I wanted to make some trigger template sensors
- Leave all my packages using the legacy config for sensors and binary sensors. Remove the ones that should be trigger template sensors out of their corresponding packages and put them somewhere else. This will work but it will frustrate me when I can’t find them where they are supposed to be later.
- Refactor my entire config to stop using packages and figure out a new organization system.
#3 is not what I was planning to do this weekend but I guess here we are. Packages don’t serve much purpose if they can’t encapsulate functionality. Bummer that it looks like they’re becoming legacy config too.
1 Like
just for the sake of being complete, I wrote this FR, which you could add to and support:
1 Like