Insteon KeypadLinc - all buttons activating at once

Hi everyone,

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?

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.

Keypad configuration

UID: insteon:device:home:256AAE
label: Insteon Device  256AAE main hallway keypad
thingTypeUID: insteon:device
  productKey: F00.00.23
  address: 25.6A.AE
bridgeUID: insteon:network:home

I sometimes get random messages from my dimmers, but I haven’t seen this one before. Maybe your device is dying a slow death?

Do you have any rules that trigger on these buttons changing state? Like:

rule "example"
	Item keypadA changed

If you have something like this and polling detects a state change not picked up normally, it will trigger your rule to run.

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.

Here is how this happens:

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.

These are all ideas that should be considered.

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.

@tommycw10 to your point

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

  - id: "1"
      itemName: InsteonDevice256AAEmainhallwaykeypad_KeypadButtonG
      state: ON
      previousState: OFF
    type: core.ItemStateChangeTrigger

I’ve got a couple of options I guess

  1. the kludgy timer option (not great - a workaround for something that shouldn’t be happening)
  2. 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.
  3. 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)

Appreciate the brainstorming thus far!