Having a very odd issue with a KeypadLinc 8 button keypad that I have at my front door.
This is on OH3 setup that was new (didn’t migrate anything from my older OH2 version), running on a raspberry pi.
The issue I’m seeing is that at some random times, all of the keypad buttons will just trigger at the same time.
This is concerning, but what makes it particularly unfortunate is that one of the buttons controls my garage door, so it’s been opening unexpectedly when this occurs. Another button is the “all lights off” button, so that’s not great either.
Wondering if anyone has seen this, or may have some diagnostic/troubleshooting tips to help out?
Thanks
Log entries of the most recent occurrence
2021-04-08 20:20:53.920 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'InsteonDevice256AAEmainhallwaykeypad_KeypadButtonB' changed from OFF to ON
2021-04-08 20:20:53.925 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'InsteonDevice256AAEmainhallwaykeypad_KeypadButtonC' changed from OFF to ON
2021-04-08 20:20:53.929 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'InsteonDevice256AAEmainhallwaykeypad_KeypadButtonD' changed from OFF to ON
2021-04-08 20:20:53.931 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'InsteonDevice256AAEmainhallwaykeypad_KeypadButtonE' changed from OFF to ON
2021-04-08 20:20:53.936 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'InsteonDevice256AAEmainhallwaykeypad_KeypadButtonF' changed from OFF to ON
2021-04-08 20:20:53.938 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'InsteonDevice256AAEmainhallwaykeypad_KeypadButtonG' changed from OFF to ON
2021-04-08 20:20:53.942 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'InsteonDevice256AAEmainhallwaykeypad_KeypadButtonH' changed from OFF to ON
Nothing else before/after in the log seems to be related (but there is a lot, since button C triggers everything off), but happy to post if that helps.
Yes, I do have rules like this - and this is the exact issue.
However in my view it’s not normal for the state of these buttons to just randomly change, let alone all at once.
Is there some other way I could capture only “real” changes that you’re aware of?. Seems like @ranielsen maybe on to something - maybe the device is failing…
I suppose you could make a horrible kludgy thing that -
Started a short timer on first “button press”
Counts any further “presses” during time.
On expiry, if count=0 treat as real press.
It’s an odd effect, not really the sort of thing you would expect to see from a temporary communication error, etc.
You push a button, things happen possible via direct Insteon links, but your PLM/OH don’t see it. Minutes/Hours later OH polls the device and discovers it is in a different state than the last known state - bam rule trigger
Another scenario - you restart OH and either you don’t have any persistence set up so OH thinks the state us NULL or you do have persistence set up but things changed while OH was down. Some time later polling occurs and detects the state as different than last known and - ban rule trigger.
To combat this use triggers like “received command ON” or “received command OFF”, those will not trigger in the above examples as no command was sent. I just checked my rules and I see I use a “received update ON” trigger. Experiment with these, I’m not remembering the significance of these right now, but I do know that using “changed” rules can be problematic with the keypad buttons.
It is not that here, the events.log shows ... changed from OFF to ON
Even so, so long as OP rules are triggering from changed to ON
or similar - are they? - then restores from NULL to OFF or recoveries from UNDEF to OFF would be ignored.
This will only work if the binding has been configured to issue commands in response to incoming messages. While that would be a sensible thing to do with a keypad, I don’t thinkits possible in Insteon binding.
That is correct, the binding does not send commands, only state changes.
BTW, I only use the keypad to close the garage door and only if it’s already open. I guess I don’t trust the devices enough to use it to open my garage doors. I do use it to turn on lights and I’ve randomly had lights turn on in the past.
As an observation - this hadn’t happened in the prior version of OH that I had running, nor any time in the past even back when I was using an older tool called mister house. I’m starting to feel this may be the device going sideways.
You push a button, things happen possible via direct Insteon links, but your PLM/OH don’t see it. Minutes/Hours later OH polls the device and discovers it is in a different state than the last known state - bam rule trigger
I see what you’re saying, however, in this particular instance I know that the device wasn’t physically activated by anyone that evening, and I was just sitting on the couch when all of the buttons triggered at 20h. Also, the B, C, D, E, F buttons on the keypad are not used - so in normal use nobody would press those.
@rossko57 In my rule, I’ve got the trigger set to look for the specific OFF->ON change
triggers:
- id: "1"
configuration:
itemName: InsteonDevice256AAEmainhallwaykeypad_KeypadButtonG
state: ON
previousState: OFF
type: core.ItemStateChangeTrigger
I’ve got a couple of options I guess
the kludgy timer option (not great - a workaround for something that shouldn’t be happening)
swap out the device with another similar model - I’ve got another one in the house that I could potentially swap in and monitor for any similar issues.
replace with another device. I’ve got quite a lot of Z-Wave devices, and I’d love to find something that’d replace this, but as of yet haven’t come cross something that matches the requirements (Inovelli needs to build one - love their stuff)
controls load with one switch
at least 2 other keypad switches (one for each garage)
keypad switches have a light (to indicate status of the garage doors)
