over 500 Status changes in just a few hours: Door Cycling between various states

[thomasshawn]

This unit is a previously working MQTT version 2.57 with dry contacts on a very old push button style overhead door GDO. only issue has been the debounce timing still not being correct.

To bridge that gap for the debounce issue, I have setup a few notifications (opened, closed and one that will check status and notify me if it started an open/closed cycle and didn't finish.- i can then fix the status by publishing an MQTT command- otherwise my controls within HA do no work).

The issue now is that the last few days my device will start flipping between open/closing multiple times a second. it's moving so fast that I cannot control it with HA button because it has already cycled to next state. the only option is to access the webui and tell it to reboot the device. once that is done the device is good again for ~12 hours then it starts again. no physical change to the door occurs and it fixes the flipping between phases. If i am home and can use the pushbutton on the wall to cycle the door open/closed, it also resolves it, but only for a shorter period of time- sometimes 2 hours sometimes 10 mins.. best solution is rebooting the ratgdo device.

This is only happening on 1 of my 5 units. I have 2 identical 20+yr old overhead door units and 3 newer liftmaster 8500 Security 2-ish and they all work fine with the ratgdo. it's only this unit, I can't get a log because in doing so, I'd have to disconnect/reboot the device which will solve the issue for ~12hrs. I have checked my reed switches for continuity and tested them for function and they appear to be working so it doesn't appear to be a switch issue. I verified all my wiring as well and re-did all my connections trying to make sure nothing physical was the cause.

i tried re-flashing 2.57 and when it rebooted after the flash it was in a loop again and i had to force a reboot using the web ui. i had mqtt explorer open and say this hundreds of times

01/28/2024 7:17:42 AM(-0.29 seconds) closing 01/28/2024 7:17:42 AM(-0.32 seconds) open

during the re-flash MQTT explorer was showing constant open/closing flip-flop signals After about 2 mins the constant flip/flop happened again.

i tried to flash OTA to 2.56 and it wouldn't let me downgrade OTA. previously the most reliable way to "fix" it temporarily has been to use the wall button but that lasts shorter than a device reboot. I 'm not always home to troubleshoot and cycle the button so i have to remote into my house, log onto the webui and force a reboot which previously lasted ~12hours but lately has been getting to be less

Since i have my notifications setup to tell me essentially about every state change, I got so many notifications between 7 and 9 am yesterday that HA sent me a message saying I had reached my 500 notification limit for the day. I didn't even know that was a thing. but I've been reset and now I'm back to receiving notifications.

open to suggestions on how to fix or how to provide more information since generally a reboot solves the issue for many hours,

[PaulWieland]

It seems like at least one of your reed switches is floating. If its always going between open and closing, then check the open limit switch. Make sure its mounted so that the magnet definitively closes the circuit. If the magnet is a little too far away, the switch can flip flop.

To test this, you can take a fridge magnet and just set it on the open limit switch. if the flip flopping of the status stops, you know that the magnet mounted to the door is too far away from the switch.

HTH

[thomasshawn]

I took the Reed switches out of the circuit and tested them with a continuity tester just as you describe with the kitchen magnet and it works great. reconnect the system and cycle the door and it works perfectly. If I leave the door partially opened I can trigger the correct status across the system with a kitchen magnet, and it reads the correct open or closed status and the correct opening and closing interval status.

However after some poorly defined period Of time the status flips back and forth as described. This isn't a debounce issue this is the system completely at rest and it will just start cycling.

I tried very hard to rule out the switches before I submitted this. And I'm not sure why rebooting the device would fix a floating switch.

I did power cycle the device this morning and so far it has behaved but I've gone 12 hours recently without issue so I can't put too much weight in that.

[PaulWieland]

A reboot might change the symptoms but not the cause. If you reboot and both switches are in the open state, it wont report any status.

Next time it starts flip flopping, put the fridge magnet on the switch as it is installed on the door, without rebooting or changing any other parameters. If it stops flip flopping, then the magnet is physically too far away from the switch.

[thomasshawn]

I can try that.  I will say I considered that and I adjusted magnets on the closed side trying to address that, and it didn't change anything. based on my current setup  my closed reed switch only has about 5mm of clearance with the magnet.  So that suggests that it would be the open switch in error... But this is happening at closed state so the open magnet shouldn't be in play at that point.  I will try it either way and let you know.  On Sun, Jan 28, 2024 at 8:16 AM, Paul @.***> wrote:

A reboot might change the symptoms but not the cause. If you reboot and both switches are in the open state, it wont report any status.

Next time it starts flip flopping, put the fridge magnet on the switch as it is installed on the door, without rebooting or changing any other parameters. If it stops flip flopping, then the magnet is physically too far away from the switch.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[PaulWieland]

Well, you need two reed switches: One switch for fully open and one for fully closed. If you do not have two switches connected, then that explains the problem you are experiencing!

[thomasshawn]

i absolutely do have 2 switches, not sure what i said that implied that. I have 2 switches one for open and one for closed but the closed one has very minimal clearance and the open one shouldn't be at play when the error is occurring

where are we on this debounce issue? can we get a user defined option in the webui or somewhere like the esp version? #3

[PaulWieland]

Sorry I mis-interpreted your reply.

open one shouldn't be at play when the error is occurring

01/28/2024 7:17:42 AM(-0.29 seconds) closing 01/28/2024 7:17:42 AM(-0.32 seconds) open

Maybe I'm not thinking about this correctly, but your log indicates that the state is flip flopping between open and closing which means the closed limit switch should have no effect.

• Open state is detected when the trigger open input is connected with GND
• Closing state is detected when both trigger open/closed are floating but the last state was open

So in order for it to flip flop between open / closing / open, the trigger-open terminal has to be grounded, then floating, then grounded again.

[thomasshawn]

Yep has me scratching my head too.

That's why I submitted.

Open switch shouldn't be in play but it's the one that seems to be involved.

I tested both switches best I know how with both continuity tester/magnet and also wired in using a magnet and it behaves appropriately.

[thomasshawn]

So, despite my contacts checking out and registering appropriately open and close the continual false open readings led me to swap them for actual GDO dry contacts. They are much more expensive but they had added adjustability and a much larger range of detection so they seemed to bounce much less.

I have had them installed now for a week and they have only falsed 2 times in that period.

One was a a spontaneous state change with no door movement

The second was a bounce that occurred after fully open.

A vast improvement over the 500+ a day. So the cheap switches were the majority culprit.

I would still like a bit more de-bounce to squelch the last remaining bounce because it does impact operation if the device can't determine state.

Request either a bump to 500ms from the 300

Or

User configurable possibly from the webui.