I was thinking the same thing but I don’t think the open and close change works with that variant.
only when its in a specific state though, right?
You cannot change both the on and off-icons, only one of them, right?
That could be true.
The fact that the customisation of entities icon is limited to just one icon annoys me a lot. Yes, you can select any icon you want, but then you lose the state reflected by icon change.
It depends? I think the naming has to be exact…
Example door has “door”, “door-closed” and “door-open”
window has window-closed and window-open
I believe any icon with the x-closed, x-open will work…
however the above alternate window icon is window-closed-variant and window-open-variant where the state is in the middle not the end.
IIRC door-sliding and door-sliding-open open work?
Haven’t tested in a while.
1 Like
No, it doesn’t work like this. I even tested it now too be sure. The icons reflecting state can only be the default icon. You can change it by changing the service class. But there is only one windows device class with the default window icon.
So technically a solution for this WTH would be too make a new device class for different window icon. But I would really prefer more customisation.
I created a new, now general WTH for this:
Sounds like we just need a device class to cover that icon set.
My windows look like the window in the current icon.
Most people in the world are not Americans. The default should be changed to better reflect that.
You’re assuming most people in the world have windows that you have, I highly doubt that is the case. We simply need more device class options for cover so everyone can be happy. There’s no reason to change the default.
No, I am not assuming that. What I do know is that the icon we use currently does not look like a window at all to a huge portion of the world.
I don’t want to enforce the icon that looks most like my window. I want to pick one that is immediately recognized as a window by the most amount of people (preferably everyone).
That would be changing the default 
Amend, don’t break.
That would be changing the default
Yes, that is what I said. Regardless if we add icon customization in the future, the default should be changed. Home Assistant is an international product, and therefore its terminology and look should be accommodating to the international audience to the best of its ability.
That would be breaking existing user setups for no-reason. Historically, people get really upset when their defaults change. Sorry, but I’m not going to agree with you on this.
Americans account for over 75 thousand (known) users of HA and they are the largest user group in HA at over 17% of the current user base.
That would also be fixing even greater number of users setup. 17% < 83%.
Besides it doesn’t actually break any functionality, just the look gets updated.
One compromise path might be to set the default icon based on the user locale. But I honestly don’t think it is that necessary, Americans can just get over their icon looking slightly different. As long as they can tell the icon represents a window, I would not worry about it.
And changing user interfaces is the most disliked thing about HA updates. 2nd is changing defaults where users have to adjust settings.
local based icons would be nice, but I have doubts that it would ever happen.
Reading this very interesting proposal, the other mentioned WTH and searching around the forum for similar posts, I feel the needs of @AndreKR and others. As being a HA user for some years I see three use cases behind this proposal/WTH:
- As a new user I would have felt cozy If either I could have chosen a somehow local icon set in the setup process or later on the General page as I would define my currency symbol …
- As a frequent user of my HA I like to adjust my icon set to my concrete surroundings, because even in my town we have different windows, heating systems, … in each house.
- As a frequent user I like to exchange one sensor icon (for every state) to reflect its special characteristics.
As also being a developer I see the architectural problem that rises from just these 3 use cases, even influencing each other.
Does anybody even know a good example from a user perspective not a developer one how such a thing could be resolved (without making it a configuration nightmare for all users)? Really interested 
I guess the easiest for 1 and 2 would be to let the user exchange the whole set “manually”. But that’s already to technical and goes off topic with this WTH.
I didn’t mean to change the default by the way, just give an option. That said, it’s currently 74k US installation vs. 72k German installations, we can talk about changing the default again when we have caught up with you guys. 
There is already a device class selector:
However the core team has made it clear that they don’t want another device class, although I don’t really get the reasons for that.
So the two icon solution from WTH can't we define two icons? would probably be the easiest way to solve this.
3 Likes
Agreed probably the BEST way too.
Dev is correct to limit device classes - they don’t want - need to support that many. After all at its core icon is only a feature of device class.
However if it has two icons! Enabled/disabled then WTH can’t I see /define them
Heck just give me a simple settings page called customization
In there let me set all the styles for the theme
Background picture and colors
Squares or rounded
Icon size
How much bevel on my corner.
How fast the pulse is on the pulse css.
Show all the device classes with thier icon and an icon picker
(basically all of this is just editing the default theme and icon pickers for each icon enabled and icon disabled in device classes.)
1 Like