While thinking about a GUI for the configuration of HASS it came to my mind, that it would be a nice thing to have some sort of “safe-mode”. What do I mean by that?
Image you’ve made changes to your configuration that corrupt everything, didn’t use the check-script, restart HASS, and because invalid yaml HASS won’t come back up. If we had a GUI to do such changes, we’d now be stuck and had to fix everything via SSH or similar.
So what I would like to see would be something like a fallback-minimal-configuration HASS would use in case something configuration-related is broken, loading only the minimal requirements to startup and being able to open the UI and have a look at the errors through the UI. And most importantly, having the API running so it is possible to restart HASS remotely again after fixing the config, regardless of how the files are being edited.
I’m not sure what would be a sensible solution for that. My first though would be:
HASS should internally have some sort of machanism to know “I’m pretty much done loading now”. As soon as that happens with a valid configuration, the key settings like listening IP, port, SSL etc. are backed up into some sort of .lastworking.yaml, to which HASS can fallback to in case it is unable to start with the regular configuration.
What do you guys think? Any suggestions on how to accomplish this or different opinions about the need to have something like a safe mode?
Usually if a GUI is ever to be implemented it would automatically create a backup of the current working config before saving the changes. At least while in beta. In a later state it should not allow any changes that break that gui.
As for now I don’t personally see the need for this feature. I already integrated into my workflow that whenever I edit a config I create a backup beforehand.
You’re right, that a proper GUI shouldn’t generate invalid configs. On the other side though it could be even more than just the broken config. I don’t have anything specific in mind, but in the long run HASS should more less be as reliable as any other automation-appliance you can get. I would compare that to something like routers. You can mess up pretty much anything so nothing will work anymore. But as long as you don’t set the IP to something wierd, you always get the chance to fix it through the frontend.
The point is: other solutions (no matter which category) separate frontend and backend. So even if the backend can’t do it’s job, the frontend will be alive to get everything back on track again. Sure, we can SSH into the machine to fix it. But I would compare that to the sexyness of reviving a bricked router through the JTAG connector.
Indeed there’s no immidiate need within HASS itself. But I’ve recently put together this little webapp to edit the yaml-files in the browser. The next thing I would like to integrate would be some way of calling the check_config script (don’t know how that could be done across all the different installation variants though), AND a simple button to directly restart HASS (using the API), since there sadly is quite a lot that needs a full restart to start working. And that’s where the problem arises. By just using the browser I (and everybody who uses the webapp, or even just through samba as many others do) can change the configuration with just a few clicks, and break it by doing that. The fact that the config is faulty only becomes visible if the frontend doesen’t reconnect the websocket even after getting a fresh cup of coffee. And then I’d have to revive HASS through SSH, take a look at the logs etc… Wouldn’t it be much niceer if in this case there would be at least a minimal frontend giving me the chance to have a look at the logs?
Hhmm, quite a long response… Sorry for that…
TLDR; Valid objection, but I still see a benefit, given that there probably are already a lot people messing up their configs through SMB. Those would greatly benefit from this feature (I guess).
EDIT:
Interesting coincedence: PR #5609 would handle the problem the other way around.
I also see a problem with updating of HA which comes with breaking changes where there would be no last working.yaml file.
There is already some kind of feature enabled which still loads the frontend even if you mess up the config. It just skips specific components. Sadly I do not know what are the prerequisites for that tho.
In my opinion that would actually an excellent use case. As said above, the lastworking yaml should only include the basics like listening IP, no specific components / platforms besides that. So if there was a braking change, HASS would come back up broken due to the changes, but viewable because of the minimal configuration.
I think I know what you mean. Platforms / components use voluptuous the validate the configuration regarding it’s content. So if a setting is set, and which type it is. And that’s great. But it won’t kick in if the yaml is syntactically incorrect.
As I read that again the breaking changes actually never produce a nom starting iirc so only the components wouldn’t be loaded as the tank should still be correct syntactically.
But again that’s all just my opinion. I don’t have / see a need for this feature for me but I can see why it would benefit someone else.
