Puzzled about non working include

I am trying to setup the following folder structure and am unable to find out why an include does not work.
…/dashboard/views/
If I put this in dashboard/dashboard.yaml it works

views:
    - title: Mobile Test
      path: mobile-test
      icon: mdi:cellphone
      cards:
        - type: markdown 
          content: |
            Test view from **Mobile dashboard** 

Now I change dashboard.yaml to

views: !include_dir_merge_list dashboard/views

And in views add a yaml with the following content

- title: Mobile Test
  path: mobile-test
  icon: mdi:cellphone
  cards:
    - type: markdown 
      content: |
        Test view from **Mobile dashboard** 

Then it does not work. Someone any idea why ?

if I remember right a

something: !include_dir_named DIRECTORY

works, while a

something: !include_dir_list DIRECTORY

fails until you turn it into a

something: !include_dir_list DIRECTORY/
#                                     ^
#                                     |

What I’m unsure about (not tested) if a path (e.g. SUBDIR/SUBSUBDIR/) is allowed, since it says dir_list not path_list, but you could give it a try.

Thank for your reply. The trailing slash didn’t help. I did some more testing an noticed the following.

If I put my ‘views’ directory in the root of the config directory and set the include as

views: !include_dir_merge_list views/

Then it worked.

After this I moved the views directory one level deeper to
custom_yaml/views

And changed the include to

views: !include_dir_merge_list custom_yaml/views/

And then it does not work. Do I need to use relative paths ?

See my other post. I am now struggling several days to get an include working which is more than one directory entry deep from the base config directory.

For some reason it does not work, but I have no clue why. No error message, nothing in the log. It is a lot of trial and error.
Are there any options to debug this (e.g. see which yaml files are processed, which directories are processed) ?

It is hard to imagine for me, that no one uses an hierarchical directory structure to keep thing organized.

Any suggestions will be appreciated.

check this organization

in the highlighted folder I have this:

##########################################################################################
# Dashboard Settings configuration file, simply drop in a view, and ordered by number
# in the folder
# @mariusthvdb
##########################################################################################
# require_admin: true set in package_dashboard_config.yaml

button_card_templates: !include_dir_merge_named ../button_card_templates
decluttering_templates: !include_dir_named ../decluttering_templates
kiosk_mode: !include ../kiosk-mode/kiosk-mode.yaml
custom_more_info: !include ../custom_more_info/custom_more_info.yaml

keep_texts_in_tabs:
  enabled: true
  mobile_config:
    enabled: false
  override:
    - Test 2
    - Test 10
  exclude:
    - Map mods

views: !include_dir_merge_list ui-test

which makes these folders show up as tabs in the dashboard

so, just make sure the position in the structure from which you reference the include is correctly pointing to the path of the folder you require.

also check the other includes, with the leading ../

they point to the folders below this:

Thanks for your reply. Based on your info I started testing again and found out why it was driving me nuts :slight_smile:

I use a similar structure like you. When referring to your example, I noticed that changes in the yaml file in the ui-test directory are not visible unless I modify ui-test.yaml.

e.g.

  1. edit the view in ui-test
  2. “developer tools” → “quick reload”
  3. Open the page and CTRL+F5 (reload with clear cache)
  4. Changes made are not visible
  5. edit ui-test.yaml
  6. Change !include_dir_merge_list ui-test into !include_dir_merge_list ui-test/
  7. Changes made earlier are visible after ‘quick reload.’

At first I thought due to the trailing slash, however repeating the procedure with removal of the trailing slash had the same effect.

When not modifying the file containing the !include, then the changes in the included file are not visible.

that would be not what I see. I can change anything in the yaml, and a reload (‘opneuw laden’ top right menu 3 dots)

will immediately take effect

Interesting. I didn’t use the 3 dots on top of the page, but triggered the reload from the developer menu. Just tried it with the 3 dots “reload resources” to see if it makes a difference.

I edited the displayed text in my view. Requested the reload, confirmed the question to refresh the page… nothing changed. Then CTRL+F5 to force a browser refresh… no change. .
Did the same exercise 3 more times, text remained unchanged.

After this, opened the file containing the include. Added a space to a comment line and saved it. Reload resources… no change. CTRL+F5 change became visible.

It really is very reproducible and seems HA checks if a file was changed before processing (and not taking the includes into account)

If this is the case, then it still unclear why it seems to behave differently at your side. Is it a different version ?

I use:

  • Core2025.9.4
  • Supervisor2025.09.0
  • Operating System16.2
  • Frontend20250903.5

Just found this thread from 2020 where some users report exactly the same symptom. @Mariusthvdb did not experience the problem at that time either.

https://community.home-assistant.io/t/lovelace-include-views-loads-very-slow-and-often-need-restart-of-ha-to-show-up-is-it-normal/161425

There is a similar discussion in 2023.

Based on both discussions (and myself) it seems some people see this symptom consistently, while others do not see it at all.

I do not know whether some caching mechanism is used for YAML, bit it feels like a kind of caching issue, which might behave differently based on OS or filesystem. I am running HASSOS in a KVM VM.

no that wont do it, you really need the ‘Opnieuw laden’, which is the ‘Refresh’ menu item in English
And indeed a plain browser window reload doesnt kicking the yaml changes either,

other than that, and I am not running in VM, but on a MiniPC there isnt much to say.

btw, the quote above is me running 3 RPI’s, so no VM either.
Yaml mode throughout

Thanks, I will check again.

I the mean time did a quick peek into the source code (actually the first time I looked into it, so my understanding might be wrong as well)

  def _load_config(self, force: bool) -> tuple[bool, dict[str, Any], json_fragment]:
        """Load the actual config."""
        # Check for a cached version of the config
        if not force and self._cache is not None:
            config, last_update, json = self._cache
            modtime = os.path.getmtime(self.path)
            if config and last_update > modtime:
                return False, config, json

As far as I am aware, os.path.getmtime() is not fully recursive. I do not know what the provided ‘path’ is here, but if it’s the config basepath it might explain my observations.