What if you use the sensor from one package in an automation in a different package that also uses a switch from another third automation package?
That’s why I name my stuff for the package they are in.
It allows you to use something elsewhere.
Alarms … Oooooh I need a motion sensor from the kitchen, where would I find that? Well it’ll be in the kitchen package and it will have kitchen in the name.
Never lost anything yet (the day is still young) 
And you can have multiple subfolders of subfolders under packages so organisation is however your mind works
And, like VDRainer says, why open multiple files to edit, when you can do it in 1?
- Create an input_boolean in the input_boolean file
- Create an input_select in the input_select file
- Create a binary_sensor in the binary_sensor file
I could go on but I’m bored already
2 Likes
But then you will have an alarm automation using a binary sensor that is defined in the kitchen package, and another one that is defined in the livingroom package, and maybe another one that is defined in the master bedroom package. Now you need to open 4 files if you want to modify things for your alarm system. At a certain point the idea of “everything in a package” for organization purposes will break down and you will still end up doing things the same way I already do things now. But I guess you can still technically claim that “everything is in a package” which becomes a distinction without a difference.
If I want to find a motion detector I will just look in my binary_sensors.yaml file and they’re all in there with appropriately descriptive names as well…
not sure what you’re saying here but do you mean that you have a different package for each input_booleans, input_selects & binary_sensors (3 different package files)?
No, I don’t, they are already created for use in those rooms (packages), All I have to do is cherry pick the work I’ve already done.
And that’s ONLY if I need something from another package, 98% of the time it’s already in the file I’m working in.
No, I’m saying you do. (not literally ‘you’, but some people have a separate file for each domain).
The list goes on.
input_number, input_text, sensor, automation, script are another 4 off the top of my head. Oh yeah, zones (yeah that’s all 1 package) groups and customisations
I’m not saying it’s for everyone, but I like it and it saves me a LOT of hoping around, and I’m not a console junkie 
(yes JDRainer I mean you ! )
Ah I’ve gotcha! I like separating them by type instead of having them all in one file. But it’s really just a matter of preference.
Thanks everyone for your help and input! For me, the neatest and cleanest way to organize them was to create functional groups of automations and scripts and split them into separate files. I put them into folders and then included them like this. Works perfectly!
automation: !include_dir_merge_list automations/
script: !include_dir_merge_named scripts/
2 Likes
I have the next error message *The following integrations and platforms could not be set up:script* with the next error in the log file *Invalid config for [script]: expected dict for dictionary value @ data[sequence][0][data]. (See /config/configuration.yaml, line xxx)*.
I have going to split my script in 2 or 3 smaller files, each file with a specific kind (alarm, multimedia, comfort) of scripts and will see in what part of the script I've got the error. Knowing in what script the error is located could save me some time.
So I prefer to include 3 scripts over one directory.