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:
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
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:
:
in ui-lovelace.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:
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 ;-€
mayker
(maykar (pronounced "maker" with a southern accent))
1085
So, if I were to implement something like this, say as a separate config like you mention above:
Instead of custom_header: there would also be a custom_header_template: configuration and it would essentially act as modified default CH settings. This would still be per dashboard (but could be imported to others via !import) and any setting that was also set in custom_header: either by plain config or by exception would overwrite what is set in custom_header_template:.
Will think about it and may limit this to only YAML users.
yes! thanks, that would be so awesome, and allow for more elegant and efficient multiple configs.
please let me know how I can assist to test. I’ve prepared my files
I’d use the custom_header_template: for the global config, import it in all other dedicated custom_header: files.
beautiful !
mayker
(maykar (pronounced "maker" with a southern accent))
1087
I think I’m more inclined to call it custom_header_defaults: as that would describe the interaction a bit better, but I’ll let you know for sure when I have something going.
mayker
(maykar (pronounced "maker" with a southern accent))
1089
As a heads up, in the next few versions of HA there will be quite a few changes that will affect CH. I will be trying to stay ahead of the changes and get it updated as quick as possible. Just be aware and don’t blindly update HA to beta’s or new versions if you rely on CH. I will post here and in the release notes when changes have been made to accommodate new versions. Just wanted to ask for patience before the changes start, thank you.
4 Likes
mayker
(maykar (pronounced "maker" with a southern accent))
1090
Looks like CH will be in the clear for 0.116 and if anything changes I’ll let you know. For now it seems that post may have been a false alarm (or, really, just an early one ).
So I have added /local/custom-header.js?v=1.8.3 to URL and JavaScript module under lovelace control panel and resources. I have downloaded custom-header.js?v=1.8.3 and put it in WWW.
But CH is not working? I can’t see it on the tripple dots in the right corner or on the left in the menu bar.
What am I doing wrong?
mayker
(maykar (pronounced "maker" with a southern accent))
1092
Do you get any errors in your logs or in your browser’s dev tools console (F12)?
This is confusing, your resources should only be set in one place (if using recent HA versions) and that would be in configuration > lovelace dashboards > resources.
That isn’t what you named the file in /www/ right? It should just be custom-header.js.
I am new in custom header. How can i simply create different custom header settings for my tablet and for me? For my tablet i want to enable kiosk mode and maybe some another settings.
Another question, when you do hide header true or kiosk mode, you don’t have the ability to edit dashboard / raw. How are doing peaple that?
mayker
(maykar (pronounced "maker" with a southern accent))
1095
Read the very first post in this thread, especially the part marked “Important”. Then visit the docs link in that same post. In the config section of the docs it explains how to use exceptions per device, etc with examples.
Also if you want to skip to the answer for your last question, go to this link.
If you’re still having issues, come back here and post what you have tried and what isn’t working.
creating my own button shortcut menu bar (in addition to the CH menu) we’re ow able to use a tooltip, thanks to Romrider’s latest addition.
I found out that using
- transition: opacity 0.5s
makes the tooltip appear almost immediate, while a default was set at 1.5 seconds. This feels an eternity when you want to see the tooltip…
As with the tooltip in CH, which is also rather slow. Can we use the above CSS also in CH settings, to override the default settings? Ive checked the advanced styling options, obviously…
If not, would you please allow for this in the options? thanks for considering!
Hey @mayker It looks like transparent background is not working on 0.116 Beta. No errors in the log sorry.
mayker
(maykar (pronounced "maker" with a southern accent))
1098
Yeah, I’m going to need to make some changes for 0.116. It’s not that the transparency isn’t working it’s that the view doesn’t fill the space behind the header. I’ll be on it soon.
mayker
(maykar (pronounced "maker" with a southern accent))
1100
I have come to the difficult decision to stop work on Custom Header. In the next few days I will be archiving the project. I invite anyone to try and resurrect it or, better yet, take parts of CH and make separate projects to cover small groups of related features. Who knows, maybe I’ll work on some of those as well.
Custom Header has become a beast to try to support and update, it is an absolute mess of code. The next HA update will both break CH and CH will be the cause of major performance issues even if fixed (without a major rewrite). What started out as a simple project to make the header smaller ballooned into this feature bloated monstrosity you see today, mostly for my inability to say no to any feature request.
Since the start of Hacktoberfest I have been working on adding things to HA itself and found myself working on changes that would make things in Custom Header obsolete (some are already) and I’m really enjoying the process.
Thank you all for the support, conversation, and experience this project has given me. I couldn’t code when I started this project and now I’m working on finding jobs in the field. I’m sad to see it go, but trust me it’s for the best. Both for myself and for Home Assistant.
Edit: I’m not going anywhere and most of my other projects will still be around and maintained.
Literally the only thing I’ve used custom header for is to hide the pointless header, notwithstanding the other great features. Thanks for all your hard work, and am excited to hear you’re working on core stuff instead. The more help they have there the better everything will be for everyone. If you could convince the core team to add an option to hide the header that would be just peachy though!
