oberkc

Yes, that it a reasonable understanding by a reasonable person. If I recall correctly, however, the ISY also has a condition "not off". So, you have the ability to have a condition of "on" = 100% and "not off" = 1% - 100%. Pick one that meets your needs.

Perhaps you are correct. I was not at my ISY to confirm. Instead, if you prefer to avoid the folder approach: On Mon, Tue, Wed, Thu, Fri Time is 6:50:00AM AND Time is from 0001 to sunrise+30minutes (same day) It sounds like this is going to get solved.

As I understand "from/to", the program will execute the "then" condition at the from time, and the else condition at the to time. Given this, I don't think you need to use the from/to condition. How to you turn off your scene? Manually? If you are not going to use this program to turn off the scene, then I think you can achieve your stated goals by: if On Mon, Tue, Wed, Thu, Fri Time = 6:50:00AM and Time before sunrise + 30 minutes (same day) Alternatively, you could create a program folder that is active from some early time (say 0300) until sunrise + 30 (same day) and put the following program in it if On Mon, Tue, Wed, Thu, Fri Time = 6:50:00AM I hope I am not missing something.

I agree with apostolakusl....I think we need to make sure we understand when, or if, your various programs trigger. He has in interesting thread on this. Check it out. How is it ever set to true? The only listed examples set it to false, by running the else path. When DO you expect it to get evaluated, if ever? I would expect it to be evaluated every day at 11:18p (since it is partly based on "front final shut down", which is evaluated every day at 11:18p. No, the state TRUE does not change, but it is evaluated). I would expected to get evaluated any time the folder changes state, which I now understand is the result of a switch. Unfortunately, since that same switch disables/enables the folder in which the program resides, I am not sure that this evaluation will happen. This is a least part of the "confusion" mentioned by apostolakisl, I believe. The only action in Re Dim Final (when evaluated true) is to run "front Final Shut Down (then path). Since "Front Final Shut Down" runs on its own at 11:18p, the call out from Re Dim Final appears redundant, at best. When is it that you believe this program (Re Dim Final) will trigger? Have you checked the event viewer to confirm? You state that there are five programs in the ReDim folder. I note only one program highlighted as being in that folder. Are all the other listed progams (Front Final Shut Down, Front 4 level, others not listed) part of this program as well? This may be a timing issue. Unless the folder is true, these progams are disabled. I am unsure about the timing of events, but I assume this condition first makes the folder true. Once the folder is true, the event has already passed and will never force an evaluation of the conditions of the programs residing in it. This is how I see it. The problem that I see is that running the front final shut down makes the parent folder false, which suspends any further activity of programs within. As such, it will never continue past the first then line of your "Re dim Final" program. Perhaps that is the heart of the issue. I think I may be repeating myself, but this may be what is happening. I cannot help but suspect that there is an easier way to do this, but the relationship between your alarm system and other programs is still one that I don't understand.

No you don't have to buy the module. I did, however, and like the ability to stay organized. You can give names to X-10 codes, and they show up in your 'my lighting' tree. I no longer need to keep track of these on a spreadsheet.

It is not required.

Wow. You spin a complicated web. I am not sure that I am able to sort through what you have, and I still think there may be something missing. I will offer some thoughts and, with luck, this may help. Regaring your "Re Dim Folder", the condition of this folder is based upon the condition of a program "redimswitch". I don't see this program anywhere. What is in it? When is it true? When is it false? Regarding program "Re Dim Final", there is a condition, "if folder 'Re Dim' is True'. Since this program already resides in the folder, it won't run unless the folder is true by definition. I conclude that the stated program condition is redundant. Why is it there? Is it your intention that the change in status of this folder trigger the program to run? In this same program, your second condition is that "Front Final Shut Down" is true. As I understand conditions, this program will ALWAYS be true. This program will be evaluated at 11:18pm and show true. It will remain true until it is evaluated again. It will be evaluated again in 24 hours, at which point, it will still be true, etc.. Without knowing the conditions defining the status of the folder, itself, I am not sure when to expect this program to run. It may never run. In this same program you run "front final shut down" then path. This appears to have the potential to run twice, simultaneously, at 11:18pm (since the next program will trigger the then path at 11:18p). I am not sure about the consequences of trying to run the same program twice, but I am not sure why one would want to. I see nothing in the remaining two programs which, by themselves, cause a problem. I noticed that you moved a line in a program because it never executed. Is it possible that this whole program never executed? Why would the first line execute and not the second? Again, is it possible that your conditions are never evaluated as true? It is possible that you have commands running in the ReDimSwitch" or "Front 3 Level" programs that are causing loops, but they are not listed so I cannot offer any comment. Sorry I cannot offer more. If you care to post the contents in the other programs, I may be able to see something.

It seems to me that if you have a program "front 1 level" that has conditions in which it can be true or false, the then path will run any time it becomes true. The set of code you quote would run the same set of commands again, so long as the both conditions are true. Yes, it seems like a potential for a loop to me. Before reaching any conclusions, however, I would like to see your entire front 1 program and the conditions of your dim folder. Is is possible that your front 1 program, itelf creates a loop of some type? Does the actions in the program cause the conditions to be re-evaluated?

Not true, as I understand your question. While it is true that you cannot incorporate X-10 addresses into scenes, you can set up a program to turn scenes on and off, etc. A typical program may look something like: if x-10 A6 is turned on then set scene "bedroom" on You could create a scene to include all your lights, then a program if x-10 a6 is turned off then turn scene "all lights" off

One additional thought...even if your remote does not have built-in X-10 codes, perhaps your URC is a learning remote and you have an old x-10 ir transmitter of some type? Program codes through the learning process.

I use a URC remote, RF-20. It has a built-in library of X-10 commands, house code A, number 1-10, on, off, dim, bright, etc... I think it highly likely that your URC has such a library. If not, you may be limited to the insteon version of the IR reciever. Assuming you have the built-in library, use the remote to send an X-10 code into your system. Use an ISY program to trigger the actions you desire, triggered by the X-10 code.

Smarthome makes a plug-in IR reciever. I use an X-10 one. Both convert IR to powerline signals and could be used to trigger programs. If you choose the insteon one, I assume you could even incorporate it into scenes.

I think this is exactly the suggestion/question. I think he is questioning the value in halting a running program as a result of changing input conditions.

Don't forget that forums are public and that allows many of us like to learn from the interraction of others. I have not considered this pointless. Perhaps, too, on occasion, another can jump in and try to help. I thought it did give such an example: Reciept of a new motion trigger stops the ongoing wait and starts it fresh again. This allows one to create a program where one can have the lights go off after the LAST detected motion, rather than after the FIRST detected motion. Perhaps I misunderstood. Better, of course, is in the eye of the beholder. I prefer the greater amount of flexibility, even if it adds a layer of apparent complication. There is nothing wrong with honest differences of opinion. Keep asking questions. We all get smarter as a result.

The program condition would be evaulated any time one of the conditions (status being one type of condition) changes. In your example, if it changes to a condition other than 43%, then the condition would be false. If a wait command was originally executing as a result of a true condition (then path), then the wait would halt as a result of the condition becoming false (which would trigger the else path). There are lots of triggers, or conditions. Besides "on" and "off", there are "not on", "not off", "XX%" Status is one of several conditions, including time, and control. I have never been much good at finding things in the wiki, so I cannot help you there. I have found, however, that the logic employed here to be consistent with my understanding of "if, then, else" construct and boolean logic. The most difficulty I have had with the programming is understanding the difference between the conditions of "status" and "contol".

There are posts about these types of conditions...boundary conditions were they called? There are lots of nice ways around them. My approaches tend to be brute force... I just add another program to turn all lights off at a certain time in the morning. That way, if any were inadvertently left on, or failed to turn off, or whatever, this assures that they won't be on for days at a time.

That is a surprise to me, also. I will re-read the post, but where did you get this idea? I understood that program conditions are only evaluated when one or more of the conditions change.

I updated to 2.7.7 to purchase the X-10 module. I have had no problems. It seems 2.7.13 is pretty good. While I have yet to update, I'll bet you would see no problems with this, either.

There is also an 8-button configuration that you may prefer. Yes, you could program these as you suggest.

You may want to go re-read some of the early posts. It appears that there has been some attempt to answer this question, before we all hijacked the discussion.

Your solution is one of the more efficient options that I mentioned, but was too lazy to figure out. Nice job. Exactly. And if you turned on the scene, they would both go on.

Are these dozen switches not installed? Did someone else install them? The new one would be installed like the others. Any (there may be an exception) insteon switch requires a line, neutral, and ground. If you intend to control a load with this switch, then you need access to the load's line and neutral connections. Pick a switch that suits your tastes. As suggested, you may consider a keypad. This would allow you to control up to eights scenes. Any insteon switch can act as a "master", including any of the twelve that you already have. All insteon switches have the ability to control a load. If controlling a load is not needed, cap it off as already suggested. Communication between devices is over the powerlines (some exceptions). You may need access points or some way to communicate between various phases of your electrical system.

I understand multi-linking mode to simply be the ability to set one device (the controller) into linking mode, then linking more than one device as a responder, without having to put the first device back into linking mode between each responder. I do not understand it to have the capability to separate on and off control.

There is no doubt that one can set up an insteon switch to control other insteon switches without having an ISY. Your ideal scenerio was a bit more complicated than this, however. Your "ideal" scenerio would be to turn on 3 other devices from a single switch, but only turn off 2 of the 3 original devices. It is that particular scenario that I would have trouble doing without an ISY. If all you want to do is use a single switch to control (both on and off) 3 other switches, that is easy. Set all in a scene with the singles switch as the controller. This would be done the old-fashioned way of putting one device into linking mode, then linking other devices to it.

Does this mean that you have a program running continuously, until you stop it? Or is it that you want a programs "then" condition to run when you press the KPL buttons on, and a programs "else" condition to run when you press the KPL buttons off? I am assuming the latter. First, I suggest putting both KPL buttons into a scene, with both defined as controllers. The buttons also need to be in toggle mode, which is the default setting. This will keep the KPL buttons synced. Second, set up a program without "if" conditions, having only the desired "then" (turn lights on, for example) and "else" (turn lights off, for example) actions. Set up a second program. This program would look something like: if control KPL1 button X is switched on or control KPL2 button X is switched on then run first program then condition Set up a third program, similar to the second: if control KPL1 button X is switched off or control KPL2 button X is switched off then run first program else condition I suspect there are more efficient ways of doing this, but my brain is being lazy today.