KPL Scene weirdness

[stillwater]

I am on 5.0.14...  not sure if this is an ISY issue or an insteon issue but suspect insteon.   In general I don't have communication problems with insteon (filterlincs in appropriate places, lots of dual band devices, phases bridged in power cabinet) 

I have two different KPL-8s that are exhibiting this strange behavior on two different scenes. 

The common situation is that each KPL-8 has its load (A-button) a responder to a scene that is controlled by multiple controllers, including another button on the same KPL that has a controlled load.  

In each case the scene works perfectly when a button on another KPL is pushed, or when ordered from the ISY.  But when the button on the same KPL as a load is pressed, the other elements of the scene (loads on other insteon devices) are triggered but the load on the same KPL does not.  By either using multiple retries in the scene or switching to "Command" mode in the scene, the load is controlled properly, but only with a delay of maybe 1/2 second.  It's as if the KPL sending the scene message blocks the same KPL from receiving the command.    Do I have two defective KPL-8s?  This is a new scene in a house I have been gradually programming, so I don't know whether this is a version 5 change or is a KPL hardware issue.  These KPLs were purchased from Smarthome in 2014 or 2015. 

[Michel Kohanim]

@stillwater,

Is this a configuration that was done with 5.0.14 and not 4.x?

With kind regards,
Michel

[stillwater]

I think in both cases the original scene including the load button was done in 4.x and then the additional button the the KPL was added as a controller in 5.0.14 (or possibly in 5.0.13c or d).  I have done things like reset the KPLs and restored from ISY without positive effect.  

[stillwater]

Further info...  The KPLs are version 43  and I am 90% sure in the scenes under the entry for the controller button on the same KPL bot the KPL controller button and the (responder) Load button A were set to default  before I experimented with Insteon/multiple retries or "Command."  I changed the relevant entries (KPL controller and load buttons) back to default and now the behavior is similar to when on COMMAND or INSTEON with multiple retries -- delayed execution of the load responder.  But this is an improvement compared to no response.  I believe but am not sure that the delay when on default is longer than on Insteon mutilple retries.  

 

 

 

 

[Michel Kohanim]

@stillwater,

Although improvement but this is not native INSTEON functionality and will require ISY to be in between.

With kind regards,
Michel

[stillwater]

I looked at the settings for another dimmer on the same scene that works ok. (It was set up by 4.x).  Looking at the page for the controller button on that KPL, I see that the controller button is set to default comms and the Load (A) button is set to Insteon as with all the responders.  I set the two problem dimmers in this way and restored their links (separately).    One now works fine.  The other one exhibited problems during the restore links process -- ERR 0 or ERR 1 in the event log, and a console message saying could not communicate with the device -- although then the process completed and the Exclamation point on the device went away.  After a factory reset and getting the restore process to proceed without an error, the device nevertheless returned to its original behavior --not turning its own load on/off when commanded from another button on the same KPL, but responding properly to the scene commanded on/off from another KPL or from ISY.  This no matter how many retries the Insteon comms option is set to.  (maybe the KPL thinks it has changed the state of the load when it hasn't??) Anyway all this suggests that the problem is with this particular KPL --can't now explain why the other KPL exhibited the same apparent failure earlier.

I can either change button assignments to avoid this problem or replace the KPL. 

Do you think I have this right?  Is there anything else I should try from within ISY? 

Thanks! 

[stillwater]

I just added another keypad to a third scene -- this one was created in 5.0.13d or 5.0.14.  Same result.  On the Scene screen for the controller button, both the KPL Load (A button) and the Controller button link type are "default."   The load responds properly to other controllers and to the ISY but does not respond the controller button on the same keypad.  This is the third keypad that has been acting this way.  Changing the linktype for the load to Insteon and writing the changes to the device did not change the behavior.  Neither did restoring the device or restoring it after a factory reset.  This device did not have any communication problems.   

I don't understand how I have one KPL that is (somewhat mysteriously) now behaving properly, one that I can get to work with a delay using Insteon retries, and one that I can't get to work that way (I haven't tried Command link type)

So now I have three possibilities

1) I am doing something idiotic that I never managed to do on 4.x or previous

2) I have several bad KPLs

3) There is something strange in how 5.0.14 is setting the tables in the KPLs.  

One other strange thing -- I am pretty sure in 4.x and before when I did Query device engine under Diagnostics, it would display information on the device.  Now with 5.0.14 it writes to the device and receives messages back but in the end does not display anything.  (I am using administrative console started with start.jnlp on a Windows 10 PC). 

[lilyoyo1]

19 minutes ago, stillwater said:

I just added another keypad to a third scene -- this one was created in 5.0.13d or 5.0.14.  Same result.  On the Scene screen for the controller button, both the KPL Load (A button) and the Controller button link type are "default."   The load responds properly to other controllers and to the ISY but does not respond the controller button on the same keypad.  This is the third keypad that has been acting this way.  Changing the linktype for the load to Insteon and writing the changes to the device did not change the behavior.  Neither did restoring the device or restoring it after a factory reset.  This device did not have any communication problems.   

I don't understand how I have one KPL that is (somewhat mysteriously) now behaving properly, one that I can get to work with a delay using Insteon retries, and one that I can't get to work that way (I haven't tried Command link type)

So now I have three possibilities

1) I am doing something idiotic that I never managed to do on 4.x or previous

2) I have several bad KPLs

3) There is something strange in how 5.0.14 is setting the tables in the KPLs.  

One other strange thing -- I am pretty sure in 4.x and before when I did Query device engine under Diagnostics, it would display information on the device.  Now with 5.0.14 it writes to the device and receives messages back but in the end does not display anything.  (I am using administrative console started with start.jnlp on a Windows 10 PC). 

I would screen shot your actual scenes. You may be improperly setting them up.

[stillwater]

Here is the most recent scene.  I deleted the previous one and created this new in 5.0.14    It added both the controller and load key as default link types.   THe load behaves properly when the scene is controlled from ISY or another KPL.  Tried Insteon linktype with eithe zero or multiple restries.  Didn't work when controlled from the same keypad as the load (the rest of the loads turn on fine, just not the one on the same KPL).  Changed linktype to Command and the load is controlled with a delay. I have scenes of this type that I added in 4.x that continue to work fine with the local load triggered a small fraction of a second before the ones on other insteon devices.  The load button does control another (3-way type) scene, but this is true of the 4.x scenes that work also.  

 

 

 

[stillwater]

It occurred to me that maybe I was exceeding the PLM links limit -- if the right way to measure is by the "Count" button in the PLM diagnostics/Show PLM links table screen, the PLM links count is 871.  PLM reports it is  v9E.

[larryllix]

40 minutes ago, stillwater said:

It occurred to me that maybe I was exceeding the PLM links limit -- if the right way to measure is by the "Count" button in the PLM diagnostics/Show PLM links table screen, the PLM links count is 871.  PLM reports it is  v9E.

Try the count repeatedly. An Insteon action during the count stops it.

[stillwater]

It has reported 871 after 3 separate fetches of the PLM table --Event Viewer showed no traffic except at the end it " twice says [All] Writing 0 bytes to Devices"

[lilyoyo1]

3 hours ago, stillwater said:

Here is the most recent scene.  I deleted the previous one and created this new in 5.0.14    It added both the controller and load key as default link types.   THe load behaves properly when the scene is controlled from ISY or another KPL.  Tried Insteon linktype with eithe zero or multiple restries.  Didn't work when controlled from the same keypad as the load (the rest of the loads turn on fine, just not the one on the same KPL).  Changed linktype to Command and the load is controlled with a delay. I have scenes of this type that I added in 4.x that continue to work fine with the local load triggered a small fraction of a second before the ones on other insteon devices.  The load button does control another (3-way type) scene, but this is true of the 4.x scenes that work also.  

 

 

 

It's showing that when this button is turned on, all devices in that particular scene will turn on. Is that not what you want?

[stillwater]

Yes, that is what I want.  And that's what happens when I press the other controller button (Kitchen TV 8...), or when I activate the scene from the ISY or Mobilinc.  And from the other controller button or from ISY, I can turn all of the responders off.   But when I press the controller button on the Firepit Hall KPL-8, it turns the other responders on or off, but leaves the load on the same KPL (Firepit Hall Ceiling NW 8 R) unaffected -- if it's off and the rest of the scene is off when the button is pressed, the rest of the scene turns on but the load on that KPL doesn't.  Similarly if it's on and the rest of the scene is on, and the button is pushed the rest of the scene is turned off but the load and Button A(Firepit Hall Ceiling NW R) stays on.   I can make it work with a delay by selecting COMMAND link type for the load, but the delay is annoying and requires ISY to be connected for it to work.  

 

[oberkc]

This sure strikes me as strange, and it appears to me that you have things set up as they should be.  "Firepit Hall NW 8 R-H is the troublesome (the one to which the load button does not respond) keypad button, correct?

Depending on how much effort you want to go through, the only thing that makes me curious is whether a manual linking of the button H and load button would result in correct behavior.  If so, perhaps this would point to link limit, or something other than a faulty keypad, problem.

I may have missed where you had done this already, but I would show links on the keypad, and perform a compare.  See if they match up.  With a little bit of investigation, you might even be able to start to recognize certain links and confirm that the right ones exist.

Since it is easy, I would be tempted to temporarily remove the load on the keypad to see if anything improves. If so, I would consider communication problems.

Finally, I might also be tempted to plug the PLM into a different outlet (extension cord is the easy way) on a different circuit and restore the suspect keypad.  

[stillwater]

Yes, oberkc, you are correct.  I'll do as you suggest and report back.  

[stillwater]

Link tables in device and ISY appear identical after the device is restored.  (see below)  HOWEVER, after the H button is used to turn on the scene, and the comparison is run again, Line 26  becomes mismatched.  Instead of 0F28 : E2 08 33.0F.E3 01 00 08 it becomes 0F28 : EA 08 33.0F.E3 01 00 08 -- The E2 has changed to an EA.   This happened twice.  (The ISY table is unchanged).

I also  did the obvious thing and looked at what ISY THINKS the state of the load device is -- and sure enough ISY THINKS the load (and presumably the keypad light) are ON when the Scene is ON and OFF when the scene is off, so when the scene state change is commanded by the H button on the same KPL, ISY believes the state has changed but it actually hasn't (judging by the the ceiling lights and the button illumination).  

I have clipped the event viewer (level 3) immediately below.

I don't know how to interpret either the event traffic that talks about messages being ignored or the change in the link from E2 to EA.  

Note that the scene works fine when commanded from ISY or from a button on another keypad.  I imagine that somehow the KPL thinks it has made the change and tells the PLM that, but in fact it hasn't done so. This would explain why the cleanup doesn't fix things, I suppose.

Is this possible and does it mean I just have several bad KPLs, or might it be a PLM or5.0.14 issue in how the link table is set up?   (I don't know how to read the event traffic). 

My PLM is near the panel where there is a phase bridge so it occurs to me that I should give the PLM its own circuit directly from one side of the phase bridge.  Also since my PLM predates the January 2017 durability fix that Smarthome talks about on its website, I should probably get a replacement PLM in any case.  

 

 

 

 

 

 

 

[Sub-Routine]

An E2 means the device is a controller for the scene. An EA is not a valid response. But, in binary, a 2=0010 and an A-1010, so it may not have any effect operationally. Or, it could just be garbled in transmission.

Does it change back when H is pressed Off?

As for Ignored, it is a duplicate message and has already been received. [INST-DUP] Once on 0 hops and again with 1 hop. That is normal.

What I'm not seeing in your link table is a responder (A2) link for group 08 (button H).

Perhaps removing the KPL from the button H scene and adding it back will create that link.

See this Wiki page for the links table definition: https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Tools_Menu#Show_Links_Table

Those links should be stored in the device and the PLM will have no bearing on whether they work or not.

[stillwater]

Thanks!  Yes,   It changes back to E2 when H button is OFF.  

[Sub-Routine]

That could indicate the load is causing some interference.

Make sure the load is off when you try to remove/add back the KPL to the H button scene. Though I don't know why it isn't in the ISY links table and flagged as missing. If that were the case a Restore Device would re-write it.

[IndyMike]

Assuming this is an I2CS device, the "EA" record switching to a "E2" is a normal occurrence.  It was documented by LeeG here: Link Table record mismatches keep reappearing.

I am also using ISY firmware 5.0.14.  I tried setting up the same situation using a V.43 KPL dimmer and an existing scene.  I was not able to re-produce the issue that stillwater is observing.  My KPL "C" key was able to turn on/off the KPL load under all conditions.  Even tried disabling scene responders to create communication errors.  No joy on this end.

 

 

[stillwater]

Thanks, IndyMike, very good to know.    Also thanks to  Sub-Routine -- I just deleted the scene and rebuilt it from scratch with the load off.  No change.  Luckily in this case I can use a nearby KPL as the controller instead.   

 

I have another (larger) scene where I had this problem and then somehow the problem got fixed (I have no clue how).   Looking at that scene, the load link Type on the "C" button screen in the scene appears as "Insteon" but with no retry entry -- in fact there is no box at the bottom of the screen to enter a number of retries.    This seems different from "default" which is the link type that ISY uses when it adds the load to the scene, or Insteon with some number of retries that I can set via the admin console.

 

   

[stillwater]

I did move the PLM to its own circuit directly from the power panel with the phase link, with no change in the scene behavior after removing and adding the KPLs in question to the scene and restoring them from ISY.  Since moving it I haven't had any messages that ISY couldn't communicate with a device when writing to a device, so maybe it was worth doing for that reason.

[IndyMike]

16 hours ago, stillwater said:

Thanks, IndyMike, very good to know.    Also thanks to  Sub-Routine -- I just deleted the scene and rebuilt it from scratch with the load off.  No change.  Luckily in this case I can use a nearby KPL as the controller instead.   

 

I have another (larger) scene where I had this problem and then somehow the problem got fixed (I have no clue how).   Looking at that scene, the load link Type on the "C" button screen in the scene appears as "Insteon" but with no retry entry -- in fact there is no box at the bottom of the screen to enter a number of retries.    This seems different from "default" which is the link type that ISY uses when it adds the load to the scene, or Insteon with some number of retries that I can set via the admin console.

 

   

 

May have some form of confirmation...

After reviewing your earlier post, I saw that you were using KPL button H to turn off the load.  My test was with KPL button C.

When I reset and re-tried using KPL H as you did, I received similar results.  I have a KPL that will turn on/off the load with secondary buttons C and G, but NOT button H.  Button H will turn off other secondary buttons, but it will NOT turn off the load.  Very curious.

My setup is below.  I can't see anything incorrect in the link table.  There is a responder link for group 8.  Past that, I do not have Rand's proficiency in reading link tables. 

This feels like a firmware issue or limitation with the KPL itself.

I do have a couple of differences in my KPL:

1) It's a V.41 FW - yours is a V.45

2) Mine is a 6 button KPL converted to a 8 button.

Would it be possible for you to move your secondary button (anything but H) and re-try?

 

 

[stillwater]

That's very interesting, but on another of my KPLs that is misbehaving, the scene is controlled by button C.  Also, on the  KPL that somehow cured itself, the scene is controlled by button H.  

My KPLs are v. 43.  

My next step is to replace one of the offending KPLs.