Since I’m neither experienced with custom components, nor a supervised installation (I never did anything else but the simple venv-installation on raspbian): could/would your disaster-recovery haven been simplified / speeded up if you had made a backup / snapshot of your configuration prior to making bigger changes? I don’t know if there’s support for multiple snapshots where you can go back in time step by step. But if there is, I suppose that should have been the best solution. At least if this approach could have solved your issue. And if it does not, then that’s a feature that definitely has to be worked on.
I don’t use a Supervised install either. I use straight HA Core in Docker. So no snapshot’s available.
I make a backup of the config directory right before I update to the next version and then overwrite that backup every few days after a few successful modifications. Then I do the same for the next version. So I have backups of my config directory and the backup covers a few days worth of changes but I only have one backup of the config in the current version.
So I have one backup of every version going all the way back to when I first started using HA. 
But I hadn’t made a backup right before I made my “simple” config change (I honestly don’t remember what the change was but it was not related to any logs after the start up failure), did a successful config check and restarted before it all came undone.
Again, the issue is that the logs didn’t lead to the ultimate failure so I don’t know if it was a HA core file corruption, a custom component file corruption or a .storage file corruption that was the root cause.
And I really have no idea if it’s possible to restore just the .storage files from a previous version of HA without causing additional issues. I kind of tend to think it wouldn’t work.
1 Like
This is the reason I install Samba, SSH and Portainer at OS level, not through HA. Allows me a way to get into my HA files/containers to fix/delete things if something falls over.
2 Likes
Yup, I agree with all of that and fortunately I had all of those (or their equivalents) available.
I believe the point is that the non-techie types won’t have those available or have any idea how to use them if they did. And it makes it harder for the techie types who know how to use those tools to fix things once they break.
To me that sounds like a lose-lose instead of any win.
But I guess with the way the containers that are being automatically installed on a default hassio system these days are multiplying like rabbits then maybe those things might be the next things that should be installed by default.
3 Likes
Rubbish. Unnecessary under yaml based config. Just comment out the reference to the custom component. No need to remove files.
3 Likes
If this was already answered, I missed it in 570 threads 
I’m fine with UI here, don’t mind, just curious about automations… I actually like to set them up in UI and use yaml when I have too. The biggest two reasons are not easily selecting multiple entities for state changes on multiple devices, and then the UI not really supporting templates… Will those be worked on before the full migration?
Also, will there be some tool to love the yaml automations to the new format to help migration?
1 Like
Why not both though? That integrations set up via UI also generate synchronized yaml in the configuration file, and vice versa, that any changes in the configuration yaml is read and reflects in the UI?
That’s what I do now and I’m fine, maybe I misread this post, but figured automations would move into .storage at some point and away from yaml, was curious more than anything
It has been clearly stated that automations will be yaml.
Yes it has and I was comforted and happy to hear that definitively stated.
But have you seen this?
I am not so comfortable anymore.
https://community.home-assistant.io/t/yaml-being-put-to-death-by-a-thousand-cuts/194883
2 Likes
I’m with you on this one. Heard those promises before.
1 Like
Although, mostly, I like the ability to configure via the UI, I had an issue today which shows the problems it can cause. I had decided to try the beta of 0.110, but there were some issues with some of my custom cards and components so I decided to roll back to 0.109.6, but Home Assistant Core would not start up at all.
It turned out that it was because 0.110 replaces the base_url setting in YAML with separate internal_url and external_url settings which can be updated via the URI and are stored in .storage/core.config (the default values are populated on first startup). 0.109.6 doesn’t recognise those options and will fail to start (error TypeError: _update() got an unexpected keyword argument 'external_url' in syslog) if they are present in the core.config file, which meant manually editing the file to get it to start up.
5 Likes
That’ll break someone’s ability to roll back an update for sure.
2 Likes
Any idea if that fact was documented anywhere to let people know there will be a problem rolling back? And more importantly how to fix it? OR did you just figure that out yourself
That is what backups are for!
1 Like
Right, but someone’s going to definitely post about it.
1 Like
Cheers @Silicon_Avatar I haven’t read the release notes for 0.110 at all so thanks for the heads up. For now I won’t be moving forward at all.
This project is moving in a bad direction for my purposes so I’m in the process of setting up testing suitable candidates for a long term solution for my needs. Once that is setup I may test some new releases as well. I’ll still be following whats going on here but atm it seems to me that problems being introduced in new releases far outway any benefit for my needs.
1 Like
This migration towards a UI-centric configuration approach creates problems that we didn’t have before, and forecloses solutions for those problems. And I’m really surprised that Nabu Casa would head down this architectural evolutionary path.
From the Nabu Casa perspective, you’d think that part of what informs architectural decisions is if they would help or hinder future revenue opportunities. Sure, having a UI-centric vision, and the infrastructure around to support that is great if the customer segment you want to address is ever only individual end-user retail customers. But this selects the customer segment that’s the most costly to market to and acquire - each unit is an individual sale/transaction. And your support load goes up linearly with the number of customers/users, because you have unique, individual customer relationships with each of them.
What you’d like to enable a wholesale distribution model, where Nabu Casa doesn’t have to manage individual customer relationships, but can work though channel partners that could manage groups of those customer relationships. They provide end-user support, and Nabu Casa supports distribution partners.
So, how do you support a million Home Assistant installations remotely, where these things are embedded appliances inside a larger “solution?” Maybe your distribution partners are home builders or AV/Home Theater system vendors or similar. They want to install and somehow manage appliances for these individual users.
The way this becomes successful is to get increasing leverage at scale. This means support/maintenance per instance must be more and more efficient as the number of instances increase. Your business sucks if you have to grow your support infrastructure at the same rate as you grow your customer base.
Enabling this scalability means less human touch and more automation. And that means you really should have abstracted the interface to the persistent state in Home Assistant so that it can be exposed and invoked by APIs. And you write your fancy retail GUI to that interface, and you build externally callable APIs for that interface. And you could imagine a local file-based versions (like in YAML or JSON) that could also be used to invoke those APIs to install/confirm the persistent state.
This is infrastructure as code as has been discussed previously in this thread.
From my point of view, it’s never been about YAML vs. JSON - that’s just a representation choice. It’s the fact that you did have a documented/relatively stable interface specified as a data structure, and implemented using YAML as the representation. It could have been JSON - they’re essentially equivalent. The JSON we have now in .storage is opaque and not a documented interface. You screw with that at your own peril.
The nightmare scenario is when you are really successful and you have 1 million devices in the fields, and you want to push out an upgrade – but “stuff” needs to be done to all 1 million of these. Or you have a remote support problem, where all the users with some commonality (like using some integration with an external thing/service) break and you have to push a configuration change to the 100,000 users with that problem. Having an API and mechanistic interface to the configuration allows you to respond to this sort of problem.
Sure, this isn’t the problem that people reading this discussion have. I would imagine that the problem of supporting a million Home Assistant appliances is a problem some would like to have… I’d think this scenario should be part of some longer term strategy. This approach is hardly new or novel…
I used to have to worry about this in my $DAYJOB when I was CTO for a large VoIP OTT operator, and by the time I left, we had 2,500,000 residential VoIP lines in service. And we learned how the user population transitions from “geek” to “early adopter” to “value-seeker”. And when your product is on the shelf at WalMart… usability and customer education is a whole other problem. I had newfound respect for Dell that innovated different colored connectors on their PCs, along with cable ends with matching colors and similar… You cannot believe the support calls I would listen in on… No, no, plug the YELLOW cable into the YELLOW hole and the other end into YOUR ROUTER. No, don’t plug your phone in the Ethernet jack; even if it fits if you push hard enough…
And so what I learned is that at some point, for a complex product/service, you can only make it so simple and to continue to expand. You (or someone) needs to figure out how to educate the potential users enough on why they need this thing to solve a problem they didn’t really know they had. And that education can be expensive – you need to find a way to get more leverage to reduce support requirements and figure a way to bring to bear both automation via APIs and growing distribution with partners that would also want tooling. The simple point-and-shoot UI will get you far enough to have a really large problem, and then you find yourself painted into a corner because you can’t have enough keyboards, mice, screens and people to drive them.
Maybe no one but Nabu Casa need worry about these problems. Maybe a few others think about how to add value by supplying an embedded solution in place of Crestron and other high-end automation/entertainment alternatives. If you can build an appliance component that is Home Assistant that’s more cost effective for a VAR to support for his end-users, you’ll get the “design-win” and integrated into those systems.
I dunno, this is probably thinking too big for an open ecosystem solution. Amazon, Google, etc. have fairly constrained environment they operate with by default, existing customer relationships and an existing ecosystem to expand from. Home Assistant/Nabu Casa comes at this from the other direction and is trying to solve a harder problem. Do you think this scales up far enough to take market share from some of the existing companies in this space? Go big, or go home?
18 Likes
I just tried 0.110 on dev environment… Seriously guys, this is not funny anymore. I lost my ability to configure ONVIF via Yaml files. I’m not going that way and will stick with 0.109
8 Likes
UI integration should be also more matured allowing a control over integration after first time install. Today a lot of integrations don’t alliw perform changes other way than removing integration and setting things up again. Such limited possibilities are not acceptable.
10 Likes