Yes, sorry I missed this bit:
That would be fine.
Yes, sorry I missed this bit:
That would be fine.
@tom_l, as much as I understand your advice on this, I cannot agree with overall solution. My view goes like this:
So, to sum this up, excluding attributes from sensor definition (like it’s done right now) does not resolves a problem with data model in the database. And this WTH is about attributes definition in the UI on par with advanced yaml config and nothing more.
Hope we can settle with cause and effect separation here.
Hm… but for example “media_player…” entity has quite some attributes which do change often, like volume, or even worse: current played song title in DAB radio’s entity (which i have) - this attribute is change every couple of minutes… ?
I think you wrote exactly what I was thinking:
My view of this WTH (at least the reason I voted for it) is to be capable to define easily a sensor template with some basic attributes.
My personal exemple would be to try to get rid of mushroom template card:
This is for the time being not feasible though UI.
Not for much longer
Oh? Is there any change planned? That would be great… i had to create a bunch of template sensors to be able to use these attributes.
That’s fine, you are allowed to have a different opinion. However I am not the one you have to convince. I’m just reporting the direction the devs want to take with attributes. I thought there was an ADR or note somewhere about this but I can’t find it.
I’m reasonably sure this is on someone’s to do list.