A tip for splitting up your Lovelace config

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 :+1:

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.

Good point - yes, that’s how it’s done in typical Linux configs like upstart etc.

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. :slight_smile:

which is cool indeed.

an I am learning! so if you wouldn’t mind, what does your complete ui-lovelace.yaml look like then?

do you have an include for your resources too? Ive tried that but with mixed results, especially when the custom updater card wouldn’t follow suit.

1 Like

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.

  # Home
  - title: Home
    id: home
    icon: mdi:home
    cards:

      # Left Stack
      - type: vertical-stack
        cards:
          - !include lovelace/views/home/people.yaml
          - !include lovelace/views/home/camera.yaml
          - !include lovelace/views/home/homestate.yaml
          - !include lovelace/views/home/climate.yaml

      # Middle Stack
      - type: vertical-stack
        cards:
          - !include lovelace/views/home/tv.yaml
          - !include lovelace/views/home/lights.yaml
          - !include lovelace/views/home/room_states.yaml

      # Right Stack
      - type: vertical-stack
        cards:
          - !include lovelace/views/home/devices.yaml
          - !include lovelace/views/home/priority.yaml
5 Likes

Sure… My complete ui-lovelace file looks like this:

resources:
  - url: /local/mini-media-player-bundle.js?v=1.0.0
    type: module
  - url: /local/vertical-stack-in-card.js?v=0.1.1
    type: js
  - url: /local/tracker-card.js?v=0
    type: js

title: My House
views:  !include_dir_list ui-lovelace/

I haven’t bothered splitting off the resources yet because I don’t have enough of them.

Q

1 Like

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

cards:   - !include /config/lovelace/includes/dark_sky_custom_card.yaml

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).

Hi, I would like to achieve the same results but I can’t figure out how the single card.yaml should begin.

I see error in frontend.

Can you teach me how you did it?

Here you go!

2 Likes

Are some of you using Compact Custom Header?

I couldn’t get it to split lovelace configuration, I believe because of this resource.

Already know that it is possible. I will check my CCH config.

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.

can you post your ui-lovelace.yaml file so we can see if there might be some kind of issue there.

i almost never touch my ui-lovelace file to make changes unless i am adding resources for a custom card.

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.

can outsource even that:

resources: !include /config/lovelace/resources/resources.yaml
1 Like

Yes, I switched back to !include, and it detected changes for a while, but that seems to have stopped on recent versions.

At some point I’ll dig into the code and work out why… or switch back to !include_dir_list !

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.