How do you configure your sensors / automations / scripts for an easier overview?

Hey,

I was kinda wonderring, since my own setup is becomming bigger, how you guys are doing it, when it comes to dividing things from each other. Right now I have a huuuuge automation file, where things can become pretty difficult to find, even though I try my best with comments and unique aliases.
Should I start using packages and divide it into rooms or things?

So every single thing that I have in my living room, will be in a living_room package (component, automation, script etc.), Next room and so on.

How do you it - pros and cons?

I have been using packages almost exclusively for a long time, although I have a few minor things in automations.yaml. I organize by “function.” E.g., all the device_tracker’s, input_select’s, sensor’s, automation’s & script’s that have anything to do with tracking people (for home/away) and configuring the “home mode” of my house I have in one yaml file. Then I have the entities for my cameras and their control in another. For some of my lights with more complex automation I tend to have a yaml file per light, although sometimes I have a couple in one if they’re somewhat “coupled.” So basically I think about a group of entities and automations/scripts that work closely together, and put them in a file together, although there is often interaction between the entities in different files, which is inevitable. :slight_smile:

I break my config files up into different yaml files stored in the same directory and then I !include that directory.

in configuration.yaml:

group: !include_dir_merge_named groups/
automation: !include_dir_merge_list automations/
sensor: !include_dir_merge_list sensors/
switch: !include_dir_merge_list switches/
script: !include_dir_merge_named scripts/
shell_command: !include_dir_merge_named shell_commands/
panel_iframe: !include_dir_merge_named panel_iframe/

then my directory structure is (using automations as an example):

ex

ex2

Looks very good!

Yes exactly, and it was kinda that thing that got me wondering!

I second finity. Mine is set up in a similar manor. Automations in an automation folder with more subfolders, each automation has its own yaml file and can easily be found by looking for the correct filename. Some more complex automations are contained in their own subfolder to keep them together.

In pretty much any kind of programming, when you break things into “modules”, there are going to be interactions between them. These are called interfaces. The trick (or art) to modularization is to minimize the interfaces. It helps to keep things clean and understandable.

By grouping entities that are strongly related into packages, it has been my experience, that helps to reduce the interfaces. It also makes it easier to understand interactions among the related entities because they’re all in one place.

Grouping things by entity type is another way of simplifying the organization, which can certainly make finding a particular kind of entity easier, but it tends to increase the interfaces rather than reduce them, which, in my mind, makes understanding and maintaining the overall system more difficult.

These are the main reasons I mostly use packages. But, any way can work, so it comes down to style and preference.

I also use packages for things that need multiple different entity types and will logically/solely be working together as an integrated system.

But if it’s just an automation/script/etc that doesn’t rely on any other dedicated entity or device but is part of an overall similar functionality then I break them up using the !includes as noted above.

1 Like

this is probably the best way of doing it.
Do you have any repo example that I can learn from?