I have updated to 2025, nice workaround in backup. thanks
But Goove isn´t working anymore, there are no entities, have reinstalled, no change. And all my calendars, dont work anymore. Waste collection say, it cant read the ics file. Hope, you could help
Maybe all those that dislike the forced backup encryption should vote here:
That was it! Though interesting; integration/media player causing this error was bravia_psk from HACS. I stopped to use it some time ago, but only deleted device and integration, but not removed it from HACS. So a bit surprising, that even ‘inactive’ integration can cause such problem.
- I open every backup archive each night during scheduled backup.
- The archives have to be unpacked to allow deduplication strategies to work and make diffs possible. I run an unencrypted local (dirvish) and encrypted remote (borg) backup. Typically I backup the whole filesystem, after HA Green does not seem to support access to the whole filesystem I have to use the ha backup tool via ssh.
- I gladly only had to restore a broken HA once.
I’m not willing to lose more than one day of changed settings and sensor data, thus the nightly backup. I can restore my whole IT setup after failures or even if the house burns down. Sure I hope this never happens, but this is what we prepare for, right? The UX for backups of HA is not used at all, I need shell tools I can execute via scripts.
Best for me would be easy filesystem access. Worst would be to be unable to easily extract the created archives and thus to backup only binary blobs.
That applies here too! Please can the backup time be configurable? Otherwise nice new backup facility no use here.
Kinda disappointed that the ready PR has not been merged for Ecowitt integration. Someone wrote it to add rain detection, but since November there is nothing happening.
I would also wish for that, because the backup ends up on my NAS, which is turned off at night.
First, a big thank you for working on and improving the backup system!
Making backups portable is a huge improvement as I’m planning to move from a docker install to HAOS in a VM in the near future.
I’m conflicted about mandatory encryption for backups though. It’s easy to shoot yourself in the foot if you forget where you put the key. I’m generally very diligent with secrets management, but having to keep track of another secret could be a burden for some.
Maybe a middle ground would be to let users choose a password from which the encryption key is derived? This way you could for example re-use the password for your admin account.
Yes, something similar happened to me during the beta testing phase. It was actually the other way around. I backed up a 25.1 version, messed up my VM through my own fault, restored a snapshot with 24.12, but could not restore the 25.1 version from that. Had to first upgrade to 25.1 manually. I reported this in the discord but did not create an issue for it because I had been too busy getting things working again to remember the exact steps (and didn’t want to do it again to check for reproducibility!)
Your experience and mine seem to strongly suggest there is a cross-compatibitily issue of pre and post 25 versions in the backups. That sort of defeats the purpose of a backup.
You have error about adapter.
add
adapter: zstack
after port:
in configuration
Save and restart addon
I made a feature request about changing the time:
It shows like that for me also, but not sure why there is a question? It is not looking wrong/strange to me.
This is another deprecated unit that’s finally been removed. Seems you now need UnitOfPower.WATT ?
I’ve probably grabbed files less than 10 times over my lifetime use of HA.
Going off memory:
-
I screwed up config_entries once by editing helpers because there’s no mass way to replicate them quickly from the UI.
-
I’ve screwed up some automations that was not included in my source control. This only happens when I make a mistake with my source control, or when I’m making changes to a new feature (template entity, automation, script, etc) that I haven’t backed up yet.
It sometimes takes a few days to get the new feature right and I usually don’t include it in source control until it’s at a production version.
-
Retreiving deleted (and forgotten) credentials & information that I put in
secrets.yaml
. I don’t have this in source control, so I have no choice but to rely on backups. -
Grabbing a working version of history when the current one get’s corrupted.
I avoid restoring at all costs, the process takes way too long and offers no feedback while restoring. I only use the backups to piecemeal configuration, or restore single addons. Anything more keeps the system down for entirely too long.
I think a good compromise would be an option to store unencrypted backups locally, I understand this may require HA to create 2 local backups initially (1 encrypted, 1 not) and it may not be ideal, however a small disclaimer saying that would suffice.
Modbus integration for huawei smartlogger was broken on this release, I’ve errors like this:
2025-01-04 13:03:35.243 ERROR (MainThread) [homeassistant.components.modbus.modbus] Pymodbus: huaweismartlogger: Error: device: 0 address: 40575 -> Exception Response(131, 3, IllegalValue)
2025-01-04 13:03:35.253 ERROR (MainThread) [homeassistant.components.modbus.modbus] Pymodbus: huaweismartlogger: Error: device: 0 address: 40532 -> Exception Response(131, 3, IllegalValue)
example of the config file:
- name: SmartLogger Power Factor
unique_id: smartlogger_power_factor
unit_of_measurement: '%'
device_class: power_factor
data_type: int16
scale: 0.001
precision: 3
#offset: 0
address: 40532
scan_interval: 30
slave: 0
input_type: holding
sure it does, it has already been configured… this looks like a new install
As I can see the only modbus device that stop working is the one with the slave id 0.
- Almost never. My routine backup procedure includes copying any changes in the \config directory to a mirrored directory on my NAS. I also save “old” copies of key files before making changes to them.
- See above. I really can’t foresee a need to ever open them.
- I’ve done this a couple of times in the past 5 years.
-
The recent CrowdStrike fiasco is an example of why you don’t release major updates early, without solid testing in multiple environments and user feedback.
-
Frankly there isn’t a good track record there. Highly-voted FR’s languish for years with no attention, then changes no-one asked for are implemented. Users raising concerns here are often treated dismissively or even sniped at.
-
Encrypted backups are a great idea. I think anyone seeing that in the roadmap would be supportive. Removing the option to create unencrypted backups wouldn’t have been so well received. And from what I hear, that feedback was already sent, but not acted upon.
Hmmm… indeed when you press the “Configure” button the text in the dialog indeed seems to imply that it is being setup from scratch while the stick is setup and running fine.
A couple of months back I switched firmware from Zigbee to Thread and I just selected the other one and did not read the text properly, but I expect it was the same then already, so I don’t think it is new.
But that dialog/text could probably be improved.
Tom, that’s only you because you keep pushing this us-vs-them thing. And I will continue to remind you that your posts are out of line with that train of thought.
Just compare my response to @madelena to yours. I’m not a huge fan of the encryption on local files, however I just provide my feedback. No backhanded comments on how things are ran, no backhanded comments about not hearing feedback. Just feedback. If you did this, you’d never hear a peep from me.