Look at the very bottom of the images, where the name is defined.
Again, please explain to me a situation where this will break with an example. An exact example.
The only change that would be required in your system when friendly_name is deprecated is:
state_attr(your_entity, 'friendly_name')
would need to change to
entity_name(your_entity, True)
Yeah.. of course, we can just fix everything the developers keep breaking for us..
Great fun..
I gave you an example above where you use the friendly name of the entity.
If the friendly name is removed then the script/automation/template that uses it will not function
Hellis, I think you think there will be a ton of changes without realizing there will not be. This is what I’m saying.
Yes, and you can already do a find replace for that using entity_name in whatever template that is.
Yes, but why??? Why do I need to fix everything they keep breaking for me?
There are many reasons to remove the attribute, the main contender is that it add memory to every call. This ultimately will make things faster in the long run because the data shouldn’t be in the state machine, or the database, or in every state changed event… list goes on.
Also, just understand that the deprecation for friendly_name isn’t even here yet, including next release. So you have at least 6 months to address any changes.
Remember this thread?
Just a few weeks ago the talk was we should try to not break stuff.
And I called it.. I said I don’t believe it hold for very long.
And sure enough just a few weeks later we are here again.
The name changes have been announced for a long time, along with the removal of friendly_name. You just missed it. Here’s the commit to my own configuration that moved from friendly_name to entity_name function/filter.
18 changes, it was a really quick fix on a rather heavy template configuration.
Petro. I get why you’re saying. And…
The dev team has said exactly NONE OF THIS to users in a forum not named Discord or come read in Git. Do you know the mem usage thing you just said. THAT’S LITERALLY the first time I’ve heard anyone mention it. (I had suspected btw)
Again normal users don’t read git gists.
With the already stated.. In beta it’s too late to change (horrible position btw) it makes the change feel advasarial and why would I beta if that’s the case. It’s too late anyway.
I am hopeful you are correct but I am also looking at a ton of code over years that does reference a few things that change so I’m not at all looking forward to reviewing literally over 500 combined scripts, template sensors and automations for references.
Its not ideal. And feels forced. Because they are not doing a decent job with the why.
It was said in the beta thread on this very forum, very prominently before it was pulled to address all the shortcomings.
In the beta thread which they have ALREADY SAID suck it up… it it’s too late now… (see the problem?)
Regardless, the deprecation hasn’t even started, and it’s not even starting next month. This is advanced notice of the deprecation. So now is your time to start acting.
No I don’t because it’s been known, but you’re getting advanced notice.
From my perspective, this is just people not wanting change. The goal posts keep moving, the deprecation isn’t even in affect. You’re just hearing about it and are upset about it. I get it, but we are a long time away from it being fully removed.
I know that. And… Again. That’s the first time it’s been said like that.. I appreciate you for bringing these here.
And the notice to the team needs to be. Piss poor form communicating this. (present company excluded)
So a friendly name of say 30 characters + the actual key friendly name.
Let’s go crazy and say it 80 bytes is what we are talking about?
On a installation size of 1+ GB.
The announcement is happening in the release! Before the deprecation is even happening! It’s not bad communication, the communication is happening. And it’s a heads up!
You want advanced warning before a deprecation occurs, but you’re upset about advanced warning before the deprecation occurs. Do you see the ridiculousness of this?
All I’m saying is you know when I raise alarms.
Im pointing at this one. It isn’t going to be as smooth as they think and the confusion level is VERY high.
Batten the hatches.
80 bytes times 2 for every state change event in your system.
80 bytes for every activity in your database (the event table)
80 bytes for every state in your history (the states table)
that could easily reduce system load by upwards of 10 to 20%, including database size.
You are absolutely correct.
Especially when the change is unnecessary and the problems of it is large.
Backwards compatible should be the norm, not the opposite.