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

[JonLaliberte]

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]

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]

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

[mariusmuja]

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]

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]

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.

22:21:36 | [V] | [ratgdo:278] | [92313] Position update: 0.941218
22:21:36 | [D] | [cover:170] | 'Door' - Publishing:
22:21:36 | [D] | [cover:173] | Position: 94%
22:21:36 | [D] | [cover:186] | Current Operation: OPENING
22:21:36 | [V] | [json:038] | Attempting to allocate 512 bytes for JSON serialization
22:21:36 | [V] | [json:058] | Size after shrink 76 bytes
22:21:36 | [V] | [ratgdo:278] | [92817] Position update: 0.973526
22:21:36 | [D] | [cover:170] | 'Door' - Publishing:
22:21:36 | [D] | [cover:173] | Position: 97%
22:21:36 | [D] | [cover:186] | Current Operation: OPENING
22:21:36 | [V] | [json:038] | Attempting to allocate 512 bytes for JSON serialization
22:21:36 | [V] | [json:058] | Size after shrink 76 bytes
22:21:37 | [V] | [ratgdo:409] | Baud: 9615
22:21:37 | [W] | [ratgdo:440] | Discard incomplete packet, length: 16
22:21:37 | [D] | [esp8266.preferences:238] | Saving preferences to flash...

[mariusmuja]

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]

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]

@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]

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:

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]

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]

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 <#152 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATQMJNWETBJ5OAKRE3NCKLYO4ZNBAVCNFSM6AAAAABA5J6DDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJUHAZTMMJUGE>. You are receiving this because you commented.Message ID: ***@***.***>

[PaulWieland]

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]

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]

@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.