Hmm, besides me not completely understanding why you are doing it the way you are doing it, I guess this would for me be ‘why do things in a simple manner if you can do things difficult’
Simply moving a file out of the packages folder is simplest as can be.
Change the files from .yaml to .yml. As noted from the docs:
We offer four advanced options to include whole directories at once. Please note that your files must have the .yaml file extension; .yml is not supported.
This will allow you to !include files with .yml extensions from within the .yaml files; without those .yml files being imported by the following commands themselves.
That way they get skipped by the directives but also you can still get syntax highlighting when you open them in an editor. And can include them manually if you want. There’s no equivalent to your folder one though.
On your issue:
it’s not a bug, that should be a feature request. Directives are working as designed in a way they have been for a long time. You’re requesting a new feature - support for repeated names in different subfolders.
you should exclude !include_dir_named as that doesn’t make sense. That directive uses the file name as the key in the object it creates. If that key became the path to the file then it would be like folder/folder/automation and that won’t really work
it’s a huge breaking change to advanced configs. I can’t imagine that being implemented for that reason tbh. Think you’d be better off requesting a new directive that works the way you want so existing configs don’t break.
This is a good workaround. Some day I managed to setup my Visual Studio Code to treat these “*.dis” files as yaml - just to have this highlighting. But now I live again w/o that highlighting (switched it off) - and I easily see “this file is disabled”.
The only thing is - looking at the file’s list in VCD, it will be not easy to differ “active” files from “disabled” files, they are of same color:
Probably there is some way to set different colors for yaml & yml files, I will check.
It’s ok then.
Users like me then just will keep setting unique filenames.
In my scenario: “gargen_waterpipe_test.yaml”, “kodi_test.yaml”.
Yes, this is not convenient, but it’s ok.
Also, repeating filenames should be logged as an error - which does not happen now.
Since files may be located in some subfolders - then probably these “keys” could include these relative paths, so they become unique. Ok, if you say that it is not possible - I just have to believe…
Everything is possible but it has to be clearly defined. Right now the directive collects all the files and uses their name as the key of the object it makes. You’re suggesting the same file in different subfolders still works so I guess I assumed that means the path becomes the unique identifier in the object. It could be different though.
Thats why I’d suggest just writing up an FR spelling out clearly what you want to happen.
Stunning performance?
On what machine?
When I look at ‘system status’ I see,…
Home assistant supervisor 10.70 s
Zone 12.92 s
Mqtt 13.25 s ( for only three devices)
Input_select 13.54 s
Input_button 13.55 s
Raspberry pi 13.59 s
Input_datetime 13.73 s
Input_boolean 13.74 s
Input_number 13.80 s
Nest protect 14.77 s
Hacs 15.80 s
Version 20.26 s
Switch_as_x 24.93 s
On a rpi 4, 8gb ram
Is this stunning? What numbers do you have?
Maybe time to buy a nuc.
24 second startup time is very low. You miss understand those numbers. They aren’t additive. They are how long it took for that to get set up from startup.
going off the numbers you posted…:
Home assistant supervisor took 10.70 seconds…
Zone took 2.22 seconds…
input_select took 0.62 seconds…
input_button took 0.01 seconds…
Raspberry pi took 0.04 seconds…
Input_datetime took 0.14 seconds…
Input_boolean took 0.01 seconds…
Input_number took 0.06 seconds…
Nest protect took 0.97 seconds…
Hacs took 1.03 seconds…
Version took 4.46 seconds…
switch took 4.67 seconds…
would be nice if that was true. But,the logging tells me something else:
2022-07-18 07:08:11 WARNING (MainThread) [homeassistant.setup] Setup of input_number is taking over 10 seconds.
2022-07-18 07:08:11 WARNING (MainThread) [homeassistant.setup] Setup of input_boolean is taking over 10 seconds.
2022-07-18 07:08:11 WARNING (MainThread) [homeassistant.setup] Setup of input_datetime is taking over 10 seconds.
2022-07-18 07:08:11 WARNING (MainThread) [homeassistant.setup] Setup of input_button is taking over 10 seconds.
2022-07-18 07:08:11 WARNING (MainThread) [homeassistant.setup] Setup of input_select is taking over 10 seconds.
2022-07-18 07:08:11 WARNING (MainThread) [homeassistant.setup] Setup of zone is taking over 10 seconds.
2022-07-18 07:08:11 WARNING (MainThread) [homeassistant.components.light] Setup of light platform switch_as_x is taking over 10 seconds.
2022-07-18 07:08:11 WARNING (MainThread) [homeassistant.components.light] Setup of light platform switch_as_x is taking over 10 seconds.
Time it. Restart and watch the time with a stopwatch. It will be the duration of whatever the last item is on your list. The warning is just a warning. I have them ignored. On my NUC, a restart takes about 40 seconds because one integration takes 30 seconds.
Any one else noticed that using a Sonos TTS script in an automation is broken? I use this when someone presses the Ring Doorbell.
delay: ‘00:00:02’
message: Er staat iemand voor de deur. Doe open!
sonos_entity: media_player.keuken, media_player.badkamer, media_player.woonkamer
volume: 0.3
In 2022.7 it only plays 'Er staat iemand voor de deur’.
With 2022,7 the unofficial free@home integration for the Busch Jaeger system stopped working. Had to roll back. Apparently because libsodium was removed. Is it possible to include that again?
As there is no easy solution to get it working again.
And manually installing the library doesn’t seem to work either.
The Busch Jaeger system is not widespread but in Holland it was/is used by a big building company.