LeeG

Slightly different sequence, the Group Broadcast was not received from the KPL which is different from the first trace but multiple Group Cleanup Directs are being sent from the KPL which is consistent with the first trace. The ACKs are not being received by the KPL. I think this trace entry represents the ISY posting the Primary Node Off when multiple Group Cleanup Direct messages are received for button 4. Wed 12/21/2011 8:01:54 PM : [ 5 15 36 1] DOF 4 This entry does not occur in the working trace. No messages from the KPL were missed and only one Group Cleanup Direct was received indicating the KPL did receive the ACK from the PLM.

Sorry, an Event Log with Device communications events selected. I don't think of an Event Log at any other level worth the paper it is printed on for diagnosing a problem. Hard to know the cause when only the results are shown.

You need to have the Event Log of the failure versus no failure. I suspect it fails when the KPL does not receive any of the ACKs and retries the Group Cleanup Direct multiple times. Not saying the comm problems are the failure, only that they precipitate the failure. The Event Trace showed a problem before but a single trace does always indicate the source of the actual problem. The highlighted line is the issue but it is the result. What was the sequence of command flow that lead to that result. Wed 12/21/2011 5:40:40 PM : [ 5 15 36 4] DOF 0 Wed 12/21/2011 5:40:40 PM : [ 5 15 36 4] ST 0 Wed 12/21/2011 5:40:40 PM : [ 5 15 36 1] DOF 4 Wed 12/21/2011 5:40:41 PM : [ 12 29 64 1] ST 63 Wed 12/21/2011 5:40:42 PM : [ 5 15 36 1] ST 63

nickoonce The tstat communicates with other Insteon devices which convert the RF into powerline signals. The ISY plays no role in this process. Insteon RF communication is proprietary and confidential. Not much is absolutely "impossible" but I would put the possibilities as next to none. SmartLabs would be the company to discuss this with as they own Insteon. Lee

rmlinnovator Describe what Controller is turning the bathroom lights On. The Adjust Scene first parameter is the name of the Controller, not the name of the Scene. Changing the On Level and Ramp Rate for the Scene name changes what happens when the Scene is turned On using a Program (PLM is the Controller). Each Controller has a unique set of Responder values so it is necessary to select the Controller being used. Lee

The entire UDI forum access was hacked over night. Several hours ago accessing the UDI forum resulted in an advertisement. Must have been more damage than just the initial forum page. The UDI web site has a completely different look. Quite an impressive new presentation.

DON for Devine On, DOF for Device Off (my assumption about Device). These messages are ISY annotations following the raw Insteon messages from the device for a button 6 On press followed by a button 6 Off press. Sun 10/02/2011 01:59:02 PM : [iNST-SRX ] 02 50 15.9A.F9 00.00.06 CB 11 00 LTONRR (00) Sun 10/02/2011 01:59:02 PM : [standard-Group][15.9A.F9-->Group=6] Max Hops=3, Hops Left=2 Sun 10/02/2011 01:59:02 PM : [ 15 9A F9 6] DON 0 Sun 10/02/2011 01:59:03 PM : [iNST-SRX ] 02 50 15.9A.F9 00.00.06 CB 13 00 LTOFFRR(00) Sun 10/02/2011 01:59:03 PM : [standard-Group][15.9A.F9-->Group=6] Max Hops=3, Hops Left=2 Sun 10/02/2011 01:59:03 PM : [ 15 9A F9 6] DOF 0 These were taken from a 2.8.16 Event Log file to show the DON had not changed across a wide range of ISY images. Teken noted a change from ON to DON somewhere I do not remember. Think he was wondering if the Event Log file had changed also which it has not.

Yes, DON and DOF are correct for the ISY Log. These records were pulled from a 2.8.16 trace. Sun 10/02/2011 01:59:02 PM : [ 15 9A F9 6] DON 0 Sun 10/02/2011 01:59:03 PM : [ 15 9A F9 6] DOF 0

stealle Sounds like the “On Level (applied locally)†and “Ramp Rate (applied locally)†were changed during the Scene setup. These fields have nothing to do with the LampLinc as a Responder to a Scene. They affect the LampLinc operation when the device is manually operated locally. Select the LampLinc node in the My Lighting tree and see what these two fields are set to. Lee

I think that is why Chris wanted a NEW Program with the same trigger arrangement to see if this specific Program has an issue or the If configuration in general.

Chris Major comm. problem. The ACK from the PLM is not making it back to the KeypadLinc causing the KPL to retry the Group Cleanup Direct. Makes it look like another KPL button press where the Group Broadcast was lost. Note the increase in Max Hop count by the KPL on each retry. 6:52:25 AM : [iNST-SRX ] 02 50 05.15.36 00.00.04 C7 13 00 LTOFFRR(00) 6:52:25 AM : [standard-Group][05.15.36-->Group=4] Max Hops=3, Hops Left=1 6:52:25 AM : [ 5 15 36 4] DOF 0 6:52:25 AM : [iNST-SRX ] 02 50 05.15.36 19.75.34 41 13 04 LTOFFRR(04) 6:52:25 AM : [standard-Cleanup][05.15.36-->ISY/PLM Group=4] Max Hops=1, Hops Left=0 6:52:25 AM : [iNST-SRX ] 02 50 05.15.36 19.75.34 42 13 04 LTOFFRR(04) 6:52:25 AM : [standard-Cleanup][05.15.36-->ISY/PLM Group=4] Max Hops=2, Hops Left=0 6:52:26 AM : [iNST-SRX ] 02 50 05.15.36 19.75.34 47 13 04 LTOFFRR(04) 6:52:26 AM : [standard-Cleanup][05.15.36-->ISY/PLM Group=4] Max Hops=3, Hops Left=1 6:52:26 AM : [iNST-ACK ] 02 62 00.00.10 CF 13 00 06 LTOFFRR(00) 6:52:27 AM : [ 5 15 36 4] ST 0

Have you run an Event Viewer now that it is happening all the time? That will show what the KPL is sending.

The next thing to try is to Factory reset the SynchroLinc, plug it in at the PLM and try again. Suggest running the Event Viewer with Device communications events selected as you did before. Let’s be sure the same situation after the factory reset. I would put a piece of opaque tape over the IR opening. What ISY firmware is being used. More for general information as I don't know of any issues linking the SynchroLinc with any of the ISY firmware.

Go ahead and try it. Use times that will be effective while testing, no need to wait until 11:30 PM. That is the only way to be sure. Use 8 minutes for the maximum Ramp Rate. Smartlabs has changed the maximum Ramp Rate to 8 minutes on some devices. Setting to 9 minutes results in 0.2 sec Ramp Rate on those devices.

oberkc The need to power cycle is associated with changing the Local On Level and Local Ramp Rate values. Changing Responder On Level and Ramp Rate values in the link record do not need a power cycle. The difference is link record values are retrieved each time a command is received. The link records must be searched to find a match to the incoming command thus any change to the Responder On Level or Ramp Rate is picked up. Updating the Local On Level and Local Ramp Rate change the device memory that may not be accessed other than at device power on. Devices that use the new I2 configuration commands do not need a power cycle as the new I2 commands have been implemented to change both the memory that is accessed during power on as well as the memory that is being used from command to command. Since the Controller is a RemoteLinc2 there are no Local On Level or Local Ramp Rate values involved. Lee

There is an Adjust Scene Program Action statement that can change the responder ramp rate for a particular controller. However, once the device is reacting to a command with a particular ramp rate changing the ramp rate will affect the next command but not the one in progress.

The device address 18.7E.EA is not responding to any command. Double check Insteon address label. If address is correct move the SynchroLinc to where the PLM is plugged and try again. It could be interference at the current plug point or perhaps a surge suppressor is involved. Also there are many IR interrupts occurring. I don't think they interfered with the device add process but they should be held up while adding devices.

Don't worry about it. We all were at one time where you are now. Lots of good folks on this forum that can and will help as needed.

Using that URL would have invoked the 2.8.16 level of the Admin Console. You can verify you have the correct Admin Console but going to Help | About. There are two lines, one labeled Firmware which the level in the ISY and the next line labeled UI is the level of the Admin Console. Both should indicate 3.1.14.

If the Program is as posted it should not run the Then Clause unless the RemoteLinc button is pressed. If it does it is a defect. I’m thinking along the lines of an OR rather than an AND or a Save was missed. Could be a bug but that is a basic IF. I coded this example and traced the results. The trace shows the Program did trigger at From 8:20 PM (20:20) driving the Else which issued an A1/Off. I pressed the RemoteLinc button 3 On a few minutes later which triggered the Program and ran the Then Clause issuing an A1/On. At the To time 8:30 (20:30) the Program was triggered again and ran the Else clause again issuing an A1/Off. The only time the Then Clause ran is when the RemoteLinc button was pressed. If the Program Then Clause runs at other times when the button is not pressed that is the wrong result. If Control 'RemoteLinc-2 - 3' is switched On And From 8:20:00PM To 8:30:00PM (same day) Then Send X10 'A1/On (3)' Else Send X10 'A1/Off (11)' Sun 12/18/2011 08:19:33 PM : [ Time] 20:20:00 0(0) Sun 12/18/2011 08:19:33 PM : [ X10] A1 Sun 12/18/2011 08:19:33 PM : [X10-RSP ] 02 63 66 00 06 Sun 12/18/2011 08:19:33 PM : [ X10] A1/Off (11) Sun 12/18/2011 08:19:34 PM : [X10-RSP ] 02 63 63 80 06 Sun 12/18/2011 08:22:22 PM : [iNST-SRX ] 02 50 11.AD.CF 00.00.03 CB 11 00 LTONRR (00) Sun 12/18/2011 08:22:22 PM : [standard-Group][11.AD.CF-->Group=3] Max Hops=3, Hops Left=2 Sun 12/18/2011 08:22:22 PM : [ 11 AD CF 3] DON 0 Sun 12/18/2011 08:22:22 PM : [ 11 AD CF 3] ST 255 Sun 12/18/2011 08:22:22 PM : [X10-RSP ] 02 63 66 00 06 Sun 12/18/2011 08:22:22 PM : [ X10] A1 Sun 12/18/2011 08:22:22 PM : [ X10] A1/On (3) Sun 12/18/2011 08:22:23 PM : [iNST-SRX ] 02 50 11.AD.CF 19.70.15 46 11 03 LTONRR (03) Sun 12/18/2011 08:22:23 PM : [standard-Cleanup][11.AD.CF-->ISY/PLM Group=3] Max Hops=2, Hops Left=1 Sun 12/18/2011 08:22:23 PM : [X10-RSP ] 02 63 62 80 06 Sun 12/18/2011 08:29:33 PM : [ Time] 20:30:01 0(0) Sun 12/18/2011 08:29:33 PM : [ X10] A1 Sun 12/18/2011 08:29:33 PM : [X10-RSP ] 02 63 66 00 06 Sun 12/18/2011 08:29:33 PM : [ X10] A1/Off (11) Sun 12/18/2011 08:29:34 PM : [X10-RSP ] 02 63 63 80 06

FrayAdjacent I suggest posting an example of the Time and Control based Program that ran when it should not have. The Variable is adding a complexity that should not be necessary. Lee

The ISY User Guide indicates 5-30V DC 300 mA minimum.

oberkc I like your single Program approach better. Keeps all the function in one Program. Note that the Repeat goes before the statements to be repeated. Easier to see under the actual Admin Console as it indents the statements within the scope of the repeat loop.

Use two Programs. This one covers one of the time slots. The second program would be the same approach with a different trigger time and shorter On to Off duration. If Time is 7:00:00AM Then Repeat 17 times Set 'ICON Relay 1' On Wait 40 minutes Set 'ICON Relay 1' Off Wait 20 minutes Else - No Actions - (To add one, press 'Action')

The movement of the Slider is Java itself, not the actual Admin Console application. When the movement stops Java should alert the application that the Slider position was changed. At that point the Admin Console immediately writes the change to the device, thus the Progress Bar. For some reason Java is not indicating a change of Slider position, thus no update is being generated. I have Java Release 6 Update 29 on my XP with SP3. Was a Java update recently applied.