Custom Header

Thank you @maykar. I’ve settled with width: 500px.

Also is it possible to reduce the space between the header and the tabs?

Technically, yes, but you are going to have to mess with css all over the shop. Any time you mess with the actual headers height, it will require quite a bit more tinkering than you bargained for.

  fit_tabs: true
  tab_container_css: 'width: 500px !important; margin: -13px auto 13px auto !important;'
  header_css: 'height:35px;'
  footer_css: 'height:35px;'

Using the code above as an example: While your header will be slightly smaller and your header and tabs are closer together, you’ll notice that now the main view (where the cards live) no longer fills the page. To fix that, you’d have to mess with the css of “view_css” and “panel_view_css”, as well as the possibility of adding more css to header_css, footer_css, tab_container_css, etc.

It would take trial and error as well and some css knowledge to pull it off. While I can’t tell you if it’s worth the effort for you, I can tell you that I won’t be going through the pain of doing it for you :slight_smile:

That’s not the only way to achieve what you’re looking to do, I’m sure, but just one example.

1 Like

No worries. This isn’t related but I feel like I should ask: Does less YAML in the frontend equate to faster loading when the same code is repeated 10 times?

I guess it really depends on what’s being repeated. What are you repeating in your YAML?

Style code, mostly.

I imagine using card-mod on each of those cards could cause slower load times, but that would be less about the amount of YAML and more about card-mod inserting the styles into each card. Even if you were to use methods to slim down the amount of YAML (YAML anchors, decluttering-card, etc ) it wouldn’t result in faster loading times.

You use quite a few custom cards and other frontend additions and I think that would be more of the cause than amount of YAML. If you’re looking to speed things up you could try disabling some custom cards, just to see which ones are causing the biggest slow down, and then try to replace them with a core HA card.

Also, I didn’t make config-template-card as your readme suggests. That one is made by iantrich.

1 Like

Hi Guys

Home Assistant 0.115.3
I just installed version 1.8.0.

custom-header.js is in /www/ folder with right owner and permissions

Inside ui-lovelance.yaml I have:

  - url: /local/custom-header.js?v=1.8.0
    type: js 

  compact_mode: true

I am receiving this error after I restart HA and try to open HA page

2020-09-25 14:34:38 ERROR (MainThread) [frontend.js.latest.202009182] Uncaught SyntaxError: Unexpected token ‘export’’

Some idea ? Already tried to clan cache.

type: should be module not js and resources are no longer placed in ui-lovelace.yaml they now go in configuration.yaml when using YAML mode:

1 Like

Thank you ! I own you a coffee :slight_smile: It is working.

Hello, sometimes after reloading the page the custom header does not load and I have to reload again, when it does not load correctly this is the error that appears in the log:

Logger: frontend.js.latest.202009182
Source: components/system_log/
First occurred: 21:18:47 (1 occurrences)
Last logged: 21:18:47 Uncaught TypeError: Cannot read property 'querySelector' of null

Does this happen to someone else?
this is my configuration:

  #view_css: 'padding-top: 85px;'
  hidden_tab_redirect: false
  options_hide: true
  chevrons: false
  compact_mode: true
  background: /local/black.png
  voice_hide: true
  active_tab_color: orange
  all_tabs_color: 'rgba(245,245,245,0.2)'
  tab_indicator_color: transparent
  menu_color: 'rgba(57,128,228)'



  • go to Developer Tools
  • refresh
  • go back to your dashboard

→ CH deactivated

  • refresh

→ CH active

I can live with it. :+1:

@pollinolas @VDRainer

This shouldn’t be something that is lived with, it is an issue that needs fixing and should be reported on Github with the required information. That way I may troubleshoot and fix the problem. Can’t fix what I don’t know about or don’t have enough information to replicate. The more info I have the better chance I have to find and fix the issue.

This doesn’t happen on my system, if it did I would implement a fix ASAP.


Probably unrelated, but to use a background image you need to use proper css:

  background: url('/local/black.png')
1 Like

I have already changed it as you have suggested and as you have predicted, the same thing continues to happen exporadically.
Thanks again for your work and support.

is this a known error:

local/lovelace/resources/custom-header/custom-header.js?v=1.8.0:146:79779 TypeError: undefined is not an object (evaluating 'm.user')

at startup? using HA 115.3 and CH 1.8.0

That’s one that may fall under what is being fixed in the latest pre-releases. Give it a go if you’d like 1.8.2

ok let me try, thanks
meanwhile I have another question:

using 3 dashboards, I have 3 custom-header files corresponding with these.
Yet, in all 3, I have a large set of identical code (mainly the core input-booleans discussed earlier)


## all default
disabled_mode: >-
kiosk_mode: >-
compact_mode: >-
shadow: >-
footer_mode: >-
split_mode: >-
disable_sidebar: >-
hide_header: >-
hide_help: >-
hide_unused: >-
hide_refresh: >-
hide_reload_resources: >-
hide_config: >-
#hide_raw: false
default_tab_on_refresh: false

menu_hide: >
voice_hide: >-
options_hide: >-
menu_dropdown: >-
voice_dropdown: >-
reverse_button_direction: >-

Do I need to set all that 3 times, or can I have a ‘master file’ with all settings identical for all dashboards globally, and only use specific settings in those separate files?

or, should I create a custom_header_global, and add all of those settings, and then call 2 files in the dashboard, like:

  - !include lovelace/includes/custom_header_global.yaml
  - !include lovelace/includes/custom_header_data.yaml #specifics

I tried this, but it doesn’t work fortunately, seemed rather elegant though?

I’m not an “advanced” yaml user myself (use storage mode mostly), but I’m not sure you’re going to get there with includes. For example, this isn’t possible:

  !include lovelace/includes/custom_header_global.yaml
  !include lovelace/includes/custom_header_data.yaml

While this would be, but you wouldn’t be able to define anything after it:

  !include lovelace/includes/custom_header_global.yaml

This is definately a question for a different thread, but maybe something like decluttering-card, YAML anchors, or similar might be able to help you here.

For example, you can do some fancy stuff with anchors and the like. Made this one real quick by following Thomas Loven’s guide on YAML:

ch_1 dictionary: &ch_1
  compact_mode: true
  background: green

  <<: *ch_1
  footer_mode: true

Maybe a combination of includes and any of the above?

well, thanks, but that isnt going to do what I am seeking for I am afraid. Rather extensively using anchors throughout the setup.

Maybe I should explain better:

these are my 3 dashboards, the ui-x files:

Schermafbeelding 2020-09-29 om 17.24.35

each of them has this in their global settings:

title: Ha Rpi4 Data

button_card_templates: !include lovelace/includes/button_card_templates.yaml
decluttering_templates: !include_dir_named lovelace/decluttering_templates
custom_header: !include lovelace/includes/custom_header_data.yaml # <---- this one, of course depending on the dashboard

so I have 3 custom_header configs:

these contain settings specific for the dashboard, which is unique in these files. However, they all 3 also contain identical settings that are global, for the full instance.

Because of this, I cant use yaml anchors (they need to be defined and merged in the same file.)

another option maybe would be importing a ‘global’ file in the dedicated files maybe? we do that all over the place, so why not in the custom_header: file?

like this which would be like the button-card uses button-card-templates.
we’d only need a new ‘key’ to be able to to so. maybe custom_header_template: :slight_smile:
in ui-lovelace.yaml:

custom_header: !include lovelace/includes/custom_header_specifics.yaml

and in custom_header_specifics:

custom_header_template: !include lovelace/includes/custom_header_global.yaml

Although it’s not what it’s intended for, might it be possible to have your global settings as “secrets” in your secrets.yaml file and then the file for each could have things like:

disabled_mode: !secret custom_header_disabled_mode
kiosk_mode: !secret custom_header_kiosk_mode


This would potentially make it easier to manage if you need to change one of the templates.

Ha yes, I did think of that, but it would still require 3 times the exact same code.

Btw indeed using the secrets in other places like that ;-€