Closed preppietechie closed 3 months ago
PaulWieland
commented
4 months ago I bet the capacitors in your 888LM are failing / leaking causing a higher than normal consumption of current on the signal line. Since the GDO responds to dry contact control, when the line is pulled low for more than ~50ms the GDO interprets this as a door toggle command.
This is a known issue with the 888LM, and liftmaster even offered a replacement program: https://cloud.info.liftmaster.com/888LMReplacement
cjhesse
commented
3 months ago I have an 889LM and sometimes experience similar issues on the ESPHome firmware. I never experienced the issue when using the MQTT version. MY door is Security+ 1.0 with purple learn button.
A couple times when I've had power to the garage turned off, then turned it back on, turning both the ratgdo and GDO at the same time, the door began cycling several times uncommanded, with the button making a beeping sound prior to each occasion. This didn't stop until I unplugged the ratgdo and plugged it back in. Unfortunately, I wasn't able to capture logs from the event because I was working outside and simply needed to get it to stop. When I have time, I can see if I can reproduce it.
Just this morning, the garage door began opening when my wife opened the door to the garage. I have an automation that turns the light on when the door opens, so I'm wondering if an issue with that command caused the garage door to open too. I don't have ratgdo logs of the events, but here's the Home Assistant histories and automation traces:
Light:
Garage door (according to my camera, the door began opening at 05:45:34):
All traces:
First trace (that triggered the light (and door?)):
Second trace:
Last trace (which ultimately shut the light off after 5 minutes):
The gist of the automation is:
The light has also been less reliable with the ESPHome firmware. There's been a few times the light didn't turn on or didn't turn off, but I don't recall having any of those issues with the MQTT version. The history above shows a quick off-on-off sequence for the light when the last step of the automation occurs, but the camera in my garage shows the light only turning off, so it worked fine this time even though the history looks odd.
edrikk
commented
3 months ago @mariusmuja This "initial boot" experience for V1 could be a much bigger issue if people are away from the home e.g. for vacation etc. From reading the various posts (in this ticket and others), it's clear that ratgdo has to start after the gdo/wall panel is up and running.
MQTT firmware specifically handles this scenario:
https://github.com/ratgdo/mqtt-ratgdo/commit/6f62cc2b5f0e70afcbf75ff949737f0fe65d3e12
door = 6; // stop from entering emulation after power outage when 889lm is booting up
My understanding is that this was accidentally dropped in the MQTT firmware, which caused issues, and was then added back by the above commit.
ESPHome should do the same/a similar thing I would think...
mariusmuja
commented
3 months ago Esphome version also handles this scenario:
https://github.com/ratgdo/esphome-ratgdo/blob/main/components/ratgdo/secplus1.cpp#L74 https://github.com/ratgdo/esphome-ratgdo/blob/main/components/ratgdo/secplus1.cpp#L370
but there's obviously some bug/timing difference to explain the difference in behaviour, not sure why at this point.
I would need a log capture (with verbose debugging turned on) to try to understand what's going on.
PaulWieland
commented
3 months ago I don't think the two issues in this thread are related. The original issue sounds like a typical 888LM hardware failure.
EDIT: I've tested power cycling ESP Home Sec +1 + 889LM and have found no issues yet. Ive started with a fully discharged 889LM (capacitors drained) as well as a partially discharged, The ESP Home firmware sees the 889LM syncing and does nothing except listen when booting up.
cjhesse
commented
3 months ago I haven't testing power cycles again yet, but I got another occurrence of an uncommanded opening that coincided with an attempted light command.
When my automation (as described above) attempted to turn off the opener's light at the end of the sequence, the light did not turn off and the door opened.
Unfortunately I don't have logs from the ratgdo because I was not there.
There's also been a few cases where a command to turn on or off the light was sent but to acted upon by the GDO. Is it possible theESPHome Sec+1 version has issues sending commands?
I believe your correct--my issues are different from the original ones, but I believe my issues are also separate. Should I create two new issues for those and let this one be closed?
cjhesse
commented
3 months ago I haven't been able to reproduce an uncommanded opening/closing while capturing logs, but I do get incomplete packet warnings every time I send a command, even if it works. Here's a sample from commanding the light on:
[05:55:26][D][ratgdo:095]: Door state=CLOSED
[05:55:27][D][ratgdo:204]: Light state=OFF
[05:55:27][D][ratgdo:210]: Lock state=UNLOCKED
[05:55:27][D][light:036]: 'Light' Setting:
[05:55:27][D][light:047]: State: ON
[05:55:27][W][ratgdo_secplus1:262]: [470660671] Discard incomplete packet: [39 ...]
[05:55:27][D][ratgdo:210]: Lock state=UNLOCKED
[05:55:28][W][ratgdo_secplus1:262]: [470661198] Discard incomplete packet: [3A ...]
[05:55:28][D][ratgdo:204]: Light state=ON
[05:55:28][D][ratgdo:210]: Lock state=UNLOCKEDAre such incomplete packets expected?
mariusmuja
commented
3 months ago Are such incomplete packets expected?
This happens when the GDO doesn't reply to a query within 100ms from a when a query is sent. A query is sent to the GDO every 250ms (by the wall panel or by ratgdo if it's in emulation mode) and normally a reply is sent immediately after. In this case the queries 0x39 and 0x3A receive no reply.
DesertHillsautomation
commented
3 months ago I am having the same issue. I have actually replaced my 88LM in the past because it died. I have RATGDO on two doors, same units with 88LM and one is acting up and the other is normal so far. I have an 8500 Jackshaft oddball unit that is maybe 1.0 but every thing we read we're not sure if it's a 2.0 protocol. Kinda bummed.
gullygossner
commented
3 months ago I just had a similar occurrence this morning after a good stretch of flawless operation. With the ratgdo power on, I powered the opener on. The opener then opened without any interaction.
The wall panel was doing a similar thing where it would be unresponsive, light up and then beep. It was almost like a boot loop. I restarted the ratgdo and it seems to have synced up and fixed itself.
Easy fix when one is available to handle it, terrifying if you're not home.
preppietechie
commented
3 months ago I followed the advice @PaulWieland gave and replaced the 888LM with an 889LM (using the replacement program Paul mentioned. Random door events have since stopped. It’s been 72 hours and I would have seen one by now if the problem were something else. Closing this because the problem was not with the RATGDO But with the 888LM.
tl;dr - if you’re using an 888LM, you’re gunna have a bad time. Swap it with an 889LM.
gullygossner
commented
3 months ago I followed the advice @PaulWieland gave and replaced the 888LM with an 889LM (using the replacement program Paul mentioned. Random door events have since stopped. It’s been 72 hours and I would have seen one by now if the problem were something else. Closing this because the problem was not with the RATGDO But with the 888LM.
tl;dr - if you’re using an 888LM, you’re gunna have a bad time. Swap it with an 889LM.
I have a 889LM.
preppietechie
commented
3 months ago I followed the advice @PaulWieland gave and replaced the 888LM with an 889LM (using the replacement program Paul mentioned. Random door events have since stopped. It’s been 72 hours and I would have seen one by now if the problem were something else. Closing this because the problem was not with the RATGDO But with the 888LM. tl;dr - if you’re using an 888LM, you’re gunna have a bad time. Swap it with an 889LM.
I have a 889LM.
It almost sounds like the capacitors in your 889LM are failing the same way the 888LMs do. It’s a super easy swap if you have a soldering iron, and new caps are super cheap, just match the same values listed on the side of the existing caps. You also might want to check your wiring to the wall button and make sure it’s getting the full voltage (and isn’t loose or anything). Either way, the initial issue (888LMs are bad) is resolved.
tmeekes
commented
3 months ago I just had a similar problem. MQTT has been working flawlessly, but when I put the ESPHome version on the board, it almost immediately started acting up.
Going to swap back to MQTT due to its reliability for now, will check back in on this one sometime later.
mariusmuja
commented
3 months ago I just had a similar problem. MQTT has been working flawlessly, but when I put the ESPHome version on the board, it almost immediately started acting up.
@tmeekes
Sounds like you can easily replicate the issue, can you capture a log (with verbose logging enabled) of when this happens?
tmeekes
commented
3 months ago I already swapped it back, but setup is easy enough I can look at doing a bit of testing and see what I can get out of it. Might have time to try it out tonight.
I'm using the current version available from the web installer (as of 2/1/24) on 2.5i hardware with an S+ 1.0 with an 888LM.
The door is opening and closing frequently. The 888LM is flashing a yellow light every minute or so, and occasionaly beeping (like it's just received power after being unplugged for a bit).
I had a similar problem with the MQTT version (See Issue #34 for the MQTT Version), but that was closed suggesting that my MQTT broker was "spamming mqtt messages to ratgdo for some reason." Now that I'm on the ESPHome version, I've got the same issue. Within one hour of flashing and installing the firmware, I'm having random door open and close event. They seem far worse using the ESPHome version. The logs scrolled past too quickly for me to get it in time, but I did see the unusual string below. Note that RATGDO believes that the button was pressed. Unless my house is haunted, I can confirm that the button was not pressed, as I'm the only one home.