Spurious remote lock enabling

[linux4life798]

The remote lock feature is randomly being enabled, causing garage remotes controls to stop functioning.

I am using the ratgdo32 disco with a LiftMaster 8550-267.
I do not use this remote lock feature, do not have any automatons that touch it, and have this knob hidden in Home Assistant.

The only automation that the ratgdo is involved with is one where the ratgdo's motion detection entity is used an an input trigger to turn lights on and one to alert me when the "remote lock" state changes (added only after this issued started occurring).

---

The only interesting thing about this garage door opener is that recently-ish the integrated backup battery died and the gdo started beeping every 30 seconds.

I have since replaced the battery (beeping stopped) and started monitoring the "remote lock" entity.
I am seeing that the ratgdo will report that the remote lock feature is locked for 5 mins at random. Nothing obvious is happening at these points in time -- no one has send requests to the ratgdo and no one has even stepped foot in the garage. See the following graph that shows the 5min period when remotes were locked out:

[PaulWieland]

What version of the firmware are you using?

[PaulWieland]

Duplicate of #425

[linux4life798]

What version of the firmware are you using?

2025.11.2 Nov 30 2025, 22:10:36

I am building and installing using ESPHome Builder using the following description:

substitutions:
  name: ratgdo32disco-3118a0
  friendly_name: Garage Door - Right
packages:
  ratgdo.esphome: github://ratgdo/esphome-ratgdo/v32disco.yaml@main
esphome:
  name: ${name}
  name_add_mac_suffix: false
  friendly_name: ${friendly_name}
api:
  encryption:
    key: <removed>


wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

[PaulWieland]

Ok, you will need to setup a long term log capture so we can see what events and data are being sent.

Use our remote logging script or syslog

[linux4life798]

Sounds good! Thanks for quick response!

[linux4life798]

I looked a bit closer at the historical data. It seems like I didn't have spurious locks on firmware version 2025.7.4 Aug 4 2025 and prior. After updating to 2025.9.1 Sep 26 2025, the spurious remote locks started occurring. A few days after updating to 2025.11.2 Nov 30 2025, 22:10:36, I saw the remote lock become enabled (just through HA) for 5 minutes and then was disabled.

Firmware Color in Graph	Firmware Version	Note
Blue	2025.7.3 Jul 22 2025	No spurious lock
Orange	2025.7.4 Aug 4 2025	No spurious lock
Yellow	2025.9.1 Sep 26 2025	Remote lock auto enabled
Pink	2025.9.3 Oct 7 2025	Unclear
-	2025.11.2 Nov 30 2025	Remote lock was enabled for 5 mins and then disabled without explanation.

[PaulWieland]

99% sure your door opener is sending bad packets. It's not actually locked, it's just reporting that it is, and then during the next update cycle it reports that it isn't.

[linux4life798]

99% sure your door opener is sending bad packets. It's not actually locked, it's just reporting that it is, and then during the next update cycle it reports that it isn't.

I could believe that for the most recent 5 min "locked" period, since it resolved itself. Is the default polling rate of the ratgdo 5 mins?
Just clarify, the previous remote lock sessions around October actually resulted in locked out remotes and I had to keep manually "unlocking" through HA.

[linux4life798]

I caught the logs for one of these 5 min locked then unlock events. Seems like a single bit flip 0xFF to 0xFE between received packets.

The full multi day log:
ratgdo-logger-locked-unlocked-dec-10-2025.txt

[PaulWieland]

It's exactly what I suggested above. Your door isn't actually locked, its just sending a bad packet.

[linux4life798]

I gotcha. Definitely reassuring, but that's kinda still odd, though, since these wires are pretty short.
I would not think that the opener sent bad data nor would I assume that there is a signal integrity issue with these short wires.
Is there really a "known transmitter design flaw" with these openers?

If not some odd software receiver timing/clock misconfiguration, this kinda feels like a receiver hardware design issue.

[PaulWieland]

It only happens with certain door openers and isn't something I have been able to reproduce locally.

[linux4life798]

I gotcha. Is the packet always corrupt in just that one lock bit spot, or have you seen reports of other spurious bit errors? Do you have any references to how your hardware transceiver is implemented? Only trying to help 😃.