Emulation mode conflicts with LM889 panel

[emlynmac]

I have a SecPlus v1 GDO with the LM digital upgraded panel.

This panel has a small rechargeable battery that needs a few minutes before it starts communicating with the GDO.

In the case of a power outage, the battery becomes discharged.

When power is restored, the panel starts charging and takes 2-3 mins. The ESP chip powers up quickly and starts listening for the communication. After the 35s time period, it starts emulation mode.

The LM889 then starts communicating and the two cause random behaviour with the door, lights and lock status.

Some ideas for solutions:

• Create a sec1plus flavour that disables the emulation code.
• Make the timeout for the emulation configurable via property

I can look at disabling the emulation code and test it locally.

Potentially similar issue here: https://github.com/ratgdo/esphome-ratgdo/issues/226#issuecomment-1953282085

[rlowens]

@edrikk posted this code in https://github.com/ratgdo/homekit-ratgdo/issues/116 as a workaround:

esphome:
...
# Delay 120 seconds on boot to allow GDO and 889LM wall panel to boot first. 
  on_boot:
    priority: 800
    then:
      - lambda: |-        
          delay(120000);

[emlynmac]

@edrikk posted this code in ratgdo/homekit-ratgdo#116 as a workaround:

esphome:
...
# Delay 120 seconds on boot to allow GDO and 889LM wall panel to boot first. 
  on_boot:
    priority: 800
    then:
      - lambda: |-        
          delay(120000);

Thanks - a great workaround.

I was able to pull down the code and build locally to remove the start of emulation mode.

I'm thinking to make a sec1plus-noemulation configuration and submit a PR, as I can see how to do that. I'm not clear on how to turn the esphome configuration into C code, so if that is a preference as a solution, some pointers in that direction would be good.

[MrTechGadget]

I also just switched from MQTT to ESPHome versions and am experiencing the same symptoms as this and #226 and #231 (which really I don't think should be closed yet) Another 'workaround' I've found that seems effective is after the LM889 panel initializes, reboot the ESP. When it comes back up, it no longer reports the discarded packets and odd light and door commands and random opening and closing of the door. Of course, a power outage would reset the odd behavior. It would be good to have a good fix for those with the LM889 wall panel.

[cgbale]

Agreed, would be good to have a fix in production for this, for those of use with Security+ 1.0 (LM8500) garage door openers. I'm replacing the 888LM keypads with 889LM keypads, but won't be making upgrades to anything newer for years to come.

[SK360]

It’s currently 2am and I just had to run out of bed after a storm knocked power out because my Sec 1.0 garage door opener was opening and closing itself for the last 45 minutes. We need a way to disabled emulation mode completely, I can’t trust leaving this thing connected any longer when we’re not home.

[cjhesse]

I also have this issue most of the time after power to my garage is restored (i.e. after power outage or when I switch the breaker back on).

It occurred again last night after I did some electrical work and I was finally able to capture the logs (attached). logs_garage-door-f99729_logs__startup_emulation_mode_issues.txt

For now, I've implemented the startup delay suggested above, but I really think it needs to be configurable to disable emulation mode entirely. In almost all cases, both the wall panel and ratgdo are permanent installations, so if the ratgdo doesn't detect messages from the wall panel, something may be wrong with the system and I'm not sure I want the ratgdo doing anything anyway.

An additional potential solution I've not seen mentioned yet--when running in emulation mode, could the ratgdo periodically stop requesting status to see if there is a wall panel connected? That would at least limit the window during which something undesired could occur.