Attributes are the biggest single headache I have with HA.
Much discussion has gone into this topic and most of the posts end with someone pointing out that “eventually” attributes will disappear.
The reality seems to be that it will be years, if not decades, for every integration developer to fully convert attributes over to separate entities.
A potential solution would be to create a UI page that lists a device’s attributes and automate the process of creating template sensors and assign them to the host device.
This can currently be done with a tedious manual process in yaml but is not beginner friendly.
If users could easily create a helper that derived its value fr an attribute, that would be awesome. Bonus for nesting that derived sensor into the device of the entity that provides the attribute.
Currently you can do it with the template helper, but template helper doesn’t seem to have availability template.
I find attributes great.
I would not want them to go, they give us possibilities to add more data to one single sensor than just the state can hold.
It would be more or less impossible to have API connections with just states.
Some of them are a bit more complicated than that, like nested attributes.
But then again, if you have nested attributes then you could not do it without the attributes in the first place.
But the developer tools is a great place to learn and test how to set up a template.
Unfortunatelly not everywhere you can use templates, so creation of interim sensor is frequently a must. I’d rather love HA to automatically create sort of virtual entities based on attributes. So in case @Troon shown it would be sufficient to use entity name climate.my_heating.temperature and then HA would treat it as regular entity. It would make our lives so easier…
Thanks. i tried this already. In my entity the attributes names start with uppercase letters. I just changed it to lower case. now it works.
Even if you consider it easy, there are still some things to have an eye on.
Watch out for the front end trying to be helpful. Depending where you looked, they might have been “translated”. Developer Tools / States gives the true picture:
the state of an entity is limited to a max of 255 characters. Attributes are limited to (I think) 16k characters.
Attributes are a literal must have in certain instances.
The two examples I can think of are both weather related…
the forecast of a weather service would never be able to fit into a sensor state.
and I maintain a NWS severe weather alert integration that needs to have the alert information in the attributes. I’m fairly positive that even the info for 1 alert would exceed the 255 character limit of a sensor.
I’m sure there are many more examples but those are the most obvious off the top of my head.
I have never run into an attribute that I couldn’t extract from an entity.
And what if all those was entities instead?
It would be very long names on some of the entities and it would clutter the developer tools.
Now you just have one big block you can scroll past
Personally I much prefer attributes over entities. Why? Because entity states are for some reason always a string, while state_attr immediately returns the “correct” variable type (number, date, whatever).
not 100% true.
Json is not strict typed and has no validator as xml has.
Lot of developers put there strings picked directly from 3rd party APIs, not even trying to validate them or convert to normalized datatypes.
So… yes, if a developer puts there numbers or booleans… then they are numbers of booleans. Things gets less obvious in case of time. there is consensus about using ISO formatted time, but often found values don’t comply the standard.
