Restore has saved my system more than once. I am no longer afraid of screwing around and trying things. That said, I’ve never done a partial restore.
1 Like
Since you don’t understand, it’s ok.
Some other people prefer things more structured.
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_namedas 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 likefolder/folder/automationand 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.
1 Like
Right, I will do it. Here is a FR.
Thank you for explanations.
Then this issue is about “show an error/warning in case of repeating filenames”.
“RESTART” and "CHECK CONFIGURATION” spin forever, it’s not working. I’m rolling back :’(
I removed miflora, and now it’s ok. I switch to Passive BLE Monitor integration
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…
2 Likes
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.
BrenTreck - Did you ever get this figured out? Having the same issue and found your post but didn’t see any resolution. Thanks
‘<’ not supported between instances of ‘BinarySensorEntityDescription’ and ‘BinarySensorEntityDescription’
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.
How do you ignore those warnings? Would be great to clean up the logs a bit.
1 minute 35 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’.
Great stuff 
Thanks for adding the FR, it may save some people a lot of confusion if they did what I did…
When I first tried to split my config I went for room based folders
- room1
- sensors.yaml
- automations.yaml
- room2
- sensors.yaml
- automations.yaml
I ended up with config for one of the rooms (first or last I cannot recall)
Just FYI: pySwitchmate has been updated to the Bleak stack:
Is there any way I can update this manually in my current build?
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.
Thx
You could try this addOn, if you’re running HA-OS:
Installs via the official development store (add this repository):
https://github.com/home-assistant/addons-development