As it is, we can pick one static icon, but since this helper is binary, it would hopefully be trivial to enable a separate icon for both states without further complications. This solution is UI based, and user friendly even for new users.
The most basic way of accomplishing this right now is by creating a binary_sensor template as I did here:
Of course there are other ways to do it using styles or @tom_l 's suggestion linked above but the idea is to solve a simple need with a simple solution regardless of user experience.
It would all (and more) be incorporated in tom_i’s proposal, which if it also could be managed the the ui would be little more effort. Given that doing both would then provide two ways to achieve the same, adding more clutter and potential for confusion. I’ll keep my vote for the other WFH.
@eggman Has anyone considered the mess and complications of creating a device_class every single time you just want to have a dynamic icon for a toggle? There certainly is a place for additional custom device_class but I don’t think it is ideal for this use case. This WTH does not preclude the other.
In my opinion, that is what you get using the device_class approach to change an icon…
The difference is that it would be more manageable it if was a single point of code. The device class route handles that. This route would be very specific and it would be more overhead to manage both systems. I’m with egg man on this one.
@petro - Single point of code from the HA developer’s point of view? …and assuming they were to implement both features? If so, that will be their choice but I don’t see much substance to the objection.
I’ve used device_classes mostly to change a sensor reporting on/off to door or motion and that was very useful because I was needing to change both the state and the icons on multiple contact sensors that reported just on/off to make them match the other door and motion sensors. When creating ESP32 based custom sensors using ESPHome, I used device_class to define what the sensor was reporting. There it would sometimes help to be able to create a custom device_class for ones that HA has not implemented yet, however if the rest of the system doesn’t know what to do with it, then it may be of limited use.
Creating a new device_class every time you want a dynamic icon on a toggle seems unnecessarily complicated. I can see a benefit if you create tons of toggles that all share the same states and icons but that is not the use case.
device_class seems like a way to categorize a sensor so that HA knows how to treat it. How would HA know how to treat custom device_classes it knows nothing about? How would you handle the new states everywhere in HA, Node Red, etc? Now you have to also manage the reserved states (defined by HA) and the custom ones created by the user… if the user picks a state that matches a reserved one, what should the system do? Treat it as it would with the reserved one? What if the user doesn’t want that? Imagine the nightmare when sharing code that includes custom states like “apple” and “orange” instead of the default Booleans it uses now?
If custom device_classes are just meant to show a custom state and icon on the dashboard, and you are worried about code maintenance, then why wouldn’t a template be the way to go instead of implementing a duplicated way to do it?
Again, all we are asking here is one extra measly icon to reflect the state change. No need to create a new class, states, etc. Just trying to avoid having to create a text based template each time.
Device classes simply handle icons and state translations, nothing more. Exactly what you want to do here. Making up something new to handle functionality that’s already baked into HA would be irresponsible.
@petro If all it is doing is associating a word (state) and an icon to each of the two boolean states exclusively for display purposes, I see the value, and it decreases my concerns. If device_class is used for anything else other than display, then my concerns / objections remain.
Either way, I would prefer the on and off icons to be configurable in the helper itself even if in the backend it is using a device_class to do so. I love HA, and have accomplished so much more in 1yr of HA compared to 7yrs of ST, but I still struggle with what feels like things scattered all over the place to get something done. That bit is in the helper creation window, that other bit in a yaml file where you can customize the helper further, this other bit in the lovelace dashboard, and this other bit in Node Red… you get the point. It would be great to create the helper, set custom icons and states within the helper and be done with it. No more templates or lovelace yaml to wrangle it to show what you want. Need to make changes? One spot to go to…
Exactly my point, that this could be configurable through the ui. Just no point putting in the capability to select the icon without the ability to control the state text.
Yeah you can Search by Topics/Posts in WTH using a username. Then click the more button at the bottom of the list. Then Sort By Latest Topic. The results are posts and topics though
In the advanced section you there’s a dropdown that says “any”… expand that and choose “I created”.
yes, but you can use 3.1.4 still its a longer standing bug, and Thomas hasn’t responded yet, so dont hold your breath, and find/use other ways listed above
there’s a few community members putting band aides into it to keep it alive in a forked repo. I think 
