RATGDO ~ Warnings in System Logs

Let me start off saying that the RATGDO is an awesome piece of equipment for garage door opening automations. It works seamlessly and integrates into HA like a dream. Now my question:

Since installing RATGDO32 into HA, I have noticed that I am getting new System Log warnings when I activate it. An example is:

Logger: homeassistant.components.esphome.manager
Source: components/esphome/manager.py:390
integration: ESPHome (documentation, issues)
First occurred: 11:12:33 AM (3 occurrences)
Last logged: 2:09:03 PM

ratgdo32 99ec70: [W][ratgdo_secplus1:281]: [157658896] Discard incomplete packet: [38 ...]
ratgdo32 99ec70: [W][ratgdo_secplus1:281]: [168248444] Discard incomplete packet: [3A ...]
ratgdo32 99ec70: [W][ratgdo_secplus1:281]: [168248706] Discard incomplete packet: [39 ...]

Is this normal? Is it something I should fix? If so how have others fixed this warning message?

1 Like

Seeing the same. Is this an issue to worry about?

So far I have seen no ill-effects from having these errors. However, since I have owned RATGDO since October 2025, I have had to cycle power on it twice. Twice it lost control of the garage door and could not tell whether it was up or down. Turning the power off to it seemed to reset it and get it working again.

I would say that it is about 95% reliable. I use it extensively to CLOSE the door when anyone leaves the house and OPEN the door when anyone enters the home zone. I really have to say it is very cool to come home with the garage opening automatically. With ALEXA greeting me home, the garage door opening for me, and the lights adjusting, it really makes having an automated home nice.

1 Like

That I know of, haven’t seen any reliability issues also. It has been 100% reliable in the 2 months i’ve had it but not using voice commands.

@Holydoc I read there could be noise from power. So, I moved my RATGDO further away from power cord the power cord to the garage door. Thus far, this seems to show an improvement and not seeing any Discard incomplete packet in the logs anymore. It has been 3 days of good luck.

1 Like

@batmanchi i do not have the luxury of moving its location. Both the garage opener and the RATGDO are in the same plug

I have not seen such errors. I have three of the RATGDO32 units, & no problems whatsoever encountered, in the 2+ years that I’ve had them.

@tim.plas Is it cold there? I read that can be another variable in this issue.

Not cold here either. Maybe the age of the garage door opener it is connected to? Just reaching here.

Well it’s been -20F on several nights in the last few weeks here. And none of my 3 RATGDO’s have balked at it. --But I’ll be honest that I wasn’t exactly exercising any outdoor equipment during that time. Staying indoors & warm; but didn’t get any alerts then either.

It appears i get a discard packet warning anytime i utilize the RATGDO system. Using the garage opener button seems to be fine. However if I tell the RATGDO to close the door, I get a packet warning, but the garage operates fine.

@Holydoc brainstorming, is this a possible wifi connection issue? What is your wifi strength?

My WiFi Signal at RATGDO is -56 dBM, so I think it is ok.

@Holydoc mine averages -56. However, do you have multiple access points? Wondering if it goes in and out via wifi roaming that can cause issues with IOT devices.

My garage is unattached and kept hitting multiple access points. After I added ratgdo32 to the roaming blocklist. Boom, much better! But only a sample of 1, you may be fine but worth discussing.

Thanks for the suggestions. I really do appreciate it.

No, i only have the one access point. Like i said, at least the warnings are not affecting the actual reliability of the item. Still opens and closes the garage door whenever I leave or arrive into my home zone.

1 Like

Same here. it’s just odd lol.

I get these warnings too, and it does affect my garage. Today I had a new variation of these:

data: [W][ratgdo:641]: Door did not stop, ignoring close command

Just prior to that, my HA automation commanded the door to close, but the door did not close, presumably due to that close command being ignored. And prior to that, I had opened the door manually about a minute earlier using the standard wall button, and around that time I saw the usual “Decode failed (parity error or invalid frame)” warnings.

I understand decoding errors are due to noise on the data line but I’m wondering what folks have found to be the cause (and fix) for that. I have the ratgdo powered on using the outlet in the same pair as the other outlet powering the garage door motor. All my wires going from the ratgdo to the garage motor went in snugly and seamlessly from what I remember so it doesn’t seem like that’s the problem but I’ll double check that. My wifi shouldn’t be the issue since I put an AP in the garage and it’s got an insane -38dBm and I can see that it’s always staying put on that AP. Any suggestions on what to check for are welcome.

@junktrunk202 where do you have your RATGDO mounted? I’ve read not putting it on the actual garage door reduces noise. For example, once I mounted mine higher on the metal above the garage door opener it helped reduce these odd warnings even.

Your wifi connection is awesome!

If you have a mesh network you may want to disable 2.4ghz roaming. This also helped my warnings reduce.

@batmanchi sorry I missed your reply earlier. Mine is mounted against the ceiling of the garage right to one side of the opener motor. There’s about 4 inches of space between the motor and the ceiling.

Today I tried a bunch of things to see if I could resolve the errors but they’re still there. I braided the 3 wires from the ratgdo to the motor and then wrapped those wires in aluminum foil. I tried changing out the USB power adapter for a different one but I couldn’t find any that would even power the ratgdo up other than the old cell phone adapter I’m currently using (for some reason there wasn’t one in my original order). I removed all the wiring from the wall toggle and sensors into the opener to try to confirm the dirty signal wasn’t coming from them, and I still saw dropped packet even in that situation. My network is unifi and I have this device on the IoT wifi ssid that has been configured as an IoT network specifically for compatibility, so I don’t think it’s related to that (and I didn’t find any other roaming settings enabled).

I’m running out of ideas so any other suggestions are welcome!