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.
So, instead of introducing a simple system to monitor disk space and warn accordingly, it was arbitrarily decided that it’s better for the user not to backup before a (major) update and risk losing months (or even years) of work? How does this even make any sense?
That’s exactly what I don’t understand, why would the system be incapable to track these backups if they are put in the “automatic” category ?
Because they would not be “manual” as they would be “automatically” be done before any update without any “manual” user intervention, right ?
I think a simple disclaimer from the team on turning encyption off will cover them…
Warning! Turning off encryption will remove the function of being able to upload a backup to nabucasa.
this way nabucasa is fully covering themselves, why its a great feature for most as Bob mentioned Some of us backup to system and to nas, then nas files are encrypted and sent to a off site nas. I back up every few days but I do like to backup addons esecially with zigbee2mqtt…
not sure maybe a way to be selective with what addons have the choice of backups (i mean in general most addon updates are not potention system breaking and only thing that has ever broken for me in addons even before the 2.0 update was zigbee2mqtt)
have you ever looked at how many files are in a back up and how compressed it is I think they are pretty quick considering the amount of files inside, its not just fresh install moment on windows type of scenario lol.
There would be errors in your logs letting you know why this happened. If you create a separate post, you’ll likely get help fixing the issues.
This type of issue rarely happens unless you have an invalid configuration. Are you sure there hasn’t been warnings in your logs prior to this update, telling you that you need to fix something?
Which log file should I check for this??? I have never encountered issues at least for my sensors (but also did not check the log files as it is working)
Actually, the encryption in HA uses Securetar , which uses python’s cryptography library. Cryptography is not rolled by the community or the HA developers. Many people use this and it’s a proven library that works, they aren’t rolling their own encryption. This quite simply is a bug in securetar that needs to be fixed, nothing more.
Just wanted to chime in a bit later. After it was confirmed that custom backup solutions were untouched by the new mandatory encryption I took the plunge with 2025.1.1.
What can I say - it is all working. My first autobackup went smooth as well. Unencrypted.
I think in our first shock (not reading the small print) we might have overreacted a bit.
I really hope:
that encryption can be optional within the inbuilt backup tool
that schedules can be more flexible
that an optional (not default) backup before update system could be reimplemented
I think they are pretty quick considering the amount of files inside, its not just fresh install moment on windows type of scenario lol.
