LeeG

The Dual Band 8 Button KeypadLinc is listed at [01.41] 2334-2. If not in 4.0.5 I suggest going to beta 4.1.2 (not 4.2.0) where it is listed. Beta 4.2.0 has an issue with If Status in Programs. Note that this will not fix the device not answering a Get Insteon Engine command which sounds like a comm problem.

I'm running 4.2.0 and do not see this behavior. Run Tools | Diagnostics | Event Viewer at LEVEL 3. Trigger the Program and post the event trace. Note all the device Insteon addresses the Program is controlling.

The Icon Relay is an extreme on the bad end with duplicate messages after practically every message. The I/O Linc is almost an extreme on the good end with 144 Standard messages and 11 duplicates. The V36 KPL is about in the middle with 80 messages and 44 duplicates. The surprise is the V41 KPL which is an I2CS device with 36 Extended messages, 8 Standard message duplicates and 6 Extended message duplicates. Although not an absolute I think the duplicates with the I2CS device means the duplicates are not caused by the individual device. I would look at the circuit layout. Where are the better devices located compared to the bad devices. Where are the Access Points located regarding the good and bad devices. Is the PLM newer or older. I have no guess as to why the duplicate messages but with duplicates on Standard and Extended messages across several devices I would look at the Insteon network in general rather than an individual device such as the Icon relay or I2CS KPL.

Take a look at this topic. It suggests sending an email to UDI support with the UUID of the ISY. viewtopic.php?f=27&t=14245

I don’t know to stop this but can explain what is happening. A Set MSB command (0x28) is issued and gets an ACK with Hops Left=2 which is as good as it gets. Tue 04/15/2014 06:43:14 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 28 0F Tue 04/15/2014 06:43:14 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 28 0F 06 SET-MSB(0F) Tue 04/15/2014 06:43:14 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 28 0F SET-MSB(0F) Tue 04/15/2014 06:43:14 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 The next command, a Peek (0x2B), is issued. Now the problem. A duplicate ACK from the previous Set MSB command (0x28) is received with a Hops Left=0. Tue 04/15/2014 06:43:14 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 2B F8 Tue 04/15/2014 06:43:15 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 2B F8 06 PEEK (F8) This is a duplicate ACK from the previous Set MSB command. Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 28 0F SET-MSB(0F) Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 This is the ACK from the Peek command. Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 2B A2 PEEK (A2) Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 The duplicate ACK gets the analysis of the responses out of sync. The ISY does a recovery process by going back to the Set MSB. Tue 04/15/2014 06:43:15 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 28 0F Tue 04/15/2014 06:43:15 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 28 0F 06 SET-MSB(0F) Unfortunately two duplicate ACKs from the previous Peek with a Hops Left=0 are now received. Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 2B A2 PEEK (A2) Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 2B A2 PEEK (A2) Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Now the expected Set MSB ACK with a Hops Left=2 is received Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 28 0F SET-MSB(0F) Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 A Peek is issued but this gets a duplicate ACK with Hops Left=0 from the previous Set MSB Tue 04/15/2014 06:43:15 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 2B F9 Tue 04/15/2014 06:43:15 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 2B F9 06 PEEK (F9) Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 28 0F SET-MSB(0F) Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Followed by the expected ACK with Hops Left=2 for the previous Peek. Tue 04/15/2014 06:43:16 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 2B 00 PEEK (00) Tue 04/15/2014 06:43:16 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 The explanation for the duplicate ACKs would only be a guess. They may be the result of the old ICON Relay or the result of an Insteon network that does not pick up on the fact that the ACKs with Hops Left=0 are actually duplicates from a command that has already completed and should be ignored. The old Set MSB/Peek/Poke command sequence used by the older devices could be a contributor. Could be the PLM should pick this up and ignore the duplicates. What part do the metal boxes have to do the duplicates? Lots of possibilities and no good answers. I would start the analysis by using an I2CS device where the ICON Relay now sits. The I2CS device does not support old Set MSB/Peek/Poke commands so that is an easy way of eliminating one of the variables. If the I2CS device does not produce the duplicate ACKs then I would put the old ICON Relay in the recycle box and stay with the newer devices.

Electron4951 This device is not responding to the three attempts to send it a command. Note the 02 62 outbound trace entries with no inbound 02 50 entries. After three attempts failed to get a response the ISY stops the add. Double check the Insteon address (1C.0C.6D). If correct the device could be defective or there is no powerline communication to the current plug point. Plug the device into the PLM circuit and try it again. Tue 04/15/2014 10:23:45 AM : [iNST-TX-I1 ] 02 62 1C 0C 6D 0F 0D 00 Tue 04/15/2014 10:23:45 AM : [iNST-ACK ] 02 62 1C.0C.6D 0F 0D 00 06 (00) Tue 04/15/2014 10:23:49 AM : [ELK 0 0 1] Keypad : My Office : 75 (113/135/0) Tue 04/15/2014 10:23:53 AM : [iNST-TX-I1 ] 02 62 1C 0C 6D 0F 0D 00 Tue 04/15/2014 10:23:53 AM : [iNST-ACK ] 02 62 1C.0C.6D 0F 0D 00 06 (00) Tue 04/15/2014 10:24:02 AM : [iNST-TX-I1 ] 02 62 1C 0C 6D 0F 0D 00 Tue 04/15/2014 10:24:02 AM : [iNST-ACK ] 02 62 1C.0C.6D 0F 0D 00 06 (00)

Electron4951 I missed the part about using [07.0D] in your last post. Please run Tools | Diagnostics | Event Viewer at LEVEL 3. Use New INSTEON Device, entering Address, Name of choice and Auto Discover. Post the event trace. It sounds like the PLM is not able to talk to the refurbished I/O Lincs.

Electron4951 The refurbished I/O Linc is listed in the 4.2.0 device list. Click Help | About and verify the UI and Firmware lines both show 4.2.0.

Here is the Options display of the SynchroLinc settings.

The common solution is to split the Program into two Programs. Program 1 Then clause invokes Program 2. Program 2 contains the current Then clause statements. Even though Program 1 is triggered multiple times it would not affect the execution of Program 2.

If either Climate value changes while in the Wait the statements after Wait will not execute. The Wait is stopped and the If will be False because neither Time is current.

The Program is triggered at the two Times and anytime either of the two Climate values change. The If will be True only at exactly 9:15AM and exactly 5:15PM assuming the Climate values are also True. Perhaps you want to use a From/To Time range rather than two explicit Times. Would help to know what the program is trying to accomplish and when.

A 0 count of PLM link records explains the initial symptoms. The "Driver not found" message was displayed during the Restore Modem (PLM) command? Displayed as a popup? Can you post the popup display? There have been a series of PLM problems lately. Since this is a 99i the PLM is likely older. Try another Show PLM Links Table and Count. The PLM may be failing.

If "Light Switch B Main Cans" is On before the Motion On is received the first program cannot turn On the Scene (unless a save is pending for the program).

Having separate Responder On Levels is useful when each KeypadLinc button is setting a different lighting environment. Button C could have a set of Responder On Level values for cooking dinner. The kitchen lights would be at 100% On, the primary dinning area could be Off or at a low On Level. Wall chandeliers could be Off. Button D sets the same set of Responders for dinning. Button E sets the same set of Responders to after dinner. My area is an open landscape so using different On levels for different occasions is common.

Happy to help. Insteon supports a unique set of Responder values for each Controller. Setting the Scene Responder values covers the case where the PLM is the Controller (Scene used in Program for example). It means that each additional Controller also has to have its Responder values set as well.

The Program will be triggered at Sunset. If the Status of the switch is On the If is True running the Then clause.

Click on the Red KeypadLinc button node below the Scene name. What is the On Level for the KeypadLinc buttons that should be Off? Be sure to check both Red KeypadLinc button nodes for the On Level of the other buttons.

"That is how I would expect it to work: In the parent scene node you set the responders and they respond in that fashion when the scene is triggered. However, that is not the case. As you previously indicated: the way to set how the scene responders respond is by setting those options for the child of the scene node (Controller/red node.)" Setting the On Level for a Controller (clicking on Red Controller node) affects what happens when that Controller is used. Setting the Scene name Responder On Levels affects what the Responders do when that Scene name is used (where the PLM is the Controller). No difference between using the Scene name (where the PLM is the Controller) in a Program and pressing a KeypadLinc button where it is defined as a Controller in the same Scene, the Responders react based on the On Level for that Controller.

Changing the Fan speed by ramping the On Level up/down will not affect the KeypadLinc buttons. The KeypadLinc buttons react to how the responder On Level is coded. The buttons have no idea of the Fan speed changing by ramping the speed up/down.

"What the #*@*@ is the option for on levels of the main scene node for if they have no effect!?" The Scene name for a particular Fan speed can be used in a Program. The Responder On Levels for the Scene (the PLM is the Controller in this situation) dictate how each Responder reacts.

If the Access Point is in range of another Dual Band device that is receiving the signal it should help. Also look at what is powered on the PLM circuit. UPS, other electronic equipment, surge/noise reducing power strips should all be isolated with a FilterLinc to prevent PLM powerline traffic from being affected.

I checked the event trace for 28.AA.98. It is an I2CS device which is built on a 2413 PLM Shell. That should be a Dual Band device. 02 50 28.AA.98 22.FF.06 27 0D 02 = 0x02 is I2CS which has to be built on a 2413 PLM Shell

From the event trace nothing has changed regarding the SynchroLink. The commands that work have a Hops Left=0. There are a number of cases where no command response is received for some of the initial attempts where the retries were successful. Eventually even with retries the device does not respond. The EZFlora looks like it was on the opposite phase during the add. The commands have a consistent Hops Left=1 which often means the extra Hop is to cross over to the 120v leg containing the PLM. An EZFlora can be Dual Band. If no passthru outlet it could be Dual Band. I would expect the SynchroLinc to work when plugged into the same outlet as the PLM. If it does not work there either there is a powerline issue as the SynchroLinc is powerline only or the SynchroLinc is not working well.

Michel said both are required. Did not say if that is ISY or ISP requirement. Link to UDI post viewtopic.php?f=27&t=14125