I’m just unlucky I guess.
I’ve tried quite a few times to restore a snapshot, and it’s never been successful.
For the “production” boxes - I now take a vm snapshot, and also tar the /config folder and keep it.
Typically the database is corrupted in snapshots. Restore delete database and you’re good to go. If you separate the DB then you won’t ever run into that problem. That’s how I run and I’ve never had issues.
4 Likes
DB is kept seperate (mariadb).
Is this what you do for staging/testing as well?
Yep, Maria db on a separate device
Would making a git repository of your ./config folder be helpful?
That’s what I do. Whenever it’s at a stable place, I do a commit.
If I ever want to know what changed later, well, it’s git, so that’s easy.
1 Like
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.
3 Likes
We deploy HA in commercial environments with 100s of devices and i can tell you removing the yaml config option is a serious kick in the nuts. There are fancy integrations with discovery but they are way less reliable than predefined yaml. (Like sometimes a device is down at discovery then it wont be added etc). We are currently evaluating how to tackle this challenge, the options are:
- Fork from (massive additional costs in maintenance, missing out on new features)
- Get dirty and create a custom component for given devices (mediocre effort)
- Just drop HA and switch to Domoticz, Open Hab or else.
I am honestly not happy about leaving the yaml, i see the goals but it kills the commercial growth potential and limits the platform a lot to personal usage.
5 Likes
@balloob @frenck @Bram_Kragten if there is a feature/epic in the roadmap to introduce programmatic configuration via an API that the GUI is also using I am willing to also contribute to that and add man power for the implementation.
Thanks in advance your kind reply.
1 Like
How would you see that working - most of the configurations are multiscreen/procedural. Or are you thinking of some sort of data file that could be imported to ingest configurations on a new deployment?
Well anything that is a bit more M2M. For example there are custom components that call other components async_setup directly so there are ways to bypass the Config Flow, but it would be nicer to do it officially not out of desperation. @troykelly what do you mean by multiscreen btw ?
I’m thinking of things like the onvif plugin - it’s such an incredibly painful process - especially when HA is on a seperate subnet from the cameras.
By multiscreen I mean multistep processes.
I’m trying to think of ways that this could be solved, without the buy-in of the core HA developers who’ve made their position on editable, documented, file based configuration very clear.
I think @rjulius23 is onto something - if there is an api to add (& remove?) integrations and devices that would be ideal.
Sorry. However the link gave me:
Oops! That page doesn’t exist or is private.
try this one for the full set (sorry seems i cant directly point to point 16)
This thread is like any other thread, same rules apply for everyone.
2 Likes
I fully understand your sorrow. Move away from the YAML configuration is in my opinion and from my perspective, the worst decision HA devs made in last few years, since i started using it. I dont believe that GUI configuration benefits the end-user in any way - doing things in YAML is easier, faster, more fail-proof and as experience shows allowed users to configure more things. Some integration, for example Speedtest.net, lack crucial features since they’ve been migrated to UI config, like choosing the geographically closest server for measurement. UI only shows a choice of few servers - the closest is 50 miles from my place, while YAML config allowed choosing any of the thousands of Speedtest servers around the world.
Anyhow, ive been very vocal about it, but if UI config is easier to maintain for them than YAML configuration then there’s not much i can do about it and i have just accepted it.
If they will ever change their mind i will be super-happy about it, but until then there’s no point in constantly complaining. After all, even with UI config, HA is still a great tool i couldnt live without.
2 Likes
Not for the new target audience (non-tech savy people, like your parents or the average joe that is used to not write code and configure everything through clicking around in the UI)
That’s the best you can do, I also dislike the decision, but I learned to live with it.
2 Likes
I have accepted the decision, I am just interested in a solution having a programmatic UI or a proper M2M backend for the GUI would not impact the non tech savy, but at least help the tech savy. Honestly open source will for a long time be for tech savy. In Home Automation for sure due to the quickly changing technologies and commercial products are more than enough for non tech savy. We have been contacted by commercial partners to jump in and provide solutions for niche requests. And we used HA so far as it is higly flexible. However doing larger projects is becoming more and more tedious as we cannot easily store configuration as a code due to increasing GUI integrations. I dont want to start something new if it is already in the HA backlog. The linked rules pages is iseless for this case. How can I promote an Epic and if accepted I can work on it.
1 Like
non-tech savy people, like your parents or the average joe that is used to not write code and configure everything through clicking around in the UI
That’s controversial because non-tech users like my parents or average joe are scared of HA not because they dont know how to configure it, but because whole idea of “smart homes” is terrifying for them and also they believe they dont need any automation in their lives.
I offered my parents all the equipment and setup/configuration of HA in their home and still they didnt want to hear about it.
What kind of thing are you trying to configure. Is it the same thing on many machines?