IndyMike

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.

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 Matapan, I've had 6 of the Utillitech 7.5W (40W equivalent) LEDs installed in my outdoor coach lights since May. Picked these up on sale at Lowes (~$10). They are inverted in the fixtures and have so far done well through the heat of summer. 1) The LED's are dimmable and are very linear down to ~10%. 2) I tested noise with a Switchlinc dimmer - the LEDs actually generate less impulse noise than a standard 60W incandescent. Noise comparison over here : http://cocoontech.com/forums/topic/17552-more-led-bulb-options/page__view__findpost__p__158399 3) The color temperature is a bit on the cool side (don't remember the #'s - I'd estimate ~ 3200K). There fine for outdoors or for "task lighting". I would not use these in a family room. 4) Although they are a A19 shape, the light is rather directional. Would not work well in a table lamp - most of the light would go to the ceiling rather than being diffused through the shade. I had been using dimmable CFL's in my outdoor fixtures. These were a constant maintenance problem - they generated noise and were affected by the outdoor temperature ( 95F to -10F). The LEDs have so far been a "set it and forget it" setup. We'll see how they perform this winter.

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.