Hue icons loading in dashboards only ~50% of the times - different icons load at different times

[convicte]

Describe the bug

When a home assistant dashboard is called, the page will load all standard and MDI icons just fine, regardless if they are hard coded for the entity or default, but will fail to load all or some HUE icons. Refreshing the page (F5) will change the situation by loading some or only different icons from the missing list, but always HUE icons only will be missing. On some occasions, the whole dashboard will load just fine, just to have some icons drop out 5 min later when jumping between tabs.

In addition, sometimes different entities with the same icon will load while others don't (Both kid's rooms have the same lamp, but one will load the other will not, and more often one than the other).
See screenshots below - these are takes seconds apart with an F5 refresh between each.

The same behavior can be seen across platforms (Win10, Android HA app) and browsers (Chrome, Firefox).
It started with the new 'select icon from dropdown' feature, which I believe was introduced in 2021.11.0 HA version.

To Reproduce
Steps to reproduce the behavior:

1. Go to main dashboard
2. Observe icons missing
3. Refresh the page
4. See some icons appear some disappear, and vice versa

Expected behavior
All icons load correctly every time

Screenshots
See below

Desktop (please complete the following information):

• OS: Win10 Pro
• Browser [e.g. chrome, safari] Chrome, though the same behavior is true for the HA Android app and Firefox
• Version [e.g. 22] 96.0.4664.110

Smartphone (please complete the following information):

• Device: [e.g. iPhone6] Samsung Note 20
• OS: [e.g. iOS8.1] Android
• Browser [e.g. stock browser, safari] N/A
• Version [e.g. 22] N/A

Additional context
Add any other context about the problem here.

[convicte]

Here is the Android app representation of the same issue

[arallsopp]

Thanks for raising this. I've seen similar when I migrated to the new script structures used in the "alias" pull request to HA front end.

That branch is still erratic, so I've shelved it for now, but this is the first time Ive seen that behaviour on the main repo.

Will dig in and see if I can track why you might be experiencing this.

[arallsopp]

I've linked a video on #108 that I think is witnessing the same behaviour.

Again, I can't make it happen on this branch but I'll keep looking.

[convicte]

Thank you so very much for the immediate response!

Just to inform the process a bit, my production HA setup has no beta/dev branches enabled for anything, so it's as vanilla as I can make it. I keep it updated regularly, so sometimes it's a bit unstable with the latest releases, but this situation has been maintained across several hue and HA versions, so it must be in a more conservative part of the code, though in one related to the 2021.11 changes in the icon handling.

If you can guide me through some logging steps, to deliver to you necessary information how things fail on my end, or you'd like to set up a screen sharing session to poke around yourself, it can be arranged.

[arallsopp]

Thanks for the clarification. I'll look into logging and see what options are available.

I would be intrigued to know if you can trigger the same behaviour with earlier versions of hass-hue-icons, particularly the 1.0.x releases, as this implemented a different (older) way of embedding the icons into the front end.

[convicte]

Is there an easy way for me to install an old version of the package. Would it still be available via HACS for me to simply revert to it?

At this time, it's a 10 for 10 on the ease of initiating the bug, since it happens every single time I open the interface, so it's trivial to test back and forth.

[arallsopp]

I'm not sure if hacs will let you roll back that far. The releases are all in this repo still, though, and you can use a file editor to copy the content of the JavaScript file over your install.

The JavaScript console on a desktop will tell you which version you're running.

Midnight here now, but I can put a video together tomorrow to show you how I'm doing it if it helps

[convicte]

That would indeed help, thank you!

It's pushing 1am here, but still stuff to be done today.

Cheers!!

[arallsopp]

@convicte: Here's a video showing how you can move between any version of hass-hue-icons: https://youtu.be/bQSeIUks5GY

We can use the same approach to tweak the code, so if there's a fix this will likely be how we verify it! :)

[convicte]

Hi there,

I believe to have done exactly what you described, but this unfortunately does not produce the same outcome for me as it does for you.

The version is not going back, even with a full HA restart it stayed on 1.1.17, regardless of the file in the folder www/comunity/... you pointed me to.

Any ideas?

[arallsopp]

If you click that hass-hue-icons.js?ha... underscored text, it should take you to the specific file that its loading. Potentially its another version somewhere else on your filesystem? Also, the 'disable cache' (or incognito window) will help you bust any local cache of the file if it proves to be the same one.

[convicte]

It seems the actual file that it's loading is not under www but hacsfiles/hue

[convicte]

Disabling cache under Networks resolved it and allowed the interface to roll back, however the problem remains:

[arallsopp]

That's interesting then. No problems were flagged with that version of the script at all, and I've only seen these issues with newer versions of HA. Wonder if there's something introduced in HA that's causing a conflict when certain combinations of plugins are loaded as it's not something I've seen elsewhere and would expect multiple bug reports if it were.

[spencerthayer]

I too am experiencing this exact same issue across multiple devices and user accounts running v.1.1.17 on core-2021.12.5.

[arallsopp]

Thanks for the additional info @spencerthayer. I'm going to link a few alternate versions of the script here over the next few days to see if there's anything I can do to avoid the issue.

I still can't reproduce it on my install (am running core-2021.11.5 over o/s 6.6) so will now update to latest and see if the same misbehaviour presents.

[arallsopp]

Hmm... Mine still seems completely happy on latest version. I'm linking my System Health export, just incase there's anything in there that differs from yours. Also, I notice that both @convicte and @spencerthayer are running cards with a big slider on them. I think I have a similar plug in running, but wonder if there could there be a conflict? Is there an easy way for you to disable them temporarily and see if the issue goes away?

System Health

version	core-2021.12.6
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
user	root
virtualenv	false
python_version	3.9.7
os_name	Linux
os_version	5.10.83
arch	aarch64
timezone	Europe/London

Home Assistant Community Store

GitHub API	ok
Github API Calls Remaining	4819
Installed Version	1.18.0
Stage	running
Available Repositories	933
Installed Repositories	14

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 7.0
update_channel	stable
supervisor_version	supervisor-2021.12.2
docker_version	20.10.9
disk_total	113.9 GB
disk_used	21.1 GB
healthy	true
supported	true
board	odroid-n2
supervisor_api	ok
version_api	ok
installed_addons	Samba share (9.5.1), File editor (5.3.3), RPC Shutdown (2.2), Home Assistant Google Drive Backup (0.103.1), Terminal & SSH (9.2.2), Studio Code Server (3.7.0), ngrok Client (2.1.6), ESPHome (2021.11.4)

Lovelace

dashboards	3
resources	6
views	7
mode	storage

Spotify

api_endpoint_reachable	ok

[arallsopp]

@convicte, @spencerthayer: Can you try this alternate branch version?

I've run it against latest, and it works for me. Its also a bit more verbose in the console logs, which might help us identify any issues. It also adds the new 'aliasing' functionality, so changes the signature of getIconList to match the latest examples.

[convicte]

@arallsopp

I am sorry for not getting back to you earlier. I hope I did not make you hold off on any commits being released.

Furthermore, I have since updated to 1.2.0 which from what I understand is very similar or identical to the 'alternative branch version' above.
This did not resolve my issue.
Later I downgraded to 1.16, just to make sure I am really downgrading (since the alternative was marked as 1.2.0 as well), and upgraded back to the alternative - no difference.

In short, neither 1.2.0 nor the alternative branch make any differences.
What information would you like me to provide from the expanded logging you mentioned?

Thank you!!

[pascalwinters]

I have also the same issues on HomeAssistant core-2021.12.7.

[arallsopp]

Hmmm. I still can't recreate this issue and had hoped the new methods in 1.2.0 might have fixed it. Do you get any comments in the JavaScript console in your browser regards substitution or missing icons?

@pascalwinters is there any correlation between the plugins you and @convicte are running?

[pascalwinters]

Hmmm. I still can't recreate this issue and had hoped the new methods in 1.2.0 might have fixed it. Do you get any comments in the JavaScript console in your browser regards substitution or missing icons?

@pascalwinters is there any correlation between the plugins you and @convicte are running?

I'm using this this plugins:

I don't see any comments in the browser console regarding the icons.

It seems like the functions are not triggered:
async function getIcon(name)
async function getIconList()

[arallsopp]

It seems like the functions are not triggered:
async function getIcon(name)
async function getIconList()

@pascalwinters: OK. Here's what I'll do:

• add a console output for every icon access attempt and put it into a new version of the script.
• try installing these plugins and see if I get a conflict

It'll probably be tomorrow now. Apologies for the lag.

[pascalwinters]

It seems like the functions are not triggered:
async function getIcon(name)
async function getIconList()

@pascalwinters: OK. Here's what I'll do:

• add a console output for every icon access attempt and put it into a new version of the script.
• try installing these plugins and see if I get a conflict

It'll probably be tomorrow now. Apologies for the lag.

Ok, I'll be open to test anything. Maybe with a beta version of the add-on?
No apologies necessary.

[arallsopp]

Debugging version will be landing here: https://raw.githubusercontent.com/arallsopp/hass-hue-icons/debugger/dist/hass-hue-icons.js

This should spit console information for every icon request.

[pascalwinters]

Debugging version will be landing here: https://raw.githubusercontent.com/arallsopp/hass-hue-icons/debugger/dist/hass-hue-icons.js

This should spit console information for every icon request.

How can I test it with this file?

[arallsopp]

Apologies. Here, this video I made upstream in this issue should help https://youtu.be/bQSeIUks5GY

[pascalwinters]

@arallsopp No console logging:

I created a test dashboard and minimized it all to this, with this dashboard I have also issues.

  - title: hue-test
    path: hue-test
    badges: []
    cards:
      - type: button
        name: Aan
        show_name: true
        entity: light.keuken_dimmer

[arallsopp]

Are you viewing user messages, @pascalwinters? Only I see an awful lot more output than that when I load a dash.

If you're seeing no output to the console, I'm surprised you're getting any icons... I'm going to try installing those other plugins that you have and see if I can break mine.

[pascalwinters]

@arallsopp I have another dashboard with a lot more cards where I haven't this issue. On that dashboard I see the console logging:

I don't know why 🤷‍♂️

[arallsopp]

Lol. That's the output I'd expect to see.

Ok. So I'm going to assume that you're right about home assistant not even calling the function, as any request should have spat out the lines you've given above.

I've just created a dash here to match your button card, and I see the following:

[pascalwinters]

I see a pattern right now.
When I go to my test dashboard, I get no icons. When I press F5, still no icons. But when I go first to another dashboard and do there F5 and then I navigate to the test dashbord then the icons are shown.

[arallsopp]

Ah...

Did you perform this step of the instructions?

• Add the following to your configuration.yaml, save and restart HA.

frontend:
  extra_module_url:
    - /hacsfiles/hass-hue-icons/hass-hue-icons.js

Does the console tell you if it can't find that file?

[pascalwinters]

Ah...

Did you perform this step of the instructions?

• Add the following to your configuration.yaml, save and restart HA.

frontend:
  extra_module_url:
    - /hacsfiles/hass-hue-icons/hass-hue-icons.js

Does the console tell you if it can't find that file?

No I didn't perform that step. I configured it right now, I seems to be better right now.

Maybe it's an idea to create a console message like this:
https://github.com/thomasloven/lovelace-card-mod/blob/94d4fbcb3d550caa1eaf4471db803c0dbdb3ea6f/src/main.ts#L26

[arallsopp]

Glad its working for you now. I think this was a different issue from the one described by @convicte and @spencerthayer.

Thanks for the suggestion. I'll look to see if there's a way to generate the kind of info thomasloven has used from a single script js plugin. I can't test for the filename, as it'll always be the same.

[arallsopp]

@arallsopp

I am sorry for not getting back to you earlier. I hope I did not make you hold off on any commits being released.

Furthermore, I have since updated to 1.2.0 which from what I understand is very similar or identical to the 'alternative branch version' above. This did not resolve my issue. Later I downgraded to 1.16, just to make sure I am really downgrading (since the alternative was marked as 1.2.0 as well), and upgraded back to the alternative - no difference.

In short, neither 1.2.0 nor the alternative branch make any differences. What information would you like me to provide from the expanded logging you mentioned?

Thank you!!

No worries. You didn't hold me off, @convicte. I'm sorry that your issues still persist.

I've installed the same set of plugins as you to see if there's any combination that upsets things, and still see no conflicts. The screen shot below is on the debugger branch of hass-hue-icons, but I'll also go for the main branch before uninstalling those add-ons. I still can't replicate the issue at this end.

Edit: Updated to 1.2.1, updated HA/OS, full restart, still no issues. Sorry. I cannot reproduce this issue.

[spencerthayer]

I don't have time to participate in debugging this issue but I wanted to make sure you know that your efforts are appreciated. I cannot wait to be able to use the hue icon packs again.

[MiguelCosta]

I am using the last version of Home Assistant and I have the same issue, it is impossible to use the hue icons.

[arallsopp]

Thanks for the video, @MiguelCosta. Can I just check that you've performed this step of the instructions?

• Add the following to your configuration.yaml, save and restart HA.

frontend:
  extra_module_url:
    - /hacsfiles/hass-hue-icons/hass-hue-icons.js

(Assuming you're installed via hacs. The file could be somewhere else if you've installed it manually. Easiest way is to click the name of the .js in your source view and find out where it is.)

[MiguelCosta]

Hi, @arallsopp

yes, I install via HACS and I have the statements on configuration.yaml file.

but maybe the path is not correct 🤔

[arallsopp]

but maybe the path is not correct

If it's incorrect, it should show up as a 404 in your console. You can tell if it's working as you'll have two entries for hass hue icons in the console info list. One right at the top, the other in the list of plugins.

[MiguelCosta]

I don't have any 404, so I think all configurations are OK but it is not working

[arallsopp]

One thing that might help is to try a totally different implementation I'm working on here. It uses a different method to get the icons in, and comes as an integration rather than a plugin. It could be that this solves the issue, and if so, I will try to adopt that methodology in the main branch.

To install:

• Remove the existing plugin and any reference to it in configuration.yaml
• Copy the contents of custom_components/hasshueicons/ to <your config dir>/custom_components/hasshueicons/.
• Restart Home Assistant
• Click this:

If you don't mind messing around with your HA, please let me know if this solves it. Or if it doesn't, for that matter, as then I can turn my efforts elsewhere :)

[arallsopp]

For those wanting to try out the alternate install method, you can install the integration version of this repo, manually or via hacs custom using https://github.com/arallsopp/hass-hue-icons-integration. Please let me know if this fixes the issues.

[MiguelCosta]

It's working after use this https://github.com/arallsopp/hass-hue-icons-integration ;) Thanks for your help @arallsopp

[arallsopp]

It's working after use this https://github.com/arallsopp/hass-hue-icons-integration ;) Thanks for your help @arallsopp

Thats excellent news. Thank you for letting me know!

[convicte]

@arallsopp my sincere apologies for going silent. I've been following the thread, but were not able to participate.

The latest integration variant of the package, tested over 30 times, both in the Android app and in Chrome, produced no issues so far.
The icons loaded correctly and there were no missing instances at all.
What I realized is that the locations on my dashboard, which usually caused problems and/or failed to load, were lagging behind the rest of the icons by a minimal, but noticeable moment.
This would point me to think there may be something to it, where in the frontend plugin they would fail to load due to this delay, while now the integration variant has more robust retries or less stringent delay handling.

I am optimistic this will continue working for me, but will report on any idiosyncrasies.
This said, do you have any thoughts on the above observation?

[arallsopp]

@convicte, that is excellent news. You raised a very well documented bug report, and I felt bad that I had not found a solution that would work for you.

I'm really glad to hear it's working again. The integration uses separate methods to prep the icons, clean them, and finally insert them. Potentially this helps avoid a race condition where the DOM was still being manipulated as the icons were placed, and so the inserts were lost.

I still can't find a reason why that would happen, but am so happy that we have found a workaround.

Now I just need to find a neat way to keep the two repos in sync, and make sure that people are aware of the integration version if they're encountering issues. :)

The integration doesn't really suit frequent updates (as it requires a restart of HA each time it changes) but as long as I describe what's changed I guess people can just skip unnecessary versions.

[convicte]

The pleasure is all mine!
I am working with a group of programmers and an international team of support personnel around the globe, so raising a bug ticket is kind of my thing... ;)

I completely agree that heading down the integration route is a hustle, having to update and reboot all the time, while you often spit out versions very frequently (which of course is a plus not a detractor). To this end, if you would ever find a solution or an idea how to troubleshoot it better, please share it, and I'll do my best to test it out, as I would certainly prefer going back to the frontend version for this reason.

Would you consider seeking input from the CORE HA dev team, as your package has a very wide user base? Maybe they could point you in the right direction as the icon processing goes in the new releases. It's noteworthy, I believe, that it only became buggy in the latest 'icon selector' era and not before.

[arallsopp]

Ah, that explains the ability, but I'm still grateful for the diligence. I'm trying to cook up a local version that uses the script from the integration within the plugin structure, but haven't got anywhere yet. I'll link it here as soon as I have something (if I have something)

As you've seen on this thread, often the issue is actually people missing the configuration.yaml step. In fact, that's been the largest group of problems I've seen across the life of this repo. The integration avoids that step entirely, which makes it perhaps a hassle worth enduring.

The second most popular issue is "can I have an Icon for XYZ (where XYZ has nothing to do with Hue)". The integration solves for that as well, as you can serve icons from the <config>/my_icons folder with the prefix my:

It might be that both coexist for a while. I'm hopeful I can solve the script issue, but as I can't recreate it I'm very grateful to be able to have people like you to help.

[arallsopp]

OK. @convicte, when you get the chance, I've created a new branch that holds a reworked version of the plugin script. This file uses the methods seen in the integration's main.js.

The only difference is that I'm missing one await step, as I don't have to retrieve the svg file from the filesystem. I'm hopeful that this isn't the step that fixes things for you, as there are myriad other differences.

If you get the chance, can you disable the integration, reinstall the plugin (with the configuration.yaml step in too), and then replace the script it creates as hass-hue-icons.js with the contents of the file linked above?

Edit: You can install the beta plugin, v.1.2.3-beta, and add the configuration.yaml step.

If that doesn't solve it, the next step for me will be to refactor the plugin to include all of the svgs in the hacs folder, and try to read them in so that the await step is identical.

Hopefully that won't be necessary, and you won't have to keep rolling back and forth between versions.

[convicte]

Hi @arallsopp, I must admit I am at a loss. I had some time today, so I decided to follow the steps as described above.
While uninstalling the integration was straightforward, I was not able to complete reinstallation of the plugin, being faced with the folder location errors related to the frontend command for the configuration.yaml. Simply put, the plugin being installed would not mean that the appropriate files landed where they needed to, particularly hass-hue-icons.js.

I decided to purge everything related to the hass-hue-icons from my HA instance, and proceeded to delete everything.
Reinstalling still did not work, with the same issue, but I realized I missed a crucial step, which was powering down my HA VM to purge anything being in limbo in different areas.

So I cleared everything one more time and 'power cycled' the VM, proceeded to install the plugin and update the config.
This time the folder was created where it should have been in the first place and the error was no longer there. Furthermore, the icons load just fine every time. This is on the main production version of the plugin, not even the customized beta.

It must have been something related to my folder structure and how the plugin was installed on my side. I've been an early adopter of the hass-hue-icons, so it may be that things changed over time, but having never cleared my whole HA since, the later updates just worked, but it was too much for the latest changes.

A lot of assumptions on my part here, I know, but I really have no clue what else it could be.
Thank you once again for all your help.

[arallsopp]

Goodness. Ok, well that is good to know, at least. I'm glad your issues aren't persisting and though we never quite got to the bottom of the cause, it's been an interesting challenge to try and resolve and it's driven my understanding forwards, so thank you.

Happy New Year and thanks for the update, @convicte.

Andy.