oberkc

I don't have access right now, but I recall it being under the "time" option. I think one can check days of weeks, all days of the week, or there is an option for date. Hopefully, someone can confirm. Perhaps the wiki can help: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Schedule

I actually do it slightly different than this. Rather than a manual enabling or disabling of programs at a specific point in time, I still use folders and conditions for my seasonal programs. However, I use the built-in date function of the ISY (which, unfortunatly, must include a year). My conditions are: from time = 00:01 on 1 march 2012 until time = 11:59 on 30 September 2012 then run the programs in this folder While I have not done this, one could even use something like: from time = 00:01 on 1 march 2012 until time = 11:59 on 30 September 2012 or from time = 00:01 on 1 march 2013 until time = 11:59 on 30 September 2013 or.... then run the programs in this folder The value in taking this approach is that there is much greater flexibility in the timing of my annual folder condition update

I have yet to take advantage of variables, either. At this point, the posted example is the only use of variables that I can currently think of that solves a problem that I cannot (and have not) otherwised solved with an approach that does not include variables. In this case, I have simply decided that it is easier to simply go into the admin panel once a year and update the non-variable program. After all, it is not as if I don't periodically open the admin console for other reasons.

You should check out the wiki. One of the regular posters wrote an article about the use of variable to create a yearless date function. My guess is that it will address your concern: http://www.universal-devices.com/mwiki/ ... _Variables

I have been having morninglinc issues as well. While I don't believe it is related to this problem, I offer it up as a data point... After my first morninglinc failed, smarthome replaced it with a second. It failed to work out of the box. It would not even pair with the lock. An interesting tidbit: Tech support folks likened the relationship between the morninglinc and lock as like that of a keyfob and lock. The lock views the morninglinc as, simply, another keyfob. It is not the same as an insteon scene.

I have been having morninglinc issues as well. While I don't believe it is related to this problem, I offer it up as a data point... After my first morninglinc failed, smarthome replaced it with a second. It failed to work out of the box. It would not even pair with the lock. An interesting tidbit: Tech support folks likened the relationship between the morninglinc and lock as like that of a keyfob and lock. The lock views the morninglinc as, simply, another keyfob. It is not the same as an insteon scene.

None of which I am aware. However, I have not felt a strong need to access the Admin console via iPad, so I have not investigated this beyond cursory looks.

by "program", do you refer to managing your scenes, or controlling your scenes?

No. They would stay in their current status. I am not sure that I fully understand your requirements, but what about removing the else path, then creating a second program: if time is 1130 then set scene "lights" off else

The first question you are going to have to answer is how is the ISY-99 going to know that you are in bed? Certain time? A keypad button used as a status? Motion sensors in the bedroom? I suppose a variable would work here, if you are really into such things. Otherwise, how about "this program": if control "kitchen light switch" is switched off then wait 15 minutes run this program (if path) <<else This program would be triggered any time the kitchen light switch is turned off, which would execute the "then" path (program status = true). After 15 minutes, this program would be triggered again, at which point it would execute the "else" path (program status = false). In other words, this program would be "true" for 15 minutes any time someone turns the kitchen light off. Then, update your existing program, using "this program" as a status condition: If Control 'Motion Sensor-Sensor' is switched On And Status 'Kitchen' is Off And status program "this program" is false <<<< Then Set 'Kitchen' On Else - No Actions - (To add one, press 'Action') Please keep in mind that the programming language is approximate.

I don't currently use variables, but undertand the state variable is analogous to the "IF-status" construct as a trigger mechanism.

Perhaps your's is a more accurate understanding.

Yes, it makes sense. Unfortunately, the devil is in the details. I agree with the approach advocated by Apostolakisl, but this does not send multiple OFF commands, as reqested earlier. In general, you can create a scene with which turning the scene on can command some devices to go off, but you cannot create a scene where turning the scene off can command some devices to come on. You can create a single scene with multiple controllers, and where scene response varies depending on which of the controllers is used. You can create muliple scenes with some devices being in more than one scene as responders. A given device, however, can be CONTROLLER of only one scene. If you desire a delayed response to a command, or to send multiple commands, you would require a program. You have several viable approaches here. I would use a scene-based approach if possible (tends to respond quicker and continues to work if ISY fails). If you are driven to a program based on a need for special capabilities, then that is the path you must take. Some of your decision will be based on what your controlling devices are and where they are located. How many devices do you want controlled by each controller and what response do you desire from each. Based on the devices you have mentioned so far, you can certainly create a scene that has the "on button" as controller, with the following devices/on levels/ramp rates as responder: cove lighting/0/2 minutes recessed lighting/0/2 minutes fireplace/0/2 minutes bedroom light/on/1 second These are only suggested levels and rates. You would adjust based on your own needs.

I don't use mobilinc, but assume that it can control scenes. Therefore, I don't thing this would drive the need for a program. However: I believe this requirement points towards a program. "Multiple OFF" commands would require a program (and I am curious as to why you desire this? Are you having reliability problems?) Sending "on" commands in response to a scene "off" command would also require a program.

I agree with LeeG assessment regarding the consequences of closing the garage door prior to you five-minute period. Have you considered trying "control" versus "status" for your garage door sensor? Your question with regards to running only the "if" clause is also a good one. Besides these two issues, I liked the approach you took with the programs. Keep your first program unchanged. For the second, try: If From Sunset + 20 minutes To Sunrise + 20 minutes (next day) And ( Control 'Garage / Main Garage Door Sensor' is turned On << Or Control 'Garage / Small Garage Door Sensor' is turned On << ) Then Set 'Front Yard / Front Coach Lights' On Wait 5 minutes Run Program 'Coach Lights Night' (If) << Else Set 'Front Yard / Front Coach Lights' Off << The reason I suggest the last line is to guard against the possibility if you open the garage door less than five minutes prior to "sunrise + 20". Without this last line, if the garage door would open within that five minute period, the wait would be interrupted at sunrise+20 when the program triggers an evaluation (now false) and the light would have remained on all day.

Unfortunately, my morninglinc failed and a replacement has yet to arrive, so my ISY does not currently have one. I am going by memory. When you added the morninglinc to the ISY, did you not get two devices: "on" and "off"? I thought both of these needed to be added as responder devices.

What are the responder devices in this scene?

Have you checked out the wiki? The user manual? These are great places to start. First steps would be to add all your devices to the ISY. There is a little symbol near the top that initiates the "start linking" process. Press it, putting the ISY into linking mode. Once there, go through your house and put your other devices into linking mode (usually press and hold "on" for a few seconds until it beeps). When done, you should see the devices listed in your ISY admin panel, under my lighting. Once added, you create a scene (another button along the top). Create a scene, giving it a descriptive name. Drag various devices into the scene, making them controller if you want them to control the scene, or responder if you want them only to respond to a controller. This is how one sets up links through the ISY. To use the ISY effectively, this is how you must create links, or relationships, between devices. The process described in the various device manual for creating scenes no longer applies.

And you have confirmed that "house black" is unswitched power...not controlled by a switch somewhere or by another motion sensor? That is what it sounds like to me. Sounds like it will work. May or may not cause damage to inlinelinc or motion sensor, or both. Regarding the inlinelinc, I don't believe this is consistent with the directions and you may be risking a warranty issue. But they are your devices....have at it. If your question is still "what is the best way to do it" my answer is still "inlinelinc with sense".

!!!??? So the second light you supplied unswitched (direct line) power to the motion sensor only, feeding the switched power directly to the light. Did you not install the inlinelinc? I believe to incorporate insteon control of a fixture AND maintain motion control of that fixture, you will need in inlinelinc WITH sense. Given your inlinelincs, black wire connected to unswitched power, red to load, white to neutral. I don't believe there are provisions for a motion sensor.

I don't worry about relay status in the ISY. It has no impact on operation, in my mind. I understand the relay is a responder-only device, lacking the capability to broadcast status. Given this the ISY will display the status last known, which was usually that which was transmitted by the ISY or as part of a scene. It may, or may not, reflect actual status.

Teken...based on the original post, I understand the buzzing was from the "ISY component" (later explained as the blue ISY box). I have no explanation why the ISY, itself, would buzz. I still think your keypad button was originally configured in non-toggle-off mode. Is your sensor is controller of a scene, with the keypad button as responder? Is your keypad button controller of a second scene with relay as responder? Can you confirm momentary A mode for your relay? If answers to all these questions are yes, put your keypad button in non-toggle-off. I don't believe this is a wiring problem.

Is it possible that the KPL was originally configured to be in a non-toggle mode? What mode (latching, momentary A/B/C) is your IOLinc set? What is an ISY component?

I have experienced nothing with the ISY which would explain why latency would be inherently longer with on than with off. Communication issues can sometimes delay response, but I assume that is not the case here, since the communication environment is consistent. My question is how do you determine latency? What device is providing door status? Is it possible that your sense of door "open" is different than that of the door sensor? If you have a laptop or tablet, have you experimented with door position to determine when your sensor sends "on" and "off" signals?

It makes sense, but was not the intent of my question. I was wondering if the physical device that controls your porch lights are insteon-capable, or x-10 only. If they are insteon, then I suggest using insteon commands, rather than x-10, to control your porch lights.