I currently have over 25 devices setup in my Bond bridge, and most of them are Somfy shades, which are tedious to setup. Everything is working perfectly.
I wanted to know if there was a way to backup the entire configuration in case I ever have hardware issues, or need to transfer to a different Bond bridge?
I was thinking the same thing, would be nice and save lots of brain cells.
We are working on this right now. You will see it soon.
That’s great news! Thank you for the update!
I’ll share some details of the planned feature. Your feedback would be appreciated:
We’re looking at a backup/restore feature which would be additive rather than monolithic. So if you already had some number of devices on the 2nd Bridge, you could bring all the devices in from the 1st Bridge without deleting the devices already on the 2nd Bridge. If you want a monolithic restore you could always factory reset the 2nd Bridge.
For now, a backup will include all devices, but not network settings. In the future, we may allow selectively backing up (or selectively restoring) certain devices.
Backups will be made not to Bond’s cloud, but rather to the Bond Home app local storage. So, users are responsible for backing up their own backups. Thankfully this is easy using Android’s backup to GDrive or iOS’s iCloud backup. This is a more privacy-conscious and offline-focused approach, but is somewhat less convenient: if you lose your phone or delete your app data without a backup, you will lose the Bond Bridge backup.
For rolling code devices (like Somfy RTS), the backup contains the rolling code in the position at the time of backup. So, when restoring, your Bridge may be “behind” and you’ll need to operate the device several (or many) times before the codes catch back up. — Now, our cloud does try to automatically adjust the rolling code when the restored device comes back online, but this may not always work 100%. This will be an important area of testing for us.
Hi Merck,
Thank you for sharing the details of the planned feature! Please see my feedback below:
Please feel free to request any additional feedback from me.
Best Regards,
Roy.
I would certainly like the option to initiate a backup from my raspberry pi and to have that downloaded to the raspberry pi for me to store wherever I choose. I assume this was the kind of option @royf007 is referring to with a REST API.
I know this is not likely to be an “average user” type requirement, so could understand if it wasn’t in a first cut of the backup feature, but would be nice to have on the roadmap. As a halfway point, I guess having backups stored in cloud storage that I could then download could work, but ultimately I would like to keep the initial backup local with my raspberry pi, then upload to the cloud as a redundancy option.
Depending on how big a full backup would be, I’d be happy to do a full one, rather than needing to account for piecing together different backups if I manage it locally as I described above.
Thanks,
Simon
This will be supported from Day 1.
Backups would be up to 4 MB. More typically ~ 512kB. With LZMA (xz) compression you could shrink it considerably, especially if compressing multiple full backups.
Backups are always “full” rather than incremental.
All sounds great to me, can’t wait 
I appreciate the continued community engagement, and active solicitation of our feedback, that you and your other team members pursue, @merck!
@sburke781 @royf007 @residualimages @marcio : The day has arrived. Backup & Restore feature is available via the Beta Firmware Channel!
How to:
You can even backup from one Bridge and restore to a second Bridge. Super useful for upgrading from BD-1000 to BD-1750-PRO.
NOTE: Sadly the Snowbird Bridges (serials starting with A or B) run into problems every time they firmware update, which prevents releasing the v2.20 firmware for them. So, this will only work for Bridges with serial numbers starting with Z.
Backups are stored on your smart phone. They are not sent to the cloud. So, you will want to backup the backups by using iCloud or Google backup for your phone’s apps. For security reasons, you must be on the same local network as the Bridge to initiate a backup or restore.
For developers out there, you can use the API (documentation for this endpoint is deploying atm) to send your backups to a RaspberryPi or other local HTTP server. Please do not send these backups over the open internet without a VPN, as the connection is unencrypted.
To clarify, the “iCloud or Google backup for your phone’s apps” is using the platform specific app data syncing they both support automatically, correct, not that we need to go find the backup file and manually upload?
This is awesome - even the portability between compatible models!
Exactly. It should just work.
Great news, in particular the HTTP option. Will hopefully get a chance to test this out in the next few weeks.
I tried to restore a back up and received an error message stating “missing content length”
Created another back up to check and received the same error for both back ups when trying to restore.
Are you using the Bond Home app for the backup/restore? Or are you using a third-party HTTP server?
This error means there’s no Content-Length header on the HTTP server’s reply to the Bond Bridge’s download request. That can happen if the HTTP server defaults to “chunked transfer”, which is not supported by the Bond Bridge for downloading the restore file. — BTW, this is why sometimes when you download a file it doesn’t tell you the % complete, it just says “4.7 MiB of unknown size” or something like that.
I am using the latest Bond app. Odd, I am simply using Android, Chrome and nothing special. I have not run into the downloading unknown file size issue either…
Motorola Z2 Force
Android 9.0
Not.sure what the problem could be then???
I also see the content-length error when trying to restore in the Bond App. I’m using a Pixel 2 XL if it is significant.
Also, where are the backups stored on the phone?
I guess it’s not just me…
OK, we have a new beta v2.20.11-beta out this morning with a whole bunch of fixes related to backups, but I don’t know if this specific issue is fixed because we haven’t reproduced here. — Would y’all (@sburke781 @KMDonlon) kindly check again? If the “content-length” issue persists we will dig in.