I was going to post a feature request asking for the ability to change the sensor read averaging config to avoid some false positive open/close events, but it looks like that feature used to be in the code and was removed. I’m wondering if it didn’t work as intended, or my idea about what it will solve is wrong.
My Garadget unit works beautifully most of the time. I have it set up in MQTT-only mode for local integration with Home Assistant. But I’ve noticed that sometimes, when the garage door is physically open, I get rapid close->open alerts, sometimes dozens of them. The sensor only reports that it’s closed for a moment, then back to open…it never gets stuck in the wrong status, and it only jumps to the wrong status for a split second. It’s clearly some ambient light reflecting off of something–car in the driveway, white rocks outside, whatever. I tried increasing the “srt” threshold value up to 30, but while monitoring the brief false positives, the detection level jumps WAY up near 100 when it happens, so continuing to increase the threshold seems like the wrong approach.
Instead, I figured the simplest solution would be to require a state change to remain active for longer before reporting it. Then I saw the “srr” setting mentioned in some older docs, presumably achieving the same effect by low-pass filtering the trigger level. With a default value of 3 and a max (?) value of 20, I figured I’d just try cranking mine up to 20 to see if that fixed the issue. But, lo and behold, it’s no longer in the code. Nuts!
Should I just manually increase the #define'd SENSOR_READS value and compile+flash my own firmware? It seems like some user setting for time-based hysteresis would be helpful in some cases–just a simple option that says “don’t trigger a reported state change unless the value has been in the changed state for [x] milliseconds.” Maybe I could add it in as an “srd” value for “delay,” or something.