The plot thickens… this indicates that you’re not facing a hardware issue. Some kind of unidentified firmware issue. Also, I checked on our end and every single unit we had with the “White Ring of Death” was in our ZZBL or ZZCC production batches, so I really don’t think that’s the problem here anymore.
You don’t happen to have an air-gapped Bridge, do you?
Somfy RTS uses a rolling code. When you restore a backup, the rolling code counters are all out of date, and the shades don’t respond. However, when our backend sees the outdated counters, it will automatically PATCH to the most recently seen counter value. As long as you don’t remove the Bridge from your account, this will work. If you did remove the Bridge from the account, then we obediently delete our database entries with the counter information, in which case you’d need to re-pair the shades. However, at least you dont need to re-do the integrations, because the IDs remain the same after restore.
If by that you mean what you went on to describe, then yes, that will be the case. I removed the bridge from the app. I can’t remember for sure, but I think I got into a state where I had attempted to do the reset and temporarily connected to the hub, but the connection dropped and I couldn’t reconnect. I removed the bridge from the app and redid the rescue reset operation (pin+power) and was then able to add the bridge back into my account and appky the second last firmware update.
Sorry for the jargon. By “air-gapped” I mean, a Bridge disconnected from the internet. Some people like to isolate their home automation gear from the internet for security reasons, and we try to make that possible for users, but there’s situations like the restore of rolling-code shades where air-gapping is going to cause an issue.
Just wanting to check on this comment. I tried to setup my devices again this morning, which I was able to do, but all I could see to do was remove the old devices and add them back in using the add new device option. This, from what I can tell produced shades in my Bond Bridge with new IDs. I could not see a way to re-pair a shade under the exisitng device ID. Is there something I am missing?
Explaining my comment about the IDs remaining the same across backup/restore:
Each device has a unique 64-bit ID, randomly assigned when it was first created.
Backup and restore preserves the IDs.
So, if you restore to the same Bond Bridge, your integrations should not know that the devices ever went missing.
If you restore to a different Bridge, the integrations probably will see them as new devices because most integrations identify a device by <bond-bridge-id>:<device-id>, for example: ZZBL12345:aabbccdd11223344.
Now, for the case of rolling code technologies (such as Somfy RTS):
One of the device state variables is a rolling code counter (devices/{}/state.counter2 on the API).
This counter increments every time the device is controlled from the Bridge.
These motors only accept commands from a programmed address if the counter value in the transmission is greater than the previously accepted command from that address. This is presumably to protect against naive “replay attacks”.
When restoring from a backup, the counter value is old, since it was saved possibly many activations ago.
So we have some logic on the Bond Cloud that detects counter rollback and patches the counter value to 16 ahead of the last seen value.
Practically this means you should be able to restore RTS devices to the same Bridge without losing the pairing with the shades.
However—at least at this time–restoring to a different Bridge will not work for rolling code motors. (This is a point we are looking at improving in the near term.)
It may be possible to use the “Pair / Unpair” option under Device > Settings > Advanced to re-pair the Bond device to the motor. However, I suspect that some rolling code motors may not like to accept a pair signal from a (virtual) remote with the same address that is already programmed, but where the counter value has rolled back. — For this reason, you may just need to create a new device on the Bridge and pair it again.
Lastly, do be aware that there is a limit of 12 programmed addresses inside of the Somfy RTS motors. So it’s best to pair sparingly, and unpair a device before deleting whenever possible. If the 12 address limit is reached and you are unable to unpair existing addresses (because, for example, they are from now deleted Bond devices), the motor will need to be factory reset and limits re-configured, which is not a fun process.
That’s probably too much of an inside view—but I’m just trying to be helpful and transparent as possible.
I think where my issue may be is I don’t see this for the restored devices, only those I created (paired) this morning.
I could imagine with my backup being over 2 years old this could have something to do with it.
Ultimately it is fine (with me), setting these up again is not a major hassle, at least inside Bond. The fact that restoring the backup actually left my newly paired copies alongside the old ones will hopefully make the changes in Hubitat and HA / NR a little easier.