HA Atomation - project sructure

I have began to write my first project and have a lot of questions.
The question about structure of project:

  • do i need to make separated YAML files for different zones/rooms - for example - main room has wall switches (2 x 3 buttons), TV, aircondition, heating floor, windows sensors, motion sensor - lot of elements and lot of automation, almost same on kitchen and rooms on second floor… + halls+WC - seems to me better to divide at least automation to different files, not sure about Lovelace elements…
    Have somebody some practice/experience - give me advice about it?

My method has been to keep the small entries for components in the main configuration.yaml file. Anything that starts to get lengthy goes in its own separate yaml file. If that separate yaml file will get lengthy it is moved to a sub folder and has separate yaml file. The yaml files in the subfolder are generally organized however it makes sense to me.

When the files get really big and you are trying to adjust a config or troubleshoot it can become a nightmare.

Get a good file editor (The VScode addon is great) and it becomes really easy to navigate around.

My Github shows my organization.

Recorder as an example was broken out as it got lengthy.

I ended up with a large switches file so it was made into a subfolder with separate yaml files. They were then organized by types of switches. Automations was the same, in general, automations are grouped into files based on a similar action or topic.

Lovelace (if you choose to use yaml mode) is a great one for separate files. I have a pretty simple setup and the files get lengthy quickly. I have mine separated by view into separate files.

Yes, I thought like this. But it seems to me little bit different from classical approach - divide when too big. I think to do that some kind as ReactJS - visual component + automation -> one folder, several components folders put into ‘room’ folder - to find easily component and change all related with it files… Then when you have tested and fish one component then you can forget about it and work with others… I don’t have well practice with Lovelace - it’s possible to make included cards to one view? At least roomX_automation.yaml can to be as a header with list of includes of components from subfolders, and can be a child to main automation.yaml, isn’t?

One learning from my side (well, I learned this way too late myself); while separating configuration to individual files, lets use packages rather than configuration item specific one. E.g. go for room/hall/garage/car/etc packages instead of sensors/automations/lights/etc. Once configuration starts to grom it keeps some order in entities, but causes need to frequently jump between files keeping different types of entities to work on single configuration. Keeping everything related to one ‘area’ inside apckage, makes working with configuration files way easier/faster. For myself; just after learning about packages I started gradually moving all of my config to individual packages and it makes life so easier now!

My only issue with packages is when there is a breaking change you have to search for all the affected entries. A good editor with a search function should take care of though.

Does the config check work well with packages? I seem to recall there being an issue.

Thank you guys for you attention to my topic and for your time. I see that here everyone goes by own path with own errors.
Let’s keep in touch.

So far I did not spoted any problems with config check. If something is wrong inside package yaml, it points properly to the right file and place within. Here is sample error I generated for testing this inside my garbage.yaml package:

Error loading /config/configuration.yaml: while parsing a flow mapping
in “/config/garbage.yaml”, line 26, column 26
expected ‘,’ or ‘}’, but got ‘’
in “/config/garbage.yaml”, line 26, column 59

Regarding breaking changes… well it actually might make things easier (sometimes) if breaking change is related to specific integration used in one package. If it is more generic one… welll then you might be right!