How to make state_color: true global?

Looks like you’re going to have a long weekend :sweat_smile:

I mostly use templates to create the cards on the frontend, this way I only need to add this option to a few templates and I’m done. However I don’t need to add this at all, because all my templates already have a color configured for the icon based on the state of the entities used.

Yeah I am. :frowning: Now you have me intrigued though, I haven’t messed with templates nor was I aware how to configure icon based one the state of the entity. Can you elaborate please? This might be a good time to revamp my lovelace config.

I believe you’ll find lots of examples when you search the forum. One of the more interesting ones is here, where the goal was to have the color of the icon match the color of the light: Pull color state from light

Yeah you are right, the global file is for entities overides not lovelace. I didn’t think about that. Sorry about that :slight_smile:

Can someone give an example how to enable that for all the switches?

What you need to insert and where?

Apparently there is no global way.

That’s pretty cool but my lights already do that (Hue and z-wave). I’m more interested in the templating stuff.

But it says that you can enable switches or all types there is a way to do it

Add this to customize_glob

switch.*:
  templates:
    icon_color: >
      if (state === 'on') return 'var(--state-icon-active-color)';
      return icon_color;
2 Likes

You can use it per Lovelace card.

7 Likes

@Krocko - That didn’t work

@VGE - I know but I have a crap-ton of cards across maybe a dozen tabs. I’m looking for a GLOBAL way to change this back to the old behavior.

1 Like

Yea that sucks. Sorry cant help.

It is working. I use it.
Have you installed custom ui?

Custom UI? What’s that?

I know how to use it, but I’m not experienced enough with lovelace to give you a good explanation. Maybe @jimz011 (hope it’s ok that I tag you here) can give you a short explanation if he doesn’t mind.

@Burningstone, I could yes. @danodemano custom-ui is actually a modification meant for the states-ui (which is now deprecated btw). But it has some extra functionality regarding customization. By default Home Assistant does not support templating customized entities, with Custom-UI this is possible.

By default you can customize entities and give them another name, icon and/or device_class. But you can’t set an icon based on the state of the device. With custom-ui this is possible as well as having a colored icon based on the state (though this will only work with core cards and NOT with e.g. custom:button-card).

in my case I use the custom:button-card a lot and so color isn’t very useful for me, however I do use icons based on the state. For an example of how I use it click here and then click on “Personal Setup”.

You can find a lot of other useful examples there. I hope this will help you!

1 Like

The states UI is being removed in 0.107 (Or 0.108 - can’t recall) though right? So does that mean at that time custom-ui also goes away? I don’t want to start putting time into that if it’s just about to go away.

To be honest I have not the slightest idea. I also use Custom-UI for exactly the purpose I mentioned above. I don’t think it will stop working though, though the states-ui features will definitely no longer work.

Not entirely sure if my explanation is a 100% correct, but let me try.

If you don’t use autofilled themes like e.g. my own HKI or Dwains theme you can simply define all colors and states within lovelace (you will either have to use custom:button-card or card-mod if you want to use core entity-buttons). A few pro’s and cons though:

Defining every icon and color within the frontend is easier and doesn’t require a restart. Defining things through the frontend has a less likeliness to stop working as it basically is just CSS.
Doing everything through the frontend does make the frontend slower, and the changes will only apply to that specific card. However doing it through the frontend also makes sure your hardware doesn’t require to be very fast as the receiving device (in this case browser or phone) will handle it.

Doing it with customize.yaml (with or without Custom-UI) will make your frontend slightly faster, but requires more memory and processing power on the backend (the device HA runs on) thus it requires better hardware. Icons and colors will be handles by your HA machine and thus your receiving device has less work. It also makes sure that the entity has the same icon/color everywhere in the frontend (e.g. it will also show that icon when opening the more-info view or when looking at it in the dev-tools>states).

Either way, results are pretty similar and it is more or less up to you which method you prefer. I have a server so I prefer to do things in the backend.

2 Likes

Thanks, that’s helpful.

Unfortunately I’m still stuck with the same issue either way, I get to spend all weekend ripping my config apart because this change broke at least 75% of my cards. A bunch of them are conditional cards too which means I have to really get down into the raw config editor to screw around. It’s now WAY harder to see what’s on an off, open or closed, motion, etc. I was really just hoping for a way to globally revert this crazy change so I don’t have to waste a crap-ton of time. :cry:

I actually think it still took a long time before they really deprecate it (though you still have a month until it is really gone). At least we were talking about the states-ui right?

Lovelace has been the default since january last year so in that regard we had plenty of time. But yeah I can understand the reluctance, especially if you have already invested a lot of time creating the current frontend (trust me I know :rofl:). All I can say right now is that you will have to change everything, a little upside is that I don’t think they will change it again (as lovelace really is much more versatile than the states-ui is).

If you have any questions regarding Home Assistant, lovelace, or any of those things you can always ask!