oberkc

For most systems, you need at least two dual-band devices, one on each leg of your electrical system. If you are sure that all of your insteon devices are on the same leg, then you may be able to forgo this, but if not, then best be safe. Your impressions are correct. Yes. Do you not have two dual-band devices? Yes, your dual-band PLM is one. You need two, on opposite legs, to provide a communication path between legs of your electrical system. If you don't have two properly installed dual-band devices, my suggestion is to purchase a single access point and install it in an outlet on the opposite leg of your PLM. Given this news about your possible lack of enough dual-band devices, the extension cord test may be inconclusive. If you had two dual band devices, the extension cord test would have confirmed the suspected communication problems on your computer circuit. A filter for your computer equipment would be the remedy. Filters are not terribly expensive. Perhaps it would be good insurance simply to purchase one regardless.

Try out LeeGs extension cord test first, to confirm this is the problem. Be sure to plug it into an outlet on a different circuit than your computer. It probably does not hurt to ask whether you have the two legs of your electrical system coupled with any dual-band insteon devices or access points or signalincs? It could simply be that your PLM is on a different leg of your electrical system than is your PLM.

With regards to your 'cloudy days B' program, it will trigger an evaluation at: sunrise + 1 hour, sunset - 1 hour 15 minute, and ANY change in status of the motion sensor. If this program triggers an evaluation which results of "true", then it will run the "then" path. But you know all this. Additionally, if the program is re-triggered during the 25 minute wait (by a change in motion sensor status, for example), the execution will halt and restart the "then" or "else" path, based upon the results of the new evaluation. In other words, if the 25 minute period was counting down, and the motion sensor status changed to "on" during the wait period, current execution would halt and the "else' path would execute. Nothing further would happen (empty else path). Therefore, I don't believe you need a separate check of the motion sensor status. I do notice a couple of things hower. First, I find it unusual that you would limit the response of lights to daylight hours (from sunrise to sunset). Normally, lights are more needed during nightime hours (sunset to sunrise (next day)). Second, your "B" program will fail you if the lights are on and it is triggered less than 25 minutes before 'sunset-1h15m'. If this were to ever happen your lights would remain on all night. There are several ways to avoid this. The simplest, in your case, may be to add a third program to turn the lights off at Sunset - 1 hour and 15 minutes, as a backup.

The difference between the two situations is communication with the PLM. Where is it plugged in? In a surge suppressor or UPS? Next to one or both? Along with lots of other computer stuff? For the ISY to be at its most effective, you need to create links using the ISY. If you are having problems with this, my suggestion is to identify and solve that problem.

LeeG, Are there any (older) versions of dimmers that require a power cylce to accept new scene setting such as this?

Scene settings can be different based on the controller that initiates an action. In the "my lighting" tree, when you select a "scene" and view the settings for each of the responder devices, you will see the response based on the ISY/PLM being the controller. In this case, I expect to find the family romm ceiling set at 58%. Under the scene, if you now select button G, I suspect you will see a different set of responses, to be achieve when the scene is controlled by button G (as opposed to controlled by the ISY/PLM). I expect to find a 30% setting for your ceiling lights. Change this to 58% if this is the response you want when pressing button G. This is because moblinc is activating the scene based on the ISY/PLM being the controller.

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".