IndyMike

gmurch, Allow me to restate your post to make sure I have things correct: 1) If your downstairs KPL is activated you turn your lighting scene on at TBD level. 2) After 2 minutes, you dim the lights to Movie level and want to activate a button on your upstairs KPL. 3) Both the up and downstairs KPL should be capable of activating/deactivating the Movie mode. There are a number of ways of approaching this. The problem may be that you want your upstairs KPL to activate a "movie scene", but you want the button lit if any of your "movie scene" lights are on. These are not the same. Here's one method: Create the following scenes with all of your movie light responders. Include your KPL's as responders, control will be handled in the program section. Scene Home theater on Light 1 at tbd level and ramp Light 2 at ..... KPL Upstairs ON KPL Downstairs ON Scene Home theater movie Light 1 at movie level and ramp Light 2 at ..... KPL Upstairs 50% KPL Downstairs 50% Scene KPL Status KPL Upstairs KPL Downstairs Now program the control section - you'll actually need 3 controls (on/off) for your two KPLs. Downstairs KPL ON If Control KPL downstairs is set to ON Then Set scene HomeTheater on Wait 2 minutes Set Scene Home Theater Movie ON Else --- Upstairs KPL ON If Control KPL upstairs is set to ON Then Set Scene Home Theater Movie ON Else --- Either KPL Off If Control KPL downstairs is set to off or Control KPL upstairs is set to off Then Set scene HomeTheater off Else --- Now the Status section. One program to update the KPL status for on and one for off. Program to update KPLs with On Status If ( Status 'KPL Upstairs' is Off And Status 'KPL Downstaris' is Off ) And ( Status 'Lamp 1' > Off Or Status 'Lamp 2' > Off Or ..... ) Then Set Scene 'KPL Status' On {typo corrected - was Off} Else - No Actions - (To add one, press 'Action') Program to Update Off status of KPL's If ( Status 'KPL Upstairs' is > Off And Status 'KPL DownStairs' is > Off ) And ( Status 'Light 1' is Off And Status 'Light 2' is Off ..... ) Then Set Scene 'KPL Status' Off Else - No Actions - (To add one, press 'Action') Now for the problem with the above. The status monitoring will turn on your KPL button if any light in your scene is on. I'm not sure that's what you want. Using this program you may need to turn your upstairs KPL off and then back on again to activate your movie mode. Hopefully this is a starting point and you can "tune" things as you desire. IM

I was recently burned trying to use a status trigger with a wait/repeat action. I believe that my problems were due to the fact that a "status triggered" program is re-entrant. Although the following may be "common knowledge" among many of the forum members, I've never seen it stated explicitly. While I understand program re-entrance, I didn't think through the implications of using a "status" trigger with a wait or repeat loop. Edit - General rules for "Status" and "Control" triggers: 4-5-08 If Status 'Master KPL 1st FL' > Off And Status '1st Fl Timer Lockout ' is Off Then Wait 5 seconds Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Wait 2 seconds Set Scene '1st Floor Off' Off Else - No Actions - (To add one, press 'Action') The above code executes ~ 10 seconds; the scene dims correctly; turns lights off correctly. Unfortunately I wanted the 2 second delay prior to the "scene off" command to be 1 minute. If Status 'Master KPL 1st FL' > Off And Status '1st Fl Timer Lockout' is Off Then Wait 5 seconds Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Wait 4 seconds Set Scene '1st Floor Off' Off Else - No Actions - (To add one, press 'Action') Increasing the 2 second wait time to 4 seconds had dramatic effects. This code executes for ~45 seconds; The lights wound up dimming to 0% in multiple passes. The scene off statement was never executed. I believe the 4 second wait interacted with the program re-entrance rate, resulting in a loop. I actually surprised that the program was able to "break out". If Control 'Bar Lamp KPL2-Primary' is switched On And Status '1st Fl Timer Lockout' is Off Then Wait 5 seconds Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Wait 4 seconds Set Scene '1st Floor Off' Off Else - No Actions - (To add one, press 'Action') Same program using a "control" qualifier. Runs for 10 seconds; dims light properly; executes off properly. Since the "control" event is a single pass, things operate properly. If Status '1st Fl Timer Lockout' is Off And Status 'Master KPL 1st FL' is On Then Wait 5 seconds Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Set Scene '1st Floor Off' Dim Wait 20 seconds Set Scene '1st Floor Off' Off Else - No Actions - (To add one, press 'Action') Increasing the wait time to 20 seconds reduced the execution time to ~8 seconds. The lights dimmed properly, but the off command was not executed. If Status '1st Fl Timer Lockout' is Off And Status 'Master KPL 1st FL' is On Then Wait 5 seconds Repeat 11 times Set Scene '1st Floor Off' Dim Repeat 1 times Wait 5 seconds Set Scene '1st Floor Off' Off Else - No Actions - (To add one, press 'Action') Converting the individual dim actions to a repeat loop doesn't work either. The above runs for ~8 Seconds; doesn't dim; doesn't turn off light. If Status '1st Fl Timer Lockout' is Off And Control 'Bar Lamp KPL2-Primary' is switched On Then Wait 5 seconds Repeat 11 times Set Scene '1st Floor Off' Dim Repeat 1 times Wait 5 seconds Set Scene '1st Floor Off' Off Else - No Actions - (To add one, press 'Action') The above shows the proper method for triggering this program. A control action is used instead of the "status" trigger. This program correctly runs for ~ 20 seconds; Proper dimming; Proper turn off;. All of the above code will run properly if triggered by a "control" action. Hope this keeps others from falling into the same trap. IM[/i]

Forum Members, My apologies to anyone who tried to implement the original example posted above. It flat didn't work. I had tried to "pretty things up" with repeat loops and add an additional feature (the one minute delay prior to off). I had thought that I had tested these upgrades prior to posting. Obviously I made a mistake somewhere (most likely didn't "save" the code prior to testing). Looks like the log fell on me instead. The bottom line is the repeat loops and second delay don't play well with "status" monitoring. I've corrected the original post using "control event" triggering. This does appear to work (at least this morning) and provides similar features. Again, my apologies to anyone who's time may have been wasted trying to implement the original code. An example of a simple status monitor for my outside entry lamps follows. This has been working for a number of weeks, and I didn't try to pretty it up this time. The following monitors the outside lighting during daylight hours. If any lamp is inadvertently turned on it is shut down two minutes later. I used the 2 minute timer because I am at times experimenting with the lighting and need that time to check for results. IM If From Sunrise + 1 minute To Sunset - 10 minutes (same day) And ( Status 'Outside Deck ' > Off Or Status 'Outside Garage ' > Off Or Status 'Outside Patio ' > Off Or Status 'Outside Porch ' > Off ) Then Wait 2 minutes Set Scene 'Ouside Night' Off Else - No Actions - (To add one, press 'Action')

The following is an example of how to prevent "inadvertent" lighting. With the advent of KPL's and remote activated lighting, we often can't "see" what is occurring when something is activated. Family members and friends often don't understand the lighting system. The result can be outside lights that a left on during daylight hours or indoor lighting left on during the wee hours of the night. With the advent of X10 2-way modules, we were able to monitor when loads were activated and time them or check them against predefined operating times. I had previously managed to monitor lighting during "off time" hours with my X10 system. It was extremely involved and required many macros. With the ISY program structure, it's like falling off a log. The following code monitors a "scene status lamp" for my first floor. 1)If any lamp on my first floor is activated the "master KPL 1st Fl" is turned on. 2)If this occurs during the "off hours" a 11 minute off timer is started. This would presumably allow a family member to get a glass of milk during the activated time. 3)After 10 minutes the lights are dimmed ~50% to warn anyone that they are near the end of the timer period. 4)The "lockout" is a separate KPL button that can be activated at any point to exit the timer program. I use this in the event that my wife or I are having one of those "sleepless nights" and want to read a book. If ( On Sun, Mon, Tue, Wed, Thu From 11:00:00PM To 3:35:00AM (next day) And ( Control 'Bar Lamp KPL2-Primary' is switched On Or Control 'Bar Lamp' is switched On Or Control 'Bar Cans' is switched On Or Control 'Bar Cans KPL2-C' is switched On Or Control 'Fam Lamps KPL1-C' is switched On . . . ) And Status '1st Fl Timer Lockout 08.4C.8' is Off ) Or ( On Sat, Fri From 12:00:00PM To 5:00:00AM (next day) And ( Control 'Bar Lamp KPL2-Primary' is switched On Or Control 'Bar Lamp' is switched On Or Control 'Bar Cans' is switched On Or Control 'Bar Cans KPL2-C' is switched On Or Control 'Fam Lamps KPL1-C' is switched On . . . ) And Status '1st Fl Timer Lockout 08.4C.8' is Off ) Then Wait 10 minutes Repeat 15 times Set Scene '1st Floor Off' Dim Repeat 1 times Wait 1 minute Set Scene '1st Floor Off' Off Else - No Actions - (To add one, press 'Action') Corrected on 1/13/08 - Changed from status monitoring to "Control Event" monitoring. Status monitoring causes problems with the repeat loops and the second wait statement due to the re-entrant nature of the code. I have similar programs monitoring my outside entry lighting and X10 flood lamps. Ever come home after work to find that someone has accidentally activated your flood lamps (for who knows how long)? This would absolutely kill me is the past. Not a problem any more. If they are inadvertently activated, the ISY triggers and turns them off in a predetermined time frame. IM

Your problem may be occurring due to different ramp rates between your devices. When you instruct a group of devices to turn off they will do so according to their programmed ramp rate. I believe you want the following as "and"s rather than "or"s. If all of the lights are off, then turn off the status lamps. Since your status lamps are set by a scene (??) these should probably be "and"s as well. Let us know how things work, IM If ( Status 'Hall Ctyd' is Off AND Status 'Hall Dining Room' is Off AND Status 'Hall Front' is Off AND Status 'Hall LR' is Off AND Status 'Dining Room' is Off ) And ( Status 'Floor 1 ctrl - Rear KP-A' is not Off AND Status 'Floor 1 Ctrl-Front KP-D' is not Off ) Then Wait 1 second Set Scene 'Floor 1 Status Light' Off Else - No Actions - (To add one, press 'Action') FLOOR 1 STATUS ON If ( Status 'Hall Ctyd' is not Off Or Status 'Hall Dining Room' is not Off Or Status 'Hall Front' is not Off Or Status 'Hall LR' is not Off Or Status 'Dining Room' is not Off ) And ( Status 'Floor 1 ctrl - Rear KP-A' is Off AND Status 'Floor 1 Ctrl-Front KP-D' is Off ) Then Wait 1 second Set Scene 'Floor 1 Status Light' On Else - No Actions - (To add one, press 'Action')

MikeB, Could you use a "program control" as a lockout? I'm not sure this whether this would accomplish your goal... Program "Party" If Control 'TheaterControls1H' is switched On Then Set Scene 'TheaterParty' On Else - No Actions - (To add one, press 'Action') TheaterControl Program with "Party" lockout If PROGRAM 'PARTY' is off (Lock out while party program is active) And Status 'TheaterControls1H' is not Off And -( | Status 'TheaterControls1A-Table' is not 50% | Or Status 'TheaterMain1' is not 50% | Or Status 'TheaterMain2' is not 50% -) Then Set Scene 'TheaterPartyStatus' Off Else - No Actions - (To add one, press 'Action') Rand - excellent catch on the execution flow (Homer slap on this end). I've already modified my programs accordingly. IM

Frank, Thank you for the reply. It's always nice to hear that I'm not totally out in left field. Looking at your quote below, I was hoping that this wasn't actually the case. If the Insteon cleanup and the X10 commands are concurrent it would imply that neither is functioning properly. I would have thought that the "collision avoidance" in the PLM would prevent this from happening. I suppose it's possible that the collision avoidance doesn't function across communication modes (X10-X10 and Insteon- Insteon works, but Insteon-X10 doesn't). My original assumption that the PLM is "tailgating" an X10 command too close to an Insteon command doesn't work. I had envisioned that the X10 start code was being "missed" by receivers due to an improper gap between the Insteon and X10 transmissions. I forgot that every X10 command is repeated automatically per the protocol. A bad gap could affect the first command sequence, but the second should make it through. Based on this, I'd have to agree that the group cleanup functions appear to be operating concurrently with the X10 sequence. This is easy enough to handle within the ISY, but what are the implications for other asynchronous X10 events. Without proper collision detection any X10 transmission (motion sensors, timed events, etc) can occur during Insteon communication. With regard to repeating the X10 commands - I was trying this for a period of time. I found that the PLM simply doesn't have enough output for my installation. As present I have my PLM and CM15a located at the load panel on opposite phases (X10 repeater across the phases). I'm using the PLM/ISY as the brains, and the CM15a as the brawn (due to its higher output level). In this configuration the ISY trigger's off Insteon events and transmits X10 to my CM15a (they're close enough that this communication is reliable). The CM15a in turn runs a macro and broadcasts to the house. Not the most efficient, but I do manage acceptable X10 levels in my problem areas. Thanks for the insight, IM

The following is a FYI. I believe this is a PLM timing issue rather than a ISY programming issue. I apologize if it has been previously reported. Here's the summary - X10 triggers followed by X10 actions work well. X10 triggers followed by Insteon commands work well. Insteon triggers followed by a X10 action must be separated by a wait period. Not doing so will produce an unintelligent House/Unit code. Here's the long version - I recently found that one of my "Insteon Triggered" X10 actions was not functioning properly. I added a controlinc to control my X10 floodlamps. The Insteon command from my controlinc triggeres an X10 action in the ISY. This command is received by my X10 CM15a which activates a X10 macro. I noticed that I could no longer activate my X10 devices with the KPL. My Insteon devices queried 100% and all of my other X10 devices appeared to be functioning normally. As usual, I suspected a X10 noise or signal absorber first - out come the X10 troubleshooting tools (ELK ESM1, Testerlinc, and the CM15a activity monitor). Here's what I found - Insteon triggered X10 event - doesn't work If Control 'Controlinc Floods 00.79.0A.5' is switched Off Then Send X10 'G6/Off (11)' Else - No Actions - (To add one, press 'Action') Transmission in response to the above trigger (Checked with my CM15a Activity Monitor and Testerlinc): Receive G6 ON The problem with the above is there is no Address/Housecode preceding the "G6 On" command (required by X10 devices). In contrast, X10 Triggered commands followed by X10 actions work flawlessly - If X10 'A12/On (3)' is Received Then Send X10 'B3/On (3)' Else - No Actions - (To add one, press 'Action') X10 Transmission from the PLM- Receive B3 Receive B ON In comparing the activity between the two actions above, I noticed that my Testerlinc registered a lot of "Bad start code" and "bad blocks" during the execution of the Insteon triggered command. The testerlinc normally registers some of these codes during transmission of Insteon commands (misinterpreting Insteon activity for X10). The issue with the Insteon triggered X10 commands was that the was a LOT of bad code activity for several seconds. Very suspicious... Trigger Modification- If Control 'Controlinc Floods 00.79.0A.5' is switched Off Then WAIT 1 SECOND (SORRY DON'T KNOW HOW TO BOLD THIS) Send X10 'G6/Off (11)' Else - No Actions - (To add one, press 'Action') So simple... From the above I would infer that the PLM is "tailgating" the X10 command too soon after receiving the Insteon transmission. X10 devices look for a gap between transmissions (protocol requires 3 cycles but many devices operate with less). The PLM is stacking transmission too closely and X10 devices are not able to distinguish the information from the previously transmitted Insteon. Hope this helps. Had me going for a bit. IM Almost forgot - PLM firmware 5.2, ISY version 2.6

Had a chance to test the restore function this morning (using V2.6). I have a "problem" KPL that has a bad habit of dumping it's link table. I noticed this morning that a number of secondary device buttons were again not responding (queries were flawless, KPL just forgot the link). Relinking these devices would normally have required eliminating the Load link, adding the secondary links, and then rebuilding scenes. To make a long story short, the restore fixed the broken links and restored the proper order for my scenes (just as Chris had stated). Thanks ISY guys, this is a gem.

Has, I ran a quick test on the ISY Dim command. It does work, but it's probably a bit different from what you're accustomed to. The standard X10 Dim sequence is a mess (I'd like to use a more descriptive word but it would probably be bad form). It consists of an House/address code followed by a stream of bright/dim commands (ex: A1, bright,bright,bright,bright). The bright/dim commands are repeated continuously (no gaps) until the correct level is achieved. This command sequence is very hard on repeaters and prone to noise problems. The ISY output does not concatenate the "bright/dim" commands. It treats each as separate command with it's own House/unit code (see the example below). This sequence is far easier for receivers/repeaters to interpret. The down side is it takes a LONG TIME to transmit. The following is a test that I ran to check the X10 communication. The ISY triggers on a X10 A12 ON received from my CM15a. The ISY then turns on my lamp (100%) and executes 15 Dim commands (75%). From the log below, this took roughly 31 seconds to transmit. A standard X10 Dim sequence would take on the order of 4-5 seconds. I suppose we could ask the ISY folks to implement a DIM*n command, but to be honest, I avoid them because of the problems they can cause. I would much prefer the ability to execute an extended code direct dim. Hope this helps. IM ISY Trigger and Dim Sequence If X10 'A12/On (3)' is Received Then Send X10 'I1/On (3)' Wait 1 second Send X10 'I1/Dim (15)' Send X10 'I1/Dim (15)' Send X10 'I1/Dim (15)' Send X10 'I1/Dim (15)' Send X10 'I1/Dim (15)' Send X10 'I1/Dim (15)' Send X10 'I1/Dim (15)' Send X10 'I1/Dim (15)' Send X10 'I1/Dim (15)' Send X10 'I1/Dim (15)' Send X10 'I1/Dim (15)' Send X10 'I1/Dim (15)' Send X10 'I1/Dim (15)' Send X10 'I1/Dim (15)' Send X10 'I1/Dim (15)' Else - No Actions - (To add one, press 'Action') X10 Transmit sequence received by my CM15a 1007 12/21/2007 11:30:37 pm Receive I1 1008 12/21/2007 11:30:38 pm Receive I On 1009 12/21/2007 11:30:39 pm Receive I1 1010 12/21/2007 11:30:40 pm Receive I Dim 5 1011 12/21/2007 11:30:41 pm Receive I1 1012 12/21/2007 11:30:42 pm Receive I Dim 5 1013 12/21/2007 11:30:43 pm Receive I1 1014 12/21/2007 11:30:44 pm Receive I Dim 5 1015 12/21/2007 11:30:45 pm Receive I1 1016 12/21/2007 11:30:46 pm Receive I Dim 5 1017 12/21/2007 11:30:47 pm Receive I1 1018 12/21/2007 11:30:48 pm Receive I Dim 5 1019 12/21/2007 11:30:49 pm Receive I1 1020 12/21/2007 11:30:50 pm Receive I Dim 5 1021 12/21/2007 11:30:51 pm Receive I1 1022 12/21/2007 11:30:52 pm Receive I Dim 5 1023 12/21/2007 11:30:53 pm Receive I1 1024 12/21/2007 11:30:54 pm Receive I Dim 5 1025 12/21/2007 11:30:55 pm Receive I1 1026 12/21/2007 11:30:56 pm Receive I Dim 5 1027 12/21/2007 11:30:57 pm Receive I1 1028 12/21/2007 11:30:58 pm Receive I Dim 5 1029 12/21/2007 11:30:59 pm Receive I1 1030 12/21/2007 11:31:00 pm Receive I Dim 5 1031 12/21/2007 11:31:01 pm Receive I1 1032 12/21/2007 11:31:02 pm Receive I Dim 5 1033 12/21/2007 11:31:03 pm Receive I1 1034 12/21/2007 11:31:04 pm Receive I Dim 5 1035 12/21/2007 11:31:05 pm Receive I1 1036 12/21/2007 11:31:06 pm Receive I Dim 5 1037 12/21/2007 11:31:07 pm Receive I1 1038 12/21/2007 11:31:08 pm Receive I Dim 5

Thank you Chris! That's a handy time saver. Is this a recent development (V 2.5 or 2.6) or did I just miss it during the Beta releases?

MikeB, I've been using your example for some time now. Thank you, it's been working nicely. After playing with things the other night, it occurred to me that the trigger would be re-evaluated on each status change. The result is multiple on commands to the keypadlinc status button when it's already on. Being an old X10'er I have a mindset regarding excess traffic on the powerline. I've added the following qualifiers to prevent re-triggering of a scene that is already on. Thought I'd pass it along FWIW. 1st Floor status off trigger 1st Floor status On Trigger

OK, I'm wiping some serious egg of my face right now. I just pulled a 4th KPL out of it's box, wired it to a power cord and Tap linked it to the ISY/PLM. No problems-all button changes are recognized by the ISY. Presumably my other KPL dumped it's link table at some point and lost the link to the PLM. Instead of trying a "restore device", I assumed the KPL was different and went for the workaround. Thanks for getting me back on the path.

MikeB, Maybe I missed something very basic here. I have 3 Keypadlincs. All were linked to the PLM/ISY via tap linking. The KPL in question is the only unit where the primary button is connected to a load (not a scene controller). I've never been able to monitor the status of this button, until I added it as a controller of a scene for the dummy AppliaceLinc. Did my KPL simply loose the link to PLM (sometime very early on in my playing).

Hello, After reading numerous posts on the subject, I arrived at the understanding that a Load connected KPL button could not be monitored unless it was also a controller of a scene. My KPL is direct connected to my family room wall lamps. I have no other scenes that I wanted it to control. I just wanted to monitor it's status. I run a trigger on the status of all of my first floor lamps. If any member of my 1st floor scene is on (including the KPL Load) I want to light a secondary button on the KPL. It really frustrated me that I couldn't do this (monitor) with the KPL load button. My work around was to grab an ApplianceLinc that I wasn't using, plug it in with no load, and create a scene with my KPL load button. Not the most efficient use of hardware but it works. Life is good. Last night I came up short on Appliance Modules for Christmas lighting. I was forced to remove my Appliancelinc from the KPL Load scene and move it elsewhere. Here's the rub - The ISY can still monitor the status of my KPL Load button. It's no longer the controller of a scene, but the ISY still hears it. Life is good, but I don't understand why! Here's my synopsis - 1) A KPL load button does not transmit unless it's the controller of a scene. As a result, the ISY can't normally monitor it's status because it doesn't transmit a local on/off. 2) By adding the dummy ApplianceLinc scene (with the KPL Load button as a controller), I forced a link that the ISY could monitor. 3) When I deleted the above scene, the KPL Load button should have reverted back to being "mute" when I activate it locally. How can the ISY still monitor it? Feature, KPL Bug or other? Thanks, IndyMike

After starting to play a bit with X10 commands I was astounded to see options for "Extended Codes" and "Extended Data". However, I can't seem to find a method for specifying the code or data sent. I have a number of Leviton switches (HCM06 and similar) that I would dearly love to use "extended code dim" commands with. Is this a option for future releases or am I missing something in the command structure? Thanks, IndyMike

Chuck, You and I are doing very similar things (right down to using Keypad E for alloff/allon). While I don't see anything wrong with your "alloff LED trigger", I'm using inverted logic (or's) and things appear to be working (actually this is shameless plagiarism of an example from MikeB - thanks Mike) . The following is how your trigger would look with the logic inverted. if Status 'Basement Playroom Lights (loa' > Off or Status 'Dining Room - DECK' > Off or Status 'Dining Room - LIGHT (load)' > Off or Status 'Dining Room - YARD' > Off or Status 'Dining Room Ceiling Fan (load' > Off or Status 'Kitchen Ceiling Lights (load)' > Off or Status 'Kitchen Sink Light (load)' > 40% or Status 'Living Room Ceiling (load)' > Off or Status 'Living Room Lamp (load)' > Off or Status 'Office Ceiling Light (load)' > Off Then Wait 2 seconds Set Scene 'ALL OFF LED' off Else Wait 2 seconds Set Scene 'ALL OFF LED' on

evarsanyi, I've gotten around this in the past with another application (ActiveHomePro CM15a) by using user settable "flags" or X10 "dummy modules". This allows your second program to test the flag or dummy module state prior to executing. I'm a newbie with the ISY-26 (2 days), but from what I can see neither of these options exist. Possibly a suggestion for future releases? As upstatemike indicated, I believe you need a separate qualifier for your RF2 trigger.