KeypadLinc Troubles

A while ago my 8-Button KPL started having issues. Usually the buttons would display whether their linked devices were ON or OFF and you could toggle them by clicking the buttons. Suddenly, one of the buttons stopped working properly. It would display a devices status but if you tried to toggle it ON or OFF by clicking the button it would just flash twice and the device would not respond. This behaviour spread to another button so I decided to Factory reset the KPL and re-sync the links.

After doing that, most of the buttons appeared to display their linked device's Status but now none of them were able to control their devices when manually toggled on the KPL. So I decided to remove all links in the Manage Links window and re-add them. The same problem persisted. Buttons Respond to their device's Status but manually toggling them does not Control the devices. The button LEDs do toggle on and off when manually operated.

I should note that I don't seem to receive any Insteon Commands in my log window when any of the buttons are pressed other than the Main Load.

Also. One of the buttons is controlled by Indigo since I use it to display Status and Control a Device Group that I set up.

I'm running the latest version of Indigo 6beta.

When I turn ON or OFF one of the linked devices (a DualBand SwitchLinc) I get this in the log...
unable to set keypad button state for main load-controlled buttons ( 1, 2, 7 or 8 ) -- use turn on/off commands instead

Thanks for any advice.

[matt (support)]

It sounds like the module might be failing.

I'd suggest you factory reset the module, then Define and Sync it again. Immediately after that, re-sync it again and copy/paste the Event Log contents showing both syncs. I'll take a look at the results and see if I can deduce anything.

The error you are seeing is because you have an action that is trying to control one of the LEDs on the KeypadLinc that is currently assigned to control the main load (attached to the KeypadLinc). For a KPL in 8 button layout mode, that is button #1. But for a KPL in 6 button layout mode, that is buttons 1 and 2 (top row of buttons which turns the load ON) and buttons 7 and 8 (bottom row of buttons which turns the load OFF). For those buttons (depending on the button layout mode) you cannot directly control the LED but you have to instead send the ON or OFF commands to control the load (which the KPL will then use to update the LEDs). Note Indigo might not know which button layout mode the KPL is in -- it might think it is in 6 button mode instead of 8. The factory reset and re-define/sync should help that, if that is the problem.

Thanks Matt,

Sorry, you can file this one under 'dumb question'. Turns out, for some reason my KPL actually WAS in 6-button mode. I'm not sure why since it's not something I would have changed at any point. After updating to 8-button and re-syncing, everything seems to be back to full operation. I can't really explain how the original issue arose but at least it's working now.

One thing that might be worth adding to that error message about buttons 1,2,7,8 is maybe something that plainly says the button is currently in 6-button mode... For dummies like me.

Anyway, thanks for pointing me in the right direction.

Mark

just now, i was trying to set up some triggers whose actions turned on/off keypad buttons.

i was having problems with the triggers not working. did some poking around the forums and tried some things: making sure keypad was in the correct 6/8 button mode (it was). performed factory reset. problem persisted.

the error i was seeing in the log was: "<module name> keypad button <button#> on; failed (checksum invalid)". i got this error 100% of the time the trigger executed. i got a similar error 100% of the time for a similar trigger that was supposed to turn a keypad button off.

i created action groups that turned on/off the keypad using the same action and they worked reliably. strange... so i then tried adding a 1-second delay on the triggers' actions and this made the triggers work reliably.

i'm not certain whether there is something unique to the turn on/off keypad button action vs. if it was just the specific details of how i was testing the triggers. btw, the triggers use device state change as the trigger and i was invoking a device state change by pressing a remotelinc button linked to the device whose state is tracked by the trigger. afaik, the smallest delay you can add is a full second, which makes the buttons seem slower to respond - i can live with it.

the thing that makes me uncomfortable about this, is that i set up some similar triggers some months ago and didn't run into this problem. now i suspect that the reason i didn't was merely because of the specifics of how i was testing and if the trigger got invoked a different way, i suspect my older triggers would probably fail as well. does not say much for indigo/insteon robustness, i'm afraid.

[matt (support)]

Unfortunately, it doesn't appear the INSTEON transport layer handles collisions very well. Does the originator of the Trigger (button press on an INSTEON controller?) have any additional direct links to modules besides the PowerLinc? This is the most common cause of these types of problems. The problem is the outgoing command from the Indigo action can collide with the direct clean-up commands the controlling module is sending. It is possible that even without any additional links there is a collision with the direct cleanup command that occurs to the PowerLinc itself, but that normally doesn't occur. Collisions are also more likely in cases where there is signal noise since that increases the likelihood of repeats and hopping (less likely in this case since I think you have lots of modules).

yes, i have remotelinc with some direct links setup to controlled devices.

so based on your comment, my guess is that the remotelinc sends the initial group command and then, a) indigo/powerlinc "hears" it, the triggers kick in, and additional insteon commands are sent and b) the remotelinc sends a group cleanup command and the controlled device(s) send responses. it seems that these two parallel series of actions are causing signal conflicts in a very repeatable way and that the devices involved are somehow not "smart enough" to detect these collision and avoid them or work around them by retransmitting, etc.

so is it the case that the probability of collision increases when series b above is more involved - i.e. when the remotelinc is trying to communicate with multiple devices (vs. only to the powerlinc controller)? while i realize that i can approximate some of the same functionality by only linking to the powerlinc and then creating triggers in indigo, i have - perhaps stubbornly - resisted going this route over the last few years. some reasons:

#1 response. probably the most important reason. i sometimes like the immediacy, directness, and instant feedback i get when (for example) using a remotelinc to control local lights. it feels very much like a directly-connected (non-insteon) dimmer switch in this regard. there is little or no delay.

#2 dimming. (closely related to #1) if i want it a brighter background lighting in my bedroom when i'm reading at night, i can bump up the brightness a little bit (for a set of multiple lamps around the room). because the response is direct and immediate, i can set a light level i like easily and with no "overshoot", no devices getting out of sync, etc. my recollection is fuzzy, but i believe insteon has some fairly low-level support for dimming and push-and-hold type actions between a controller and responder that (i assume) would be hard to duplicate with powerlinc/indigo trying to act as a middleman in the communication.

#3 independence from controller. i made it a goal of my HA installation and configurations that when possible, the system should at least preserve the pre-HA level of function. so for example, when i automate a 3-way or 4-way switch in the house, i go to some lengths to put in multiple switches in the same locations with linking setup so that (with no controller, no motion sensor, etc.) the house will still behave essentially the same as it was originally designed to do - even when doing so is technically not really necessary in the automated environment. generally this means, that if i move out and sell my house, many/most of basic control functions (at least for lighting) will still work - ditto if my HA controller system happens to be down for any reason. this doesn't really apply directly in the case of the remotelinc (since nothing about how the remotelinc works has anything to do with the "pre-HA" state) i think to some extent, i set up the remotelinc this way to be consistent with how i have done other n-way switches in the house - so perhaps that's actually a fourth reason, "consistency".

[matt (support)]

Correct. The clean-up commands can take a while (especially coming from an RF device) because a direct command has to be sent for each responder. The controller (RemoteLinc in this case) is supposed to cancel the clean-up sequence if it hears any traffic on the power line. And all modules (RemoteLinc and PowerLinc in this case) are supposed to retry after collisions with random exponential back-off, I believe, but as you are seeing it doesn't appear to work very well.

Your reasons for wanting the direct links are valid, but in this case I don't believe there is an ideal solution (best solution is the 1 second delay, IMO).

Regarding issue #1, the response time from a Trigger that immediately sends out a PowerLinc Scene broadcast should be pretty fast, especially if the RemoteLinc is only directly linked to the PowerLinc. There isn't a good solution for the #2 dimming issue though -- for that the controller has to be directly linked to the responders.

A while ago my 8-Button KPL started having issues. Usually the buttons would display whether their linked devices were ON or OFF and you could toggle them by clicking the buttons. Suddenly, one of the buttons stopped working properly. It would display a devices status but if you tried to toggle it ON or OFF by clicking the button it would just flash twice and the device would not respond. This behaviour spread to another button so I decided to Factory reset the KPL and re-sync the links.

After doing that, most of the buttons appeared to display their linked device's Status but now none of them were able to control their devices when manually toggled on the KPL. So I decided to remove all links in the Manage Links window and re-add them. The same problem persisted. Buttons Respond to their device's Status but manually toggling them does not Control the devices. The button LEDs do toggle on and off when manually operated.

I should note that I don't seem to receive any Insteon Commands in my log window when any of the buttons are pressed other than the Main Load.

Also. One of the buttons is controlled by Indigo since I use it to display Status and Control a Device Group that I set up.

I'm running the latest version of Indigo 6beta.

When I turn ON or OFF one of the linked devices (a DualBand SwitchLinc) I get this in the log...
unable to set keypad button state for main load-controlled buttons ( 1, 2, 7 or 8 ) -- use turn on/off commands instead

Thanks for any advice.

I had the same issue and a factory reset - define and sync fixed the issue for me.

[jay (support)]

Did you see that this topic is 6 years old?