Well I got a bit of sleep but I did not solve my issues. I still have a lot to do to get things working again (I see it more as a waste of time than an interlective expanding experience). I’m not the type interested in why it is working - I’m more into prevent situations like this where well working environments goes totally wrong by doing simple upgrades. I see the art of software development being improving user experience over adding new features and functions that for a while will “kill” good user experiences. Seamless feature and function improvements is more impressive for me than being an expert into deep feature and function developments where the user experience is totally neglected.
From a behaviorist scientific point of view my experience last night was total punishment and no reinforcement at all. This will only prevent me and others (I don’t think I’m the only one) from making updates and upgrading systems. And this cannot be in the interest of the software developers (the improve’rs) . It most be frustrating for these people to know that their effort of doing software improvements is wasted or not used.
A cynical aspect could be that some are interested in users not upgrading and thereby making their systems more vulnerable. Who have interest in this?
Probably the best thing in this case, is to rollback from a snapshot, hopefully from the day before the upgrade, and then, before proceeding to a new one, read all the breaking changes for all versions and sub-versions that there were from the installed version and the target one, and prepare all the stuff needed to avoid issues.
The title of this thread seems too strong than the reality.
I had a similar situation with my node-red.
After a restart didn’t solve it I did this:
Backed up my node-red folder
Copied my add-on config
Unintalled the add-on
Reinstalled add-on
Pasted my add-on config back in and started the add-on
That worked for me. You shouldn’t need to back up the node-red folder, uninstalling the add-on doesn’t remove any flow data etc. It was just a precaution.
Hi Woody - you are right the title seems strong - but never the less fixes could be minor but impact of things stop working is righter frustrating. But the term “breaking changes” should be called “fatal changes”. I see this team “breaking changes” being used a lot in my professional life. And here I call these potential business harming changes fatal.
You are totally right about ways to either role back changes or ways to test impact in an safe environment before major role out. It was actually what I would like to hear more about from others. How can I make an “testing environment” for testing impact of future updates before “messing up” my operating hassio environment. There is NO WAF in a not working hassio environment. The wife might start to shout: “Give me Google Home, Alexa or Apple Home in stead of this annoying technical crap”. And that’s a shame don’t you think Hassio-follows ?
I am still learning and am developing upgrade theories to increase my system stability.
The current one I want to try is to only upgrade to .2 or later, being sure to read the release notes in between for breaking changes. I understand that in 0.92.x we are supposed to have an option to choose to set up addons in the menu automagically. That means I will wait for 0.92.2 before upgrading.
That’s on you, not Home Assistant. This is how it works right now, the pace is fast and a lot of breaking changes are necessary for the software at this stage.
I have 200+ loaded components, but almost never have any downtime when upgrading other than the restart. I read up on the changes in the blog post before I do anything. I never upgrade until at least x.1, often x.2. If I notice a breaking change in the post that possibly could affect me I fix the config before I upgrade, use the “Check Home Assistant Configuraiton” add-on and also try to gather how important the thing that might break is to my setup. If it’s crucial I might wait on upgrading until someone else can verify that everything works.
If anything goes wrong anyway I always have a snapshot from before upgrading to go back to. I don’t upgrade if I’m in a hurry or just going to bed.
Also please refrain from using such derogatory terms as “WAF”.
I can second that never have many dramas if you read the braking changes and plan accordingly. When you get stuck come to the forums and someone will be more then happy to help out. There is no need to put others hard work down because you can’t keep up.
Exactly - I’m having the same issue. NO Node-red from the Web-UI in the Add-on part.
Is it safe to uninstall and reinstall my Node-red add-on? will I loose all settings I have used hours to setup. I could see lots of possible improvements for the usability even for node-red.
The worst part for is that I need to do the Hassio updates and modifications from remote (vacation you see) and I have experienced to have to power off my RPI after updates and that is hard to do from remote.
I can see your point - but is it somehow possible to prevent this in anyway? Could breaking changes (fatal changes) warnings appear before making the update? Is it possible for the developers and the code behind the breaking changes to check if the broken code is used anywhere? Could major upgrades automatically create a snapshot backup for possible rollback ?
I actually installed an add-on to check for breaking changes in upgrades and then I get stuck in this mess. And yes it is frustrating and could be prevented all will win.
You can try to have a test environment in a spare Raspberry or in an virtualized platform (also Virtualbox is good).
Probably everyone has a different view of testing environment, if you ask people.
Personally, I moved from RPi to an Intel Nuc with Proxmox as virtualizer and I have created a VM just for testing.
But normally what I do is try to update each sub version taking care of changes, and only if needed (big changes) I will go for the testing environment.
Main thing for me is to do a snapshot of the VM (not the HA snapshot, that I do daily) prior of doing any update, so that in few secs I can go back.
I’m not entirely confident that addon works as suggested. I have tried to run it when I knew I had breaking changes and it said it was good to go.
As a general rule you proba ly shouldn’t do remote upgrades although I’m guilty of doing it most of the time.
If you need to reboot your pi in order to get updates or config changes to work you probably have a config error somewhere. I would look at secrets or customize as the main areas that don’t always through errors in the check but one line out of whack there or an extra : will cause headaches.
Yes it is on me - you are right - but again my burst out most be accumulated frustration over time. If it is a “fast pace” then their must be a way go back fast if anything goes wrong. As people we are different and that’s a fact. And we could all gain from our diversity. Some are readers and others are “do’ers”.
I’m sorry if you get offended by the term WAF - but everyone knows what I mean. We can make a deal. If you will start to call “Breaking Changes” for “Fatal Changes” - then I will start to say PAF in stead of WAF. PAF = Partner Acceptance Factor - then we all are aligned with what I really mean.
One hassio improvment suggestion then: Why not make an automatic snapshot when you make a major upgrade - why should I do that each and every time.And mostly it is not necessary and then you stop doing it and then once you should have made one. Behaviorism you see.
Exactly - this we will see again for sure if you are not got feed-up and have chosen another path. That would really be a shame. I’m the fighter of state of art usability. And I would love to see hassio development going in front on this. At the moment I’m feeling we are more Alfa and Beta testers than actual users of the hassio wonders.