It seems that you're not able to have a package with the same file name as another.
For example, I had something like like this, which worked fine:
/config/packages/hallway/light.yaml
Then I added a light for another room and the new light in conservatory works fine, but the hallway light no longer appears in Home Assistant.
/config/packages/conservatory/light.yaml
/config/packages/hallway/light.yaml
If I call either file something different, it starts to work as expected. For example, this works:
/config/packages/conservatory/light.yaml
/config/packages/hallway_light.yaml
And this works:
/config/packages/conservatory/lights.yaml
/config/packages/hallway/light.yaml
I can't see anything in the documentation that says you aren't allowed to have packages with the same file name, so I would expect this to work.
configuration.yamlhomeassistant:
packages: !include_dir_named packages
Package 1:
automation:
#...
Package 2:
automation:
#...
Conversation on Community forum: https://community.home-assistant.io/t/missing-automations/162046
This is expected.
include_dir_named finds all files (including the ones in subfolders), and uses the file name as the key element in the YAML. Having files names with the same name inside a directory structure will cause duplicate key elements in YAML.
IMHO, this is not a bug, but incorrect use of the include_dir_named.
Hmm. I think it feels to me like it's a bug because, in general, everyone knows it's totally valid to have two different file with the same name in two different folders.
Would it be possible to use the directory name in the YAML key? If not, I think it should at least be well documented that you can't have more than one file with the same name, and probably it should have a warning in the logs saying "the config in file directory/file.yaml wasn't loaded because...".
Maybe include_dir_named shouldn't be able to read files from subfolders? That would fix the problem, but is a pretty bad breaking change.
Is there another way to do what I'm trying to do? It seems like I'm trying to organise my config differently from all the examples on Splitting up the configuration. Someone on the forum suggested include_dir_merge_named, but I'm not really sure if that does what I want either.
Should I be doing something like this?
packages:
- !include_dir_named packages/conservatory
- !include_dir_named packages/hallway
- !include_dir_named packages/kitchen
Thanks.
Agree with @jjok
This isn't expected behaviour from a user-perspective. If this indeed is desired behaviour (which still is weird) it should then at least error out, fail, crash or something letting the user know it is using this in a manner which wasn't intended. But it all cases, it should definitely not silently ignore the file.
I spent a few hours banging my head as why this specific file was different (permissions, ownership, acls, FS errors, line break chars, syntax error in the file. It was a wild guess to rename the file, but nothing had pointed me to my misuse of !include_dir_named
Ah, include_dir_merge_named in
https://www.home-assistant.io/docs/configuration/packages/#create-a-packages-folder added 14 days ago by https://github.com/home-assistant/home-assistant.io/pull/11971 seems like the solution
Not sure if this will fail on duplicate package names, but now at least you have control over the package name, instead of just using the filename.
@mkarnebeek Did you try include_dir_merge_named? From the docs it looks like you have to add an extra key inside each included file, so I haven't tried it yet.
Yes, and yes, you have to add an extra key, and i've tested if you can still make duplicates: Yes. And these are also silently ignored. So, all-in-all it isn't a solution, but now it is a bit more explicit.
Conclusion: Still meh.
Hmm. Thanks for trying it.
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 馃憤
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
Inconclusive.
I just spent the last 2 hours pulling my hair out for the same issue.
Would a solution to be to include the folder path in the key that gets generated? So hallway/lights.yaml would become hallway_lights.yaml? I know I can do it manually, but it would be a nice feature to have/avoid other users frustration when they start splitting their config, like I have.