Energy panel not customized?

[Mariusthvdb]

Tbh I hadn't noticed before, but now (ha 2025.12) Energy dashboard has evolved, I see the icons I dont want to see (+, search and Assist), and have configured the Kiosk-mode options for.

The download icon should not be hidden (might be a new option though ;-) )

Would hiding the icons in the Energy dashboard be an option for Kiosk-mode?

or would we have to resort to card_mod, and if yes, would you have any tips to do that most efficiently?

Maybe even in combination with the new options in card-mod to modify the config panels @dcapslock has made available to us

thanks for having a look

[dcapslock]

There are a bunch of Dashboards which are strategy Dashboards where the panel is <ha-panel-xxxx> which in the case of energy is <ha-panel-energy>. There are essentially lovelace dashboards built with a strategy. card_mod works fine with these as it looks for the descendent elemenets hui-root and hui-view. Fro checking kiosk-mode code it only searches for <ha-panel-lovelace>

[elchininet]

Would hiding the icons in the Energy dashboard be an option for Kiosk-mode?

If the Energy panel has a config that can be read and the header elements are the same, with the same name and order as the ones in the Lovelace dashboards, it is possible. But if it has different layout/element ordering is not something to include in kiosk-mode because that would require a complete and separate new styling code.

[dcapslock]

This makes sense. I was thinking code wise before, but of course a strategy dashboard has no config so no where to put kiosk mode config. This will become something to consider as there will be more strategy dashboards in the future and these will likely be where new comers will start and then if they use kiosk-mode they may get confused.

Just a thought, as any dashboard get be retrieved from backend, perhaps allowing for a global settings dashboard that can be used just for global kiosk-mode settings might be a feature and also allow to place config for built in strategy dashboards like home and energy.

[elchininet]

Yes, it's something to consider for the future. But it's definitely something that will create a lot of confusion, because users do not differentiate between these dashboards (that we technically know that are similar) and Media or History dashboards or even Add-ons dashboards like Esp-Home, Frigate, or DeconZ. Every now and then there are requests to hide the header of one of these dashboards and the explanation is always the same: kiosk-mode is intended for lovelace dashboards, a panel that one can curate and set it permanently in a kiosk device, but it is not the scope of the plugin to style or hide generic things everywhere, that should be achieved with flexible approaches like card-mod. Trying to move away from that boundary will open a Pandora box for sure. 🙂

[Mariusthvdb]

I've always live by that rule indeed...

but, using card-mod for the growing number of 'other' dashboards, will move people away from this sweet plugin.
I've already set several in my card-mod theme modifications, and commented that with the requirement from kiosk-mode.

because, setting that for the 'other' dashboards can just as easily include the 'regular' dashboards
and take us back to the modifications we used before Kiosk-mode became relevant/existed.

Maybe we can hookup with the frontend devs, and discuss whether some crafty method could be considered adding custom plugins to those 'other' dashboards?

[Mariusthvdb]

we've found a way to hide the regular icons ni the many bar, and leave only the relevant download button:

  card-mod-root-yaml: |

    .header: |

      .action-items ha-button-menu:first-of-type {
        display: none;
      }
      .action-items #button-1 {
        display: none;
      }
      .action-items #button-2 {
        display: none;
      }
      .action-items #button-3 {
        /*display: none;*/
      }

but the logic isnt obvious. we need to take care with those numbered items, because before you know it, youre in the 2nd ha-button-menu, at that point becoming the first, and messing with the modifications one had set to that 2nd... (because of the change they did several releases ago adding that second menu bar)

if only those button could be targeted by their name/function, and not the number. Because now this breaks the dynamic functionality for the regular panels as this is a brute force method applying to all.

Only way out I now see is adding an extra conditional on the Panel id, for which we need card-mod 4+

  card-mod-root-yaml: |

    .header: |
      {# remove action buttons, except the download button in Energy panels, where
          Kiosk-mode doesnt apply #}
      {% set panelUrlPath = panel.panelUrlPath if 'panelUrlPath' in panel else '' %}
      {% if panelUrlPath == 'energy' %}
      .action-items ha-button-menu:first-of-type {
        display: none;
      }
      .action-items #button-1 {
        display: none;
      }
      .action-items #button-2 {
        display: none;
      }
      .action-items #button-3 {
        /*display: none;*/
      }
      {% endif %}

can confirm that to work: allow for dynamic hiding in regular panels, and hide as is for the energy panel

[Mariusthvdb]

or even make it happen, based on the already existing booleans Kiosk-mode uses:

  card-mod-root-yaml: |

    .header: |
      {# remove action buttons, except the download button in Energy panels, where
          Kiosk-mode doesnt apply #}
      {% set panelUrlPath = panel.panelUrlPath if 'panelUrlPath' in panel else '' %}
      {% if panelUrlPath == 'energy' %}
      /*.action-items ha-button-menu:first-of-type {
        display: {{'none' if is_state('input_boolean.hide_add_to_home_assistant','on')}};
      }*/
      .action-items #button-0 {
        display: {{'none' if is_state('input_boolean.hide_add_to_home_assistant','on')}};
      }
      .action-items #button-1 {
        display: {{'none' if is_state('input_boolean.hide_search','on')}};
      }
      .action-items #button-2 {
        display: {{'none' if is_state('input_boolean.hide_assistant','on')}};
      }
      .action-items #button-3 {
        display: {{'none' if is_state('input_boolean.hide_energy_download_button','on')}};
      }
      {% endif %}

Note: this relies on the button numbering and is very prone to failing if the changes

[Mariusthvdb]

@elchininet please see https://discord.com/channels/330944238910963714/1351536906437005313/1447308757619970150

maybe you can join if you feel like it. I’ve suggested in broad terms what we found here.

[elchininet]

Unfortunately, we are building custom plugins, we need to adapt on the way instead of the other way around. The team will not (and they should not) adapt the development of the Home Assistant native taking into account what would be easier for custom plugins. We need to live with that.

About the balance between keeping the plugin focused, and therefore easy to maintain and to adapt quickly to Home Assistant changes, and bloating the plugin with functionalities that would likely break on every Home Assistant update and would make the development tedious and hard to maintain, it's a trade of. I think that with the current architecture of this plugin, it's in a status that it's enough and it should not pursue to do more.

If one wants to have simple options that one sets in true or false and the plugin does all the complexity of selecting which elements need to hide, that comes at the cost of making the plugin very focused and with a very light and rigid internal logic. If one wants to hide almost everything, in every panel present or future, that comes at the cost of making the plugin very flexible, then it cannot be done with simple options, it should be an API that allows users to make those selections in their side and if Home Assistant changes, it is up to users to change those selections and make them work again. Having both worlds it is just impossible to maintain, the development speed of Home Assistant will make any plugin that tries to pursue to do what card-mod does with simple options obsolete every month, and then, as custom plugins are not developed by a big team of developers but just by a few enthusiast developers that do that work for hobby, such plugin will be abandoned as always occur in those cases. My recommendation in this matter is: if someone needs a complex set up and hide whatever they want in every panel, then kiosk-mode is not for them and it is OK if they move away from kiosk-mode to any more flexible solution because it's what they should do in that situation.