core: Unable to have packages with same file name
The problem
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.
Environment
- Home Assistant release with the issue: 0.105.*
- Last working Home Assistant release (if known): N/A I first noticed it not working in December.
- Operating environment (Hass.io/Docker/Windows/etc.): Home Assistant
- Integration causing this issue: -
- Link to integration documentation on our website:
Problem-relevant configuration.yaml
homeassistant:
packages: !include_dir_named packages
Package 1:
automation:
#...
Package 2:
automation:
#...
Traceback/Error logs
Additional information
Conversation on Community forum: https://community.home-assistant.io/t/missing-automations/162046
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 17 (1 by maintainers)
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.
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_namedYes, 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.