IndyMike

Mark, A couple of additional possibilities: 1) If one of the two switches is not controlling a load (part of a 3 way) you could develop a program to control the second switch through double taps (fast on) or fades. This would eliminate the interference between the two. 2) Again if one of the switches is not load connected, you could replace both units with a single Keypadlinc. I have a couple of locations where I've combined 4 mechanical switches (3 ways) into a single KPL. Again, since the KPL is controlling all of the outgoing signals it appears to prevent the multiple switch activation phenomena. IM

It was always my understanding that a "factory reset" would completely clear the memory (not sure how you could perform a partial clear). I don't have my PLC running at the moment and can't verify things with powerhome. I did try a reset on a Icon - afterward it will not communicate with the PLM or scene members. Not exactly conclusive, but if yours responds differently I'd say you have a switch problem. We are exercising the "writing" of the switches a lot more with the ISY (it's so painless now). I haven't worked with embedded controllers or EEproms since the 80's. At that time guaranteed write cycles were in the 1000's. What are current devices capable of?

Upstate, I don't mean this to sound insulting, but is it possible that you're not actually performing the reset? Depending on the "fit" of the switch plate it can sometimes be difficult to depress and hold the "set" button. I've found that a small, flat "green stick" can be very helpful in prying the set button out and then depressing it. You might try reseting your switch and then communicating with it prior to reloading. If all of the links are still intact (as well as ramp rates and levels) your reset didn't "take". I suppose its possible that the internal "set" button isn't functioning. IM

d_l, Been there. The "control" works fine with an "or". Some time back I somehow convinced myself that it would work with a "and" as well. It took me two days to recover from that mistake. I'm simply a student from the school of hard knocks, IM

d_l, I don't believe you can use "control" here. You are essentially looking for two simultaneous events - unlikely. A secondary problem could be that the "control" condition can't tell if the light was activated by a scene. A status command can work, but it will require two programs since you're modifying the Kitchen lamp within the program. Monitor IF X10 'A%/On(3)' is Received And STATUS 'Kitchen Light' is OFF Then Call KitchenTimerProgram Else No Actions KItchenTimerProgram No conditions Then Set "Kitchen Light" On Wait 5 Minutes Set "Kitchen Light' Off Run "KitchenTimerProgram" (Else Path) Else - No Actions

Upstate, Sounds like a nice system (I like the hardwired motion sensor). I have seen instances where X10 transmissions have "morphed" (changed house code or unit code) in the presence of noise. I have never seen a valid X10 communication produced purely from noise. To that end, is your Stargate unit capable of registering Insteon traffic and preventing a possible collision? I've wondered this about my X10 transmitters (very difficult to test). Unfortunately the "morphing" and "collision" theories don't work if the ISY doesn't register the activity (can't be a rogue X10 receipt if the ISY doesn't log it?). I am extremely interested in your outcome. Like you I'm using a combined X10/Insteon system and have seen some rogue events (not repeatable). IM

upstatemike, If you have a Controlinc or maxi controller you can cycle through the X10 Housecodes using All-on/All-off commands. I use this to check my Lamplincs when I move them around (verify no X10 address). What type of communication are you using with your motion dectector? Rf only, or RF and transceived X10? I've had difficulties in the past using both RF and transceived (depending on the transceiver) when the detector is in a "high activity" area. If unplugging the ISY doesn't show anything, consider disabling the motion sensor/transceiver. IM

Falco, At one time I was using single scenes with the "status" buttons as controllers. I can't honestly remember why I got away from that (the mind is the first thing to go, I can't remember the second). I suspect that the separate scene (with only the status buttons) is more flexible. In general, I prefer to use program control to activate the scenes. This allows the use of delays, program enable/disable, and other niceties. The above is my interpretation of the functions that gmurch had requested. It may be over complicated and I have not tested it (I corrected one error when I reread it). I'd encourage you to look at other threads which deal with the same concept :http://www.forum.universal-devices.com/viewtopic.php?p=3338#3338 One last comment, the status monitoring includes a "lockout" to prevent the code from running if the "status" is already set. Since the "status command" is evaluated every time one of the devices changes state (bright, dim, on, off) I use this to prevent the program from continuously executing when the condition is already true. In the following code, the "lockout" prevents the program from running if the KPL status lights are already on. No sense turning on lamps that are already lit. I also believe this helps to alleviate the "status button flash" phenomena that can occur when a scene is in the process of executing. If (Lockout section Status 'KPL Upstairs' is Off And Status 'KPL Downstaris' is Off ) And (Status monitor section Status 'Lamp 1' > Off Or Status 'Lamp 2' > Off Or ..... ) Then Set Scene 'KPL Status' Off Hope this helps, IM

Jim, I found a method for executing the "else" but it involves two programs - Program Test1 - Triggers off the X10 off command and tests to make sure "Test2" is not already running (prevents re-triggering). If X10 'A1/Off (11)' is Received And Program 'X10 Test2' is False Then Run program 'X10 Test2' Else - No Actions - (To add one, press 'Action') Program Test2: Turns on lamp I1 and dims through 10 steps. The else loop is forced which turns the lamp off. The conditional "If Program "X10 Test..." is required to allow access to the else path. If Program 'X10 Test2' is True Then Send X10 'I1/Off (11)' Wait 1 second Send X10 'I1/On (3)' Wait 10 seconds Repeat 10 times Wait 1 second Send X10 'I1/Dim (15)' Repeat 1 times Run program 'X10 Test2' (Else Path) Else Wait 10 seconds Send X10 'I1/Off (11)' If you're not concerned about re-triggering, you should be able to move your else action to the last statement in your then sequence. If X10 'G15/Dim (15)' is Received Then Set '-Status Indicator (Ent. Ctr.)' 40% Repeat 10 times Set '-Fireplace' Off Wait 10 minutes Set '-Fireplace' On Wait 20 minutes Repeat 1 time set '-Status Indicator (Ent. Ctr.)' Off Else No actions IM

Jim, I believe the issue is that the "If X10" condition is a trigger (similar to a Insteon Control). The else loop really doesn't apply here. If there were a X10 "status" trigger (doesn't exist) your else would execute. I'm still playing with the program call trying to "force" the else loop. The following does execute the else (and sets the program status to false) once the then is completed. The problem is, the X10 off command isn't executed. I'm scratching my head a bit on this end. If X10 'A1/Off (11)' is Received Then Send X10 'I1/Off (11)' Wait 1 second Send X10 'I1/On (3)' Wait 10 seconds Repeat 10 times Wait 1 second Send X10 'I1/Dim (15)' Repeat 1 times Run program 'X10 Test' (Else Path) Else Wait 2 seconds Send X10 'I1/Off (11)'

Wow Jim, As you already know - I was way off base. I had thought you were using a time base trigger and totally missed the repeat loop. In the future, I'll try not to make posts when it's after my bedtime.

Jim, This is similar to a thread that Chris Jahn had posted elsewhere (thanks again Chris). Try putting a "run program XX" after the last wait in your "then". Looping back through the program should evaluate to the "else" (X10 Code not received) and turn your status indicator off. IM

Rod, I'm by no means the most qualified to answer your concerns, but I do share them. To that end, let me add an additional metric to your list - unnecessary powerline activity. Coming from the X10 world, I'm keenly attuned to this. There are a number of tools built into the ISY-26. I'm making the rash assumption that the 99i shares these same tools. Using these tools can give you an idea of memory consumption, and total links: Telnet to ISY shell: ISY Advanced Configuration Guide Commands: SM: show memory utilization scan z: lists known links - Scenes Create Additional Links Thread These can help evaluate the "efficiency" of your code. Optimization of the various parameters (memory, cpu utilization, execution speed, powerline activity) is most likely contradictory and is based on personal preference and your installation. I have been focusing on CPU utilization (availability of the ISY to respond to events in a timely fashion) and powerline activity (I view this as reliability and responsiveness). Others will have different requirements (execution speed). For my purposes, I have found that creating folders for timed events works well. Grouping a series of programs under a single "time qualified folder" appears to lighten the load on the ISY (you're evaluating a single condition rather than many). This does not imply speed, it may in fact take a given program longer to execute, but rather lower overhead and increased overall responsiveness. The use of "status" conditions can lead to both high overhead and unnecessary powerline communication. The following is an example: Program 1: KPL status monitor If Status 'Bar Cans' > Off Or Status 'Bar Lamp' > Off Or Status 'Dinette' > Off Or Status 'Fam Wall KPL1-Primary' > Off Or Status 'Fam Fan' > Off Or Status 'Family Room LampLinc' > Off Or Status 'Family Room Lamplinc' > Off Or Status 'Fireplace Spots' > Off Or Status 'Foyer' > Off Or Status 'Kitchen Cans' > Off Then Wait 1 second Set Scene '1st Floor Status On' On Else - No Actions - (To add one, press 'Action') Program 2: Qualified Status Monitor If Status 'Master KPL 1st FL' is Off and ( Status 'Bar Cans' > Off Or Status 'Bar Lamp' > Off Or Status 'Dinette' > Off Or Status 'Fam Wall KPL1-Primary' > Off Or Status 'Fam Fan' > Off Or Status 'Family Room LampLinc' > Off Or Status 'Family Room Lamplinc' > Off Or Status 'Fireplace Spots' > Off Or Status 'Foyer' > Off Or Status 'Kitchen Cans' > Off ) Then Wait 1 second Set Scene '1st Floor Status On' On Else - No Actions - (To add one, press 'Action') Program 1 will execute anytime one of the units in the "or" condition changes state. This can result in multiple "on" commands being sent when the overall condition is already true (unnecessary overhead and powerline traffic). Extend this concept to a "dim" and things get a bit ugly. Program 2 qualifies the "or" and doesn't execute the program if it is already "true" (Master KPL status is already on). That's my limited take on programming and execution flow. Others will have different end goals. Bottom line is we are both still learning (I've had my ISY for roughly 1.5 months). I've gotten a lot of excellent feedback from the ISY guys and forum members by posting code and have changed my programming accordingly. My $0.02, IM

Chris, Thank you. I was looking for a way to qualify a program with a false status on a previously run schedule (trying to avoid conflicts). Your 'Run program (else path)' does the trick. You answered my question before I could post it. Are you becoming clairvoyant as well? IM

sfhutchi, You're exactly correct - the lights do step down while they are dimming. This is intended as a warning to my family members that the "off" program is about to extinguish the lights. If allows then to hit the override button if they wish. This was a "quick and easy" program that works with my entire first floor scene (dimming the On lamp leaves the other Off lamps unaffected). I would have preferred to monitor and flash only the lamps that were activated. Just takes a lot more "individual" programs. I haven't gotten there yet. By the way - Just another Joe and Rand had some very good "enhancements" for trigging the above. The post is located here: Combining Timers and Events IM

Just Another Joe and Rand, Thank you both. Excellent suggestions - I'll be test driving both when time permits (weekends). Rand - I agree completely with your stance on automation working for you rather than the opposite. Alas, I answer to a higher authority. The 11:00 PM activation time is a concession to my family's lifestyle. I'm the one that wakes up at 3:45 for work. I'm in bed long before the "kids" and they have a problem finding the "off" position on the switches. Thanks again guys, IM

Joe and Frank, Thank you for the accolades. This post was born out of my failure in presenting "good code" in my "Combining Timers and Events" post. It still ticks me off that I botched the original post in that thread. I've made it a rule over the years to search for a way to turn a failure into something worthwhile. This was my attempt to do just that. IM

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