LeeG

If the existing Scene that has KPL button C as Controller looks like this Scene xxxx KPL1 button C Controller Barn Spots Responder The Program can turn Scene xxxx Off and no additional Scene is needed. If there are other nodes in Scene xxxx that should not be affected by the automatic turn Off Program then a separate Scene is needed to control button C LED.

The Program that has the If Status "Barn Spots" is On would Then Wait .... Set Scene 'kplbutton' Off Set 'Barn Spots' Off to turn the KPL button Off. If multiple Secondary KPL buttons should be turned Off along with button C these can be added as Responders to the 'kplbutton' Scene. If the other Secondary KPL buttons are associated with other situations separate from "Barn Spots" then separate Scenes are needed. kplbutton Scene KPL1 button C as Responder KPL2 button C as Responder KPL3 button D as Responder etc.

The KPL button must not be the load control button. The "Barn Spots" must be a separate device being turned On/Off by a Secondary KPL button. Turning "Barn Spots" On/Off from an ISY Program has no affect on other devices that may be controlling the "Barn Spots" device. If the only way "Barn Spots" is turned On is with the Scene that has the KPL button as a Controller, the Program can turn that Scene Off which will turn Off "Barn Spots" and turn Off the Secondary KPL button. If this Scene is more complex, controlling other devices such that the Scene should not be turned Off, then use a separate Scene with the KPL button as a Responder. A Scene is needed because Insteon does not have a Direct command that can turn a Secondary KPL button On/Off. The Direct command cannot identify which KPL button should respond. Only a Scene identifies the actual button. There should not be a problem defining a Scene and adding the Secondary KPL button as a Responder. Insteon allows a node to be a Controller of only one Scene. This is an Insteon design point, not an ISY limitation. A node (KPL button) can be a Responder in many Scenes.

If 'Barn Spots' is turned On by a Program or other switch the 'If Control' will not trigger the posted Program. If Control triggers the Program when the 'Barn Spots' switch is turned On with a paddle press at the switch itself. Use If Status when the switch is operated remotely. If the switch was operated manually then the On messages did not make it back to the PLM or the Program is not Enabled. Run Tools | Diagnostics | Event Viewer at LEVEL 3. Press the switch paddle On and see if the expected messages are being traced.

Lots of areas to cover. The link table was/is fine. When I ask for the Device Links I get: 0 : 0FF8 : A2 00 25.14.64 FF 1F 01 1 : 0FF0 : E2 01 25.14.64 FF 00 01 2 : 0FE8 : 00 13 25.14.64 FF 1F 01 Record 2 starts with a 00 which is an end-of-list indicator. The remaining bytes have no meaning. The ISY shows this record as all 00’s assuming the device link table started in a factory reset condition. The ISY sets only the first byte to 00 when defining the end-of-list record. The 1A.AA.46 activity is originating from the OutletLinc itself. Note that all the messages start with 02 50 which are inbound from the device. These are NOT messages sent by the ISY to the OutletLinc. Messages sent from the PLM would start with 02 62 (outbound message). The OutletLinc Dimmer has a Sense capability. It is sensing the load plugged into the OutletLinc Dimmer has turned On and immediately turned Off. All the inbound messages are time stamped 09:03:55. I suspect the voltage on that circuit is fluctuating enough to make the OutletLinc Dimmer think the load is changing state. The load sensing can be turned Off but it is done at the OutletLinc Dimmer so you will have to wait until the next time in the Holiday house. A Program coded with “If Control†statements is designed to react to manual operation of the device paddle. If Control statements look at the inbound message command code coming from the device. How the Program reacts to being invoked manually by the Admin Console should be considered unpredictable. A Program written with only If Control statements is NOT designed to be invoked by anything except a message coming from the device resulting from pressing the paddle. If you want a particular Program clause to execute invoke that clause, do not execute the If section. This applies to Programs with only If Control statements. As oberkc has noted the Then clause is being driven in this case but it is dependent on how the If Control statements are coded. DO NOT depend on this and invoke the actual clause (Then or Else) desired. “Changing the state of the the switch (via the admin console) does not cause either of the programs to trigger into a "True" state. This is worrying when the ISY does see the state of the switch change (or at least it reports it as ON or OFF)†This is by your design. If you want a Program to trigger when the device is turned On/Off by the Admin Console use “If Status†statements. As I said earlier “If Control†is designed to react to manual paddle activity, not from the device being turned On/Off remotely. Do not restore the PLM. It is simple to do with File | Restore Modem (PLM) but that action IS NOT NEEDED! The lack of Program trigger when using If Control is the expected result. Use If Status when the Program should be triggered by remote activity. If I missed something or there are questions please post again.

Run Tools | Diagnostics | Event Viewer at LEVEL 3. Operate the SwitchLinc paddle manually and post the event trace. The lack of a Program being triggered can be caused by lost link records so the PLM is not aware of a paddle press. Can be caused by a comm problem preventing the message from the SwitchLinc reaching the PLM. The Folder containing the Programs may have a False Status. Check the Programs | Summary display to see the current Folder Status. The If section is looking at commands flowing from the device (If Control). Driving the Programs manually does not simulate a command flowing from the device.

Click on the Red KPL button node name listed below the Scene name. Set the device levels as desired. In Insteon each Controller has a unique set of Responder values. Clicking the Scene name displays the Responder values when the Scene name (PLM is Controller) is used in a Program or from the Admin Console. Clicking the Red KPL button node name exposes the Responder values for the KPL button when the KPL button is pressed.

Secondary KeypadLinc buttons have to be turned On/Off with a Scene. Define an ISY Scene with KPL button C as a Responder. The Program turns the Scene Off to turn KPL button C LED Off.

The Log shows the Motion Sensor - Sensor Off triggered the Program which issued an Off for the SwitchLinc at 08:03:03 PM which had no errors logged. The next Sensor On at 08:06:43 PM resulted in a Switchlinc error at 08:07:11 PM responding to the SwitchLinc On command. With the SwitchLinc comm problems and the KPL comm problems leaving button C On look for something common between the two devices. Same circuit, something new on that circuit, etc.

The Motion Sensor – Sensor node turned On (Status=100%) at 08:00:14 PM and turned Off (Status=0%) at 08:02:03 PM. The Sensor node also turned On at 08:06:43 PM and turned Off at 08:07:43 PM KPL button C was changed to 100% On at 03:00:05 AM. This triggered the LampLinc Program which turned On the LampLinc at 03:00:09 AM.

Thanks for the data. The Event Trace shows device 15.3F.90 is not responding to commands at all. There should be several 02 50 inbound messages. There are none. The Red entry is what should be in the Event Trace Tue 11/19/2013 06:28:01 PM : [iNST-TX-I1 ] 02 62 15 B2 6A 0F 11 FF Tue 11/19/2013 06:28:01 PM : [iNST-ACK ] 02 62 15.B2.6A 0F 11 FF 06 LTONRR (FF) Tue 11/19/2013 06:28:01 PM : [iNST-SRX ] 02 50 15.B2.6A 22.80.0B 2B 11 FF LTONRR (FF) Tue 11/19/2013 06:28:01 PM : [std-Direct Ack] 15.B2.6A-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 If the SwitchLinc was On when the trace was taken try turning the SwitchLinc Off locally and then try the commands again. If the SwitchLinc was Off there is a major problem communicating with the SwitchLinc. If the CFLs were On they can cause enough interference to prevent the SwitchLinc from seeing commands. The LampLinc Program turns the LampLinc On if it finds KPL button C On. Likely the 3AM Query found button C On, changed the Status to On which caused the Program to trigger and turn On the LampLinc. With multiple symptoms that look like comm problems I'm wondering if something else has happened. Any new devices such as cell phone chargers, have devices been moved, check the Access Points to insure they are still coupling the two 120v legs. Sometimes they get moved to a different outlet so a vacuum cleaner can be used, something like that. Run the 4 tap Set button test to insure they are working correctly.

Item 1 & 3 are the same. When the SwitchLinc failed to turn Off the SwitchLinc would have been marked with a Red !. The Red ! can be cleared by right clicking on the SwitchLinc node and selecting Query. A device that will reliably turn On but not turn Off is usually a problem with the load being controlled. What type of load is the SwitchLinc controlling? Run Tools | Diagnostics | Event Viewer at LEVEL 3. Post the Program that is driving the SwitchLinc in case there are other factors involved. The ISY Queries devices at 3AM. It sounds like the 3AM Query found a device is a different State/Status, changed the Status of the device which triggered a Program that turned the LampLinc On. Post the Program that controls the LampLinc.

Was the cross linking of the KPL and the 2477D done with an ISY Scene or done manually with Set button linking? If done manually the ISY is not aware of these links and will overlay or delete them at some point. All linking must be done with an ISY Scene. Secondary KPL button A and the 2 wire dimmer should be added to an ISY Scene as Controllers. How many times does button A blink when pressed to turn Off the 2 wire dimmer? If button A blinks twice it is in non-toggle On mode since the button LED remains On. If it blinks more than twice it indicates a comm problem with the 2 wire dimmer. What type of load and what is the wattage of the load being controlled by the 2 wire dimmer?

Download the WSDK and search for family.* http://www.universal-devices.com/isy-developers

Assumptions: $SVar1 is a State variable set to 1 when timing should start. If a drop out occurs the variable will be set to something else and back to 1 when new timing should start. Program 1 If $SVar1 is 1 And From Sunset To Sunrise (next day) Then Run Program 'Program 2' (Then Path) Else Stop program 'Program 2' Program 2 If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Wait 1 hour Set 'SwitchLinc Dimmer DB' On Else - No Actions - (To add one, press 'Action')

What LEDs on the front of the ISY are On? If the new IP address is not valid something more than the Power LED will be On. If only the Power LED is On the new IP address is valid for the local network which I would think would be identifiable from the Router.

Is Jumper 5 being used? If so Jumpers 2,3,4 have no affect. These Options are set using ISY functions when Jumper 5 is used.

Sunset is a moving value. There may be a fixed Timed event the Sunset driven Program walked into as Sunset time changes. Also household activities that generate Insteon activity or powerline noise may now be overlapping Sunset.

Exactly. A Disabled Program can be called from another Program. The If will be evaluated, assuming Program A calls the If section of Program B, causing either the Then or Else clause of Program B to execute. Being Disabled prevents Program B from triggering itself. It does not stop another Program from calling Program B.

There is no embedded If capability. Use your previous implementation, Disable Program B. That way Program B cannot trigger itself.

If From 1:00:00AM on 2013/11/15 To 1:00:00AM on 2014/01/01 Then Else

I would suggest opening a ticket. The link is at the bottom of any post by Michel.

"OK, so are you saying that there's no internal consistency check at all?" I do not have access to the code but I would assume the ISY link table information is not sanity checked against the Scene information since you are not getting errors. "Or rather that there is no way to even tell without visually checking every scene yourself that the correct links have been written?" It is not the device links that are wrong, the 'what scene is a particular node is in' information that is not accurate in this case. "How do I figure out if other things have disappeared? or if there are stale links?" I believe the problem centered around Secondary buttons controlling the load but I can't find the topic that I am think about to confirm that. It was an older problem that has long since been resolved. "how do I tell even if I delete the scene and the kpl, and add both back that other devices in the scene then won't have 2 copies of the link" When the KPL is added back use the default 'remove existing links' option. "Can you explain how its possible that the ISY agrees with the link table and doesn't show the right information in the gui at the same time?" The device link table matches the ISY link information because the problem is not with the link records. If I can find the old topic perhaps it will have some additional detail.

Thanks for all the additional data. I believe the problem is the result of an issue in an earlier ISY image involving a Scene that had a Secondary button as Controller with the KPL Load also being controlled by the Scene. Not sure if recreating the Scene will resolve the problem or perhaps the KPL itself has to be deleted and added back under 4.0.5. The problem is old enough that I have not found the topic that documents the problem to see what the solution is. Since the Scene no longer has a reference to button D just recreating the Scene may not clean up the KPL link table.

Sure. Also what is the ISY firmware level?