FYI: Interesting observation on rolling code

[rgr101]

I made an interesting random observation with a Somfy Oximo RTS drive:

The rolling code can apparently be reset (e.g. in case you have lost it)!

How to reproduce:

• Add an Oximo RTS drive to any address using 'Add Shade' and set the rolling code to a high number, such as 1000 (The rolling code of a newly paired transmitter may have any value, so we set it very high to ensure it is outside the 100 tolerance zone when we reset it afterwards - see below).
• Pair ESPSomfyRTS with the drive.
• Now, conduct some running tests.
• Verify the rolling code by accessing http://{espsomfyurl}/shades and record it for safety purposes. It should now be at the number of test runs plus 1000.
• Proceed to set the rolling code to 0 (zero!)
• Perform additional test runs. Note that the drive may not move during the first few attempts, but it should start working again after a few more tries. This indicates that the rolling code has re-synchronized to the new value.

It is still unclear if this method is universally effective, even for all different kinds of RTS drives. However, the observed behavior does not appear to be entirely random: After repeating the procedure with another drive, it was successful once again.

=> Maybe you would like to try it yourself and share your observations?

If the method proves to be effective, the loss of a rolling code may no longer be a concern...

[rstrouse]

Early on when testing the solution I managed to get one of my shades to lock out the rolling code of my main remote. Unfortunately, to factory reset it in my instance requires removal of the. So I went about creating a little program in an attempt to get it to move. This program started at a low rolling code number and incremented for several hours sending a command at 1 second intervals and the address never came back to life. Alas I had to spend most of the day up on a ladder connecting and disconnecting the motor to get it to reset.

What my little program did not do is hit 0 ever so perhaps there is something with that. However, I am not going to risk that myself as pulling down the motor is not a fun task. Perhaps others with much easier access to their reset could test this out. I believe mine are LT60s.

[rgr101]

Oh, I'm so sorry about having ruined your day... :o
Interesting. So apparently different drives seem to behave very differently. The fact that this has destroyed your main remote is of course very annoying! This probably shows that yours is obviously less "cooperative" and that it's best to keep your hands off something like this...
Perhaps the LT60s are younger and have more sophisticated safety mechanisms than the Oximo's?
I assume that the firmware within the series does not change much over the batches, so that all Oximos should behave in the same way? But again, I could be wrong - mine are quite old: they were installed in 2007.

Apart from that - I had read somewhere that the tolerance should get smaller and smaller the more "wrong" codes are received by the actuator (no idea for which actuators this applies)? I.e. could it be that this is another problem for your little program?

I can only say that I had set the code in ESPSomfyRTS to ZERO, so the next code sent was then ONE.
I have just repeated the procedure and it worked again.
On an Oximo, mind you (I am very lucky that I have a "floppy" replacement Oximo lying around that is still suitable for these tests. Then, when the "floppy problem" became more frequent with the other drives, I decided to dismantle them and just replace the starting capacitor...)

[rstrouse]

If I ever manage to goof mine up again I am going to certainly try your method. I cannot confirm or deny the rumor that the rolling code window gets smaller. There is a lot of speculative information regarding that behavior so I cannot be abso-positive that the code window shrinks.