IndyMike

Someguy, Sorry for the long delay in responding... The Dec2Hex conversion was to allow you to look up the device addresses and compare them with the ISY listing. Not required otherwise. Were you able to eliminate the duplicate entries and get to a consistent link count?

Hello Nowandthen, To the best of my knowledge, X10 is not "defeated" if the add-on is not installed. As you indicated, the add-on allows you to ad "named" devices to the tree, and it will track the status based on communications. Not sure how you are trying to control your devices, or what operation you were performing when you received the "unsupported device" response. It sounds like you were trying the add the device to the tree - can't do that without the module. You can control your devices using programs, but you will need to use the X10 command with the device address. Example: Device X10 relay device at address A5 Program If Time is 5:00 PM Then Send X10 A5 ON Else Nothing While the add-on installed, you were able to name the device and use the X10/Insteon program call Device X10 relay at address A5 - Named "Christmas tree" Program If Time is 5:00 PM Then Set "Christmas tree" on Else Nothing Not sure if that was what you were looking for... Edit - Glad you figured it out. What brand/model X10 repeater are you using? Strange that it would play nice with your older modules but have problems with the newer dual-band. Are your newer modules the I2CS version?

Absolutely NOT! I'm sorry, but I may be confusing the real issue... The duplicate links displayed are due to a problem with the PLM "get next record" process. The process can be interrupted, and as a result, the PLM begins reporting links that it has already sent to the ISY (the duplicates). From what I can see, this is a problem with the PLM reporting method only. I do NOT believe that there are actually duplicate records in the PLM. I used the Excel process to determine the "correct" number of links in the PLM by eliminating the duplicates. Unfortunately, it's not perfect. The PLM can "skip" link records as well as "duplicate" them. I performed the above 9 times before I was comfortable that I truly had 407 records. Bottom line - the ISY writes and manages the link records in the PLM using a different process. I fully trust the ISY to perform this correctly. I am constantly creating and deleting test scenes and have not had an issue with lost or duplicate records. I am a bit disappointed that the PLM has issues in correctly reporting the link records back to the ISY. As usual, the UD folks will be looking for a viable workaround to make this a usable feature.

If you have Microsoft Excel 2003 and above, you can import the XML file directly. Excel will create a table of the XML data in integer format (left table below). To convert to Hex, use the Hex2Dec function as shown in the right hand table below. Note that the "ix" column is still in integer - other values in Hex. The real value in importing the data is the ability to search for duplicate records. To do this: 1) Copy the second data table (the one with the hex values). 2) Perform a "paste special" as "values" to a 3 table in your worksheet. This will cause the Hex2Dec functions to evaluate to simple values in this table. 3) Select your 3rd table and perform a "remove duplicates" from the Excel data tab. deselect the "ix" and "ad" columns from the duplicates scan. Excel will remove any duplicate entries from the PLM scan. If the scan completed properly, there should not be any duplicates. In my case, the raw scans indicated anywhere from 407 to 743 records. After removing the duplicates, I had 407 records across nine runs.

Michel, Agree that this is somewhat bittersweet news... I am also not sure that we can say that it's devices near the end of the link database that have issues. I have 407 links in my plm but, as Lee indicated, I can generate link pretty much any link count by interrupting the process with a simple device "on" communication. I've been testing with a specific Icon relay - each time I activate the relay the PLM re-starts transmitting links from the same location (again, as Lee stated). In short, we may need to get back to an address based link interrogation method before we can say what is happening with someguy's link table.

Hello Michel, I do not believe that my 2412S contains duplicate records. When I was able to isolate the PLM and shut down programs I received a consistent 407 records. During times of traffic or program activity, the PLM would report duplicate records but there were only 407 unique. The ISY appears to be requesting the "next link record" rather than using absolute addressing. I believe my 2412S is getting confused with inbound communication and repeating previously transmitted data.

Michel, Your comment on "repeated records" caught my attention. I decided to perform some testing on my 2412S PLM. The results of very different from what I remember. I performed multiple scans with the PLM in different configurations and downloaded the link table results to excel. Using excel, I was able to delete duplicate records. The unique record count is consistent across the runs. The reported record count varies wildly. What I learned: [*:voshzmdg]I had thought that incoming transmissions interrupted the PLM causing an understatement of the link records. What I found was that when the PLM was interrupted, it would repeat records causing an overstatement of total records. [*:voshzmdg]I had previously thought that only powerline of RF (in the case of a 2413S) would interrupt the link count. From testing I found that scheduled programs (queries and the like) would also interrupt the count. [*:voshzmdg]Run 7 showed an overstatement due to a powerline command making it through my double filters. I was logging events in the viewer and saw a device communication register. What I don't know - [*:voshzmdg]I disabled programs, weatherbug, and time updates. The programs defiantly had an effect. Not sure about weatherbug or the internet time updates. [*:voshzmdg]My connection to the Elk was active during the scans. I did not see an Elk status change during the PLM link read. Don't know if this could affect the count. Based on the above, I would guess that someguys link count is below what is being reported. Since he is using a 2413S with RF, the likelihood of obtaining a UN-interrupted count is far lower than mine. IM

Hello ixlr8, I'm jealous - that must be a sizable shop to fit 12 - 8' fixtures. I have 9 - 4' (4 tube) fixtures in mine. When I fire them up in the morning, it will make you squint for awhile. You are fighting both signal attenuation over the 130' distance from the house and noise at both ends. 1) I saw where you are currently running off an extension cord. I have no numbers for signal attenuation over an extension cord (stranded / xx? gauge). It sounds like you have a sizable load in the shop. You may want to put in the final service drop before you spend money trying to fix communication problems. Things may get better or worse - but they will likely change. 2) You are currently running some distance of wiring within the house (distance between the nearest Insteon device and the extension cord connection). Try minimizing this by placing an Insteon device near the connection point (minimize losses). When you put in your "real" service drop, it will be at a panel. Make sure you have an insteon device close by (same phase) to relay the signal to the shop. 3) I'm not clear on your fixtures. Are these true 8 foot T12 bulbs ( 4 tubes per fixture X 75 watts = 300 watt / fixture)? ... or are they 4 foot T12 bulbs ( 4 tubes per fixture x 40 watts = 160 watts / fixture)? I am running 3 of my fixtures on a switchlinc relay (4 tubes X 40 watts X 3 fixtures = 480 W total) as an endurance test. This is a pretty high fluorescent load and has a high inrush current. I haven't had problems so far - but it's only been in place 3 months. 4) If you are running 160 watt fixtures, I would rather see you put your filter money toward better ballasts. If you are running 300 watt fixtures, this might be rather expensive. Fix your service drop first before making any improvements here. For shop lighting, it's hard to beet the fluorescent tube fixtures. Each 40 watt T12 bulb puts out ~ 3000 lumens. I buy the bulbs in 10 packs at roughly $2 / bulb. I've had my fixtures in place for 11 years now. I'd estimate that roughly half of the tubes are original (half replaced).

Hello Johnnyt, I do not believe the following is correct. I have the X10 module installed and I am using X10 "Status" in my programs. I use several programs to monitor the status of my X10 PR511 floodlamps and display the status on KPL's. I also run a polling program during the day to determine if the lamps have been inadvertently activated. In my experience, the ISY (with X10 addon) will: 1) Respond to X10 ON/OFF and Status Response transmissions when using the "Status" condition 2) Respond to an X10 ON/OFF transmission when using the "Control" condition. 3) Will track status and trigger properly when combining "Status" and "Time" conditions ( if Time = XX and Status = XX). Please note the difference in the Status/Control conditions above: A X10 Status Response will not trigger a "Control" condition. The following is the activity monitor trace for a X10 Status Request and Status Response for one of the PR511 flood lamps. The flood lamps have been added to the device tree using the X10 module. They are defined as X10 Generic devices (not A10). Status Request Activity Monitor Sat 09/15/2012 10:27:07 : [ X10] F1 Sat 09/15/2012 10:27:07 : [X10-RSP ] 02 63 96 00 06 Sat 09/15/2012 10:27:07 : [ X10] F1/Status Request (10) Sat 09/15/2012 10:27:08 : [X10-RSP ] 02 63 9F 80 06 Sat 09/15/2012 10:27:09 : [X10-RX ] 02 52 9E 80 Sat 09/15/2012 10:27:09 : [ X10] F1/Status = off (2) Sat 09/15/2012 10:27:09 : [X10-RX ] 02 52 9E 80 Sat 09/15/2012 10:27:09 : [ X10] F1/Status = off (2) Polling Program If From Sunrise + 1 minute To Sunset - 10 minutes (same day) And Time is Last Run Time for 'Flood Daytime Poll' + 15 minutes Then Send X10 'F1/Status Request (10)' Wait 9 seconds Send X10 'F3/Status Request (10)' Wait 9 seconds Send X10 'F5/Status Request (10)' Else - No Actions - (To add one, press 'Action') Status Program (Updates Keypads with Flood status) If Status 'Outdoor / Deck Flood' is On Or Status 'Outdoor / Deck Flood Comm' is On Or Status 'Outdoor / Drive Flood' is On Or Status 'Outdoor / Drive Flood Comm' is On Or Status 'Outdoor / Garage Flood' is On Or Status 'Outdoor / Garage Flood Comm' is On Then Set Scene 'Outdoor / SC Flood Status' On Else Set Scene 'Outdoor / SC Flood Status' Off Daytime Monitor Program - Monitor KPL Status buttons and Turn off floods after 1 mintue If From Sunrise To Sunset (same day) And ( Status '1st Floor / Fam Room / Fam KPL 1 - Wall / Fam KPL 7 - Floods' is On Or Status '1st Floor / Mud KPL 1 - Entry Garage / Mud KPL 6 - Floods' is On ) Then Wait 1 minute Run Program 'X10 Contol Floods Off' (Then Path) Else - No Actions - (To add one, press 'Action') If you are having difficulty, it's possible that your X10 modules are responding differently than I'm showing above. Please post back your module make/model and the activity monitor output for a status request transmission (you can also query the device from the ADMIN Tree). IM

From memory (dangerous): The requested module will return a Status ON or Status OFF. This is a standard X10 response that is recognized by the ISY. I use the status request in a program to Poll my PR511 outdoor motion floods. If one of the floods returns a status of ON, a second program is activated to turn off the floods after a period of time (day/night dependent). I'm currently out of the country, but will try to post some activity logs when I get back. IM

Hello dss, Not sure if you are looking for a deadbolt or a locking handset (you linked to both below). If you are looking for a deadbolt... Unless something has changed in the Schlage design, it will not throw the bolt to lock the door (no motor). The "lock feature" simply disengages the external lever so that the door cannot be unlocked without a code. The Kwickset model does include a motor, and does report lock/unlock status. Since you already have an Elk system, I was wondering if you would consider using a deadbolt separate sensor? I've been using the following inductive sensors to sense the position of my Morning lock for the past couple years. It takes a little woodworking to get them in the door frame, but they've been bulletproof. I've also embedded the sensors in my sliding door foot locks to confirm that they are locked. The sensors require 10 to 30 volt excitation - I use the 12 V Aux outputs from the ELK to power them. Integrating the sensor with the ISY/morninglinc became "fall off a log" easy when UDI incorporated the ELK module. The combination of the ELK and the ISY has been one of the great success stories with the boss lady. When I'm on the road she can see the lock status of the house and all of the 7 entry points by looking at one of the "Status" KPL's spread through the house. No need to run the stairs unless a door is unlocked. http://www.automationdirect.com/adc/Shopping/Catalog/Sensors_-z-_Encoders/Inductive_Proximity_Sensors_-z-_Proximity_Switches/Rectangular_(CR-z-DR-z-APS-z-LF40_Series)/12X27mm_(APS4_Series) Thought this might give you another option, IM

Hello Lee, Your code from the 24th doesn't show a "wait" in the else statement (only the repeat). When I run this I get the same 60 second period. If a 1 second "wait" is inserted, the period increases to 120 seconds. I can confirm that the "Repeat" by itself is being scheduled. Other Insteon activity alters the timing as reported by Tim and Lou. It appears that both the repeat and wait are interruptable (program re-evaluates and re-enters). The use of the repeat, by itself, appears to have 1 second of overhead.

Hello porscheguy, Your 2476 devices are showing V00 because you added them manually. At some point you should check them to make sure they are not V35 devices (know to cause problems). You could delete/re-enroll them using the "auto discover" option which will read the version from the device memory - that's just painful. The easy method is to read the device memory directly using the "Show device Links" command and address 0x0000 to 0x0000 as shown below. This is my 2476D - it's showing a firmware revision of 27 ( the 27.00.00 entry) and agrees with what the ISY is listing for the device. Aside from the above, I don't have much in the way of suggestions that you probably haven't heard already. Since your devices aren't responding, I'd try to determine if they were on the opposite phase from the PLM- it might indicate a noise or phase bridging problem. As far as your program is concerned, I'm a firm believer in the "don't fix what isn't broken" theory. Your program is time tested - mine is not. After seeing your program, it occurred to me that I was forcing the use of a variable where one wasn't needed. Your program could actually be made simpler than what I offered. Just in case you're curious - remembering that your program is already working (although it may not be working the way you thought it was). Your program Your program condensed Last - to copy a program, right click on the program name (in the program tree) and select "copy to clipboard" from the popup menu.

Porscheguy, This isn't exactly what you were looking for, but it may suffice in the interim. The following appears to work when I tested with a disconnected KPL. It's an example of how we are not supposed to program - a "then" section that modifies the "If" conditions. Note that you must use a device direct command in the then section. A scene will not work since the ISY will not request an acknowledge for a scene. I used a short wait for test purposes. I would suggest using something a bit longer (30 seconds?) to allow any spurious noise (that may be affecting communication) to subside. Edit (additional notes): The variable is an integer type - it will not cause a trigger or event when it changes. Do not use a state variable as it will re-trigger the program each time it is incremented. Questions: 1) What devices are you having communication errors with (PLM Model/version, Insteon Model/version)? 2) Does the device controlling the pump actually turn off/on when commanded? Said differently, does the device respond to the command, but fail to communicate back to the ISY? Why do I ask the above - If you understand why the remote device is failing to communicate back to the ISY (spurious noise, etc) retries may be valid. If the problem is due to longer noise periods (TV's, refrigerators, well pumps, etc) a different approach is required. By changing the retry wait period in the above, you may be able to "bracket" the duration of the problem communication period. If the remote device is responding (on/off) but failing to communicate back to the ISY, there may be other workarounds.

Hello Tekken, I recently received a 2487S as well. After reading your post, I wired it to an appliance cord - ever so slight buzzing with the relay on. No noise with the relay off. In order to hear the relay, I had to basically put my ear next to the switch. No way would I be able to hear it in when mounted in a box (but then I'm old). These do make a rather loud click when the relay switches. They are also rather DEEP. I didn't know that when I purchased them (rushed to get the 20% off). Smarthome does have a nice comparison of the standard depth vs these newer deep switches on their webpage. I just didn't read it. I may have to re-think where I'm putting these. A double or triple J-box will be tight.

Michel and Lou, I was about to post back that I "sometimes" see the -1 log entry as well. After testing, I have to change that to "always". I had also wondered if this was associated with "differences" in some of my Icon switches. It is not. I've tested a SWL relay, SWL dimmer, and Icon relay. They all generate the -1 log error. Curiously, there is no indication of an error in the event monitor: Event Monitor Fri 12/09/2011 09:39:26 AM : [iNST-ACK ] 02 62 16.10.95 0F 30 FA 06 BEEP (FA) Fri 12/09/2011 09:39:27 AM : [iNST-SRX ] 02 50 16.10.95 13.22.F9 2B 30 FA BEEP (FA) Fri 12/09/2011 09:39:27 AM : [standard-Direct Ack][16.10.95-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 12/09/2011 09:39:28 AM : [iNST-ACK ] 02 62 16.10.95 0F 30 FA 06 BEEP (FA) Fri 12/09/2011 09:39:29 AM : [iNST-SRX ] 02 50 16.10.95 13.22.F9 2B 30 FA BEEP (FA) Fri 12/09/2011 09:39:29 AM : [standard-Direct Ack][16.10.95-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 12/09/2011 09:39:30 AM : [iNST-ACK ] 02 62 16.10.95 0F 30 FA 06 BEEP (FA) Fri 12/09/2011 09:39:31 AM : [iNST-SRX ] 02 50 16.10.95 13.22.F9 2B 30 FA BEEP (FA) Fri 12/09/2011 09:39:31 AM : [standard-Direct Ack][16.10.95-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Error Log 1st Floor / Mud Room Beep 250 Fri 2011/12/09 09:39:27 AM Program Log 1st Floor / Mud Room Beep 250 Fri 2011/12/09 09:39:27 AM Program -1 1st Floor / Mud Room Beep 250 Fri 2011/12/09 09:39:29 AM Program Log 1st Floor / Mud Room Beep 250 Fri 2011/12/09 09:39:29 AM Program -1 1st Floor / Mud Room Beep 250 Fri 2011/12/09 09:39:31 AM Program Log 1st Floor / Mud Room Beep 250 Fri 2011/12/09 09:39:31 AM Program -1

Hello Frank, The proper Access Code is the "User Code(s)" as defined on page 14, section 2.3 of the Elk manual. If you use another code (ELKRP or Installer) or an incorrect code the ISY will still be able to "Monitor events" but will not be able to arm/disarm the system. User Code 1 (normally the Master) should always work. Other User codes (that you have defined), may not have privileges to arm/disarm the system depending on how you set them up. An easy way to check this is to activate the "ELK Console" from the ISY admin screen. If the ELK Console allows you access with the user code, and you are able to arm/disarm the system, the ISY should work with the same access code.

Lee and Oberkc, I'm sorry, but I must respectfully disagree - A scene can be queried and it will produce status updates for each device within the scene. The scene itself does not have a status. I use the following two programs to ensure that my outdoor lights are not inadvertently turned on during the day. The Outside Daytime program will trigger anytime the ISY recognizes that one of my outdoor lamps has been turned on. Program Outside Daytime If From Sunrise + 1 minute To Sunset - 10 minutes (same day) And ( Status 'Outdoor / Entry Deck' > Off Or Status '1st Floor / Mud KPL 1 - Entry Garage' > Off Or Status 'Outdoor / Entry Patio' > Off Or Status 'Outdoor / Entry Porch' > Off ) Then Wait 2 minutes Set Scene 'SC Ouside Night' Off Else - No Actions - (To add one, press 'Action') The Poll program is only necessary if the ISY "missed" an outdoor lamp being turned on. The query will interrogate each device in the scene. If there is a status change in one of the devices ( > off) the Outside Daytime program will trigger to turn off the scene. Program Outside Daytime Poll If From Sunrise + 1 minute To Sunset - 10 minutes (same day) And Time is Last Run Time for 'Outside Daytime Poll' + 30 minutes Then Set Scene 'SC Ouside Night' Query Else - No Actions - (To add one, press 'Action') The following is the Event Viewer output after running the Query program on the Scene. It shows each device in the scene being interrogated and responding with it's status. Tue 11/29/2011 04:14:30 PM : [iNST-ACK ] 02 62 0C.7A.38 0F 19 00 06 LTSREQ (LIGHT) Tue 11/29/2011 04:14:30 PM : [iNST-SRX ] 02 50 0C.7A.38 13.22.F9 2B 00 FF (FF) Tue 11/29/2011 04:14:30 PM : [standard-Direct Ack][0C.7A.38-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Tue 11/29/2011 04:14:30 PM : [iNST-ACK ] 02 62 03.42.48 0F 19 00 06 LTSREQ (LIGHT) Tue 11/29/2011 04:14:31 PM : [iNST-SRX ] 02 50 03.42.48 13.22.F9 2B 00 00 (00) Tue 11/29/2011 04:14:31 PM : [standard-Direct Ack][03.42.48-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Tue 11/29/2011 04:14:31 PM : [iNST-ACK ] 02 62 0C.77.D2 0F 19 00 06 LTSREQ (LIGHT) Tue 11/29/2011 04:14:31 PM : [iNST-SRX ] 02 50 0C.77.D2 13.22.F9 2B 00 00 (00) Tue 11/29/2011 04:14:31 PM : [standard-Direct Ack][0C.77.D2-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Tue 11/29/2011 04:14:31 PM : [iNST-ACK ] 02 62 09.8C.CD 0F 19 00 06 LTSREQ (LIGHT) Tue 11/29/2011 04:14:32 PM : [iNST-SRX ] 02 50 09.8C.CD 13.22.F9 2B 00 00 (00) Tue 11/29/2011 04:14:32 PM : [standard-Direct Ack][09.8C.CD-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Tue 11/29/2011 04:14:32 PM : [iNST-ACK ] 02 62 09.8C.CD 0F 19 01 06 LTSREQ (01) Tue 11/29/2011 04:14:32 PM : [iNST-SRX ] 02 50 09.8C.CD 13.22.F9 2B 00 D4 (D4) Tue 11/29/2011 04:14:32 PM : [standard-Direct Ack][09.8C.CD-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Hello Michel, I was using the "right click" method as well. The problem only occurs after you use the "compare" function within the device links viewer. After using the compare, the ISY link viewer appears to hang - presents the same information for all devices.

Michel, There appears to be a refresh problem with the ISY Link Table Viewer under 3.1.13: 1) Upon initial entry into the admin console everything works fine. Viewer correctly displays the ISY links for various devices. 2) Performing a device link table scan correctly shows device links. 3) Performing a compare correctly opens the ISY Link Viewer and compares links. 4) After step 3 (compare) the ISY Link Viewer will "stick" to whatever device was compared. All devices will appear to have the same links. Exiting/re-entering the admin console clears the problem. Not a huge deal - we have a work around. Hope you and the team managed to fit in some down time over the Holiday, IM

Michel and UDI Team, Thank you for all the hard work. 3.1.13 Installed without issues. ELK Arm/Disarm, Exports, and Zone queries appear to be working nicely. I attempted to diagnose the problems reported by weunch and FRR regarding the ELK "connected" function and learned a couple of things - 1) Initially the program below indicated false. I assumed this was due to it not being triggered. 2) Fired up ELKRP2 and connected to the ELK. The program did not trigger. It was at this point that I realized that the ISY could still communicate with the ELK with ELKRP2 running. I didn't realize this was possible. Communication appears to be one-way. The ELK communicate state changes to the ISY, but ISY cannot Arm/Disarm the ELK. 3) Physically disconnected the ELK from the network. The ISY displayed a warning message in the top menu bar area and triggered the program. This appears to be automatic - the user does not need to manually query to determine the status. 4) Reconnecting to the Elk again triggered the program which now evaluated to True. If Elk System is Connected Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') I'm hoping that the source of the confusion is the fact that running ELKRP2 does not fully disconnect the ISY. IM

jetjock, There is a device mapping problem with the ELK export in 3.1.12. Please see Lou's post here - http://forum.universal-devices.com/viewtopic.php?f=25&t=7342. I exported with 3.1.12 and had the same issues that Lou reported. I f you have already exported/imported to the elk, please revert to 3.1.10, export/import, and things should be back to normal.

frustratednon-geek, Knowledgeable Fathers are a wonderful thing to have. I still consult my Father on electrical issues (he's in his mid 80's now). Spent 30 years in Aerospace and, as luck would have it, 10 years as Chief Engineer in a local Hospital. I have 30+ years in Aerospace, but I still listen and learn. I'm still a bit concerned about your fixture ratings - the switch must be rated for the fixture, not the installed bulbs. If your fixtures are rated for 60W bulbs, an 1800W switch is appropriate. If the fixture is rated for 90 or 100W bulbs you are at or over the switch rating. My chandeliers are rated for 6-100W bulbs (I have 60W installed). Even though my installed load is 360W, I use 1000W dimmers because that is what the fixture demands. Check yours to make sure. If the worst happens, you want to make sure that an insurance adjuster does not point to this switch.

Frank, Have a look at the ELK firmware as well. I had similar symptoms prior to upgrading to the latest M1 and EXP firmware. I also had to upgrade the ELKRP software to R2 (to support the new firmware). After upgrading, I get the security bar and the ELK can communicate with the ISY. Reverse (ISY to ELK) is still a problem. Current ELK Config: M1G Firmware: 5.2.8 Bootware: 3.3.6 Hardware: 0.13 XEP Firmware:1.3.28 Bootware: 1.2.0 Hardware: 1.0 Symptoms: 1) Events generated by the Elk are recognized by the ISY. 2) The Elk does not recognize Insteon lighting events. 3) The ISY cannot arm/disarm the ELK.

Hello frustratednon-geek, Since this is a commercial installation, please proceed carefully. The switch rating should be matched (exceed) to the maximum fixture load. The rated fixture load may well exceed the 60W bulbs that are currently installed. If you "trust" the original dimmer installation (1800W) do not install a device with a lower rating. If you are unsure about the installation, look up the max fixture rating or get out that ladder (that you don't yet have). I was not aware that SH was offering a 20A KPL. From the website, it lists a 1800W incandescent capacity. Again, please be careful and check the UL label on the back of the switch. I have switches that are rated differently from the information presented on the website/product manuals. An inspector will not care about websites or manuals - he will look at the UL label which indicates what the device was certified to.