50ms debounce may be too short for the dry contact open/close limit switches

[CrazyCoder]

I noticed this in statuses:

Changed closeDoor and openDoor debounce times from 50 to 500 in isrDebounce and it seems to work correctly now.

[jrsquared]

I'm getting the same issue on my 8500; opened/closed toggles together at the same time.

[thomasshawn]

Same issues here. Is there a way to fix it on my end?

[CrazyCoder]

It was bumped to 100ms in 2.24: https://github.com/ratgdo/mqtt-ratgdo/commit/08677514f65595e7cda1530ca45069b8b3d31cca.

[thomasshawn]

I'm having the issue. I have five of these devices all on mqtt. Three of them are 8500 devices that use the old security protocol and they are working correctly. The other two are very old dry contact devices that I was able to get up and running with some Reed switches. One unit is working perfectly no issues it recognizes open, closed, as well as everything in between. However the last device appears to be bouncing when it settles. I've tried to add additional magnets I've tried to position the magnets closer or farther away but nothing seems to consistently fix the problem. I wish there was a way to poll the device again after 30 seconds to get the final state. I've checked my switches at fully open and fully closed and they are operating correctly so this is definitely a issue of some sort of Bounce within the device when it finally decides to record a final measurement. Would it be possible to open up that delay setting as a user-defined option so that we can tweak it for our own particular devices? Some people might be better at 500 milliseconds and some might be better at 100.

I'm open for suggestions to get me through until we can sort this out I don't know mqtt that well so I'm having a hard time troubleshooting I thought maybe changing qos might help but I don't see that as an option either

[rewardone]

User config would be interesting. Seems feedback and fine-tuning are still taking place.

Bumped to 300ms in 2.57: c91d0dc

[thomasshawn]

I was reading the yaml for the esp version and the debounce is A configurable option.  Would be nice if there was a way to tweak it on the web interface.  Currently, I have an automation the checks 2mins after open/close. If status reads opening or closing then it alerts me via an actionable notification. That notification opens a dashboard with images of my garage from cameras. I can then choose to send another mqtt publish command to update it correctly.  It's a long process for something that likely could be tweaked with a little longer time on the debounce but it's likely user and system dependent. 

On Thu, Jan 4, 2024 at 8:14 AM, @.***> wrote:

User config would be interesting. Seems feedback and fine-tuning are still taking place.

Bumped to 300ms in 2.57: c91d0dc

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

[PaulWieland]

Yes I increased it to 300ms because it seems that some external reed switches bounce for a lot longer as the door physically settles. It can be increased further based on feedback, but I would expect 300 to be plenty.

[thomasshawn]

Thanks I will update this afternoon and report back.  Download the file and update via OTA I assume? 

On Thu, Jan 4, 2024 at 8:56 AM, Paul @.***> wrote:

Yes I increased it to 300ms because it seems that some external reed switches bounce for a lot longer as the door physically settles. It can be increased further based on feedback, but I would expect 300 to be plenty.

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

[PaulWieland]

Yes, you can get the bin file from the release page.

[thomasshawn]

I'll keep a lookout for it but the bump to 300ms appears to have fixed it on my end thank you very much

[thomasshawn]

One way to guarantee that it's going to break is to brag that it's working. Just had a open closed cycle and it hung up on opening. So it never saw the full open and then it never saw the closed either. So I had to send the mqtt publish to get it straight

[thomasshawn]

Watched it this time. Sees opening, open, closing and closed... Then bounces to opening after fully closed.

[dennisracine]

So i have this issue as well. hardware v2.5, dry connect, with firmware v.2,56 the open state was correct, but on close would flash 'closed' state for .11 seconds, and then switch to 'opening' ... when triggering a open event, the status would switch to 'closed' and then to 'opening' and then 'open' (and stay 'open') as expected. With firmware v2.57 now when the door is open, the state is 'closed' instead of open. while the closed state now just switches to 'opening' when it's in the closed position.

[xAcrosonicx]

So i have this issue as well. hardware v2.5, dry connect, with firmware v.2,56 the open state was correct, but on close would flash 'closed' state for .11 seconds, and then switch to 'opening' ... when triggering a open event, the status would switch to 'closed' and then to 'opening' and then 'open' (and stay 'open') as expected. With firmware v2.57 now when the door is open, the state is 'closed' instead of open. while the closed state now just switches to 'opening' when it's in the closed position.

Similar issue here. I have a v2.5 board with dry contact with reed switches on a Genie 2028. Ever since I got the ratgdo about a month ago it has always gone from "Was closed" to "Was opened" to "Was closed" every single time I used my wall button or remote opener - regardless of whether or not it was opening or closing.

Just read through this thread and updated to v2.57. Gave the garage door a few full opens and closes for good measure, then did one and watched. Now, when it just cycles from "Was closed" to "Is opening" regardless.

Can someone verify I have wired the reed switches correctly? This is a new concept to me, but I have them both wired to NC, with the open reed switch connected to the open trigger on the board and closed to closed trigger. Then I have both grounds joining up and running to the actual garage door opener terminal.

[dennisracine]

So the odd thing here is, if i have the door in a non-closed position, I can manually trigger the 'closed' condition with no issues, I get a response immediately and it sticks. even if I go on/off/on/off it will still remain 'closed'. It's as if there is another condition of the door actually being closed thats messing with the signal, as once the door is actually closed I can not force the condition, as I could when it was not. Maybe I'll do a vid to try and help see what I'm seeing/doing.

[thomasshawn]

I ended up setting up an mqtt script to push the mode I wanted. 

On Fri, Jan 12, 2024 at 10:49 AM, Racine-Web @.***> wrote:

So the odd thing here is, if i have the door in a non-closed position, I can manually trigger the 'closed' condition with no issues, I get a response immediately and it sticks. even if I go on/off/on/off it will still remain 'closed'. It's as if there is another condition of the door actually being closed thats messing with the signal, as once the door is actually closed I can not force the condition, as I could when it was not. Maybe I'll do a vid to try and help see what I'm seeing/doing.

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

[redstormsju]

I ended up setting up an mqtt script to push the mode I wanted.  On Fri, Jan 12, 2024 at 10:49 AM, Racine-Web @.> wrote: So the odd thing here is, if i have the door in a non-closed position, I can manually trigger the 'closed' condition with no issues, I get a response immediately and it sticks. even if I go on/off/on/off it will still remain 'closed'. It's as if there is another condition of the door actually being closed thats messing with the signal, as once the door is actually closed I can not force the condition, as I could when it was not. Maybe I'll do a vid to try and help see what I'm seeing/doing. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.>

How did you connect the wires to the reed switch? To NC or NO? Ive seen on threads different answers.

[thomasshawn]

NO in both locations. So the circuit is open unless the magnet is preset. So when the device sees a Closed circuit it knows the closed circuit spot represents the door in the current position (top reed switch vs bottom) . When neither circuit is closed then it knows it is either opening or closing.

[redstormsju]

NO in both locations. So the circuit is open unless the magnet is preset. So when the device sees a Closed circuit it knows the closed circuit spot represents the door in the current position (top reed switch vs bottom) . When neither circuit is closed then it knows it is either opening or closing.

Thank you. When I first installed it, that's where I set them up but the status was not working due to the bouncing issue so I disconnected them for now. Hopefully a fix in the software is made.

[mjmcg]

I think my issue is related. I've got 3 ratgdo boards. Two Overhead Door Legacy models using dry contact and one Liftmaster 8355 using Security 2.0. One of the dry contact ratgdo keeps bouncing "was opened/is closing", no issues with the other two. To eliminate it being a hardware issue, I swapped the reed switch and even swapped the ratgdo board with the Security 2.0 one and the issue still occurs.

I'm on firmware v2.57 for hardware v2.50.

[thomasshawn]

Yes I increased it to 300ms because it seems that some external reed switches bounce for a lot longer as the door physically settles. It can be increased further based on feedback, but I would expect 300 to be plenty.

Thank you. Can it be updated directly from your site or do I need to download the latest bin file and manually upload the update?

Would love the ability to tweak individually. Is there a harm in pushing it to 500 or even 750ms?

Seems several people still having issues and looks like the esp version default is 500.

[redstormsju]

NO in both locations. So the circuit is open unless the magnet is preset. So when the device sees a Closed circuit it knows the closed circuit spot represents the door in the current position (top reed switch vs bottom) . When neither circuit is closed then it knows it is either opening or closing.

So it seems the new software update has fixed the issue for me. I took at a look at my wire in the reed and they are on NC. I’m getting the correct status on HA, so maybe as long as both reeds are connected to the same contact, the status will be correct on the app.

[thomasshawn]

hope it helps. for me there was a honeymoon period where it looked like it was working and then it was erratic again. My theory is the baseline flakiness of the reed switches and not the ratgdo platform. for me it's close but not finished,. hoping for a user-defined debounce or maybe a doubling of what we have and see if that fixes it for most.

[mjmcg]

I'm wondering if this is made worse due to the flakiness of the cheap Amazon reed sensors many of us have. This error started happening when the temperature dropped down well below freezing, and hasn't happened since it's warmed up into the 40s F.

[thomasshawn]

I agree. I mentioned it on one of the reddit threads a while back and i assume we all bought the cheapest multipack we could to make it work. I've been hesitant to buy new ones try for two reasons. 1) my openers are almost 20yrs old and I'd rather not dump a lot of money into these if the GDOs might fail soon. When they do fail I'll move ratgdo onto new GDOs that'll be security 2+ and won't need reed switches. 2) don't want to go down the rabbit hole of spending money on 5 different sets of switches and the issue still isn't completely resolved.