Long delay before state reaches "Open" ... sometimes

JonLaliberte commented 11 months ago

I have an automation that opens the garage, then waits up to 1 minute for the state of the cover to switch to "open". It was working well for about a week or more with the ratgdo, but today the automation has failed three times. I checked it out and I'm seeing that it's showing the garage door is opening, but it doesn't reach the open state until nearly 5 minutes later.

Example:

After leaving, I have an automation that closes the garage when I exit the home zone, this one worked fine:

As did the next automation that opens the garage when I enter the home zone:

I could trigger on "opening" instead of "open", but I'd like to figure out what is causing the problem here.

mariusmuja commented 11 months ago

Hard to say what the issue is without a debug log from the ESP, but it looks a lot like the status message from the GDO was not received. The GDO sends a status message when the door finishes opening/closing and that's what triggers the door state change. Status messages are also send by the GDO every ~5min, probably that's why the door status was only updated ~5min later.

JonLaliberte commented 11 months ago

@mariusmuja Thanks! That makes sense. How could I enable /access the debug logging?

mariusmuja commented 11 months ago

The simplest way to access the log is probably on the web server page of the ESP. Ideally, you would change the logging level to verbose to see more information, in the yaml file update the logger component to:

logger:
   level: VERBOSE

igorparsadanov commented 11 months ago

I have started to run into this same issue too. Today the door was stuck in closing state, but in the past I have seen the device get stuck in opening state essentially breaking the automation and leaving my garage door open. It seems that the motor off state isn't being seen? Today when it got stuck I hit the query state button and that updated it for me. Can we add a feature that if opening time > expected opening time we query state?

igorparsadanov commented 10 months ago

Added logging verbose and opened the door. It looks like its almost always now missing the last motor off status: Looks like it's discarding an incomplete packet which I believe is the status update packet.

mariusmuja commented 10 months ago

Can we add a feature that if opening time > expected opening time we query state?

This has been added on a working branch, should make its way to master eventually.

mariusmuja commented 10 months ago

Added logging verbose and opened the door. It looks like its almost always now missing the last motor off status: Looks like it's discarding an incomplete packet which I believe is the status update packet.

I've been seeing this on my GDO as well since is got colder. My hypothesis is that the gate voltage of the MOSFET on the RX side is close to the low voltage on the data line, and since the this threshold decreases with the temperature it ends up not (correctly) receiving some of the packet bytes.

igorparsadanov commented 10 months ago

@mariusmuja I think you nailed it. It has something to do with the cold temperature. The garage temperature right now is 40*F. I can send commands to GDO, but status and other updates aren't registering from GDO (looked at the logs for the ratgdo lines. If I turn on the light bulb, a few minutes later I can get updates from the GDO when hitting the query status. For reference I have ratgdo 2.5.

mariusmuja commented 10 months ago

I've come to think it's something to do with the GDO boards that's made worse by cold temperatures. When it got colder any messages my GDO was sending were not recognized. I looked at the data line with an oscilloscope and when the GDO was sending message, instead of pulling the 12V line to 0V it would pull it to somewhere between 2V-4V (with a noisy low threshold).

I was also taking 3.3V to power the esp from the GDO board, so wanting to eliminate that as a reason, I opened the GDO to tap into a 12V rail. While probing around on the GDO board (on top of a ladder) a managed to short the 12V rail to the 3.3V rail. The GDO stopped working and I was sure I fried it (even started searching how much a replacement board would cost). Then I figured I should look at the board with a thermal camera and noticed that the embedded wifi board was really hot (indicating a short on it). Having nothing to loose I ripped off the embedded wifi board and the GDO board started working again:

20240114_190239

Also now the messages from the GDO look nice and crisp, the line is pulled to 0V when the GDO is transmitting and no more missed messages.

Problem is that there are to many variables and I don't know what fixed it:

removing the 3.3V tap? I tend to think not, because I also tried with a board powered separately from USB and the issue was still there.
removing the embedded wifi card? Is the embedded wifi card pulling too much power and causing issues when the weather is cold?
both of above? Maybe the 3.3v rail was under-powered and removing both my tap on the 3.3v line and the embedded wifi card allows the rest of the logic on the board to have enough power to function correctly (and properly open the transitor on the data line to bring it to 0V when transmitting).

Btw, my GDO is the kind with a battery and a DC motor. When searching for a replacement GDO board I noticed that there have been 2 revisions/versions of the board since it was made, so maybe the old boards had some issues the new revisions fixed?

mariusmuja commented 10 months ago

If I turn on the light bulb, a few minutes later I can get updates from the GDO when hitting the query status.

Btw, same was true in my case, after having the light on for a while I could receive messages from the GDO.

igorparsadanov commented 10 months ago

BTW I’m not pulling power from GDO but running mine of separate 5v, just as a datapoint.

Sent with Shortwave https://www.shortwave.com?utm_medium=email&utm_content=signature&utm_source=cGFyc2FkYW5vdkBnbWFpbC5jb20=

On Wed Jan 17, 2024, 02:28 AM GMT, Marius Muja @.***> wrote:

If I turn on the light bulb, a few minutes later I can get updates from the GDO when hitting the query status. Btw, same things was true in my case, after having the light on for a while I could receive messages from the GDO. — Reply to this email directly, view it on GitHub https://github.com/ratgdo/esphome-ratgdo/issues/152#issuecomment-1894836141, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATQMJNWETBJ5OAKRE3NCKLYO4ZNBAVCNFSM6AAAAABA5J6DDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJUHAZTMMJUGE. You are receiving this because you commented.Message ID: @.***>

PaulWieland commented 10 months ago

This is really interesting as my 2.0 test opener works correctly in cold temperatures (it's 7 degrees here this morning). I will try and capture a scope reading from it later at various temperatures (its sitting on my bench so I can just move it around to test it).

That being said, a 2v low should still work. 3v is grey area/floating and 4v shouldn't work.

mariusmuja commented 10 months ago

This is really interesting as my 2.0 test opener works correctly in cold temperatures

I swapped my GDO for a quieter DC motor model with battery backup sometime last year. I didn't have an issue with the one before (AC motor model), only with the DC motor model one. They obviously have quite different control boards.

@igorparsadanov Is you GDO also a DC motor model with battery backup?

igorparsadanov commented 10 months ago

@mariusmuja Not sure how to tell if I have a DC motor, but I do have a battery backup. And the logic board number on my unit is 001d8363.

Edit: My other gdo does not have a battery, and its logic board is 41D7675 and this unit does not seem to be affected by temperature.

Now that I think about it the unit that has a battery would have to be a DC motor unit for the backup battery to operate it.

yargok commented 10 months ago

I am having the same problem here. My automations/home assistant are not working with the cold weather we have (22F). Commands work instantly, light status works, but door status is intermittent. I can open with myQ or remote and the door changes state immediately. The ESP web dashboard does not show the change.

chriscrowe commented 7 months ago

Has anyone confirmed if the ratgdo is still attached to your network during these minutes where the state is not updating properly? I have the same symptom where the ratgdo becomes unresponsive (doesn't update state) for several minutes after issuing an open-command, but during that period the device has completely dropped off the network (doesn't respond to pings). I think its related to this issue:

device regularly becomes unresponsive for several minutes

igorparsadanov commented 7 months ago

I have confirmed that the ratgdo for this issue is fully functional while not getting status updates. This only occurs on the gdo with a battery backup and only when temperature is below 40*.

Sent with Shortwave https://www.shortwave.com?utm_medium=email&utm_content=signature&utm_source=cGFyc2FkYW5vdkBnbWFpbC5jb20=

On Sun Apr 28, 2024, 05:50 PM GMT, Chris Crowe @.***> wrote:

Has anyone confirmed if the ratgdo is still attached to your network during these minutes where the state is not updating properly? I have the same symptom where the ratgdo becomes unresponsive (doesn't update state) for several minutes after issuing an open-command, but during that period the device has completely dropped off the network (doesn't respond to pings). I think its related to this issue:

246 https://github.com/ratgdo/esphome-ratgdo/issues/246

— Reply to this email directly, view it on GitHub https://github.com/ratgdo/esphome-ratgdo/issues/152#issuecomment-2081574007, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATQMJIAHNW7DOZHXR47IADY7UZGBAVCNFSM6AAAAABA5J6DDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBRGU3TIMBQG4. You are receiving this because you were mentioned.Message ID: @.***>

yargok commented 3 weeks ago

As we head back to cold weather, i am considering adding heating tape to keep the garage door opener warm. Anyone tried something like this?

ratgdo / esphome-ratgdo

Long delay before state reaches "Open" ... sometimes #152

246 https://github.com/ratgdo/esphome-ratgdo/issues/246