Long delay before state reaches "Open" ... sometimes #152
Comments
|
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. |
|
@mariusmuja Thanks! That makes sense. How could I enable /access the debug logging? |
|
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: |
|
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? |
|
Added logging verbose and opened the door. It looks like its almost always now missing the last motor off status: 22:21:36 | [V] | [ratgdo:278] | [92313] Position update: 0.941218 |
This has been added on a working branch, should make its way to master eventually. |
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. |
|
@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. |
|
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:
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? |
Btw, same was true in my case, after having the light on for a while I could receive messages from the GDO. |
|
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: ***@***.***>
|
|
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. |
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? |
|
@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: 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. |
|
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. |
|
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: |
|
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 <#246>
—
Reply to this email directly, view it on GitHub <#152 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATQMJIAHNW7DOZHXR47IADY7UZGBAVCNFSM6AAAAABA5J6DDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBRGU3TIMBQG4>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
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.
The text was updated successfully, but these errors were encountered: