Why do I always need to create a template sensor if I want to add an entity attribute of any sensor to the frontend?
The answer here is for those integrations to extract those attributes into separate entities for the same device.
This is the standard for newer implementations of integrations.
1 Like
Should be also the case for glance card 
1 Like
I’m still voting for this WTH because it seems like the whole reason to have an entity with multiple attributes is to specifically avoid the problem of having tons of spurious entities. As a relatively new HA user, the natural hierarchy would seem to be:
Integration -> Device -> Entity -> Attribute
There should be a default attribute, which the entity returns when nothing else is specified, but the secondary attributes should be directly addressable. I’d imagine using syntax like this example, for my Aqara Zigbee leak detector, which has a primary state (dry or wet) and two additional attributes.
binary_sensor.leak_detector = "Dry" or "Wet"
binary_sensor.leak_detector.default = "Dry" or "Wet"
binary_sensor.leak_detector.on = "True" or "False"
binary_sensor.leak_detector.temperature -> floating point value
For cases where the measurements are truly unique, then splitting out new entities makes sense, but when the attribute is a feature of the actual sensed value, such as whether it is available, or what it’s battery level is, then being able to directly utilize those attributes seems to be the most intuitive action.
3 Likes
Where can I find the official guidelines about this, how to decide what should be an attribute and what not?
IMHO it’s a lot more clear when all attributes belonging to one entity are together instead of having many different entities, but if there are guidelines I’ll follow them.