hide individual attributes from more-info dropdown

[Mariusthvdb]

just a thought to consider please, given the fact this Kiosk mode plugin can hide a great many things, but does no want to 'card-mod' stuff:

would it be feasible to hide individual attributes from the dropdown?

example: we see the new enum device-class add a list of possible values to the attributes. To me these are more 'backend' attributes, (just like device_class itself is, a filtered attribute) and I don't need/want them in the dashboard . Ive filed a FR/discussion in the Frontend repo, but figured it might suit this Kiosk mode plugin just as well.

It (more-info updating) is a part of my own custom-ui to be able to do so, and Ive even made a separate js script. However, that is not up to the modern Dashboard implementation, and has its downsides.

I was hoping Kiosk mode would be the best candidate for an addition doing so, in a perfect , smooth and modern way. Just like anything else Kiosk mode does

thanks for reading thus far...

[elchininet]

Hi @Mariusthvdb,
What dropdown are you referring when you mention "more-info dropdown"?
Some screenshots can help to identify which UI element you are referring to.
Regards

[Mariusthvdb]

sorry, I figured that was obvious, my pardon..

consider a weather condition showing the attributes dropdown

and then clicking that only reveals the enum values:

which imho are not very relevant for the Frontend, and required only when you need to do some template evaluation or what ever in the backend.

there are many examples for this enum attribute:

being able to keep those out of the Frontend would clean up those cards a lot.

I do realize it requires some magic to not only not show these attributes, but also Hide the attributes box completely, if it were the only attribute....

see our earlier discussion on that subject

[elchininet]

Hi @Mariusthvdb,

Thanks for the screenshots, everything is clear.

In my personal opinion, the content of the attributes is something that most users would want to hide altogether in Kiosk-devices (Mac addresses, hosts IP, serial numbers, events ids, etc), that is why there is an option that allows one to hide them. But hiding specific items of the attributes, not only is out of the scope of the plugin, but it will open a Pandora box because there are tons of attributes and each integration can add any number of them.

But that is something that could be added to the Kiosk-mode complements though, maybe addressing the issues that make your current implementation not up to a the modern dashboard implementation.

@NemesisRE has the last call on this one, but this is just my opinion on this matter.

Regards

[Mariusthvdb]

sure, thanks for your in-depth reply, as always

my thought would have been to set an option for hide_attribute, and let the user add a single or list of attributes. Not that Kiosk mode would set a predefined attribute.

In core HA, there is a 'filtered attributes' list, and my hope was to add the manual addition to that list of filtered attributes.

I believe this can not be done with Card-mod, since that only manipulates frontend

see: https://github.com/home-assistant/frontend/blob/dev/src/components/ha-attributes.ts

and extra_filters

whihc in the end all uses https://github.com/home-assistant/frontend/blob/aa4acc65724964339014b4a9724cc1e4182342ec/src/data/entity_attributes.ts#L1 as list of filtered attributes.

seems that instead of doing what my update_more_info currently does:

    if (t.length) {
      let e;
      for (const node of t) {
        const o = node.getElementsByClassName("key")[0];
        if (o.innerText.toLowerCase().trim() == "hide attributes") {
// make compatible for both 2023.8 and 2023.9
          const valueContainer = o.parentNode.getElementsByClassName("value")[0];
          const haAttributeValue = valueContainer.querySelector('ha-attribute-value');
          const text = haAttributeValue
            ? haAttributeValue.shadowRoot.textContent
            : valueContainer.innerText;
          e = text
            .split(",")
            .map((item) => item.replace("_", " ").trim());
          e.push("hide attributes");
        }
      }
      for (const node of t) {
        const o = node.getElementsByClassName("key")[0];
        if (
          e.includes(o.innerText.toLowerCase().trim()) ||
          e.includes("all")
        ) {
          o.parentNode.style.display = "none";
        }

is we could set that extra_filter like core does it (example here of the person entity)

<ha-attributes
--
.hass=${this.hass}
.stateObj=${this.stateObj}
extra-filters="id,user_id,editable,device_trackers"
></ha-attributes>
`;

and then even do that generically, and not only for a single domain.

but I am no dev so dont know how to reliably do so ...

[NemesisRE]

@elchininet is doing a damn good job at hiding almost every element of HA but at some point we have to think about our goal and the goal was "kiosk mode" which means "No touching, only look" originally that was only header and sidebar now we are more and more going towards RBAC and that could be fine if we would switch focus.

I for one think we should not switch focus but as long the code is easily manageable and new HA versions or different cards don't break the code every time we could add even RBAC stuff. We should also keep in mind that this just a lovelace mod and no real access control system if some one thinks this makes HA secure they would be misguided.

the Kiosk-mode complements on the other hand can be extended with everything, what could help.

[elchininet]

I believe this can not be done with Card-mod, since that only manipulates frontend

Hi @Mariusthvdb,

What is the part that you believe cannot be done with card-mod?

Because that is precisely what kiosk-mode does, we have access only to the DOM and we only manipulate front-end stuff 🙂

[Mariusthvdb]

@elchininet is doing a damn good job at hiding almost every element of HA

I couldnt agree more! amazing indeed.

What is the part that you believe cannot be done with card-mod?

I don't think card_mod can add attributes to the extra-filters as linked in the files above? If so, it would be amazing, but I've never been able to manage that...

maybe a tiny custom integration/custom card could do that, it would probably only require a few lines of code.
But as said, I cant make that lacking the dev skill set for such an undertaking.

[Mariusthvdb]

wow, I do believe it works as we had hoped for!
on my season entity, no more options, and indeed, no drop-down attributes box

no more icon_color anywhere.!

this is truly great, I now have to figure out what you did ;-)

btw I had already opened a repo at https://github.com/Mariusthvdb/custom-attributes but if you like, please keep it at yours ofc course.

I have 2 questions:

1. since we hardcode filter 'options' now, this seems to also filter out the options on an input select. That is undesirable as far as I am concerned, though nit entirely unexpected.... I only wished to filter out the options of enum device_class.

2. directly related to hard coding the filters, Id love to be able to set them via customize in yaml. that way we can do things like:

homeassistant:
  customize
    '*.*':
      filter_attributes:
        - icon_color

  customize_domain:
     person:
       filter_attributes:
         - source

not sure how to get to the enum values, without touching the (input_)selects though. Maybe you would know of a way?

Ill play with the for now, and try to find the correct spot where you set the current filters so we have a thoutough idea of the functionality. (I'll even re-install the former custom-ui to see if it can filter the templates too! that would be awesome

thanks for now, hope you had a bit of fun too

update

Yes, it also filter the templates attribute we set in custom-ui. so that makes it even better.

[elchininet]

I now have to figure out what you did ;-)

Just go to src/custom-ui-filter-attributes.js and you can check the code.

btw I had already opened a repo at https://github.com/Mariusthvdb/custom-attributes but if you like, please keep it at yours ofc course.

Move the files to your repo, I created that repo just for make a quick set up so you could test the code.

since we hardcode filter 'options' now, this seems to also filter out the options on an input select. That is undesirable as far as I am concerned, though nit entirely unexpected.... I only wished to filter out the options of enum device_class.

You need to explain this a bit (we can do it later in a discussion in your repo), and I can recommend you a solution, but I need to understand what you are searching for, I addded options just because it was in your original code.

directly related to hard coding the filters, Id love to be able to set them via customize in yaml. that way we can do things like.

Configuration is possible, but a front-end configuration in a lovelace dashboard (like the one in kiosk-mode or keep-texts-in-tabs), but if you are referring to any back-end yaml config, we cannot read those.

not sure how to get to the enum values, without touching the (input_)selects though. Maybe you would know of a way?

I don‘t get the question, let‘s discuss it in your repo, just move the code there and we can discuss in the correct scope.

thanks for now, hope you had a bit of fun too

Welcome, glad to help 👍

[Mariusthvdb]

done, I copied the files an all is set at https://github.com/Mariusthvdb/custom-attributes
if you wouldn't mind I could share the site with you, make you a contributor?

you could also move this discussion maybe to he other repo, so your repo here can be cleansed a bit ;-)

[elchininet]

You can add me as a contributor, I wouldn't mind.
I‘ll move the discussion to yours.

Edit: I cannot do it, it says "Move this discussion to another repository owned by Steven "NemesisRE" Kurz.".

[Mariusthvdb]

that is a pity. I'll see if I can copy some of the more important aspects into some background document then, or discussion.
meantime you've been made a contributor ;-)

[Mariusthvdb]

We should probably close this discussion and refer to https://github.com/Mariusthvdb/custom-attributes

[elchininet]

Makes sense 👍🏼