@bcopeland@gopher.ny The recent .123 update nicely addressed excessive events for Schlage BE468/BE469 locks.
That actually did seem to be impactful in a very positive manner for those locks (stopping spurious events that caused some ill mannered behavior, possibly worse than I realized). Thanks!!
Is something similar needed for the FE599/BE369 lock driver? Or, was the issue you fixed only impacting the BE468/BE469 locks and associated driver?
The thing I noticed as soon as I enabled the new option was that the "lock event manager" seemed to properly retain the state of the lock and there were not a bunch of "follow on" events that triggered extra actions (it's been a long time since I dealt with those BE468/BE469 locks--but I do recall having to make some adjustments to work around the extra events that this change suppresses).
I did notice that the option was only in the one driver.
I was wondering if, based on your knowledge of the drivers, if the unchanged one would benefit from being changed also--or if that wasn't necessary for it (iow, the other driver didn't have the problem of extra events)? I have some of both locks--and didn't realize how much that change helped until I had that option.
While the setting appears to make the lock behave better when commanded from the lock itself (keypad or knob),, when the setting is turned on it doesn't seem to update the state when the hub sends a command to it
Even pressing the "refresh" button didn't cause the state to update.
With the setting enabled, I ordered the lock and unlock buttons on the device page and, while they locked and unlocked the lock (a ZP version), the device state didn't change. Disabling the new setting caused the state to be updated.
I'll probably poke around with this more later.
Perhaps, certain "hub" actions (e.g., lock, unlock, refresh) might need to allow 1 lock operation report to go through?
