2022.9: hide_attributes no longer functional

[Mariusthvdb]

as title, see:

homeassistant:

  customize_glob:

    sensor.*_sensor*temperature:
      <<: &hide
        hide_attributes:
          - templates
      templates:
        icon_color: >
          if (state < -20) return 'black';
          if (state < -15) return 'navy';
          if (state < -10) return 'darkblue';
          if (state < -5) return 'mediumblue';
          if (state < 0) return 'blue';
          if (state < 5) return 'dodgerblue';
          if (state < 10) return 'lightblue';
          if (state < 15) return 'turquoise';
          if (state < 20) return 'green';
          if (state < 25) return 'darkgreen';
          if (state < 30) return 'orange';
          if (state < 35) return 'crimson';
          return 'firebrick';

[Mariusthvdb]

probably the Dom path changed in that selector, need some help correcting

https://github.com/Mariusthvdb/custom-ui/blob/2ea37d41457ccd02c7c459a72254f9eba8fc1c36/custom-ui.js#L86

[Mariusthvdb]

see: https://community.home-assistant.io/t/new-interactive-history-explorer-custom-card/369450/450

I had a quick look at your code. You’re using a very different method to modify the more info panel. You’re basically waiting for a HA expansion tag to open (on any dialog) and then brute force the DOM and see if it’s the attributes on the more info dialog, by walking the DOM with hardcoded elements. That works, but it’s very fragile. It’s basically like webscraping the DOM :slight_smile: As soon as the HA frontend guys change the slightest little thing, it’s gonna break. At a quick glance, comparing the 2022.4 and 2022.11 DOM around this area, it looks very similar. But the slightest change will be an issue.

Another possibility is timing. Your code is very time sensitive. You only try to search the DOM twice, during the first 200 msec after the attributes expand. Then the code gives up. If the expansion takes longer, it’s going to fail.

Things you can do (load the code up on the JS debugger):

Put a breakpoint just below updateMoreInfo, on line 47. Open the attributes, see if it hits. If not, they changed the event. Change the number of retries on line 51 from 2 to some huge value. See if it works now. If it does, it’s a timing issue. Break on line 53. Open the attributes and step line by line, following your DOM walking. See where it fails. Doing this you’ll eventually hit the problem. Do improve the code and make it more robust, directly search customElements for a custom tag close to your target, like for example ha-attributes. Then you can remove pretty much all of the DOM scrapping. In a next step, you could also directly hook into the ha-attributes tag, overriding its prototype. Then you could remove the timing based brute forcing. That’s the way the history explorer card does it.

Thank you @HeyImAlex for your suggestions. hope to be able to test that soon. Appreciated

[alexarch21]

There's a new custom tag with its own shadow root that was added to the DOM: ha-more-info-info.

Here's a PR that should fix it (test please).

This whole thing is a house of cards though. As soon as the HA frontend changes the DOM in the slightest way, it's going to break again. To make it more robust, the whole thing would need to be refactored and the hardcoded DOM walking eliminated.

[Mariusthvdb]

and merged and released. great! thank you very much indeed.

the whole thing would need to be refactored and the hardcoded DOM walking eliminated.

I wouldnt mind if you had suggestion for that ... ;-) as a matter of fact, there's even more to it, if we're talking about modernizing this. As you've fixed the hide_attributes option now, we should be able to do that completely differently.

I'll link an older chat with Bram and Philip from the dev team, in discussions.

pending that, I will close this issue, as its been fixed.