What’s the procedure for re-installing a previous version of an Add-on?
Unlike for Home Assistant, I am unaware of a rollback command for Add-ons.
Why I ask is because there was a bug introduced in the Tailscale Add-on (a few versions ago) and I quickly recovered functionality by simply restoring the partial backup that was made just moments before the upgrade. Easy-peasy.
OK. Then you are free to disable backup for those addons.
If these are so tiny (without data), the difference in time on recovering them it’s even more significant compared to recovering the whole HA.
If you suggest to recover using downgrade version, then my argument are:
not applicable to addons/ha with data
having 2 ways of recovery, depending on add-on properties, is not a good pattern. It’s better to have one method for all addons. regardless if those contain data or not.
you are obviously not aware about cases which require recovering more components, each to different version.
Ehmm. A lot of great things have been added over years.
It was annoying that you could have an option to permanently turn it off?
Are you ok?
And because of that you suggest me to click hundreds of times (and take care to not forget)?
I believe all users are smart enough to turn it off if it annoys them. If you have worries, I’m OK with making the toggle disabled by default. we can manage it.
And boom - you damaged underlying data used by the addon or HA.
Correct. If there is a default, there is an option to change that.
Where is the option then?
The option is any other way that currently exists and has existed. These have already been pointed out. If you look beyond the UI Backup page, you should find satisfaction.
FYI, it wasn’t permanent. You had to click it off every time.
I personally hated the checkbox/toggle on everything aside from Z2M, Zwave JS, and MariaDB. It would be much better as a toggle on the addon itself. I.e. A backup before updating toggle on the addon page, set it once and forget it.
Also, I’m fairly sure you yourself has made comments about number of clicks in the UI before. Why does that matter when you say it but not Cogneato? Everyone is allowed to have their preferences, especially when dealing with UIs.
I’m going to have to jump on this bandwagon as well. I have my config folder set up as a Samba share and each night my local backup is copied to another server and prepped for my offsite drive.
My concern is that on more than one occasion I have had something fail and unzipped one of my backups from when I remembered that it worked and performed a diff on the config folders to find out what has changed. I will continue to use a plugin that does auto-backup skipping HA’s native if this is the case. Probably going to put off this update unfortunately.
Very disappointed with a “feature” that removes extremely critical functionality.
This has always been an issue. The only way to restore to a previous add-on version is to restore from a backup. I’m just saying the full backup allows for restoring of a single add-on, and in most cases (for me) the little individual backups piling up are not needed.
It would be nice to choose a version like you can with HA.
Backing up before updating is a need. Especially for certain add-ons. I would just rather see it configured elsewhere. Like maybe in each add-on’s config?
Hi. For me also, encrypted Local backups KILLS this release, and I doubt that I’ll update HA again until encryption becomes optional - hopefully very soon.
Enforcing Backup encryption is a retrograde step. It’s a bit like installing smart lamps that only operate via your phone or Alexa, thus disabling your manually operated wall light switches!!!
“As for any software products, the best practice is to release early and get feedback first, …”
Not so. Best practice is to consult with the best “customer” representatives you can get hold of and get their requirements, document them, verify your understanding, and check out any issues/inconsistencies you see, get sign-off and only then proceed to design and development (again with customer checkpoints).
In this case, there is/was an existing working (Backup) process, so an “MVP” or Radical approach was not appropriate - nor needed when the needs are very well understood. But the “killer” was taking away existing capability by enforcing encryption. Encryption as an option, or even default, is fine, but the Unencrypted option is a mandatory for at least Local backups.
However, I am very pleased to see Backup getting some much needed attention and improvements. Long overdue and very worthwhile - even critical. It’s just the mandatory encryption I don’t like.
Re your questions:
Why Unencrypted? For me, because I only Backup locally on my network. I never use Cloud - ever - for storage. Encrypted adds an unnecessary risk and increases backup/restore processing load. And the risk of lost keys or complexity of storing them safely.
a) “how often do you open your backup archives?” Never needed to so far - I use a Development .v. Live process and sourcefile versioning.
b) “What do you open it up for?” - n/a.
c) “How often do you need to restore your backups?” Once in 2 years - to roll back 2025.1 to its 2024 state, when I realised the extent of the Mandatory Backup Encryption issue!!
For major planned developments, where User guidance/input and prioritisation is really helpful, could there not be a discussion in the Forums (or etc.) beforehand? Perhaps there was - but I’ve not seen anything obvious. Did I miss it?
If you don’t like/can’t use that method either, there’s always SAMBA Backup.
Its not like they took away options (well, excluding the addon backup button but that was a more drastic workflow change still I’d argue), they just changed a workflow (which I guess I can get why this thread is crawling up on 700 comments, change sucks sometimes).
I prefer to have a backup of the Add-on I’m about to upgrade. If I need to rollback the Add-on, I restore that one, recent (partial) backup. Simple and easy.
I feel that’s more convenient, and foolproof, than picking out and restoring just the Add-on portion out of a full backup that was made hours ago (or more). One small mistake during the selection process (easier to make after you’re frustrated by a buggy upgrade) and you potentially make matters worse.
Thanks Julesx,
Regarding the Victron Integration,
Followed the steps in the link you provided above, and it transitioned smoothly without losing any on my history or entity configurations.
It was supposed to be ironic, given the number of times my wife says “why are you on your bloody home automation sites at work again?” No offence intended.
Right – but that still sounds like HA is implementing it wrong, other people are implementing it wrong, and is good indication it should be swapped for something standard and well-designed and well-specified… it’s hard to do encryption properly, even for something as trivial as this.
Hi Paulus, thank you for your response. The total shi*tstorm in this comment thread is probably not how you and the team thought the new year would start, and I think many of the comments are overly harsh. Especially the ones that see a malicious intent behind the changes made in 25.1. Personally, I don’t believe that at all and think you are genuinely trying to make a product that is better for everyone, and I really appreciate that.
That being said, I also think there have been a few major errors made in the process surrounding this release, most of which are related to communication.
This is comment # 607 in the thread, the third one by the NC team, and the first one in which it is explicitly acknowledged that mistakes were made. I think those numbers speak for themselves.
There was no time for an overhaul, I completely agree. That is part of the problem IMO. There isn’t really a period in which regular users (who opt in for this!) can give feedback on potential new features. Sure, there are architecture discussions on GitHub but that’s not the same. And on top of that, would it have been that much work to roll back some branches and simply not release the new back-up system yet, making the improved history graphs the highlight? When multiple trusted and dedicated users indicate that they will skip the upcoming release because of a certain feature being introduced, that should be a red flag. Yet you went ahead and released it anyway.
These points focus mostly on the technical part. There’s a deeper underlying issue that I think is more important. Two of the three principles of the Open Home Foundation are privacy and choice. Together, I believe they can be put into one word: autonomy. Let’s face it, there are a couple of big tech firms out there that have a million times the resources you do, and they make home automation products that are very easy to use. But some people want to be able to decide for themselves how things are run in their own home, and who gets access to their data. They want autonomy.
This is where this release went wrong. Encryption used to be optional. Backup before update used to be optional. The user had a choice. You introduced features that deliberately took away that choice. Never mind that there are still third party solutions that allow such choices. By introducing this you sent a message (intentional or not) that choice doesn’t actually matter to the HA dev team, but you know better what is good for users than the users do themselves. This, in my opinion, is what evoked the strong reactions.
To my knowledge there is no “third party solution” to date which restores the toggle to backup before updating right there in the dialog. And this is apart from the fact that I have yet to understand why it was removed to begin with.