The packages should be in the block “homeassistant:”
like this:
homeassistant:
packages: !include_dir_named packages/
If it doesn’t work, can you please post your full configuration.yaml file?
1 Like
This was the issue.
My configuration.yaml didn’t have that block pre-existing.
I didn’t end up needing the trailing / .
Thank you again for your help. 
1 Like
Glad that it worked out now 
Do some things not work inside a package?
For example, I am trying to add:
customize:
sensor.garage_door_time_in_state:
icon: mdi:timer-sand
sensor.garage_door_wifi_signal_strength:
icon: mdi:wifi
Inside a package.
However, I get:
Package garage setup failed. Component customize Integration customize not found.
After searching the community, I found that customize: needs to be under the homeassistant: however the packages: include is already under this, so I thought it would work.
I tried to indent customize: also, however got the same issue.
You can’t have customize inside another package. You can however have a separate customize.yaml file instead of putting everything in configuration.yaml.
The “homeassistant:” block could look like this:
homeassistant:
packages: !include_dir_named packages
customize: !include customize.yaml
And then in the customize.yaml file you put this:
"sensor.garage_door_time_in_state:"
icon: mdi:timer-sand
"sensor.garage_door_wifi_signal_strength:"
icon: mdi:wifi
OK, just for reference, is there anything else that can’t be in a package?
What about scripts, automations?
I don’t know to be honest, from the documentation it looks like you can put most integrations in there.
Customize is the only exception I currently know. But, just try it out.
Scripts and automations can be put into packages
HACS has to be directly in the configuration.yaml and not in a package if you use the yaml config method.
If you put everything in a package then at a certain point the package concept loses its benefits.
It’s just as easy to organize your configuration using includes from a directory structure and store the things that make logical sense to keep as a “system” together in packages.
If you put everything in packages you’ve just put one more layer of code that ends up being almost identical to the configuration.yaml and you could end up with almost the same issues trying to figure out where stuff is because now you have a ton of package yaml files.
IMHO…
@finity I see what you are saying.
I wasn’t going to put all the code into one package.
I just had some icon customization that was related to items/devices for that package.
It would be nice to be able to have a different set of customizations in each package.
It’s ok if it’s not allowed.
I will just have all the customizations in one file.
You can use different files for your customizations by using an “!include_dir_merge_named customizations/” then split your customizations into different categories in yaml files in that directory. That’s what I do.
I have different files for “binary_sensors.yaml”, “sensors.yaml”, “switches.yaml”, etc in that “customizations” directory.
You just can’t put them into packages.
1 Like
I will share my experience.
I also looked at packages but decided against because I found that same devices would often have multiple purposes.
E.g. making packages that relate to a room. I may have light and motion sensor and a dimmer and it would make sense to put those automations, motion sensor, and dimmer switch in a package.
But then I made an alarm setup and all the alarm stuff would logically fit in a package. But the motion sensors that turn on light are then part of the alarm system detecting bad guys in the house.
And I have device trackers and sensors that trigger text to speech announcements. But the device trackers also disable the alarm system. And the device trackers influence the lighting scenes in different rooms that would be in multiple packages.
And the motion sensor on my terrace also has a light sensor and I use that light sensor value to turn lights on and off in multiple rooms. And dimmer switches in the bedroom turn on light in the other rooms.
I cannot make packages fit all the complicated combinations. I found it much better to organize things by logical function.
What I have now is this in my configuration.yaml
I keep all the little things that are just 2-10 lines in configuration.yaml
And then I have these includes
camera: !include cameras.yaml
cloud: !include clouds.yaml
input_boolean: !include input_booleans.yaml
input_number: !include input_numbers.yaml
rest_command: !include rest_commands.yaml
sensor: !include sensors.yaml
binary_sensor: !include binary_sensors.yaml
switch: !include switches.yaml
cover: !include covers.yaml
light: !include lights.yaml
group: !include groups.yaml
automation: !include_dir_merge_list automation
script: !include_dir_merge_named scripts
zone: !include zones.yaml
scene: !include scenes.yaml
timer: !include timers.yaml
So note that automation and scripts are included directories and the rest are a single file.
When a single file gets too large I split up in a directory. Fow now this is automations and scripts.
The automation files typically contain 1 to max 10 automations and they will all be related. E.g. if I have a dimmer in the bedroom, the automations to the 4 buttons, and long press functions will be in one file. This way I can overview things.
E.g. binary_sensors.yaml file contains 14 sensors. Still easy to overview and no need to split yet.
I see some having one thing per file. I personally find that too messy also. For me it works best keeping things that belong together in one file. But not in packages because I ended up very early with things crossing over between them and I could never remember where things had been put. With my current split I know that a binary sensor is in binary_sensors.yaml
In my automations directory I have 46 files. The largest is my announcement.yaml which is 8 k.
configuration.yaml is kept at 6k and it will not grow more now
1 Like
Sorry, I must have missed this when it came up …
YES YOU CAN : -
I have customizations within packages for the items within that package, please see part of such a package with the necessary headers, this is not intuitive but it kinda makes sense after you’ve thought about it for a while. This is inside a package.
homeassistant:
customize:
input_number.in_global_line_volts:
unit_of_measurement: 'v'
2 Likes
Yeah, you’re right. I’ve never tried it but now that you point it out it makes sense.
Yes, your scenario is quite common, but in defence of @Burningstone 's position.
You can still have a bedroom1 package, and a bedroom package etc.
And you have an alarm package, that package can then reference other items.
So within the alarm package you reference the bed1 motion sensor and the bed2 motion sensor etc. It’s an umbrella reaching over all the elements you need for your alarm (in this case)
If your naming conventions are unique it’s not a problem.
All my input_boolean’s start with ib_ , my binary_sensor’with bs_ etc.
But the next part is named for the package they come from
And then the use name
The ib_ etc. Is not strictly necessary but it helps me locate things quickly in a big file as they are all listed alphabetically
This is just the way I do it, everyone will have their own.
At the moment most stuff lives in 1 package but some overlap into 2 packages but pretty much every package has something from my occupancy package