IndyMike

Hello again Chuck, Your code below is changing the status of your condition 'Living Room - ALL OFF' is not Off. When this is executed the program status be changed to "false" and the statements that follow will not be executed. The fact that you require the status check may indicate that you're having communication problems with your device. Executing the scene "All off LED" off should work by itself. You may want to focus your efforts on improving the device communication rather than "re-querying" the device. If you feel you need to check the status of the lamp, you should divide things up into two programs to prevent changing the state of your conditions within the program: If ( Status 'Basement Playroom Lights (loa' is not Off Or Status 'Dining Room - LIGHT (load)' is not Off Or Status 'Dining Room Ceiling Fan (load' is not Off Or Status 'Kitchen Ceiling Lights (load)' is not Off Or Status 'Kitchen Sink Light (load)' is not Off Or Status 'Living Room Ceiling (load)' is not Off Or Status 'Living Room Lamp (load)' is not Off Or Status 'Office Ceiling Light (load)' is not Off ) And Status 'Living Room - ALL OFF' is not Off Then Wait 2 seconds Run Program 'ALL OFF LED - Off (Daytime)' Else - No Actions - (To add one, press 'Action') Program 2 sets the scene OFF and tests the status. If the status comes back "ON" I would assume that the ISY would treat this as an "event" and Program 1 would again become true (triggered by the event "Status 'Living Room - ALL OFF' is not Off"). I haven't tried triggering programs with status calls. Hopefully someone else can confirm if they function in this manner. If No conditions Then Set Scene 'ALL OFF LED' Off Wait 10 seconds Set Scene 'ALL OFF LED' Query (if the light is on, the ISY will hopefully see this as an event and call the original program) Else No actions Be careful with this code - If you cannot turn the indicator lamp off for some reason, you may wind up stuck in a loop (querying and re-triggering the original program). IM

Chuck and Darrel, Sorry for the misinformation. Obviously (hindsight) the below is incorrect - you can turn an Insteon device off if it is already in the off state. I honestly never considered this before. I guess my "old school" brain isn't wired that way. Also seems that I may have some holes to plug in my programming... IM

Hello Chuck, From what I can see, your Status and Control statements below can't be satisfied with the same event. The light can't be off and switched off at the same time. I tried the below code with varying ramp rates to try to ensure that there wasn't some trick involved - could not get it to execute. The below will function with an "or" between the status and control. You mentioned that this worked at one time - I honestly can't see how. Is it possible that you modified the program and didn't save it? Be advised that beta 2.6.1 did not save programs with it's "backup feature. Programs could only be saved with an explicit export. IM

Michael, I re-read your original post again. I sounds as if the PLM can't "hear" the switch unless it's at a level somewhere above 40%. Does the switch respond to the ISY/PLM when it's off (turn on from a off condition)? I'm beginning to wonder if you have a problem with your neutral connection to the switch. If this switch works in another location, you may want to start checking connections along the circuit (other boxes in the chain).

mcrean, I'm not sure if this is a typo but, your original post specified a local on level of 40%. Your program specifies 43% - if this is correct you won't get a trigger. Other than that this program should function properly (just tested it). I looked over your second program as well. I don't see any obvious error's. I'm assuming that these both worked at one time. If that's the case, and you're still running V2.6 or 2.6.1, you may have been bit by the Feb 29th bug. These versions have a calender problem with the 29th and caused problems with timed schedules. Check the status of your "scheduled folders". If they are "false" when they should obviously be "true" you have two options: 1)Upgrade to beta 2.6.2 (problem corrected). 2)Manually update your date on the ISY and reboot.

jgraziano, What version are you running? From reports that I've seen, the Feb 29th schedule issue was corrected in ver 2.6.2. I ran into a similar problem yesterday using Ver 2.6.1. I changed the date to March 1 and reset the ISY. Everything checked normal after that. If you are running 2.6.1 or previous you may need to "reboot" your ISY to terminate any schedules that are still running from the 29th. IM What's going on here???? Thx.

Clark, Sorry we took this thread a bit sideways (that's my/our nature). I'm glad that you were able to pick out the pertinent details. You're correct that, in some instances, the ISY documentation hasn't progressed. This is due to the fact that the ISY people have been following this forum and implementing changes at a incredible pace (documentation hasn't kept up). Once we users stop throwing requests at Michel and Chris I expect a new documentation package will be released (they really have been extremely attendant to our requests). In the mean time, MarkSanctuary has been doing a wonderful job of including things in the Wiki. IM

Dave, I experimented with something similar using two programs to detect the "control" of the kitchen light. Activating one program would turn the other off. Unfortunately, I realized that this would not work if the light was activated by a scene (I use a lot of them - I understand that you do not). If Control 'Bar Lamp KPL2-Primary' is switched On Then Run Program 'Bar Control Off' (Else Path) Else - No Actions - (To add one, press 'Action') If Control 'Bar Lamp KPL2-Primary' is switched Off Then Run Program 'Bar Control On' (Else Path) Else - No Actions - (To add one, press 'Action') You setup is obviously simpler (and interesting). My question is (I haven't tested), does the " Or Control 'Kitchen Light' is not switched Off" set the program status to "false"? Sorry, it's Sunday and I'm feeling a bit lazy - actually working on my projection TV and doing a brake job in parallel... IM

Clark, As d_l stated, if you do not run the "else path" the program status will remain "true" in the program summary table. Since I sometimes use the status of one program to qualify another ( if program 1 true, then run program 2) it's become habit to run the else path to ensure a "false" status. IM

Upstate, That's great news. I was beginning to get concerned - the symptoms resembled some of the X10 problems of bygone years. I suppose I should dig out my PLC and powerhome to make sure that I don't have any "old" links running around in my devices. Most of my installs were performed with the "replace all existing links", but I can't be 100% sure. Thanks for having the patience to see this one through. It was a rather long and winding road. This should be a great help to the rest of the forum for "future" phantom problems (I've bookmarked this thread). IM

Paul, Answers/clarifications below - You may want to post in the Linux thread. Maybe LinuxGuy has experience. Sorry, I wasn't very clear on a number of items: 1) All of my interfaces include the "last entered" unit code along with the Allon/Alloff command. To activate the ISY you need the "-" unitcode (as you surmised). 2) I am currently running Version 2.6.1 (2.7 beta). It's entirely possible that the "-" unit code wasn't available in 2.6 (full release). Email the ISY guys and they'll give you a link (they're great about this). The ISY linking is a snap once you've gotten accustomed to it. My preferred method is to "remove all existing links" (option 1) so that the ISY has knowledge of all links in the system. 1) Place the ISY into Linking mode (option 1 remove all links) 2) Tap link your individual devices - Place them in linking mode by holding on for 10 sec's (or per instructions for lamplincs - etc). 3) Hit cancel in the ISY - It will link all of your "tap linked" devices" Absolutely correct - this become far more dangerous if you happen to choose the incorrect "neutral" connection. If this happens, there is the possibility of developing 220V across your switch. There's a long thread over at techmall dealing with this. If you're interested, I'll try to forward it (initiated by Yardman). Sorry this is again a bit brief - I'm elbows deep into a big screen TV and have an hour before game time. IM

Paul, Welcome to the ISY. Like you I'm a long time X10 user transitioning to Insteon. I had used the Insteon devices for 2 years waiting for a credible stand alone controller to be developed - the ISY has fit the billing. Once you get beyond the (short) learning curve, I believe you'll be elated. I can't help much with the linux questions. I have a linux server, but chose to administer the ISY through my windows machines. There is one linux tread located here : http://www.forum.universal-devices.com/viewtopic.php?t=225 In regard to the X10 command troubleshooting - there are debug commands that can be accessed. The wiki describes how to enter debug mode 1 through telnet. X10 receipts can then be monitored through the Java console (I find firefox to be a convenient browser interface). The Wiki instructions are located here : http://www.universal-devices.com/mwiki/index.php?title=ISY-26_Insteon:X10_Troubleshooting I just tried an X10 All-on trigger with three different devices (controlinc Maxi, X10 remote/RR501, CM15a) - these do work. The issue may be related to the trigger itself. The ISY is very literal - what you see is what you get. The X10 protocol embeds a unit code (the last accessed) within the allon/alloff commands as shown below. Java Console Monitor (DBG=1) 2008/02/16 16:40:34 : [ X10] hc=A uc=1 2008/02/16 16:40:36 : [ X10] hc=A uc=1 cc=5 {all on} 2008/02/16 16:40:37 : [ X10] hc=A uc=1 cc=13 {all off} 2008/02/16 16:40:39 : [ X10] hc=A uc=5 2008/02/16 16:40:41 : [ X10] hc=A uc=5 cc=5 {all on} 2008/02/16 16:40:43 : [ X10] hc=A uc=5 cc=13 {all off} Trigger If X10 'A/All Lights On (5)' is Received Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') Note that in the above the trigger is for "A" (no unit code). In order to select this you need to choose the unit code "-" from the drop down menu. If this doesn't work for your X10 device, please post the Java Console reception for your X10 Allon command. IM

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