IndyMike

I agree - I tried this on my one (only) 2477D V.40 and received the same results and virtually identical event log. I have tried disabling programs, removing my passive coupler, and adding accesspoints to no avail. The ISY seems to regard every other paddle press as a "duplicate" event. By slowing the paddle presses to 1 every 3 seconds, the ISY recognizes the presses as "unique" events. This does appear to be something related to the 2477D or the way that the ISY interprets its communications. I have been running similar counting programs on non-dual band relays and dimmers since variables were introduced (fan timer programs). I have never seen a hiccup on these.

Hello again mfranzel, I am not trying to upset you. In my original post, I was inquiring about your configuration (kpl controlling an outlet). I should have posted this as a direct question. You had indicated that your Keypadlinc was a non-dual band unit. The only non-dual band Keypadlinc relays that I know of are the 2486S units which are rated at 13 Amps. Do you have a 2486S relay Keypadlinc controlling a standard outlet? You can check this using the ISY - click on My-Lighting and then find the device type in the right hand pane (under "Type"). If that is the configuration (please respond), I believe it does not comply with NEC code (as Brian also indicated). I was actually more concerned about you trying to place a filter between the KPL and the outlet. The filters are rated at 5 Amps while the KPL is rated at 13 Amps. Adding a filter to this configuration would have been against code AND unsafe.

Sorry, 1 outlet or many makes no difference. It's against code. Whether or not this is a safety issue is debatable. Enough discussion - I'll climb off my high horse. From your description, your CFL's are using the GU24 base. I have not seen LEDs with this base locally. Rather than spending money on new bulbs, you could try plugging your lamps into a filterlinc (assuming you have one). If this solves the problem, you may want to try different bulbs. If it does not, you may have another "unknown" load on the circuit.

Hello mfranzel, If I understand the above correctly, you are using the KPL relay (2486S?) to control a standard duplex outlet. You may very well already know this but, the KPL is not rated to control a duplex outlet. It is rated for "Wired-in incandescent lighting and inductive loads". You could overload the KPL by plugging in an "inappropriate" device at the duplex outlet. If this is the configuration that you are using, please do not try to put a leviton filter between the KPL and the outlet. The leviton filters are only rated at 5 amps.

Hello Bill, I had similar problems with X10 devices not responding. To get around this, I build a "query" scene and included only the devices that I wanted updated. Downside is that it is a maintenance issue (I forget to add new devices) and it consumes additional links in the PLM and devices. Schedule 1 If From 3:00:00AM For 10 minutes Then Set Scene '1 House Query' Query Else - No Actions - (To add one, press 'Action')

The "query at restart" option behavior is not at all obvious and has what I believe are "dire" consequences. Reported here http://forum.universal-devices.com/viewtopic.php?p=78145#p78145 bsobel added his insight at V 3.3.9 here Release 3.3.9 (RC6) Is Now Available Post 1 and here Release 3.3.9 (RC6) Is Now Available Post 2. Thank you Bill!. While the operation described may be "As Intended", I would submit that it could have serious consequences for the way that I and other users implement programs. Detailed post here: Release 3.3.10 (RC7) - 3.3.8 (RC5) Startup and Query Bugs

I've seen a few other situations that can cause these erroneous results: 1) Programs can interfere with the scene test as they are activated through "status" triggers. Timed events or periodic queries can also wreak havoc. Programs Enabled Wed 01/09/2013 17:26:18 : [GRP-RX ] 02 61 3D 13 00 06 Wed 01/09/2013 17:26:19 : [iNST-SRX ] 02 50 0F.D2.68 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:26:19 : [std-Cleanup Ack] 0F.D2.68-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 01/09/2013 17:26:19 : [iNST-SRX ] 02 50 1A.4F.6B 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:26:19 : [std-Cleanup Ack] 1A.4F.6B-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 01/09/2013 17:26:19 : [iNST-SRX ] 02 50 03.D3.46 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:26:19 : [std-Cleanup Ack] 03.D3.46-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 01/09/2013 17:26:19 : [iNST-SRX ] 02 50 09.8C.CD 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:26:19 : [std-Cleanup Ack] 09.8C.CD-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 01/09/2013 17:26:19 : [iNST-SRX ] 02 50 0A.E5.EC 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:26:19 : [std-Cleanup Ack] 0A.E5.EC-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 ----- SC 2nd Floor Test Results ----- [succeeded] David Switch (1A 4F 6B 1) [Failed] MBath KPL B - Vanity (F BF A4 2) [Failed] MBath KPL A - Vanity (F BF A4 1) [succeeded] Mud KPL 4 - 2nd Floor (9 8C CD 4) [Failed] Matt Inline (E E4 62 1) [succeeded] Master KPL H - David Bed (A E5 EC [succeeded] Master KPL F - Kath Bed (A E5 EC 6) [succeeded] Master KPL C - 2nd Floor (A E5 EC 3) [Failed] MBath KPL E - Closet (F BF A4 5) [succeeded] Master KPL D - Matt Bed (A E5 EC 4) [Failed] MBath KPL D - Toilet (F BF A4 4) [succeeded] Master KPL A - Overhead (A E5 EC 1) [succeeded] Master KPL B - Overhead (A E5 EC 2) [Failed] Master Bath Tub (16 92 BD 1) [succeeded] Kath Icon (3 D3 46 1) [succeeded] Master Fan KPL A (F D2 68 1) [Failed] Master Table KPL B - Light (19 46 CE 2) [Failed] Master Bath Toilet (14 78 B2 1) [Failed] Master Bath Shower (1B F4 54 1) [Failed] Master Table KPL C - 2nd Floo (19 46 CE 3) [Failed] Master Table KPL A - Light (19 46 CE 1) [Failed] BSMT KPL Game - 2nd Floor (F FF F1 4) [Failed] Master Table KPL D - Fan (19 46 CE 4) [Failed] Master Bath Closet (14 6C F0 1) [succeeded] Master Fan KPL B (F D2 68 2) ----- SC 2nd Floor Test Results ----- Wed 01/09/2013 17:26:26 : [iNST-ACK ] 02 62 00.00.3D CF 13 00 06 LTOFFRR(00) Programs Disabled Wed 01/09/2013 17:27:51 : [iNST-SRX ] 02 50 21.D5.C5 11.00.02 C7 06 00 (00) Wed 01/09/2013 17:27:51 : [std-Group ] 21.D5.C5-->11.00.02, Max Hops=3, Hops Left=1 Wed 01/09/2013 17:27:51 : [iNST-SRX ] 02 50 21.D5.C5 11.00.02 C7 06 00 (00) Wed 01/09/2013 17:27:52 : [GRP-RX ] 02 61 3D 13 00 06 Wed 01/09/2013 17:27:53 : [iNST-SRX ] 02 50 0F.D2.68 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:27:53 : [std-Cleanup Ack] 0F.D2.68-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 01/09/2013 17:27:53 : [iNST-SRX ] 02 50 1A.4F.6B 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:27:53 : [std-Cleanup Ack] 1A.4F.6B-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 01/09/2013 17:27:53 : [iNST-SRX ] 02 50 03.D3.46 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:27:53 : [std-Cleanup Ack] 03.D3.46-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 01/09/2013 17:27:53 : [iNST-SRX ] 02 50 09.8C.CD 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:27:53 : [std-Cleanup Ack] 09.8C.CD-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 01/09/2013 17:27:53 : [iNST-SRX ] 02 50 0A.E5.EC 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:27:53 : [std-Cleanup Ack] 0A.E5.EC-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 01/09/2013 17:27:53 : [iNST-SRX ] 02 50 0E.E4.62 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:27:53 : [std-Cleanup Ack] 0E.E4.62-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 01/09/2013 17:27:53 : [iNST-SRX ] 02 50 0E.E4.62 0C.A8.B4 67 09 FD LNK-ON (FD) Wed 01/09/2013 17:27:53 : [std-Cleanup Ack] 0E.E4.62-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Wed 01/09/2013 17:27:54 : [iNST-SRX ] 02 50 0F.FF.F1 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:27:54 : [std-Cleanup Ack] 0F.FF.F1-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 01/09/2013 17:27:54 : [iNST-SRX ] 02 50 19.46.CE 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:27:54 : [std-Cleanup Ack] 19.46.CE-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 01/09/2013 17:27:54 : [iNST-SRX ] 02 50 14.6C.F0 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:27:54 : [std-Cleanup Ack] 14.6C.F0-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 01/09/2013 17:27:54 : [iNST-SRX ] 02 50 1B.F4.54 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:27:54 : [std-Cleanup Ack] 1B.F4.54-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 01/09/2013 17:27:55 : [iNST-SRX ] 02 50 14.78.B2 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:27:55 : [std-Cleanup Ack] 14.78.B2-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 01/09/2013 17:27:55 : [iNST-SRX ] 02 50 16.92.BD 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:27:55 : [std-Cleanup Ack] 16.92.BD-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 01/09/2013 17:27:55 : [CLEAN-UP-RPT] 02 58 06 Wed 01/09/2013 17:27:55 : [iNST-SRX ] 02 50 0F.BF.A4 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:27:55 : [std-Cleanup Ack] 0F.BF.A4-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 ----- SC 2nd Floor Test Results ----- [succeeded] David Switch (1A 4F 6B 1) [succeeded] MBath KPL B - Vanity (F BF A4 2) [succeeded] MBath KPL A - Vanity (F BF A4 1) [succeeded] Mud KPL 4 - 2nd Floor (9 8C CD 4) [succeeded] Matt Inline (E E4 62 1) [succeeded] Master KPL H - David Bed (A E5 EC [succeeded] Master KPL F - Kath Bed (A E5 EC 6) [succeeded] Master KPL C - 2nd Floor (A E5 EC 3) [succeeded] MBath KPL E - Closet (F BF A4 5) [succeeded] Master KPL D - Matt Bed (A E5 EC 4) [succeeded] MBath KPL D - Toilet (F BF A4 4) [succeeded] Master KPL A - Overhead (A E5 EC 1) [succeeded] Master KPL B - Overhead (A E5 EC 2) [succeeded] Master Bath Tub (16 92 BD 1) [succeeded] Kath Icon (3 D3 46 1) [succeeded] Master Fan KPL A (F D2 68 1) [succeeded] Master Table KPL B - Light (19 46 CE 2) [succeeded] Master Bath Toilet (14 78 B2 1) [succeeded] Master Bath Shower (1B F4 54 1) [succeeded] Master Table KPL C - 2nd Floo (19 46 CE 3) [succeeded] Master Table KPL A - Light (19 46 CE 1) [succeeded] BSMT KPL Game - 2nd Floor (F FF F1 4) [succeeded] Master Table KPL D - Fan (19 46 CE 4) [succeeded] Master Bath Closet (14 6C F0 1) [succeeded] Master Fan KPL B (F D2 68 2) ----- SC 2nd Floor Test Results ----- Wed 01/09/2013 17:28:00 : [iNST-ACK ] 02 62 00.00.3D CF 13 00 06 LTOFFRR(00) 2) Pending writes against a device will interrupt a scene test. To test the following I unplugged a lamplinc and then instructed the ISY to include it in a scene. That obviously failed since the device was unplugged (! mark next to the device). There are, however, writes pending against the device (ISY wants to complete the scene addition). Apparently, when the scene test is activated the write update to the devices also activates. This interrupts the scene test response as shown below. The device with pending writes can be anywhere in the system. It does not need to be a member of the scene being tested. Pending writes against a device Wed 01/09/2013 17:45:45 : [GRP-RX ] 02 61 3D 13 00 06 Wed 01/09/2013 17:45:46 : [iNST-SRX ] 02 50 0F.D2.68 0C.A8.B4 61 13 3D LTOFFRR(3D) Wed 01/09/2013 17:45:46 : [std-Cleanup Ack] 0F.D2.68-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 01/09/2013 17:45:46 : [CLEAN-UP-RPT] 02 58 15 ----- SC 2nd Floor Test Results ----- [Failed] David Switch (1A 4F 6B 1) [Failed] MBath KPL B - Vanity (F BF A4 2) [Failed] MBath KPL A - Vanity (F BF A4 1) [Failed] Mud KPL 4 - 2nd Floor (9 8C CD 4) [Failed] Matt Inline (E E4 62 1) [Failed] Master KPL H - David Bed (A E5 EC [Failed] Master KPL F - Kath Bed (A E5 EC 6) [Failed] Master KPL C - 2nd Floor (A E5 EC 3) [Failed] MBath KPL E - Closet (F BF A4 5) [Failed] Master KPL D - Matt Bed (A E5 EC 4) [Failed] MBath KPL D - Toilet (F BF A4 4) [Failed] Master KPL A - Overhead (A E5 EC 1) [Failed] Master KPL B - Overhead (A E5 EC 2) [Failed] Master Bath Tub (16 92 BD 1) [Failed] Kath Icon (3 D3 46 1) [succeeded] Master Fan KPL A (F D2 68 1) [Failed] Master Table KPL B - Light (19 46 CE 2) [Failed] Master Bath Toilet (14 78 B2 1) [Failed] Master Bath Shower (1B F4 54 1) [Failed] Master Table KPL C - 2nd Floo (19 46 CE 3) [Failed] Master Table KPL A - Light (19 46 CE 1) [Failed] BSMT KPL Game - 2nd Floor (F FF F1 4) [Failed] Master Table KPL D - Fan (19 46 CE 4) [Failed] Master Bath Closet (14 6C F0 1) [succeeded] Master Fan KPL B (F D2 68 2) ----- SC 2nd Floor Test Results ----- Wed 01/09/2013 17:45:53 : [iNST-TX-I1 ] 02 62 00 00 3D CF 13 00 Wed 01/09/2013 17:45:53 : [iNST-ACK ] 02 62 00.00.3D CF 13 00 06 LTOFFRR(00) 3) Disabled devices. If a device has been disabled in the ADMIN tree it will show up as "failed" in the scene test. Probably not what you are experiencing, but something to keep in mind. Tip on disabling programs. Tired of using the program summary tab to enable/disable programs? Use a variable in the main "My Programs" folder. Folder Conditions for 'My Programs' Add conditions to limit when programs in this folder are allowed to run. If $Programs_Enable is 1 Then Allow the programs in this folder to run. IM

Hello George, I'm thinking you are trying to find the ID of a backyard station near you. Not at all intuitive - as you'll see. 1) Navigate to the weatherbug site and enter your ZIP code (if it hasn't picked up the location from your browser). 2) Weatherbug will select a Station near you. It will NOT select a backyard station (which may be closer). 3) Select "Change Weather Station". 4) Weatherbug will bring up a map of local stations. You may need to pan back to find your actual location. Backyard stations are shown in yellow as depicted in the graphic below. I am in the little burg of Granger, which happens to be close to the KD8FW station. 5) Select the backyard station, click "set station", and you'll be returned the the main station page as shown below. The station ID will be similar to the highlighted ID I'm showing in the address bar (p04609 in this case). Enter this into the ISY "location ID" and click save. It should bring up the readings for that station. Be careful in selecting your station. Not all stations provide rainfall, wind speed, etc. Worse yet, not all stations are "maintained". My selection of KD8FW was based on good consistent readings, the fact that he's a HAM (speaks well in my mind). The fact that I've know him since grade school doesn't even enter into the equation. Hope this helps, IM

Initial upgrade from 3.3.5 to 3.3.7: Don't remember the ISY performing a Query at restart. This normally requires quite a bit of time on my system. The lack of a query could explain the inability to control ramp rates, etc. Reboot: ISY does perform a query on reboot. Curiously, my 2 AM shutdown program evaluates to "true" and runs. Local time is after 10 AM. I have a similar program set to turn off the basement at 11:20 - it does not run. Program is set NOT to run at startup. Thought this might be an error with the grace period. Set the grace period to 0 with the same effect. If Time is 2:00:00AM Then Set Scene '1st Floor / SC 1st Floor Off' Off Wait 1 minute Set Scene 'Basement / SC BSMT' Off Else - No Actions - (To add one, press 'Action') Link Table Reads: Can't read the last record (511) from device EEprom anymore (range restricted to 510 by ISY). This was very handy for determining X10 addresses, etc. Can we get this back? I can read the 127th record from my Icon units with the reduced memory. Icon Config info: 127 : 0C00 : 50 10 39.00.00 00 00 00 Downgraded to 3.3.5: 1) 2 AM program still runs on re-boots. Disabling "Catch up Schedules at Re-start" prevents the program from running. 2) Link table read range restricted in 3.3.5 as well. Not sure when this was implemented.

foxcob and JCBond, I have not seen the button issue on my V.39 KPL. The KPL does exhibit the backlight issue. Since the button action is controlled by the link table, would you mind performing a "device link scan" and compare? Please post the results if you see compare differences.

Michel, I concur with foxcob and JCbond. After upgrading from 3.3.5 to 3.3.7 I can no longer control backlight on KPL's (mine are I2). Backlight on my I2CS SWL works fine. Below are the event viewer results for the respective firmware revisions. Neither generates errors. 3.3.5 adjusts KPL lighting, 3.3.7 does not. Let me know if you need additional information V3.3.5 KPL Backlight Sun 12/30/2012 15:50:33 : [iNST-TX-I2 ] 02 62 19 46 CE 1F 2E 00 01 07 7F 00 00 00 00 00 00 00 00 00 00 4B Sun 12/30/2012 15:50:33 : [iNST-ACK ] 02 62 19.46.CE 1F 2E 00 01 07 7F 00 00 00 00 00 00 00 00 00 00 4B 06 (00) Sun 12/30/2012 15:50:33 : [iNST-SRX ] 02 50 19.46.CE 0C.A8.B4 2B 2E 00 (00) Sun 12/30/2012 15:50:33 : [std-Direct Ack] 19.46.CE-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 V3.3.7 KPL Backlight Sun 12/30/2012 16:03:26 : [iNST-TX-I2 ] 02 62 19 46 CE 1F 2E 00 00 03 7F 00 00 00 00 00 00 00 00 00 00 50 Sun 12/30/2012 16:03:26 : [iNST-ACK ] 02 62 19.46.CE 1F 2E 00 00 03 7F 00 00 00 00 00 00 00 00 00 00 50 06 (00) Sun 12/30/2012 16:03:26 : [iNST-SRX ] 02 50 19.46.CE 0C.A8.B4 2B 2E 00 (00) Sun 12/30/2012 16:03:26 : [std-Direct Ack] 19.46.CE-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Managed to catch one of the DBLL's in the act of activating/de-activating the scene. This does not appear to be in response to any Insteon or X10 activity. Setup for the following log: [*:33j35vnk]2457D2 LL (V.3B) @18.93.83: Load Sense enabled with local Incandescent Lamp turned off. Scene controller [*:33j35vnk]2457D2 LL (V.3B) @18.8F.3C: Load Sense enabled with Local Incandescent Lamp turned ON. Scene controller [*:33j35vnk]2486DWH8 KPL @0A.A9.A5: Button 3 Scene controller [*:33j35vnk]2842 Motion sensor @21.D5.C5: Linked to PLM only (program control for another scene). [*:33j35vnk]Red: 2457 turning on [*:33j35vnk]Blue: 2457 turning off [*:33j35vnk]Black: other (unrelated?) events In the log below, the LL @18.93.83 appears to spontaneously activate and then de-activate 1 second later. There are no consistent Insteon communications associated with this event. The activity only occurs if the local lamp is switched off. If the lamp is on, everything works "swimmingly". Curiously, this only appears to happen during the evening hours. I'm guessing that I have some line voltage variations that occur during the evening that "trick" the LL into thinking that the load has switched on. Some combination of the capacitance in the lamp combining with the current sense and the line voltage... My Wife has complained that the problems only occur when she is alone in the family room curled up with her book. She's accused me of programming the system to PI$$ her off. I of course point out that, after 30+ years of bliss, I hardly need to look for new buttons to push. Unfortunately, after reviewing the logs, she does have a point. The times in the log below line up with "book time". What has me a bit peeved is that this configuration worked for 7 years when I was using my old 2856 Icon LampLincs ('05 vintage). These were installed with local sensing via X10 addresses and worked flawlessly in the same location with the same loads. These finally died (1 triac, 1 power supply failure) and I moved the DB-LL's into place. Am I missing something in the log below? I do not have any of the "old" Lamplincs left. I'm about to try applicancelincs with X10 addresses to restore my Wife's reading time to normal.

I have a similar situation happening between two 2457D2's. The devices are setup as controllers (local load sense enabled) of the same scene along with a KPL. I use the LL's as controllers so that my better half can turn one lamp off locally and turn off the scene. Both LL's are connected to 60W incandescent loads. Everything works fine as long as both loads are applied (on locally). If one lamp is off, and the scene is activated, the second lamp will turn off - on - off after an indeterminate period of time. To date I have not been able to catch this in the event viewer - I haven't been monitoring when the "event" happens. I do see the devices intermittently turning on/off in the log. No X10 codes Devices factory reset/restored Waiting to catch them in the act - typically happens when the better half is involved with a good book (i.e. not good for me or Insteon).

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.