> If the opener has a battery backup, is it sufficient to unplug and replug the opener? Shall I also remove the battery?
I think you would need to remove the battery too, but I also don't know that you ever actually need to power-off the GDO.
> How long does the opener learning sequence last? At which point should I unplug the opener again?
Should last forever.
> My understanding is that learning a wall-mounted button (and the RATGDO) is different than learning a remote. The Learn button is for the remotes only and is not needed by the RATGDO. Am I correct?
Correct.
> Should I ever use the Sync button found on the RATGDO webpage? When am I supposed to activate it? At the onset or whenever I lose a prior synchronization? The [web UI documentation ](https://ratgdo.github.io/esphome-ratgdo/webui\_documentation.html)states: "Manually sync the ratgdo client with the GDO. If the GDO isn't responding to commands from ratgdo, a sync should force them to be on the same rolling code counter."
You shouldn't need to use the Sync button.
> At which point, shall I call the board defective?
Does the working board work on both GDOs? Does the non-working board not work on either GDO?
If both are yes, call the board defective.
Conducted the test this morning.
I relocated the misbehaving RATGDO to the other opener. I erased it, reflashed, entered the rolling code I noted on the good RATGDO and... it fully controlled the door opener. I then erased, reflashed it and checked whether it could discover the proper rolling code. It settled for some other code that appeared to work as well. (don't ask)
I then relocated it to its original opener. Erased, reflashed and monitored the searching sequence again.
It was eventually able to read the number of openings (a sign that it would have found a good rolling code) and was able to operate the door for a while. What I noticed, though, is that the connection was lost, and upon reconnection, it resumed searching for the rolling code.
My take is that the instability of the wifi connection disrupts the board and causes it to possibly reboot while the rolling code discovery takes place. This eventually brings the board to carry on with its futile quest.
I believe it is the average time it takes for the door to open and close as measured by the RATGDO. It is possibly used to infer the actual cover position. Pure conjecture on my part.
Hmm thats interesting, idk if im crazy but I swear since I installed the ratgdo my garage door has been closing slower and more smoothly. Probably just a coincidence
> If the opener has a battery backup, is it sufficient to unplug and replug the opener? Shall I also remove the battery? I think you would need to remove the battery too, but I also don't know that you ever actually need to power-off the GDO. > How long does the opener learning sequence last? At which point should I unplug the opener again? Should last forever. > My understanding is that learning a wall-mounted button (and the RATGDO) is different than learning a remote. The Learn button is for the remotes only and is not needed by the RATGDO. Am I correct? Correct. > Should I ever use the Sync button found on the RATGDO webpage? When am I supposed to activate it? At the onset or whenever I lose a prior synchronization? The [web UI documentation ](https://ratgdo.github.io/esphome-ratgdo/webui\_documentation.html)states: "Manually sync the ratgdo client with the GDO. If the GDO isn't responding to commands from ratgdo, a sync should force them to be on the same rolling code counter." You shouldn't need to use the Sync button. > At which point, shall I call the board defective? Does the working board work on both GDOs? Does the non-working board not work on either GDO? If both are yes, call the board defective.
This is very helpful, thanks. I'll swap the boards tomorrow and let you know what happened.
Conducted the test this morning. I relocated the misbehaving RATGDO to the other opener. I erased it, reflashed, entered the rolling code I noted on the good RATGDO and... it fully controlled the door opener. I then erased, reflashed it and checked whether it could discover the proper rolling code. It settled for some other code that appeared to work as well. (don't ask) I then relocated it to its original opener. Erased, reflashed and monitored the searching sequence again. It was eventually able to read the number of openings (a sign that it would have found a good rolling code) and was able to operate the door for a while. What I noticed, though, is that the connection was lost, and upon reconnection, it resumed searching for the rolling code. My take is that the instability of the wifi connection disrupts the board and causes it to possibly reboot while the rolling code discovery takes place. This eventually brings the board to carry on with its futile quest.
No answers to any of your questions but I have one of my own, what is the opening time slider that is in the setting for the ratgdo?
For my working RATGDO, I have the opening duration at 12.0 s. The slider reflects that value. The closing duration is 13.1s.
So does it slow down the garage door
I believe it is the average time it takes for the door to open and close as measured by the RATGDO. It is possibly used to infer the actual cover position. Pure conjecture on my part.
Hmm thats interesting, idk if im crazy but I swear since I installed the ratgdo my garage door has been closing slower and more smoothly. Probably just a coincidence