Garage door sometimes open when a light command is sent (Security+ 1.0 / 889LM)

[cjhesse]

(Moving this from a comment in another issue because the cause was unrelated.)

On three separate occasions, a command to the opener's light resulted in the door opening. Unfortunately, I haven't been able to reproduce the issue while viewing the logs.

I discovered the issue when using an automation to turn the garage door light on when the door to the garage opened. When the automation was triggered:

1. Command the GDO light on.
2. Wait 5 minutes.
3. Command the GDO light off.

The automation runs in "restart" mode, so it will stop the current instance and start over if it's triggered while still running.

This automation was in use with the ratgdo MQTT firmware for about a week with no issues prior to changing to the ESPHome firmware.

In lieu of ratgdo logs, here are the sequence of events in Home Assistant and Frigate (NVR):

05:45:34: The door to the garage opens and the automation is triggered.
05:45:34: The video from Frigate shows the GDO light turn on and the garage door opening at effectively the same time.
05:45:34: Home Assistant logs show the GDO light was turned on by the automation.
05:45:37: Home Assistant logs show that the garage door is opening.
05:45:38: Home Assistant logs show that the GDO light was turned off by the automation. Video from Frigate shows that the light **did not** turn off.
05:45:38: Home Assistant logs show that the GDO light was turned on by the automation.
05:45:48: Home Assistant logs show that the garage door was fully opened.
05:45:53: The door is opened again and the automation restarts.
05:46:38: The door is opened again and the automation restarts.
05:51:39: Home Assistant logs show that the GDO light was turned off by the automation. This is correct.

Something similar has happened on two other occasions. Once, when the light was being commanded off (at the end of the automation) and once when the light was being commanded on. The sequences for the other two occasions were similar to what's described above, including some incorrect Home Assistant entries about the light turning on or off when it wasn't. For the occasion where the garage door was opened when the light was commanded off, for no amount of time did the light actually turn off.

I've since attempted (unsuccessfully) to reproduce the issue while logging. While I didn't get the door to open, I did capture a few instances of nothing occurring when a command was sent. I'm not sure if these are valuable, but here are a few samples:

[20:20:28][D][ratgdo:204]: Light state=OFF
[20:20:28][D][ratgdo:210]: Lock state=UNLOCKED
[20:20:28][D][ratgdo:095]: Door state=CLOSED
[20:20:28][D][light:036]: 'Light' Setting:
[20:20:29][D][light:047]:   State: ON
[20:20:29][D][ratgdo:204]: Light state=OFF
[20:20:29][D][ratgdo:210]: Lock state=UNLOCKED
[20:20:29][D][ratgdo:095]: Door state=CLOSED
[20:20:30][D][ratgdo:204]: Light state=OFF
[20:20:30][D][ratgdo:210]: Lock state=UNLOCKED
[20:20:30][D][ratgdo:204]: Light state=OFF

[20:21:01][D][ratgdo:204]: Light state=ON
[20:21:01][D][ratgdo:210]: Lock state=UNLOCKED
[20:21:02][D][light:036]: 'Light' Setting:
[20:21:02][D][light:047]:   State: OFF
[20:21:02][D][ratgdo:095]: Door state=CLOSED
[20:21:02][W][ratgdo_secplus1:262]: [868198026] Discard incomplete packet: [3A ...]
[20:21:03][D][ratgdo:204]: Light state=ON
[20:21:03][D][ratgdo:210]: Lock state=UNLOCKED
[20:21:03][D][ratgdo:095]: Door state=CLOSED
[20:21:03][D][ratgdo:204]: Light state=ON
[20:21:03][D][ratgdo:210]: Lock state=UNLOCKED
[20:21:04][D][ratgdo:204]: Light state=ON

Unless I'm able to reproduce it with logs, I'm not sure how much this can help in solving the issue.

[thedeacon]

@cjhesse I ran into the same issue with my Security+ 1.0/889LM setup, even down to the incomplete packets in the logs. My 889LM was acting weird, slow yellow/red flashing sometimes and rebooting itself. The door would sometimes open on its own, or if I commanded the light on/off via esphome.
In my case I determined that for some reason the 889LM was not detected during ratgdo boot-up, and so ratgdo went into emulation mode. This caused problems when the 889LM started polling the opener, including "random" door openings, door openings when the lights were triggered, the opener ignoring actual commands to control lights, and lots of Discard incomplete packet messages in the logs. Behavior was inconsistent and all over the place, as you might expect if two devices were talking over each other on the same shared serial bus.

After some reading on Reddit, I saw someone mention that their ratgdo went into emulation mode even though they had a smart wall switch, because the 889LM took too long to boot and start sending serial messages the ratgdo could detect. So, after my 889LM was fully booted, I power-cycled the ratgdo. Instantly everything started working, and my logs are now 100% clean (no incomplete packet messages any more). This will probably work fine until the garage door opener loses power, then I'll have to do it again.

I may try to compile myself a version of the esphome firmware with the emulation code removed, just to prevent this happening in the future.

[bdraco]

Maybe try increasing this value from 35000 to 60000

esphome-ratgdo/components/ratgdo/secplus1.cpp

Line 74 in 471e78a

if (millis() - this->wall_panel_emulation_start_ > 35000 && !this->wall_panel_starting_) {

[cjhesse]

@thedeacon While I've also had some erratic behavior after power (to the whole garage) is restored, I believe the issue I'm describing is different than emulation mode conflicts. Aside from those startup issues, the only times I've had uncommanded behavior was when something else was commanded. I've had no "random" or spontaneous uncommanded openings.

To verify, I just rebooted my unit and send a handful of light on/off commands (spaced out, of course). While I still haven't reproduced an uncommanded door opening, I'm still getting the same, frequent incomplete packets around the time commands are sent, along with the occasional failure to turn the light on or off.

I've also considered running a version of the firmware without emulation mode. It would be nice insurance against potentially unwanted behavior caused by power or connection issues.

... but again, I don't think that's the root cause of the issue I first described.

[thedeacon]

@cjhesse Agreed, that sounds different than my issue.
Have you tried removing the wall button + wiring from the circuit? I wonder if your incomplete packets and command failures would stop, if you disconnected the wires leading to the wall control from the ratgdo. If they stop, then it's some sort of interference from the wall button or wiring - maybe the wiring's out of spec or something. If the errors persist, then it's more of a fundamental incompatibility between ratgdo and your opener, but you can at least know your wall button is not the cause.

[emlynmac]

@thedeacon While I've also had some erratic behavior after power (to the whole garage) is restored, I believe the issue I'm describing is different than emulation mode conflicts. Aside from those startup issues, the only times I've had uncommanded behavior was when something else was commanded. I've had no "random" or spontaneous uncommanded openings.

To verify, I just rebooted my unit and send a handful of light on/off commands (spaced out, of course). While I still haven't reproduced an uncommanded door opening, I'm still getting the same, frequent incomplete packets around the time commands are sent, along with the occasional failure to turn the light on or off.

I've also considered running a version of the firmware without emulation mode. It would be nice insurance against potentially unwanted behavior caused by power or connection issues.

... but again, I don't think that's the root cause of the issue I first described.

I need to remove the emulation mode and build locally. What's the best way of doing this?
I have installed locally and disabled emulation mode.