IndyMike

There are a few misconceptions regarding the protocol and how the ISY handles scenes - 1) Scenes - ISY scenes do not interrogate members to determine if they have responded correctly. As a result, there are no PLM retries used. The ISY assumes that the scene executed properly. The scenes are a single command and are very fast. Since there is no additional communication between the PLM and responders, scene commands in programs normally do not require delays. 2) Device direct commands (admin console) - Device cleanup commands are used to determine if the device has responded properly. If it does not, the PLM will re-try the command xx times. PLM retries are invisible to the ISY. 3) Device direct commands (programs) - Similar to commands executed from the admin console, cleanup commands are issued. The difference here is that the PLM can be overloaded if commands are "chained" and it will abandon cleanup attempts. This is where you need to insert delay between commands to give the PLM time to issue cleanup messages and retries. 4) Device cleanup retries (advanced menu for the devices) - This is for adjusting the #of retries that devices use to communicate with the PLM (not PLM to device). It will have no effect on scenes initiated by the ISY. It is only available on newer devices. https://wiki.universal-devices.com/index.php?title=ISY994i:INSTEON_Device 5) ISY Retries - ISY retries are used when querying a device. To my surprise, they do not appear to be used for device direct commands (anymore??). Retries default to 2 and can be changed by using Telnet to connect to the ISY Shell. Use "CR" max command retries. I do not advise adjusting beyond 2 as this significantly bogs down the ISY. https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Advanced_Configuration_Guide#CR_-_Max_Device_Command_Retries

My ISY994 does respond to a ping.

That's a classic no-response from a device. The ISY tried to query the device 3 times and received nothing back. Below is and an example of a correct response vs timeout. Your device address (42.D7.A8) indicates that the dimmer is reasonably new (V.45 firmware). It's newer than most of the devices I am using. Unlikely that 3 devices on the same circuit would suddenly all develop problems. If your equipment closet is on the same circuit as the dimmers, you may want to consider filtering devices.

You are not communicating with this device. The ISY is retrying the query after a timeout. Note - the PLM also retries XX times between each of these commands (invisible to the ISY). You're having severe communication issues to this location. Any new devices hanging on your powerline (i.e. Christmas decorations)?

I looks like you may have "Factory Reset" your KPL (erased the link table) and then performed a query. If that is the case, the device is responding with errors and NAK's (negative acknowledges) because it is an I2CS device and is not longer linked to your PLM. I factory reset one of my Test KPL's and got a very similar response. One curious difference is that my ISY994 is using the I2CS protocol to talk to the device. Your log does not show the "CS" (using I2 protocol). That may be a simple difference in presentation (not sure what system you are using). Normally this would be rectified by simply "restoring" the device from the admin console.

As a last, last, last attempt, I dug out an old V1.65 2486D (2007 vintage). Replaced my existing test KPL with the old unit and verified no errors in the link table. Guess what - I behaves EXACTLY as you have described. The buttons work perfectly from the KPL. Activating the scenes from the Admin Console causes all 4 secondary button to light. Go figure. The extremely old revisions are not compatible. Newer versions are. Now you have two reasons to replace your device. Sorry

I understand. That's why I started by reproducing your scene using two different vintage KPL's on my ISY994. This, plus that you have link table errors across multiple reset/restore cycles, makes me believe that your device is failing. Could there be two different things going on? Absolutely. You could have a failing device and a problem with the Polisy firmware. Even so, when I look at your link tables, they appear to be at least partially correct. The highlighted section below is for group #48. It should turn button 3 on, and turn off buttons 4, 5, and 6. It's analogous to your "Exercise Room Fan High" scene. Unfortunately, that's not what you experienced. All of your secondary buttons turned on. The Polisy appears to have written this section of the table correctly. The device is simply not executing it correctly when you call scene #48 ("Exercise Room Fan High") from the admin console. If the table is written correctly, and we are ruling out bad communications, that leaves a bad device.

I checked my "used device box". My KPL from the same date range was made in 2007. This was back when you could buy a KPL for under $20 (Icon's were under $10). I removed it because it had a nasty habit of corrupting it's link table. These older devices used a very simple power supply described in Microchip: AN954 They were rather intolerant of input supply variation (poor 120V regulation) and most died an early death because of this. The fact you and I have devices in this date range still operating indicates we owe our local Power Co. a word of thanks. Older devices develop problems regulating their internal 5V supply as the C2 cap begins to fail. One of the symptoms is inability to maintain voltage during the EEprom write cycle. I believe this is what you are experiencing now. On a good note, the newer devices with switching power supplies draw far less standby power. You'll be knocking 0.5W off your utility bill.

The device record mismatch @location 0F70 is showing a controller address of 51.1F.B3. The ISY is showing a controller address of 51.10.B3 at the same location - I'm guessing this is the address of your PLM. This type of error should NEVER happen. You either have horrible communication (noise/failing PLM/etc), which you have not observed, or you have a failing device. Your KPL address is 05.16.14. I have 1 remaining device in that address range. It's an I1 ICON switch. I would classify that as ancient (and I drive 50 year old cars). It may be time to let go and try a new(er) KPL. The one I tested above was from 2012.

The responders behavior is mostly contained in the responder link table. That's what I tried to show in my overly complicated post above. When I activate my "Test KPL High" scene, the ISY transmits the following group broadcast command to group 00.00.37 In this simple test case, we are instructing button 3 to turn on and buttons 4, 5, and 6 to turn off. All of that functionality is contained in the device link table. That's why I was concerned that your link table had issues after a restore. This is a simple instance with only 1 group responder. The scene could include every device in your installation. Each group member would have an entry telling it how to respond to the broadcast group 00.00.37 command

Thank you for confirming that the Non-Toggle is still current for the KPL's. I did try @apostolakisl's scene setup on a new 2334-2 KPL. It functions there also.

Hello Javi, I very much hope that you are incorrect about the non-toggle mode. I use it rather extensively. It is actually a hardware feature on the KPLs (documented in the user manuals). If newer KPL's do not include the feature, that would be a news item. I have understood that the button grouping was not advised.

It's possible that the "missing this record" message on the isy link table is simply a difference in presentation between the ISY and PolISY. Beyond that, I do not see anything in your device link table that indicates the scene should be turning on buttons 3, 4, 5,&6 at the same time. If deleting/re-installing doesn't work, you may need to try a different device.

You have missing/incorrect records immediately after a restore. That's not good. I'm surprised you didn't get any write errors. This would normally imply device communication issues. How do your Comms look in the event viewer? What I have never seen is the errors on the left (ISY link tables) side. It almost seems that the ISY is saying it's missing records (SDcard issues?) Curious if you see this on different devices. The following is a scan of my test KPL. I turned the "KPL High" scene on from the Admin Console. The event viewer showed this as scene 00.00.37. Inspecting the KPL link table I can see where Scene #37 is set to turn button 3 on (FF) and buttons 4, 5, 6 off (00). Your scene #48 appears to do the same. Curious if things behave differently now.

@apostolakisl, in a word "Yes" the above should work. I have similar KPL's all over my house. I use the Non-Toggle Off in my installation but understand why you are using Non-Toggle On. Just to be certain, I set up an old 6 button test KPL using your configuration. And yes, we are not crazy. It works, both from the KPL and the admin console. Based on the screenshot in your post, I do not understand why your "Exercise Rm Fan High" scene would activate all of the buttons. My configuration - ISY994 V5.3.4 KPL - 2486D (6 button), FW V.41, V6.0, D.C. 1213 Ideas (SWAGs): 1) Since you are re-purposing, wouldn't hurt to delete the device from the ISY, factory reset, re-include. 2) For this to be happening, the scene responder link in the KPL would need to be missing or incorrect. Could you do a device link table scan and provide the results? I would explain why the KPL isn't responding properly. It would not explain why it wasn't written properly. 3) Not sure if you are using a Eisy, or Polisy. I would think the scene management would be the same, but maybe the integration of Zwave and other technologies has broken something.

The I2CS protocol increased security - Incorporated @ FW V.41/ Rev 6.9 in late 2012 (madreporite) Removing the All-on/All-off command seems to have been incorporated @ FW V.45 / Rev 7.8 in the 2016 time frame. Beyond that, there "may" have been power supply capacitor changes to improve durability (similar to the changes in the PLM). I do not have information on that. @Brian His a good source for hardware information on many of the devices. Hopefully he can educate us on any improvements that may have occurred. IM

@gweempose, not sure exactly what you are looking for. I believe all of the 2477D's were dual band. The following link lists I2 and I2CS introductions for the device: http://www.madreporite.com/insteon/Insteon_device_list.htm Beyond that, I ran some testing on my 2477D devices to determine if Smartlabs had removed the "all-on/all-off" broadcast commands. From what I saw, devices with a FW level V.45 did NOT respond to the All-On/All-Off broadcast: https://forum.universal-devices.com/topic/41651-all-on-removed-in-what-firmware-version-of-switchlinc-dimmers/?do=findComment&comment=369748 Not sure if that's what you were looking for... IM

@Merlin - Thanks for the response. Another device to investigate - oh well. I am curious how you are powering the devices (and hiding wires) in your installation. Would you mind describing or providing a photo of your wired device? Thanks, IM

I agree that the ISY cannot directly address a KPL secondary button. In order to control a secondary button, it needs to be included in a scene. I am curious why the ISY isn't creating a "scene" for Insteon devices and an "association" for Zwave devices. Either way, it should be an easy thing to determine from the event viewer when the scene is activated by the Z-wave controller. Scene Activation - The 00.00.XX device address is indicative of a Scene. The "CF" flags also specifies a scene command but I am to lazy to decode this AM. Fri 12/01/2023 09:15:15 AM : [INST-TX-I1 ] 02 62 00 00 13 CF 11 00 Fri 12/01/2023 09:15:15 AM : [INST-ACK ] 02 62 00.00.13 CF 11 00 06 LTONRR (00) Device Direct Addressing: The 1A.5D.C7 address is an individual device in my system (member of the scene above). The "0F" Flag also specify a "direct command". Other indicators of a direct command are the 3rd line (02 50) which is a response from the target device. Scene commands (above) do not request a response. Fri 12/01/2023 09:16:24 AM : [INST-TX-I1 ] 02 62 1A 5D C7 0F 11 F7 Fri 12/01/2023 09:16:24 AM : [INST-ACK ] 02 62 1A.5D.C7 0F 11 F7 06 LTONRR (F7) Fri 12/01/2023 09:16:25 AM : [INST-SRX ] 02 50 1A.5D.C7 53.BC.3A 27 11 F7 LTONRR (F7) Fri 12/01/2023 09:16:25 AM : [Std-Direct Ack] 1A.5D.C7-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 I do not know/understand how the ISY is activating Zwave "associated" devices. I do not currently have a Zwave/ISY installation to test. But I am very curious for future installations. One last comment - I do remember a @lilyoyo post from years ago indicating that Zwave controllers should be added to a scene 1st. I had always abided by that when I had my mixed system. Have no idea if it still applies. IM

@djones1415, I apologize if my response implied in any way that you required this type of response. Being an Engineer (and working with Engineers) for 40+ years, pictures and screen captures are my go to. My friends and family would attest that I am uniquely qualified to provide idiotic responses. Glad it helped. In retrospect, Lou's (Apostolakisi) response was exactly correct. Had I seen it, I would not have replied. Geddy's response was "most" correct - pointing to existing Wiki documentation rather than re-inventing the wheel. I need to remember that. IM

Device replacement steps - This only works with similar device types (dimmer to dimmer/switch to switch) 1) Factory reset your new switch. This removes potentially unwanted settings from the new device (X10 addresses, etc). Manual : 2466 Toggleinc 2) Link the new switch and use the "Remove Existing Links" option. There should not be any links after resetting, but... (belt and suspenders). Name the device something similar to your old device - add a "#" or a "new" to discriminate between them. 3) Right click on the "old" device that you want to replace. It should now show the recently added device as an option for replacement. IF IT DOES NOT your old device is in a sub-folder or a different device type. If in a sub folder, move to the root folder. Device in sub folder will not show replace option After moving to the Root folder: replace is now an option 4) After performing the "replace with" you will be prompted to re-boot the ISY. Following the re-boot, the new switch should be in place and all of your programs and scenes should be updated. 5) Re-name the new device if you wish. All the programs and scenes will be updates.

@paulbates, Nicely done. I'm assuming you are using a "legacy" on/off module (not the newer I3). Nice wire solution to the dusk/dawn issue. Thanks for updating, IM

Hi @Merlin, Unfortunately, I can't help with inclusion issues as I don't have the Eisy. I do have a number of the ZSE44's and am happy with them in general. They do have a lot of "nodes" as you refer to them. On my ISY994, I believe I was able to "group" nodes by right clicking on the main node (1) and selecting "group devices". This would move the secondary nodes under the main node in the device tree (make them less obvious). As I indicated, I have a number of the ZSE44's. I am happy with them except for my "outdoor" devices that consume batteries. The issue here is that I have devices outside the house that go through wide temperature swings this time of year (40" degrees). This drains a lot of battery. Devices in the house run ~1 year on a CR2450. Outside, less than 1/3 during spring/fall. I am posting because I am interested in the Aeotec Mutisensor 7's that you have coming. Then have an advertised life of 3+ years. The are similar to my Zooz ZSE40's that I have been happy with (motion, temp, humidity), but have a much better advertised battery life. Please do report back how you like the Aeotec devices. If you have further questions on the Zooz ZSE44's, I'll help where I can. IM

Wow, after reading @Geddy's post I logged into the admin console to re-checked my Scheduled execution times (no changes). They are back to being correct down to the tenth of a second. Wild and wondrous - I guess that's why they call it software.

Hey @paulbates, Let me start by saying that I have the ISY994. I have two programs that run nightly at sunset, and 30 minutes past sunset. When I looked at the program summary tab, both programs were set to run @EXACTLY sunset and 30 minute past. My sunset is at 5:36:10 (I'm a little West of you). Since my programs are slightly different from your Time = Sunset, I decided to add a test case. That's when things got weird. After saving my test program, ALL of my sunset programs showed a "Next Scheduled Run" time that was 4 minutes, 4 seconds early. I expected 5:36:10 PM (sunset) for my sunset programs, but got 5:32:06. I expected 6:06:10 PM for my night program (sunset + 30 min), but got 6:02:06 PM. All that I can think of is that the next run is "predicted" when you save the program. It is then "refined" after the program executes (or perhaps at the end of the day). Definitely not the result I was expecting and in line with what you are seeing. Original Sunset Program: Fires @5:36:10 Outside Sunset - [ID 0015][Parent 0002] If From Sunset For 1 minute Then Set 'Outdoor / SC Outside Sunset' On Else - No Actions - (To add one, press 'Action') Original Night Program: Fires at 6:06:10 Outside Night - [ID 0016][Parent 0002] If From Sunset + 30 minutes To Sunrise + 5 minutes (next day) Then Set 'Outdoor / SC Ouside Night' On Else Set 'Outdoor / SC Ouside Night' Off New Test Program: Fires at 5:32:06 Outside Sunset1 - [ID 0011][Parent 0002] If Time is Sunset Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action')