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).
I splitted my lovelace configuration using !include and I have the same problem as you. Changes in included files are not noticed by lovelace, even when the page is refreshed (also using CTRL), different from what @finity said. I need to do any cosmetic change in ui-lovelace.yaml in order to the change be loaded. That’s a bit annoying.
I don’t think it would help. No error is reported. We are talking about how the changes to take effect. And for this to happen, some minor change must be done in lovelace.yaml.
It seems HA can only check for changes in ui-lovelace.yaml. It can not detect any changes in included files.
However you can use the refresh option from the three dot menu in the top right to update any included files.