Issue thread (GDO blaQ): Purple button garage opener with 888LM/889LM wall button


I have one working and one not working. The one that is working was the one I replaced capacitors in. So, I replaced the capacitors in the other one, but that didn’t fix it.

I seem to get inconsistent results when upgrading firmware. It seems to pull different versions when I do it back-to-back.

Right now, the one that is working is:
ESPHome: 2024.5.0b4, Konnected Project Version:
The one that is not working is:
ESPHome: 2024.5.0b4, Konnected Project Version:

I do not seem to be able to get the 2024.5.4 ESPHome version.

It’s odd that one is working, but the other is not.

Any ideas on what I might try next?

Thank you.

The first three digits of the version number, i.e. 1.1.0 correspond to the project version in konnected-esphome project firmwares. The last digit is incremental and unique to you – it represents the number of times you’ve built and updated. So that last digit will increment every time you update.

Only the first three digits are significant in terms of the underlying functionality. These two devices are basically on the same firmware.

ESPHome 2024.5.0 was just released, there is no 2024.5.4 yet.

I would suggest trying the newly added Re-sync button to reset the device’s client_id and rolling code counter, that may get it back in sync with the garage opener.

Are both of these the exact same GDO model?


They are not the same. The one that is not working is a chamberlain LiftMaster Professional with a date of 05/12. The keypad has a date of 12/16

The other one is a chamberlain with a date of 07-13. The keypad has a date of 09/18

@toddtmw both purple button?

Sorry. Yes. I haven’t tried the reset yet because the car is in the way so I cannot connect it. (In hindsight, it might have made more sense to put the new blaqs by the wall panels.) :grinning:

Guys – we just pushed a small update (project version garage-door-gdov2-q v1.1.1) that should fix any remaining issues with unexpected door triggers on reboot. You can OTA update in the app or via ESPHome dashboard.

What was happening is that on shutdown, the ESP was pulling the communication output to ground just long enough to trigger a contact closure. Which, on the Security+ 1.0 openers, would still trigger the garage door to move. The fix that @Ryan_P implemented safetly de-inits the Secplus GDO library before shutdown, so this will not happen.

Let us know how this works for you!

1 Like

The fix is working for me. I get no door triggers on a cold boot or a warm restart.

Thanks @nate and @Ryan_P for the quick fix!


Hi. I installed 1.1.1 and I did a resync and the wall panel still flashes.

However, when i disconnect the wall panel, and try to control the door, it plays the chime for the door close warning, but does not close the door.

I’ve tried rebooting the opener, rebooting (both cold and warm) the blaq. Nothing is working.

It’s like the blaq isn’t even conected to the opener.

When I remove the blaq and reconnect the wall switch, the opener works fine.

Not sure what to try now.

Everything is working fine now.

Sorry, it was my fault. With all the rewiring I had been doing, I had red and white backward in one of the connections.

Again, sorry for the false issue.


Hi @nate

I’m seeing one more issue. It seems that if I lose power to the opener (and the BLAQ since they are plugged into the same outlet), then the wall panel never properly reconnects.

The only way I can get it to connect is to unplug the BLAQ until the wall panel goes yellow. Then, I can plug the BLAQ back in and everything works.

Has anyone else tried this? Or is it just me?

I was thinking that similar to the fix that prevents the garage from opening and closing during restarts, would adding an option for a delay before the Secplus GDO library is initialized (45-60 seconds) if that would allow the wall panel to connect and then for everything to work?


@toddtmw glad to hear that it’s working!! Yep, reversing the wires would be a problem. I’ve done it before too :melting_face:

What is the model of keypad that’s having the start-up problem? Are you having this same issue on both openers? I have another user that’s having a problem with wall buttons on his older openers, too. It seems possible that we could add a delay, but I wonder if it’s only specific wall button models that are having this problem.

Hi Nate. They both do it. Both are on the latest 1.1.1. Both are purple button. Both are connected to 888LM.

It is consistent and repeatable.

Unplug the gdo and blaq, and then plug them back in (each opener has a power strip with a switch that both are plugged into.)

The wall panel flashes red and yellow and beeps every so often and goes black and then flashes red and yellow (repeating). Unplug the power from the blaq (leaving it wired to the GDO), and the next cycle, the wall panel beeps and goes yellow. Plug the blaq in and everything works great.

@Dave_Jones I think you were describing to me the same issue. Can you try this workaround and see if this works for you too?

I wonder if upgrading to the 889LM will fix it. I am going to test this as soon as I can and try to confirm before you guys buy two new wall buttons. I just got the 888LM and 889LM in the mail yesterday and Wednesday, but the purple-button GDO motor that I ordered won’t be here till Monday so I will test it out next week.

1 Like

Hi @nate .

Looks like I’ll beat you to it. I picked up an 889 off eBay to test and it is supposed to be here tomorrow. I’ll report back.

Is there a way to force the BLAQ to drop secplus and then bring it back up? Might help determine if a delay would even help.

I’m really impressed that you guys have gotten this close on the 888’s. Except for this issue, it really seems to be working great! (You know when I install the wires correctly…) :slight_smile:


1 Like

The problem here lies in how the blaq works with these panels. If these panel loses power they take up to 5 mins to charge and sync, meanwhile the BLAQ is ready to go in less than 30 seconds.

The process goes that the BLAQ listens for the panel for 2.5 seconds, if not found it will begin emulating one. If this happens before the panel is fully synced then the situation you describe will be the result, an unhappy panel👎.

We could add a sync delay for these cases perhaps, lots of considerations here though.

This makes sense and explains exactly what I am seeing.

Adding an option to specify how long to wait would probably fix the issue.

TBH, after a power failure, most people are going to be much more interested in a working wall panel than a working HA solution.

Thanks for the explanation!

@Ryan_P instead of a init delay, which can have some tricky implications, what if we added an build-time config option to disable “panel emulation mode” completely? users who have one of these older/slower wall buttons can enable that to prevent the blaQ from clobbering it.

1 Like

I’m not sure what implications it would have, but, I’m clearly not the expert here. The disable option sounds like it would probably work just as well.


I was thinking it could just be another protocol option.

I have also noticed this.