Goose66

Precisely. Of course, then you have a conventional wiring scheme, which is the point.

Well, you should be able to do this: If Control 'KPL-B' is switched On And Program 'NightimeWaitFlag' is False Then Run Program 'NightimeWaitFlag' (Then Path) Wait 5 seconds Run Program 'NightimeWaitFlag' (Else Path) Else Set Scene 'NightTimeKitchen' On Set Scene 'NightTimeBedroom' On Run Program 'NightimeWaitFlag' (Else Path) But unfortunately, you can differentiate between conditions, such as the "Control 'KPL-B' is switched On", that you want to trigger the program and conditions, such as "'Program 'NightimeWaitFlag' is False", that you just want to check. This is why you will rarely use the Else branch of a program. So, given this limitation in the ISY, you have to write two programs (three, actually, couting the status program 'NightimeWaitFlag' which has no code or conditions. The first program is: If Control 'KPL-B' is switched On And Program 'NightimeWaitFlag' is False Then Run Program 'NightimeWaitFlag' (Then Path) Wait 5 seconds Run Program 'NightimeWaitFlag' (Else Path) Else - No actions - and the second program is: If Control 'KPL-B' is switched On And Program 'NightimeWaitFlag' is True Then Set Scene 'NightTimeKitchen' On Set Scene 'NightTimeBedroom' On Run Program 'NightimeWaitFlag' (Else Path) Else - No actions - EDIT: Never mind. That won't work, because the minute you set the NightimeWaitFlag program to true (run the Then branch), the first program will re-enter and cancel the Wait. Dammit, the ISY programming model is so frustrating! What should be simple is overly complex, all for the want of a simple flag to indicate trigger conditions versus plain status conditions! But I've been banging this drum for almost a year now, and it is falling on deaf ears, I am afraid.

The question is: what constitutes a switch as far as the inspector is concerned? An Insteon controller that controls a device installed in the ceiling box? Maybe. But seeing how inspection of new construction is done before the final electrical punch, the inspector may never see the insteon switch or the insteon dimmer device installed in the box. She may only see a ceiling box with a circuit running directly to the breaker box with no switch! Is she going to let that pass? In my experience, the answer is no. Moot point anyway for the OP, the electrical is done. I just would not recommend anyone else wiring their house this way for the sake of Insteon control.

As far as code requirements, code consists of some of both. However, it must be wired in a conventional way. For example, where I live, you can't have an unswitched ceiling box, even if you want to put up a fan with a pull chain. Stupid? Yes. But code is crazy like that. It probably has something to do with their measure of habitability of the house. Of course, the inspector may never ensure function of a switch for the ceiling fan, so you just have to wire through a junction box on the wall. That said, I think getting a variance is as easy as explaining the unique requirements of your installation (as long as the physical wiring is to code).

This could have been accomplished even with a convential house wiring scheme. What's more, it would make you house resellable. What you have now is going to cause you problems when you go to sell. I don't know where you are, but down here in the South, your scheme would not have been up to code, and you would have to get a variance of some kind.

Another place where the seperation of trigger conditions and status conditions in the ISY makes a ton of sense!

You may want to try reseating your humidity sensor in the thermostat motherboard connector.

If you don't want this to be circular, then what you want is program folders with conditions: You need four folders, the first with the condition: If Status 'NorthLights' is On And Status 'SouthLights' is Off the second folder with the condition: If Status 'NorthLights' is On And Status 'SouthLights' is On And Status 'EastLights' is On etc. Inside each folder you would have four programs to respond to the Command Fast On for each light and turn on the correct light based on the folder that it is in. However, this is very complex. I know folks want what they want, but what could be the possible use for such a scheme?

Well there are two problems: 1) "Control 'Garage Light' is switched On And Status 'Garage Light' is On" - I assume you are doing this to try to kill the WAIT if the garage light is subsequently turned off manually. However, If the Garage Light is off, and a command to turn the light on is received, the ISY may not have updated the status of the Garage Light yet, so the If statement would resolve to false everytime the Garage Light is off and then switched on. Why not just "Control 'Garage Light' is switched On", and then turn it off after 25 minutes, even if it is already off. If someone turns it back on, then the timer will reset. 2) In the Then section, shouldn't that be "Set 'Garage Light' Off"?

I second the unplug/15 seconds/re-plug. Since my PLM is not on a UPS (for obvious reasons) but the ISY is, I have this problem everytime our power flickers or goes out (we have a lot of thuderstorms and an occasional brown out this time of year). I am having to unplug and re-plug the PLM just about everytime. EDIT: In a few of these situations, the ISY will indicate that communication with the PLM is not possible based on the the lights on the front. But, in most, the only system is 'Communication Failure" pop-up messages that seem to reslove themselves once the PLM is reset.

That is correct . . . I think. If the conditions in the two programs were status conditions, i.e. If Status 'Garage Light' is On, then the programs would run anytime the status of the garage light changed, regardless of how it was controlled. The question is, if I send a direct device On, i.e. Set 'Garage Light' On, will that trigger a program with the condition If Control 'Garage Light' is switched On. I think the answer is no. However, one way to be sure would be to put the Garage Light device in a scene and then turn the Scene on/off in your motion program.

You are right about this not working as a programmer would expect. A programmer would expect to be able to say: Trigger Event: Motion sensor is switched On If Garage Light is Off Then Set Garage Light On Wait 10 Minutes Set Garage Light Off But as you have read, the ISY doesn't work that way. The problem with using folders as you did is that when you turn your garage light on, the folder's condition goes false, and when the program enters the WAIT, it dies because the folder it is contained in is now disabled. Unfortunately, the way to do what you want requires 4 programs. First you need a status program "Garage Light Status" with no conditions or actions. Next, you need a "Garage Light On" program that, upon receiving a command that turns the garage light On, runs the THEN branch of the status program. For example: If 'Keypad - Garage Light' is switched on OR 'Garage Light' is switched on Then Run Program 'Garage Light Status' (THEN branch) Similarly, you need a "Garage Light Off" program that runs the ELSE branch of the status program: If 'Keypad - Garage Light' is switched off OR 'Garage Light' is switched off Then Run Program 'Garage Light Status' (ELSE branch) Note that you cannot use a status condition for these programs, because those programs would then run when the light turned on in your motion program. Finally, modify your motion program to read: If 'Motion sensor' is switched on AND Program 'Garage Light Status' is false Then Set 'Garage Light' on Wait 10 Minutes Set 'Garage Light' off Subsequent motion in the garage will reset the time, as you probably already know. Also, if the garage light is turned on by motion, and then someone turns it on via the KPL button or switch during the 10 minutes, the light will stay on beyond the 10 minutes, because the motion program dies in the Wait.

As to your second question, I use a status program (i.e. a substitute for a boolean variable) that indicates if I am home or away along with a range of time. For instance, I may want to turn my hall lights on from 6:00 PM to midnight, but only if I am at home: If Program 'Vacation State' is False And From Sunset - 30 minutes To 11:59 PM (same day) Then Set Scene 'Main Floor / Hall Lights' On Set Scene 'Main Floor / Foiyer Light 3-way' On Else Set Scene 'Main Floor / Hall Lights' Off Set Scene 'Main Floor / Foiyer Light 3-way' Off Using the range, the program will run at the on time and off time to turn the hall lights on and off. The program will also run when the Vacation State program changes, i.e. when I turn off Vacation State after arriving home (or from my phone on the way there). If the current time is within the range, the lights turn on, and then turn off at the right time. Note the beauty of this is that the Off will happen regardless of whether Vacation State is true or false, so there is no clean-up needed.

Question: Does the execution of the calling program wait for completion of the runned program? Also, this is another opportunity to promote my wish for scripts kicked off by trigger conditions.

I can see why you would not want a device for ControlLinc All-On/All-Off like you have for Button 1, Button 2, etc. However, in the control conditions dropdown, it seems like it would be asy to add a " All Lights" in order to create a "Control - All Lights is switched On" condition to programs. The ISY could just listen for the group 255 for the device.

Any instructions/demos/YouTubes out there for "tuning" an old filter?

I do have filters in place on all UPS. All computers and networking/communicaiton equipment are connected to UPSs and thus behind the filters. Also, my stereo rack is behind a filter. However, these are old filters from the X10 days. I assume they are still useful. I have added a few things, recently. I have DirecTV DECA and DirecTV SWiM both powered from bricks plugged-in in the same closet as the ISY wihtout a filter. Also, the nonshielded cable that runs between the ISY and the PLM could be a problem. While I think it is a serial cable, it is constructed like a CAT5 Ethernet cable. Perhaps making a shielded cable here would help. I also need to completely reset and reconfigure my AccessPoints (4 of them spread about in a 4800 sqft home). Our cleaning service likes to unplug them to plug in the vacuum, and then sometimes only partially plugs it back in. I also wonder about the load that my V2 thermostat adaptors place on the Insteon network. These are relatively new, as well (within the last year).

Adding to the WAIT did not appear to help. However, I also tried putting a REPEAT 3 before the WAIT and the status light off, and that has helped. Again, pointing to unreliable communications. Further, I sat in bed last night with my iPad and MobiLinc and randomly turned lights and scenes on and off at 5 sec intervals for a number of minutes. I had a significant number (like 15%) of commands that did not come through. So I guess I will be troubleshooting communication issues, now. They say the more devices you have, the more stable your network should be. It seems to me that my installation was more stable before adding a lot of extra devices and the ISY. For 2 years I never questioned the stability, and even allowed Insteon (through mControl) to handle the house while on vacation. Now I'm not so confident; its like being back with X10.

If that is the case, then where is the scene for the All-On/All-Off buttons in the ISY? Why do the link tables for the devices and the ControlLincs themselves not show any type of group command, but simply show the direct links between the buttons and the devices? This is not consistent with there being a group command for All-On/All-Off buttons on the ControlLinc. EDIT: Ok, I will have to lookup this group 255. But if that is the case, and there is no scene, then how does the ISY determine which devices are effected. Does it have to scan the database to find every device that is linked to the ControlLinc? Further, I know very well that the program is run multiple times when the ControlLinc All-Off is pressed. I have seen it in action. So how do you explain that if all the device statuses are changed simulataneously from a single command from the ControlLinc?

The lights all respond at the same time, and without fail. But the lights and the All-Lights KPL button are all in the same room. The ISY is in the basement. It is the status of the lights in the ISY that don't seem to update in a simultaneous or predicatable order. Without the WAIT, when you would turn off all lights from the KPL button, the KPL button light would turn-off in response to the button press and then sometimes immediately turn back on, from the program running. It would then turn back off again, or remain lit, on a random basis. This, I surmised, was because the statuses in the ISY all don't turn to off at precisely the same time, and thus the program is run multiple times with the statuses in incosistent state. This was even more pronounced when an All-Off was selected from a ControlLinc in the room, which evidently doesn't use an OFF to a scene but simply sends individualy OFFs to all devices linked to the device. The WAIT 1 seem to fix this problem. I will increase the WAIT tonight and see if that helps.

I will have to chat with the wife about the dimmer thing. I asked her how she turned the lights off and she said she pushed the button, but she may be pressing and holding it until the lights all fade down. I will inquire further. However, I will say that when the condition happens, if I go check the status of the devices in the ISY, they show as OFF, as well as the status of the KPL button. But the light is still on. Again, pointing to comm. issues, but I can't recreate to save my life. Could be coincedence, I guess.

Michel, The WAIT is to "de-bounce" the switch. It seems that the statuses of the devices in a scene as reflected in the ISY change from on to off, for example, in a somewhat random order when you scene OFF is received (from the All-Off KPL button). This was causing the program to be performed multiple times and leaving the light in an incosistent state. By placing the WAIT in program, it will be preempted by the subsequent program runs and the last run of the program should evaluate the conditions in their final state. I left the Admin console running last night and the light worked this morning. Also, my slow fade-up of lights (my alarm clock) worked this morning, it did not work Tuesday. I may have comm. issues on my PLM, but would the Admin console running make a difference in the comm. issues?

I have the following program intended to keep the status light for a KPL button assigned as a controller for an All Lights scene in sync when the lights are turned on or off individually: If Status 'Master Suite / Left Sconce' is not Off Or Status 'Master Suite / Right Sconce' is not Off Or Status 'Master Suite / Fan Light' is not Off Then Wait 1 second Set Scene 'Master Suite / Keypad-All Lights (Status)' On Else Wait 1 second Set Scene 'Master Suite / Keypad-All Lights (Status)' Off The "Master Suite / Keypad-All Lights (Status)" scene is a scene with just the KPL button and is used to turn the status light for the button on and off. Inevitably, when I go to bed at night, my wife has turned off all the lights, but that button is still On. I will turn on a light from the bed, then turn the light back off a few seconds later, but the KPL button remains lit. However, if I get up and go sit at my computer (which is not in the Master Bedroom), start the ISY Admin console, clear the log, and then travel back and forth between the computer and the bedroom to perform tests, checking the status of the lights, the KPL button, and the program periodically, and then review the log, it is all perfect. Everytime it works. Every test combination I can conceive of works. It is almost like this only works if the Admin console is running and I am moving back and forth between the rooms. But the next night, when I go to bed, all the lights will be off, but that damn KPL button will be lit. Can anyone see an obvious flaw in the program that I am just missing?

I submitted the problem through your website, under support, through the "Contact Us" link. I submitted the problem both Sunday night and last night (Tuesday). Also, I did not receive any automated responses, as I have in the past. I guess I should have just emailed support@universal-deivces.com. Good to know about the 24/7 phone line, too. Thanks.

Oops. RTFM, right. Indeed that was the problem. I unplugged the PLM for 15 seconds and plugged it back in (as suggested by the manual) and everything appears to be back to normal. I even backed-up my ISY this time! While a locked-up or bad PLM makes perfect sense for no status/comm. errors, what threw me for a loop was the fact that my programs disappeared. This seems like an odd symptom for a PLM communication problem and was, instead, pointing to a SD card or some other problem in the ISY-99 itself. Oh, well. Thanks a lot for the info!