LeeG

BillFuchs Also note that coding this Program AFTER Sunrise DOES NOT cause this Program to execute the Then section because Sunrise has already passed. The Then clause will not execute until tomorrow. If From Sunrise To Sunset (same day) Then Send X10 'A6/On (3)' Else Send X10 'A6/Off (11)' For the initial problem make sure the Program is not in a Folder with a False state.

A Program will have to be triggered with the Off command and set it back to some low On Level. A SwitchLinc will always turn Off when the Off paddle is pressed.

The paper sticker on the device is the hardware revision. The value on line 2 of the node information is the device firmware level.

Without actual trace data of the original situation it is difficult to judge what the factory reset actually accomplished. It sounds like the device may have locked up but that is nothing more than a guess.

Factory resetting and doing a Restore Device has no affect beyond that device.

The Adjust Scene statement can change the Local values. The device controlling the load appears in both the "In Scene" and "Set" parameters. The load control device must a Controller of a Scene even if a dummy scene. In Scene 'device' Set 'device' 20% (On Level)

How you go about fixing this is up to you (as far as using FilterLincs for example). The fact that the Advanced Options had been changed to something other than the expected value is somewhat troubling. Were other changes made that have not been restored to the default values. Cannot compare the few On/Off tests to the update. I have not counted them but I would expect the update command count to be 15/20 times the 4 On/Off sequence.

Thanks for the trace. It has some useful information. Click Link Management | Advanced Options. What option is checked? Click Help | About. What is displayed for Firmware? What is displayed for UI? What is the KeypadLinc firmware level? It is displayed on line 2 on the right side of the KeypadLinc node display. Several link records were written into the KeypadLinc. There were some errors throughout the process that were successfully retried and recovered. Eventually two commands failed in a row and the update process was stopped. It gives the appearance that commands are not reaching the KeypadLinc. Look for something plugged into the same circuit as the PLM. Are there power strips with noise/surge suppression plugged into the same circuit? Is a UPS or other electronic equipment powered from the same circuit? Other devices and power strips should be isolated with a FilterLinc to avoid Insteon signal interference. Tue 04/01/2014 11:25:31 AM : [iNST-TX-I1 ] 02 62 10 01 8E 0F 28 0F Tue 04/01/2014 11:25:31 AM : [iNST-ACK ] 02 62 10.01.8E 0F 28 0F 06 SET-MSB(0F) Tue 04/01/2014 11:25:40 AM : [iNST-TX-I1 ] 02 62 10 01 8E 0F 28 0F Tue 04/01/2014 11:25:40 AM : [iNST-ACK ] 02 62 10.01.8E 0F 28 0F 06 SET-MSB(0F) Tue 04/01/2014 11:25:41 AM : [iNST-SRX ] 02 50 10.01.8E 1B.FD.F5 2B 28 0F SET-MSB(0F) Tue 04/01/2014 11:25:41 AM : [std-Direct Ack] 10.01.8E-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 04/01/2014 11:25:41 AM : [iNST-TX-I1 ] 02 62 10 01 8E 0F 2B C9 Tue 04/01/2014 11:25:41 AM : [iNST-ACK ] 02 62 10.01.8E 0F 2B C9 06 NO RESPONSE PEEK (C9) Tue 04/01/2014 11:25:50 AM : [iNST-TX-I1 ] 02 62 10 01 8E 0F 28 0F Tue 04/01/2014 11:25:50 AM : [iNST-ACK ] 02 62 10.01.8E 0F 28 0F 06 NO RESPONSE SET-MSB(0F) Tue 04/01/2014 11:25:54 AM : [10 1 8E 1 ] Link 6 : 0FC8 [E2051BFDF5FF1F05] *Failed Writing [E2051BFDF5FF1F05] Tue 04/01/2014 11:25:54 AM : [ 10 1 8E 1] ERR 1

I think that would work. It creates some On/Off/On/Off paddle sequences to insure the correct ramp rate is in effect which may be hard to follow but I see no reason why the new Local value cannot be set.

The dimmer is powering the load. No other devices involved. When the paddle is pressed the dimmer adjusts the load based on the Local settings.

Nothing special. The file will be larger so posting it the same way as the other event file is fine.

Go to this Wiki post and follow the steps described. http://wiki.universal-devices.com/index ... r_ISY-994i

Harold I have been diagnosing Event Viewer files for several years. Wordpad is a good tool to use as it recognizes /r/n. That aside the posted event viewer file was not taken at LEVEL 3 so the actual commands issued with the device response are not in the trace file. Whenever collecting an event viewer file that will be posted it needs to be taken at LEVEL 3. EDIT: note the time stamp between ERR 1 and the line just before it. Some 55 seconds of commands issued and device responses that are not traced when not using LEVEL 3. It is the missing information that will document what commands are issued and what device response (or more likely the lack of response) that resulted in ERR 1. Mon 03/31/2014 11:22:27 AM : [10 1 8E 1 ] Link 0 : 0FF8 [22141BFDF5FF1F02] Writing [22..............] Mon 03/31/2014 11:22:38 AM : [PLM ] Group 20 : Deleting Controller Link matching [10 1 8E 1 ] Link 0 : 0FF8 [22141BFDF5FF1F02] Mon 03/31/2014 11:22:38 AM : [10 1 8E 1 ] Link 1 : 0FF0 [22040FD204FF1F02] Writing [22..............] Mon 03/31/2014 11:22:59 AM : [10 1 8E 1 ] Link 2 : 0FE8 [220210060DFF1F02] Writing [22..............] Mon 03/31/2014 11:23:02 AM : [10 1 8E 1 ] Link 3 : 0FE0 [22020FD1A7FF1F02] Writing [22..............] Mon 03/31/2014 11:23:05 AM : [10 1 8E 1 ] Link 7 : 0FC0 [62020FD0BB010002] Writing [62020FD0BB010002] Mon 03/31/2014 11:23:58 AM : [ 10 1 8E 1] ERR 1

The Event Viewer needs to run at LEVEL 3 to produce a useful trace.

That configuration does not support multiple Ramp Rates. A KeypadLinc button controlling the load control switch can use multiple Scenes. The KeypadLinc button triggers one ISY Program to handle the On side and a second ISY Program handling the Off side. Each Program would use a different Scene with a different Responder Ramp Rate. A single device cannot have a Local Ramp Rate for On and a different Local Ramp Rate for Off. A Fast Off uses a preset Ramp Rate of 0.2 seconds (if memory is correct). On could use the Local Ramp Rate and use Fast Off to turn the LEDs Off. Or use a different brand of LED.

Not using a single Scene. If using an ISY Program one ISY Scene could be used to turn the Responders On and a different ISY Scene to turn the Responders Off. Also no if the LEDs are the load to a device that operated to turn them On/Off. In other words Insteon devices do not have the ability to use different ramp rates for On and Off.

Is the I/O Linc option Trigger Reverse being used? It sounds like it. Trigger Reverse affects what the Sensor sends, On sends Off command, Off sends On command. Unfortunately Trigger Reverse does not alter the Query response. Query returns the actual state of the Sensor, not the Trigger Reverse state.

As far as REST response, yes. The question is what happened to the Icon display after REST command when an Icon is missing.

What does Help | About show for Firmware and UI levels?

Thanks for posting the results. Not sure what the PLM links have to do with the display but happy the problem is resolved.

I don't think PLM link records would be a factor but the PLM can be restored with a File | Restore Modem (PLM). Be sure not to hit Delete Modem (PLM) as that will cause problems.

Below the Scene name is a Red node entry for the Controller button A. Click that Red node and set the other buttons to 0% On Level. Each Insteon Controller has its own unique Responder values. Clicking the Scene name which has the PLM as the Controller has a different set of Responder values than button A.

First, the Backlight level cannot be set for individual buttons. Setting a Backlight value applies to all buttons. The newer devices use Backlight value as a % On rather than an Off/On value. An Off/On setting of 7/15 (0x7F) is 100% On. An Off/On value of 3/15 (0x3F) is approx 50% On level. An Off/On value of 0/0 turns the button LEDs completely Off. It does not logically turn the button Off, only the LEDs Off for those who want a dark KPL at night. Going from 0/0 to 7/15 will turn the LEDs back to the previous button LED On/Off state. That is, a button LED that was On before going to 0/0 will be On when going back to 7/15.

I think running a 4.x.x UI against a 3.3.10 could be an issue. I don't have a 3.3.10 environment to test this. Suggest pulling the UI from the ISY itself and see if that resolves the display problem. http://192.168.2.3/admin using your IP address will pull the UI from the ISY itself. Check the result with Help | About.

I did not see anyone from UDI indicate this as a new problem. From what Chris posted they have not been able to recreate locally. Fixing something that cannot be recreated locally is usually a challenge. Have you been able to run the REST test Chris suggested as a means of getting more information?