Many entities provide supplementary information via attributes, which would be useful for determining which controls to show.
You can use the code view and any condition that supports attributes (e.g. state condition, numeric_state condition or template conditions).
That’s not true, you cannot use an attribute in a conditional card, in yaml or otherwise.
Not supported in state or numeric_state. There is no template condition. It’s not the same as automations.
https://rc.home-assistant.io/dashboards/conditional/#conditions-options
1 Like
Apologies. I should have followed this link rather than assuming it went to the backend conditions page.
Is the root cause of this issue in essence the same as not being able to use an attribute in a history graph? E.g. if I want to plot only the setpoint temperature of a thermostat in a graph, I can only do that by first creating a template sensor for it. I was thinking about making a WTH about that (if it doesn’t exist already) because I think it is quite ridiculous.
In general I don’t understand the logic about what goes in to an attribute and what becomes a separate entity, are there guidelines for that?
In the sense that no one has implemented it yet?
Yes.
It has changed. Historically there was no real direction. Now developers are encouraged to give values that change regularly their own entity rather than making it an attribute. Attributes should be used for mostly static values, like serial numbers. However I can’t find any official documentation that states this.
True. I was more trying to inquire how and why HA handles sensor data stored in attributes fundamentally different from that in entities.
Even the climate entity, which is internal, has changing values stored in attributes so if it is encouraged, it’s not through leading by example. (I get that it would probably introduce breaking changes and am not advocating here to start messing with the climate entity)
I don’t think attributes are meant to be used for static values like serial numbers. I’ve seen some github comments saying that such things should be in the device info, not in attributes. I think the current direction is to simply limit adding unnecessary attributes, and encourage using separate entities instead, when it makes sense.
1 Like
Yep, that’s the current path
‘when it makes sense’ is a very subjective criterion. Take the light entity for example, probably one of the most used entities in HA. It has a state, which is on or off. That makes sense to me, since this is the most important distinction in how I percieve the device. An attribute of that state may be the color temperature or brightness. That makes sense to me too, since those are further clarifications of the ‘on’ state and they are null if the state is ‘off’.
Another attribute is the friendly name. Now suddenly it doesn’t make sense to me anymore. This is not an attribute of the entity’s state but an attribute of the entity itself, while there is no way to distinguish those. To me it could make sense to either lump all properties of an entity together at the same level, or to have a clear hierarchy that represents how the different values relate, but not something in between.
Apparently that does makes sense to many because they implemented it at some point and kept it like this until this very day.
You are right that if we would treat attributes literally as state attributes, things like friendly name would not make sense. But my understanding is that in reality they are attributes of the whole entity, not just of the entity state.
Documentation does mention this, with a list of common attributes, that include some other attributes not related to state:
“Entities have some attributes that are not related to its state, such as friendly_name. A few attributes are available on all entities, such as friendly_name or icon. In addition to those, each integration has its own attributes to represent extra state data about the entity.”
Either way, my point was just that I don’t think attributes are not meant to store values that can often change.