My Lovelace config file, ui-lovelace.yaml, was getting rather large, so I decided to split each view (tab) into its own file.
The neatest way, I thought, was to create a ui-lovelace/ subdirectory and put one file per tab, then I could just use !include_dir_list to include them all.
This didn’t really work, though, because there was no way to control the order of the tabs! The list of files returned by !include_dir_list was undefined. So I contributed a tiny change to the code which meant that the files were returned in predictable alphanumeric order - you can change the order by renaming the files. This has now trickled through into the latest releases.
So my ui-lovelace.yaml now looks roughly like this:
title: My House
views: !include_dir_list ui-lovelace/
5500 lines and I’m still using storage mode on a pi
I guess I like the ability to add cards through the GUI too much. Though I do copy out the card configs to an editor and paste back when I’m finished fiddling. Maybe I should change to yaml mode.
hmm, not really sure I understand why having to rename and possibly even number your includes would be preferable to what I do and you did before: simply listing them in the correct order …?
ok cool, what works for you, but can’t help feeling you’re overcomplicating things…
in my setup, I only need to create the views in 1 place also, and don’t have to name them for a specific order, nor have to number them.
anyways, if the update has landed, will see what the change might bring.
at least we’re both saved from these horrendously large and unmanageable ui-lovelace.yaml files
The only problem with this is that if you want to change the order and insert something in between home and downstairs you have to rename every file. I would suggest you use something like
010-
020-
030-
040-
050-
then at least you have a little more space to play with.
Hi Marius - yes, I do see your point, but I like the fact that if I want to rename the file, I only need to do so in the filesystem. If I remove or add a tab, I only need to do that in the filesystem. Changes checked into git only record the change to the file concerned. If I want to generate new views automatically, they only need to create one file, and so on.
But there are lots of counter-arguments, so I’m not disagreeing - just explaining my own rationale.
I actually have it split up per card instead of per view since I use a lot of vertical-stack-in-card to add a custom header to my cards. Takes a bit more work in ui-lovelace.yaml but you have a bit more granular control. Depends on what you’re looking for I guess.
yep, that possible too, as are individual includes for, let’s say, a weather card config. Makes it very easy (and safe…) to edit those and not mess-up if you make a mistake.
Another cool use for this is handing the same card show up on different locations, and only having to define it once. Simply include it on different spots if you desire to do so. Like
I’ve discovered a minor downside to my splitting-up technique: not sure if it applies when you use !include instead of !include_dir_list:
When I edit one of the files that’s included, Lovelace doesn’t notice and if I reload the web page, it hasn’t changed. I have to go and make a trivial change to ui-lovelace.yaml to cause Lovelace to reload.
If it tracks updates on !included files, that might be sufficient reason to switch back… I haven’t had a chance to investigate yet.
I can report that the way I do it using !include I’ve never had Lovelace not “notice” changes to the files.
I change an included file and hit the “refresh” button and the new change takes effect immediately (unless of course the change was adding a new “resource:” entry…then it takes a HA restart to actually load the new resource).
