When I say “type”, I should have said “domain” (e.g. “sun.”, “input_text.”) but the idea is the same.
This is clear, but this should not be a reason of unavailability of the icon attribute…
Probably a FR required.
Some custom cards like mini-graph-card, flex-table-card CANNOT get the icon since it is inaccessible.
Yes it is. Because it’s the frontend that choose what icon to display based upon what I say, not based upon an “icon” attribute.
OK, forget about frontend. Look from another side.
A simple question - why an entity’s property (which icon is) cannot be accessible?
Everything must have a clear reason - like “cannot be accessible because it could break smth otherwise” etc.
You can’t, because it is the frontend that display the icon.
Whatever your needs / desires, you won’t change HA paradigm because you want a different icon in a custom component, trust me 
I already told you: Separation of concerns. That’s an IT paradigm.
The “backend” (HA Core) handles entity and states, the “frontend” (“Lovelace”) handle the display.
Don’t expect balloob to popup to justify his choices 
Seems you misunderstood, I was not talking about “different icon”. I meant a REAL icon.
Do not think this is a good case to use your “paradigm etc” explanation.
Will create a FR. Thanks for participating!
Done:
Thais is exactly what was said above. The attribute does not exist.
And I see no reason why.
Btw, a Mobile App integration creates sensors with accessible icons:
i.e. these entities are not customized and one entity HAS device_class
not sure what your FR will entail? get frontend info into the backend? I fear the will not be accepted.
I did however just found that we can color an icon (albeit via custom-ui)
sun.sun:
templates:
icon_color: >
return (state === 'above_horizon') ? 'green' : 'blue';
so somewhere the system must be able to find that icon to color it 
You might want to emphasize that, somehow
1 Like
Not sure what you mean; probably this is an exaggeration.
Custom UI has nothing about my concern; I said about accessibility an entity’s attribute for a user.
no, what I mean is that there is no attribute in the backend (state machine) of this entity, and the frontend decides which icon and icon color it gets.
So FR’ing that fundamental design philosophy will probably leave you empty handed.
My remark on custom-ui was merely there to draw attention to the fact that even without that attribute set in the backend, we can still get it to be colored, even override the frontend set icon:
sun.sun:
templates:
icon: >
return (state === 'above_horizon') ? 'mdi:exclamation' : 'mdi:help';
icon_color: >
return (state === 'above_horizon') ? 'green' : 'blue';
so, probably not what you are looking for in core, yet it does touch the ‘core icon’
Yes, we know that Custom UI operates on a client side only and do not touch states object.
If something is “coded fundamentally” - it does not mean this cannot be discussed.
Consider a sensor with a device_class: frontend decides which COLOR must be set for an icon, and which ICON must be used.
Then how can you explain the earlier described Mobile App example?
Man, you can bang your head against the wall as long as you want, you won’t get an “icon” attribute for each entity, so maybe try to find an alternative to do what you’re trying to achieve, whatever it is.
Besides cutom-ui, card-mod is also a common way used to flex the frontend to your biding
Stop it. Your behaviour is inappropriate. Do not use such expressions.
Heh? Language barrier?
That’s common expression, not an insult…
Anyway. You’re not open to discussion, so it’s pointless to try to help you.
I just found an interesting fact that might be useful for your quest.
When templating
{{states|selectattr('attributes.icon_color','defined')
|map(attribute='entity_id')|list}}
I get only a hand full of entity_id’s.
More specifically, those are entity_id’s where
- customize is set with a fixed color
like:
customize:
sensor.epson_wf_c5710_series_black_ink:
icon_color: black
- template sensor entities where I set an icon_color template (which I can only do because I am using custom-ui, it is not a supported core config option for template!)
attributes:
icon_color: >
{{'var(--alert-color)' if this.state|int(default=0) > 0 else 'var(--primary-color)'}}
All of my other custom-ui customizations that involve an icon_color template are not listed.
This is just a discussion on a SIMPLE matter. Nobody here “banging his head” or wants to create a revolution.
What I see is
and this is IMHO expected since the “icon_color” is not defined inside a states object.
Sorry, missed the next part about customization.
Yes, since this attribute IS customized - it is ADDED and may be accessed
yep, that’s what I tried to show indeed.