oberkc

That shouldn't matter, unless you happen to have FKey1 - B and FKey1 - G set to mutually exclusive. Is this possible?

Sounds like you need a PC. Those darn Macs aren't much good for anything! Why do you suspect your logic is no good? Is your program not working? How about the following: if status KPL button is on and From Sunset To 10:00:00PM (same day) Then Set 'one of my lights' On Else Wait 30 minutes (Random) Set 'one of my lights' Off There are several ways to do this. The example above may suffer a shortcoming that you may or may not care about. If you turn the KPL button off with the light on, the program will cease and not turn it off automatically. Try things out. You may find that you have preferences in how you do things. Enjoy!

"Phase Coupler"? Please say which one. If you are using certain X-10 couplers, this may be a problem. The only difference between manually linking the two or three devices and doing it through the ISY, is that the scene created includes the ISY. This may indicate communication problems between one or more devices and the PLM. Do you have your PLM plugged into an outlet or circuit with lots of other stuff, such as computers, power supplies, UPS, surge suppressor, etc... Another possibility....it sounds like you manually created some links already before creating a scene through the ISY. Is this true? If so, I suggest removing them first. Since you are talking only of three devices total, it may be easiest to remove the devices from the ISY, perform a factory reset on all, re-adding them to the ISY, then creating a scene through the ISY. I cannot help but wonder if the existing links are causing a problem.

I don't have access to my ISY, but I recall an option to get caught up on restart. Do you see such an option under admin/configuration/system? I recall that this option must be selected for your schedules to catch up. I think this page is the one that I remember: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Configuration_Tab

It seems to me that the LV lighting systems are part of frequent speculation about causing interference when on. While I don't have a system like yours, I have some LED-based fixtures with power supplies. These required a filter between the switch and fixture to work properly (they turned on reliably, but not off). While you might get by programming these with the pro version, if you are experiencing communication issues, this will manifest itself in ways beyond programming, and it will not be good. Other than programming, is your insteon system working reliably?

That is my guess, but 5 seconds seems to be a pretty short time. How long do you expect your PIR to stay off once motion is detected? If you are unsure, you can watch an event viewer to get a little more insight into the timing of everything. As a possible option, you might try changing 'status' to 'control'

This sure goes beyond the trivial suggestion, given the construct of insteon. Short of additional logic within the ISY to force scene response consistent with local control, I am having trouble visualizing how one would do this. I suspect solutions would also force the user to input much more data (Naming of loads? Device wired to load?) Have you put any thought into how you would display it if you were king for the day?

I must be missing the point here. I am failing to understand what problem you are trying to solve. N-way switches are easily handled in a "logical grouping". It is called a "scene", with all devices defined as controllers. In case you are interested, most three-way switches are "single pole" (they are typically "single pole, double throw"). According to wikipedia, this type of switch may also be known as "single pole changeover". By comparison, a standard switch is a "single pole, single throw". I also found it interesting that three-way switches are known as two-way switches in the UK and Europe (this makes more sense in my mind).

???? Not sure what you mean here. For your programming example, set your KPL button as non-toggle off. Then, write a program such as: if control KPL button is switched off then set 'kitchen' off set ' stair light" to 50% else There are many ways to do this. The above is one example that may give you some ideas.

I don't see this as an ISY issue, but inherent with insteon. Scenes are part of the insteon design. ISY just makes them easier to create. I am not sure that this has ever caused much confusion in my head, but many have accused me of being a little strange in my ways of thinking.

Ah! I missed the non-toggle off setting. Yes, this is likely why it is flashing, then. Though I had not known (or forgotten) about the elimination of the error flashing feature. But, still, I would expect a response from his program and I am still curious about the possibility that the ISY is not getting the command. Looking back, I am wondering also if it is possible that the action in the "then" response is changing and forcing a re-evaluation of the "if" conditions, thus halting further execution of the program. Perhaps this is the reason his program is not working as expected. Given my understanding of this possibility, perhaps removing the 'wait' statements would solve this problem.

This concerns me. While I would prefer the proposed method of Michel, I would have also expected yours to work (or at least do something). The flashing LED makes is, I thought, an indication that the keypad is not seeing some response that it is expecting. Unless this button is in some other scene, then the only response it could be expecting would be from the PLM. I would first open the event viewer. With the viewer open, I would press the KPL button. Does the event viewer show receipt of the command. My concern is that it is not. If not, then it is time to find out why not, and I would do this regardless of the method you ultimately choose for your "ALL OFF" scene.

This is my understanding. Status is shown at the admin panel. Programs (at least the example) "evaluate" upon status change. Whether they run is based on results of the evaluation.

But now you have two programs, one of which is guaranteed to evaluate as "true". Since one of the two programs is always true at each evaluation, where is the savings in internal activity? I don't see where two programs (one always true) is is more effiecient than one program (always true or false). My gut reaction is to suspect the opposite. Now I have two programs undergoing evaulation rather than one.

I use a similar logic to turn a keypad button on if any one (or more) lights are on. I don't use the wait statements. My program works fine and I expect yours will, also.

I use a condition based on time and date: if from 1200AM 1NOV2010 to 1159PM 31MAR2011 then... else.... I don't believe there is a way to do this that is more generic (same date every year, for example).

That is what I was thinking. It looks as if you have confirmed this. Your test program looks exactly like what you need to do with your lights, except without the random parts. I am glad it works for you.

I am not sure I followed. Two program scheme versus same program? When you say it does not work...care to clarify? How are you sure. I enjoy this kind of problem and it helps me better understand the ISY programming. If you care to post your latest program, I would love to see it.

Let us know how it works for you

Make sure you choose the "then" path Front Bedroom Light A If From Sunset - 30 minutes To 9:00:00PM (same day) Then Repeat 4 times Run Program 'Front Bedroom Light B' (then)<<wait 40 minutes<< Else - No Actions - (To add one, press 'Action') I continue to believe it conceivable that the 40 (or some time) delay is advisable, but that it must be in program A (rather than the 25 minute delay in . Otherwise the program "then" path will run 4 consecutive times immediately, with the second, third, and fourth times starting before the first, second, and third occurrences finish. The reason I say this is that I don't believe that the repeat will wait until the end of program B before starting (repeating) again. Given this understanding, I also don't believe the 25 minute wait in program B will have any effect. If it is mandatory lights out at 10:00, you can always modify the programs to look like this, to be sure: Front Bedroom Light A If From Sunset - 30 minutes To 9:00:00PM (same day) Then Repeat 4 times Run Program 'Front Bedroom Light B' (then path) wait 40 minutes Else - Set 'Front Bedroom Light' Off <<

You may have to add some parentheses: If From Sunset To 10:00:00PM (same day) And ( Status 'Outside-Front Door Lights' is Off Or Status 'Outside-West Side Landscape L' is Off Or Status 'Outside-East Side Landscape L' is Off Or Status 'Outside-Balcony Lights' is Off ) Then Set 'Outside-Front Door Lights' On Set 'Outside-Balcony Lights' On Set 'Outside-West Side Landscape L' On Set 'Outside-East Side Landscape L' On Else - No Actions - (To add one, press 'Action') You may also find some reliability benefits in creating a scene with all four lights as responders and turning the scene on rather than turning four lights on individually.

That is not completely accurate. WAIT (or REPEAT) statements don't CAUSE re-evaluation. Rather, I understand it as returning control of the program to the "if" statement SHOULD the IF conditions change. In your case in the second program, your "if" condition would be evaluated at at two times only: sunset and at 9:00pm. (This is what CAUSES the evaluation). If, by chance, the evaluation occurs during a WAIT or REPEAT statement, then the program will be interrupted. This is true except in the cases where your program steps include WAIT or REPEAT. I now understand why your second program has a 40 minute wait period at the end. I suggest a different approach to your programs: Front Bedroom Light A If From Sunset To 9:00:00PM (same day) Then Repeat 4 times Run Program 'Front Bedroom Light B' (then) Wait 40 minutes Else - No Actions - (To add one, press 'Action') Front Bedroom Light B If Then Wait 20 minutes (Random) Set 'Front Bedroom Light' On Wait 20 minutes (Random) Set 'Front Bedroom Light' Off Else - No Actions - (To add one, press 'Action') The performance of your program would be slightly different, but I suspect in acceptable ways. I think, too, that this will lessen the chance that you will find lights on all night.

Yeah, burning the house down would be bad. But if it (your second program, conditions from sunset to 9:00p) evaluates as false during one of your wait statements, you may exerience a case where the lights fail to go off as expected. If your sunsets are as late as ours in the summer months, you could frequently have a condition where your lights are on, your program is the second "wait" period, and 9:00p occurs. At this time, the second program's conditions would trigger an evaluation, which would cease the program execution before the light is turned off. For that matter, it could happen at any time of the year since you repeat the program up to four times. Do you have your second program "disabled"? Anyhow, if you experience this condition (lights remaining on after you expect them to be off), you may want to look at this as a possibility.

jerlands, I have spent little time in Houston, but is it possible that the period of time between sunset and 9:00pm is less than 40 minutes during certain times of the year? If so, is there a risk that your Front Bedroom Light B program may evaluate as false during the second wait period, causing a failure to turn the light off in extreme random cases? Out of curiousity, why did you include "if" conditions as part of the second program?

One other difference that I see between status and control is the that by using status, you are relying on the device (motion sensor in this case) to control the on, off, and time in-between. By using control, you can simply watch for "on" signals and then use the ISY-99 to control the timing and shutoff. I have the same perception as LeeG which is consistent with your assumptions. The status is based on an ISY-99 maintained table of current status (which can be seen at the admin panel, my lighting). If the ISY recieves an on command from a motion sensor, the status will turn to on and remain so until it recieves an off command from that sensor. That is my understanding Yes, also my understanding It can happen, but if so this typcially indicates a communication problem which needs to be solved. It appeared to me that the ISY has a default program which queried the system every night at 0300 (or something like that). Does yours include such a program? All consistent with my understanding. If the ISY misses the transaction, then this would constitute, in my mind, a communication problem, which should be fixed. If the ISY "misses" things, you will not be happy with the performance of you system. But, you are correct. Scenes will continue to work without the ISY. I believe there is a limit to the number of retries. Perhaps three? I found them neither pointless of imprecise.