stillwater Posted December 26, 2018 Posted December 26, 2018 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 Posted December 27, 2018 Posted December 27, 2018 @stillwater, Is this a configuration that was done with 5.0.14 and not 4.x? With kind regards, Michel
stillwater Posted December 27, 2018 Author Posted December 27, 2018 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 Posted December 27, 2018 Author Posted December 27, 2018 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 Posted December 28, 2018 Posted December 28, 2018 @stillwater, Although improvement but this is not native INSTEON functionality and will require ISY to be in between. With kind regards, Michel
stillwater Posted December 28, 2018 Author Posted December 28, 2018 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 Posted December 29, 2018 Author Posted December 29, 2018 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 Posted December 29, 2018 Posted December 29, 2018 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 Posted December 29, 2018 Author Posted December 29, 2018 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 Posted December 29, 2018 Author Posted December 29, 2018 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 Posted December 29, 2018 Posted December 29, 2018 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 Posted December 29, 2018 Author Posted December 29, 2018 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 Posted December 29, 2018 Posted December 29, 2018 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 Posted December 29, 2018 Author Posted December 29, 2018 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 Posted December 29, 2018 Posted December 29, 2018 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 Posted December 29, 2018 Author Posted December 29, 2018 Yes, oberkc, you are correct. I'll do as you suggest and report back.
stillwater Posted December 30, 2018 Author Posted December 30, 2018 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 Posted December 30, 2018 Posted December 30, 2018 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 Posted December 30, 2018 Author Posted December 30, 2018 Thanks! Yes, It changes back to E2 when H button is OFF.
Sub-Routine Posted December 30, 2018 Posted December 30, 2018 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 Posted December 30, 2018 Posted December 30, 2018 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 Posted December 30, 2018 Author Posted December 30, 2018 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 Posted December 31, 2018 Author Posted December 31, 2018 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 Posted December 31, 2018 Posted December 31, 2018 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 Posted December 31, 2018 Author Posted December 31, 2018 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.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.