@Lawrence_Wicklund that log looks like the device crashed and unfortunately we do not know the cause yet. Any logs you can provide to assist with this will be greatly helpful.
@nate - Just updated to version 1.3.0 from version 1.2.4.
Will advise if I get any funkiness.
Fortunately I have not had any random openings or other weird behaviour that I am aware of since I updated to version 1.2.4.
So 
SManCan
Maybe a dumb question. I’ve had my BlaQ connected directly to the laptop trying to capture a phantom opening for almost 20 hours now. Could this be a bad power supply causing the reboots?
If you have the 12v adapter plugged in at the same time then power should not be an issue. If you are directly connected via USB you can omit the --device IP flag and stream logs directly over the USB serial.
It actually happened again today. I figured out how to do the log using epshome after it happened so I didn’t catch it. I’ll get it next time and shoot it up to you guys
I finally disconnected my wall opener and now just have a remote opener screwed to the wall. Thinking that the wall switch and the BlaQ were fighting each other for control. Makes a little more sense after reading Nate’s article. When connecting the wires for the wall opener to the pass through terminals on the BlaQ it would trigger the door to open. My wall mount opener does have a circuit board with the ability to lock, sense motion or turn on opener light. Another similar occurrence of opening occurred when my home router was being updated by Rogers and the dropping out of the router on the network.
Seems to be working fine without the wired opener, also have a keypad opener installed but no issues since removing the wired opener from the circuit.
After a week without issues I had two random openings this morning about an hour apart. I have no interest in disconnecting my wall switch. Returning: Spontaneous opening is a deal breaker for me. I may try again in the future.
Quick update:
Thank you all for the feedback, logs and trials. Today I was actually able to visit a customer’s home locally here in Orlando where one of our installer partners (shoutout to Tim @ Serenity Integrated Systems) was experiencing the same problem on an older Security+1.0 opener.
I was able to witness it happening a couple of times, and we did a bit of diagnostic.
I’m quite confident now that what’s causing the unexpected door triggers are the unhandled/unexpected reboot or crash of the ESP32 chip inside the GDO blaQ. I’ve pretty much ruled out a protocol error or rogue command or something like that. The GDO blaQ is not commanding the door to move, but instead what’s happening is that the blaQ is crashing for some reason and that momentary reboot/reset of the serial data stream is enough to trigger some garage doors to see it as a push-button door toggle trigger.
What we still don’t know is what is causing or why the blaQ is rebooting or crashing every once in a while. Maybe it’s a network thing or Wifi anomoly … I’m not sure. I’m currently trying to reproduce it in my bench setup with some enhanced logging to get closer to the root cause.
Stay tuned for updates.
2 Likes
Mine just did it again. Not sure if these logs help.
[21:25:11][D][sensor:094]: 'Heap Free': Sending state 165796.00000 B with 0 decimals of accuracy
[21:25:11][V][mqtt:477]: Publish(topic='esphome/34b7da61196c/sensor/heap_free/state' payload='165796' retain=1 qos=0)
[21:25:21][D][sensor:094]: 'WiFi Signal': Sending state -46.00000 dBm with 0 decimals of accuracy
[21:25:21][D][sensor:094]: 'WiFi Signal %': Sending state 100.00000 % with 0 decimals of accuracy
[21:25:21][V][mqtt:477]: Publish(topic='esphome/34b7da61196c/sensor/wifi_signal/state' payload='-46' retain=1 qos=0)
[21:25:42][D][sensor:094]: 'Uptime': Sending state 115462.05469 s with 0 decimals of accuracy
[21:25:42][V][mqtt:477]: Publish(topic='esphome/34b7da61196c/sensor/uptime/state' payload='115462' retain=1 qos=0)
WARNING konnected-34b7da61196c @ 192.168.7.155: Connection error occurred: [Errno 54] Connection reset by peer
INFO Processing unexpected disconnect from ESPHome API for konnected-34b7da61196c @ 192.168.7.155
WARNING Disconnected from API
INFO Successfully connected to konnected-34b7da61196c @ 192.168.7.155 in 0.136s
INFO Successful handshake with konnected-34b7da61196c @ 192.168.7.155 in 0.044s
[21:26:41][I][safe_mode:041]: Boot seems successful; resetting boot loop counter
[21:26:41][D][esp32.preferences:114]: Saving 1 preferences to flash...
[21:26:41][D][esp32.preferences:143]: Saving 1 preferences to flash: 0 cached, 1 written, 0 failed
[21:27:45][D][sensor:094]: 'Heap Free': Sending state 171544.00000 B with 0 decimals of accuracy
[21:27:45][V][mqtt:477]: Publish(topic='esphome/34b7da61196c/sensor/heap_free/state' payload='171544' retain=1 qos=0)
[21:28:39][V][mqtt.idf:119]: Event dispatched from event loop event_id=6
[21:28:39][V][mqtt.idf:155]: MQTT_EVENT_DATA esphome/34b7da61196c/cover/gd/command
[21:28:39][D][cover:076]: 'Garage Door' - Setting
[21:28:39][D][cover:084]: Position: 0%
[21:28:39][D][gdo_cover:221]: Close command received
[21:28:39][D][cover:170]: 'Garage Door' - Publishing:
[21:28:39][D][cover:173]: Position: 100%
[21:28:39][D][cover:186]: Current Operation: IDLE
[21:28:39][V][mqtt:477]: Publish(topic='esphome/34b7da61196c/cover/gd/position/state' payload='100' retain=1 qos=0)
[21:28:39][V][mqtt:477]: Publish(topic='esphome/34b7da61196c/cover/gd/state' payload='open'
Update! I’ve been able to replicate the problem on my bench setup and we now have a better understanding of where the crash/reboot is coming from. As I previously suspected, it’s nothing to do with the Security+ protocol or our custom component for the GDO, and more to do with environmental anomalies with the way the ESP firmware handles and recovers from WiFi blips and interruptions.
I was able to observe a couple of times the ESP’s watchdog timer causing the unhandled reboot. This seems to happen when there’s a WiFi glitch that for whatever reason hangs for more than the 5-second timeout that the watchdog is trained to observe.
I had a call with my firmware engineer @Ryan_P yesterday and we discussed a few mitigation techniques that we’re investigating. Can’t promise anything yet but stay tuned for updates.
2 Likes
Big news! We have what we think is a rock-solid fix!
I just released firmware version 1.3.1 for the GDO blaQ. Those of you affected with Security+1.0 openers please update your devices and let us know!
This release should completely resolve the problem of the door unexpectedly moving due to a unhandled crash/reboot. Thanks to all of you who helped us track down the problem, and huge thank you to @Ryan_P who did the heavy lifting here and dug deep to find the fix.
Reminder that there are a few ways to update your firmware:
- Use the Konnected app, tap Settings and kick off a new firmware build, it should pull the new base version 1.3.1.
- If you’re managing your own firmware in ESPHome dashboard, do a clean build files then Update.
- You can physically re-flash the firmware at install.konnected.io
waiting for your feedback!
1 Like
Hi – catching up here! I bought and installed an 889LM wall panel to replace my 398LM and still got what seemed like a random open, though I didn’t catch the issue in the logs.
Yesterday I installed the 1.3.1 firmware and haven’t had a random open since then.
Is it expected that the new firmware will work with my old 398LM?
The incompatibility with the 398LM and the random door movement trigger issues are completely separate issues. The firmware 1.3.1 fixes the unexpected/random door triggering issue.
The 398LM is inherently incompatible with the Security+ wire protocol used by the GDO blaQ and is still incompatible after 1.3.1. We do not have plans to attempt backwards compatibility with this wall button. The 398LM button was discontinued by LiftMaster in 2013 and should be replaced with the 889LM to use with the GDO blaQ.
1 Like
It has been a few days since installing 1.3.1 now and no random openings. I think you guys nailed that issue. Thanks to both Nate and Ryan for working to get it resolved. Much appreciated!
2 Likes
Awesome! Thank you for the follow up @JDuncan569 and thank you even more for updating your review to 5-stars on Amazon. It really means a lot to us!!
Very happy to hear this has been working for everyone so far. The issue was quite difficult and I’d like to thank Nate and all of the people here providing the feedback to help us resolve this.