When including multiple configuration files, one needs to be very careful not to have the same type of entity (as an example) in both, as otherwise the second file “overrides” what is defined in the first one (and this also happens when having e.g. sensors: twice in the configuration.yaml)
This is straightforward for someone with IT background, but unexpected for the end user.
Yes, there are “packages”, but I think that HA could easily do better and combine everything that is included automatically.
Yes, it is documented. But intuitive beats documented.
Some weeks ago, someone almost burned in a car, in which the doors open electrically instead of mechanically.
The emergency unlock/opening of the door was well documented! But it was not intuitive.
What you define as intuitive goes against the YAML specification itself. This goes beyond HA and no amount of WTHs can resolve this.
Adding duplicate keys (sensor: in this case) is not allowed by the Yaml parser and will throw warnings such as “YAML file /config/configuration.yaml contains duplicate key ‘homeassistant’ at lines 44 and 63.” when checking the config.
I think the subject is a bit misleading but I got your point.
HA expects to load the whole config from a single file, eventually from separate files being a product of the raw split of this whole config.
It just blindly concatenates configuration files (following include commands). After that it gets the whole configuration into yaml parser.
This is why:
Each file has to follow the syntax of its parent
All components have access to the whole configuration files including secrets.
if you f*up with single file (ie theme) the HA might not rise up again.
I understand, that from a developers point of view, this all makes sense as it is.
But an intuitive design that is well explained in the docs stays an unituitive design.
The only thing that I am asking for is to read in each yaml on its own and to combine the structure that is resulting, rather than “appending” all the files into one and then interpreting the result as YAML.
Which is why a config check is performed before every restart.
But that does not detect/warn if there is a sensor: in two different files (and also not if it is twice in one file, I think).
What you define as intuitive goes against the YAML specification itself.
Well, maybe YAML is good for developers, but not for end users. That means that either HA should be UI-Only or that HA should use “something like YAML” that allows duplicate entries rather than over-writing them - provided that HA wants to be intuitive and User-Friendly also to less experienced users.
It is extremely unlikely that Home Assistant can automatically correct all the ways you can make configuration mistakes. Follow the documentation.
If I would work that way in what I am doing for living, more aircraft would crash.
You call that human factors. You need to design systems to be robust to likely errors.
Actually it works exactly the way you desire if you use packages. Then the staructure of top level configuration file is retained in package and you can easily move whole parts of code between files without worrying about intendation.
I understanbd it is in line with YAML specification, but indeed it is counterintuitive that it works differently for included automation, sensor, etc. vs. packages.
And you do not adhere to strict procedures, usually it does not directly lead to a failure - that is different in HA.
It does not even warn you, if you have a key twice in your configuration.
It seems a bit like building a car, where the steering-wheel works the other way around. People complain and the developer says: But it is documented that way!
There are enough cases in aviation where everything was well documented but still lead to incidents due to human factors. The design is usually changed - even if it is costly - if the design is encouraging failures or is just not roboust enough against them.
I mean: We all know the “remove before flight” flags. You would not need them if you stick to procedures…
Because packages came later on after devs figured out that the initial organization of configuration is not… organized enough.
Anyway I strongly suggest using packages too. Note that they are still part of whole yaml configuration, they have to follow the yaml configuration tree and might break it.
The good point is, that every package creates its own branch in the config tree (within packages: parent branch).
Thanks to that you can define sensors, switches, templates etc within each package. Still all of them must follow the main convention. For example, all lights must be defined one after another. You cannot interleave lights with switches etc. If you include another yaml file into a package, it has to follow its structure (I never did that but I expect it works like this)
BTW I think your main complain might be generalized to the fact, that a particular branch can appear only once on a particular level within its parent.
For example, it’s not possible to achieve:
config:
light:
switch:
light:
This trait, to avoid duplicities, leads to limitations like the need to follow yaml tree. Packages create their own branches, allowing to configure ie lights in different locations of the whole yaml. At the same time helps organizing/grouping entities into categories of your will.
You were the one that brought aviation up as an example. There are countless examples of air traffic controller, maintenance personnel and pilots not following procedures resulting in multiple fatalities. Follow the documentation.