It would be good if there was an API into the configuration machinery that could be used to enumerate the current configuration and also be used to add/delete persistent state that lives in the .config/ directory. Right now, that directory contains various files which contain both persistent configuration state and, apparently, some ephemeral state isn’t necessarily part of the specification for the configuration of Home Assistant.
Ideally the GUI interface would also use the same API to ensure it’s complete and can be used to manipulate the private manifestation of the configuration.
In this way, one could extract the state, with some confidence that all the required information was present and then externally checkpoint, save and modify it; and then have tools to push it into Home Assistant. I was hoping that hass-cli could be used for this purpose, but I don’t believe that it can be.
This pattern is often used in, e.g, network elements like routers and switches built by vendors like Juniper, Cisco, Arista and others. Some of their customers own only a handful of boxes and hand-configure each one with some interactive interface. Others own an entire fleet with dozens or hundreds that are managed, and the idea of manually doing anything to them all is just incomprehensible. Too much opportunity for human error. And it flies in the face of how they manage the authoritative expression of their infrastructure configuration – it’s not in the network elements, it’s in a configuration database, and state gets pushed out to ensure consistent deployments. See “infrastructure as code” in the funny papers.
If someone (a VAR? Nabu Casa?) were to imagine operating hundreds or thousands of Home Assistant instances, you’d absolutely need something like this, so you can avoid scaling your headcount at the same rate as your customer base. I wrote a longer comment about this in the Future of YAML thread if anyone wants to relive that.