added continously automatic icon color updates for tile card

[chillymattster]

Hi,

after creating issue #8 "Icon color of tile card only updated on page refresh" and catching up with the discussion #3 "add icon-color to Tile card" I spend some more time on how automatic update could be done for tile card without the need for page refresh or card_mod. I found a way which I would like to present with this pull request.

Setting and modifiying icon_color attribute for entities with templates and showing those entities with tile cards for me results in exactly the same behaviour as the default behaviour if tile card with entities that change icon color on their own, e.g. lights.

I'm happy to take any comments and hope you like my contribution 😄

[Mariusthvdb]

thanks for your contribution!

let me chime in @elchininet, he's the technical brains behind our plugin. I can't yet oversee the extra workload this might cause

some thoughts: this seems like moving the regular card_mod config to the plugin. Not sure if that is what we should aim for, as for that, card_mod itself is used best.

because: card_mod is only used when the actual entity is displayed in the frontend, and, custom-ui is evaluated upon each state change. Minimizing its processes to me seems of eminent priority.

I tested this locally and indeed it updates the icon and icon background accordingly very nicely, and see no errors. will give it some time to see if efficiency is negatively influenced or not.

let's wait and see what dev says.

[elchininet]

Hey, I‘ll check it when I get some time but @chillymattster, if you can make the changes in a gist, @Mariusthvdb will be able to test them. He has a set up with a lot of custom icon colors so he can spot an issue or an unwanted behaviour quickly.

[chillymattster]

Hi, I didn't yet use gist, but maybe it is time to do so now 😉 @Mariusthvdb Do you need a gist? I'm asking, because you wrote, that you are already testing the change of this pull request.

Let me briefly explain the rational I had in mind when proposing this change. Carefully crawling through the readme of custom-icon-color, I got the impression that this extension should be something like an easy-to-use component for being able to add and change entity colors including a visible result in dedicated standard cards without involving any other extensions or component. That's why in custom-icon-color.js there are dedicated this.style?.setProperty(..) calls for standard cards to reflect the icon_color-attribute in some standard cards. So please apologize if I'm misstaken here but I'm a bit struggling to follow your argument about preferring card_mod. If the attribute should be separated from the styling, then consequently there shouldn't be any this.style?.setProperty(..) calls at all. What makes custom_icon_color so interesting for me as a user is especially the feature, that I can set an individual icon color without the need to do deal with css styling and card_mod. I can set a color and it is shown in my UI, amazing! 😄 The problem I faced specifically with the tile card is that the current this.style?.setProperty(..) call for the tile card unfortunately destroys the default bhttps://github.com/jesserockz/esphome-external-component-examples/blob/main/components/empty_uart_component/empty_uart_component.hehaviour of the tile card, e.g. no animation and just the icon itself without the background which made it look strange beside other entities that change their color based on state by default.

I might be completely wrong with my understanding and if so, please apologize and I'm happy to adopt and learn more about the goals and principles of custom_icon_color 😃

From a technical perspective I tried to understand how cards in home assistant work to copy the behaviour for icon colors. Therefore I followed the developer docs for custom cards. My current understanding is, that set hass(hass) as a function of each card is called automatically from the home assistant frontend basesystem (or however this is called 😉 ) on each change / update of the hass-object. Each card is asked to do whatever is needed to do for reflecting a possible change in the hass-object which usually is updating the contained shadow dom. I mirrored this default behaviour because my understanding is that the frequent updates of the hass-objects and therefore frequent calls of set hass(hass) on each card also trigger the frequent call of entityCard.prototype.updated in custom-icon-color.js. That's why I added updating the shadow dom as it is should be exactly the same what each card does anyway seems to kind of "natural" and in-line with basic principles.

[Mariusthvdb]

It's ok like this , testing as we speak .

I see the tile cards being updated live. So that is progress

What is still buggy is when you pull down to refresh (iOS app)

Then they lose some colorization and we need to navigate to another dashboard and back again to see them updating again

[chillymattster]

Hi, sorry for being absent this long, real life kicked in 😉

Is there a specific reason to use localeCompare to compare the strings?

I used localCompare as I liked the idea of being case-insensitive in order to be a bit more independent of possible changes or inconsistencies in HA and therefore to increase stability. But it seems that it comes with high costs so I doubt that my decision was a good trade-of.

What is still buggy is when you pull down to refresh (iOS app)

Unfortunately I won't be able to work on this or fix it as I don't own any iOS device.

What I observe on Android is, that your describes behaviour occurs from time to time on Android as well. In such a case there is not just the color not working correct any more but also data updates in general are affected. My observation is that this happens when the connection to HA is flaky / unstable in general which leads to a general mess in the whole underlying routines to update the hass-object correctly and constantly.