2025.1: Backing Up into 2025!

With all do respect, that is what a beta is for. This is not something that should have made it into the general release for the community to “deal with” until the development team can find a better way to implement their new features.

Further more, this is most certainly not just an annoyance. These are legitimate concerns for a critical component of the system which in a single update stoped functioning in the way it did previously. Crypto isn’t just something that gets mashed into a product for the first time AND have it’s usage forced on users.

I’m pretty easy going about this project there are lots of “annoyances” that are just that, only annoyances. Because of that, I keep my mouth shut. I personally really dislike the new logo, but at the end of the day, it’s just aesthetic and didn’t break any functionality so it wasn’t really worth making a stink about, especially since I’m not a code contributer.

This is not the same and I think people are rightly upset about the decision to include what is in my opinion a half baked solution into the general release.

16 Likes

I haven’t had time yet to dive into this. I was hoping someone else has seen this. I might look into it today. It’s probably an unpinned or incorrectly pinned dependency. It happens quite often with the first couple of core releases of a month (I don’t know if the build process does both a clean install and an upgrade from the last version, which is how I would do it). My bigger thing for me is to understand why the dependency got changed, as to understand the implications of me going to change things. This is why I tagged the dev, but haven’t received a response. The PR on GitHub told me nothing of value.

I also think that the missing possibility to have (un)encrypted (for fast and local purposes - restore a single YAML file), the toggle for partial add-on backups is a big loss. Everything done with good intentions especially for newbies I think, and this will help them approach HA, but the many IT nerds (I’m one of them) will find this brings so many restrictions. That said I really appreciate the native possibility to schedule backups. Just my 5 cents.

For the record, I agree with you that there should have been a way to decrypt made available at the same time. I also know that if people don’t test for things like this during the beta, or think of testing for it at the last minute, the developers aren’t as likely to delay releasing a feature if it means delaying the release of the next major version of their software.

TL;DR: HA 2025.1 has protobuf 5.29.2 as a dependency, but the upstream dependency for the Apple TV integration (pyatv) has its protobuf messages built with 5.28.3.

@postlund you may want to take note, as the maintainer of the Apple TV integration.

Details:

I attempted the upgrade again and this time asked PIP for more info:

$ pip show protobuf
Name: protobuf
Version: 5.29.2
Summary:
Home-page: https://developers.google.com/protocol-buffers/
Author: [email protected]
Author-email: [email protected]
License: 3-Clause BSD License
Location: /srv/homeassistant/lib/python3.13/site-packages
Requires:
Required-by: aioesphomeapi, pyatv

The important bit is this: Required-by: aioesphomeapi, pyatv.

I’ve downgraded the protobuf dependency to 5.28.3, because that’s the other version mentioned in the error log (assuming that was the last properly working version).

$ pip install --upgrade protobuf==5.28.3

HA started without complaints and both my ESPHome devices and Apple TV seems to work fine (with pyatv being an upstream dependency for the Apple TV integration).

I also checked a number of ESPHome releases for protobuf references, but didn’t find anything.

What I also checked for are compiled .proto files ($ find . -type f -name "*.proto") and I only found these for pyatv, but none for anything related to ESPHome.

The last reference to a protobuf change in pyatv is this:

ae648e86 build(deps): Bump protobuf from 5.28.1 to 5.28.3 in /requirements

So, clearly the Apple TV integration won’t function correctly with HA’s newer dependency.

@mherger since you were interested too, see the above. I don’t see anything directly linking to Shelly or ESPHome though.

Might it be that on a Docker instance this option is hidden?

Both of your posts on this topic were very well written and I wanted to do more than just hit “like.” So I excerpted what I think is one key point. Plus, as a Rush fan, I love your account name.

While I agree there was no malice, only good intentions, I can’t agree that this will help new users. Having one check box at the bottom, set to whatever default you think would best serve the new user, would work fine for them. More advanced users could make the decision to check or un-check it for themselves. Remember, HA is all about local choice. I don’t think dumbing it down is the right path.

8 Likes

A big problem with this beta is that this release was geared to the backup. In order to test, testers had to turn on encryption. As with most beta releases the documentation was sketchy at best. I know I would have skipped this encryption backup as it clearly does less than the Google backup that I used before.

1 Like

I just kept both my automatic backup systems running to test the new one. In all honesty, the new system hasn’t affected my workflow at all because I still rely on the old system.

1 Like

I kept Google as well as did most experienced user. With this being said, it is clear that this backup release missed its mark.

1 Like

Yep, I’m fairly confident the gaps will be filled.

I’ve only been here a year, but I can’t remember another change that resulted in this much pushback. Maybe the new badges was close, but that was about aesthetics more than anything.

I’m just going to keep using the automated backup I have.

Has HA ever backtracked on a big change because of the community’s reaction? Or are we just shouting into the wind here?

The new badges were no where near this. I can see the metrics on the posts. That thread had a normal number of users posting, with about 15 different people posting way more than others. Statistically, the new badges were a vocal minority whether people are willing to admit that or not.

This pushback has been larger than any before, it’s closest comparison was the deprecation of supervised installations back in 2020. Everything else doesn’t even come close to either of these “happenings”.

11 Likes

When can we expect option to turn off the encrypted backups?
Has anything been officially announced about this yet?

1 Like

It’s been stated multiple times by Missy

5 Likes

FWIW, I thought your request is a good one and has merit. While there were several good posts discussing it, I don’t think your idea deserved a couple of the wildly disrespectful replies it got.

1 Like

wonder what was actually ‘stated’ there…

To be patient and wait. It’s a pretty clear message.

1 Like

why not post something useful instead, eg “check the GitHub for what we’re doing for y’all”:

https://github.com/home-assistant/core/pulls?q=is%3Apr+is%3Aopen+backup

https://github.com/home-assistant/frontend/pulls?q=is%3Apr+is%3Aopen++backup

now that would have been way more useful

3 Likes

Marius, that’s already what’s been decided on, everything people are waiting for hasn’t been decided on yet. Which is why @MissyQ keeps saying “Please have patience”.

1 Like