oberkc

Except, I fear, that the first example may fail for the same reasons as did yours...that when the program first executes the "then" path, forces another evaluation of the conditions at the 1 second point. When this happens, the 5-second timer stops, and the condition evaluates as false.

I will let you judge whether this is overly complex. Conceptually, it sounds as if devonsprings wishes to have a window of time from 1 to 5 seconds after pressing a keypad button. Within that window, if another button "nightimemode" is pressed, the whole house goes into nightime scene. For the time window, I would use a folder. I would create a flag program to use as the folder condition. For the wholehouse lighting, I would create a nightime scene. Nightime folder condition: if program "flag" is true then run the programs in this folder Flag program: if then else Opens the folder time window (outside of folder): if control "KPL-B" is switched on then wait 1 second set program "flag" as true wait 4 seconds set program "flag" as false else Look see if nightimebutton is pressed (put IN folder): If Status KPL-B is on and control nightimebutton is set on then set scene "nightime scene" else Hopefully, this is clear and can be tailored to fit existing device and scene names.

I, too, was under the impression that DevonSprings scenario did NOT necessarily pass wires through the switch box. I thought power to the lighting fixtures were direct.

That is my understanding. Still, if you are going to delete the devices and add them, I suggest performing a factory reset, just to be sure.

I believe this is true in our area, as well. I am not sure that the proposed system fails this requirement, however. I have a switch at the wall near the entry. I have a light in the ceiling (controlled by the inlinelinc). The switch controls the light. What part is he not passing?

I found the instructions to be ambiguous, or inconsistent, or both. I don't think I followed them exactly, either. Nor do I think the IOlinc cares whether "on" is open or closed, so I do not suspect this to be your problem. "Manually" linked it? With what other insteon device? Did you not use the ISY-99 to establish your links (or scenes)?

I think the OP knows this to be true, but is making the point that the wiring is simplified using his approach (which is true). Taken to the extreme, one could even wire in such a way as to maximize communication reliability. Cleary, there are potential advantages (along with the potential disadvantages) to wiring this way. I must admit to wondering about the code implications. I was not sure whether code required certain wiring techniques, or simply the ability to control lights at certain locations. I thought it was the latter.

I can only assume that the percieved state of your sensro was initially incorrect and that the query corrected this. I understand that the state of the ISY is based on acknowledgement from devices or reciept of state changes from devices. It can get out of sync if it fails to communicate with those devices, however. Failure to communicate is not generally a problem with the ISY, per se, but due to noise or interference of some type on the powerlines. If there are communication problems, the ISY will assume a state for each device based on latest commands. This assumed state can be incorrect. Do you ever notice any failure of a device to respond to commands? How reliable do you perceive your insteon system?

In math, multiplication and division happen ahead of addition and subtraction. One can add parentheses to dictate which operations happen first. The same is true with logic. I understand that the ISY-99 follows the standard boolean logic prioritization. Like multiplication over addition, "Ands" happen ahead of "Ors". Like with math, the ISY also provides the ability to group operations with parentheses, forcing the operations within the parentheses to be evaluated as a group. For example, "A and B or C" is naturally evaluated "(A and or C". However, one could add one's own parentheses and force this to be "A and (B or C)". These two statements have different outputs (true or false) with varying inputs (A, B, or C).

Buttons are easily replaceable. You could even choose one of your two. For example, away. On means away. Off means not away. If you choose to keep both, consider the possibilities if both are on (or both are off). Can this happen? Does this have any adverse consequences on your programs or folders? If you have not already, consider making these to "Mutually Exclusive".

Do you have these two buttons assigned as "mutually exclusive" (where when one is on the other must be off)? Why not have a single button, where on is home and off is away? The condition evaluates at sunset and sunrise. At sunset, the condition evaluates as "true" and causes the "then" condition to execute (turning the scene on). At sunrise, the condition evaluates as false and causes the "else condition to execute (turning the scene off). Regarding the wiki, I performed a search on "program folder" and found: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Folder_Conditions There may be more.

I don't understand what you mean when you say you have the "Home button programmed fine". Is it part of a scene? Do you already have a program using the home button as a condition? It sounds to me as if my communication skills are not up to the task here. Either I am not understanding your problem or am not communicating my proposed solution. Perhaps others can chime in here? Perhaps a general example can help: create an away program folder with conditions: if status of "away button" is on then run programs in this folder In this folder, add a programs, such as if time is from sunset to sunrise (next day) then set scene "away" on else set scene "away" off Create a second foler with conditions: if status of "away" is off then run programs in this folder In this folder add a program such as if time is from sunset to sunrise (next day) then set scene "home" on else set scene "home" off Keep in mind these code lines are from my mind and may not exactly match the words used by ISY, or the names of the devices or scenes you have. There are also lots of considerations. Do you want ALL interior lights to go off at sunrise? Are there certain lights or devices that come on regardless of whether you are home or away? There are likely some program tweaks that will be necessary here. I intend this only as a general suggestion.

"second"? Have you already created the first folder? A quick check of the wiki shows some explanation about program folders. Be aware, these are a relatively new addition to the software. They are not available on older builds. Of course, you can update yours, if you haven't already. It is possible that I am failing to understand your intenentions here, but I am assuming you want to have a keypad button to designate home or away status. Keypad button will be on for home and off for away, or vice versa. I further assume that you have, or can create, a set of programs. Some you want to run when home. Others are to run when you are away. My suggestion is to create two program FOLDERS. Each folder will include the programs you want to run when the folder condition is true. One folder would contain programs that you want to run when home, the other to contain the programs you want to run when you are away. The folder condition would be your keypad status: on (or off) for home, off (or on) for away.

Since you were doing this from the start of construction, did you consider adding cat-5 wiring to your boxes and using one of the hard-wired control systems rather than relying on powerline for your control signals? What thoughts did you have that made you choose the powerline control? Have you had any device failures? Do you keep spare devices so that you can rapidly repair any failures? I really like your approach in that it allows extremely easy reconfiguration of you house lighing system.

I apologize for being unclear. My suggestion is to create two program FOLDERS (are you familiar with these?). Program folders include programs. Program folders include their own conditions. If the program folder condition is true, then the programs within are enabled. If false, then disabled. Create a home folder and an away folder, with conditions based upon you keypad button condition. Put the correct programs within each folder. Programs you want to run when home, put in the home folder. Those you want to run when away, put in the away folder.

How are you planning to designate whether you are home or away? A keypad button? You could create two program folders, one with the condition that the away button is on. Put in this folder all programs you want to run when this button is on (pick home or away). The second folder would have the condition that the away button is off. Put in this folder the programs you want to run when this is off. I am sure there is some way to have some complicated logic, ands, ors, nested conditions, etc, but it seems that this might be a simple way to accomplish your goals.. Is this on the right track?

I like the theory behind your wiring. As much as I like insteon, I am not sure that I am ready to be completely dependent on expensive powerline-communication devices. I find comfort in the fact that I can return the house to the old-fashioned, tried-and-true, switches. Neither am I confident in my ability to sell a house so configured.

I have no doubt that one could put together a transformer to power a thermostat. (I recall them being 24V.) How you go about communicating between the two is another issue. I have no direct experience with the venstar thermostats. You may be interested in a new thermostat such as the one I have in my house...a honeywell prestige. It is a little expensive, but comes with a wireless remote control. The thermostat could be set to control your HVAC based on readings from the remote control. Install the wall unit in place of your existing thermostat. Locate the remote control upstairs. No wiring. No mess. You may have to replace the batteries, however. It may be cheaper than running wires.

I have no idea about the feasability of using one thermostat to control another. Regarding power, most thermostats I have worked with are powered from the transformer at the HVAC unit, transmitted through two wires in the bundle to the thermostat unit. Assuming both thermostats are compatible with this power, would not using this power for both work?

I am assuming that your "away mode program" is the third code listed, which is the one which flashes the lights. Correct? If correct, when your second code listing call to run program 'away ModeProgram" (If), there are no conditions to evaluate. I am assuming that this will never evaluate as true, and thus, never run the "then" commands. If so, I still think you want to run (then).

Yes, I would be tempted to take the second program out. Not necessarily, but this question revealed a potential deficiency that we both missed in you first program. It should call up the "then" path, rather than the "if" path. Try: Then Run Program 'Away ModeProgram' (then) See if this helps.

I think you are part of a large club. It comes, with time. There are MANY posts on this topic. I suggest checking them out. The related question, the one that helps understand the difference between status and control, is "when are program and folder conditions evaluated?". I think of the difference between control and status as being a control is generally true at a point in time...status can be true over a period of time. However, conditions are only evaluated when a control is recieved, or when there is a change of state in status. For example, the following condition: control KPLA is switched on and status KPLB is on is evaluated any time a command related to KPLA is recieved, or the status of KPLB changes. If the status of KPLA changes to "on", the condition is evaluated. If the status of KPLB is already on, then the condition is true. I believe this is the only time this condition can be true. If KPLA is switched off, the condition is evaluated. Obviously, the condition would be false. The harder one is when the status changes, forcing an evaluation. If the status changes to on, the condition will be evaluated and be so as false. Why? Because at that point in time of evluation there was no simultaneous reciept of KPLA control, which is also required for the condition to be true. Anyhow, I hope I got it right and that I did not further confuse things. In your case, I think I would tend to use status of utility light C as the folder condition. In reality, I assume you could use either (status remains unchanged until the condition is reevaluated). The way you have it would work, I expect, but seems inelegant. Is this the program called 'Away ModeProgram'? Is this program in the foler or outside of the folder? One thing unclear to me at this point is whether your 'additional Scenes / Away Mode' includes the utility light.C. If so, then your folder will turn false as soon as the scene starts flashing and could halt your program if they are both in the folder. Based upon the input of Subroutine, I assume that a scene and command is different than a control of an individual device, so I trust that turning off a scene that includes a device is not the same as sending a control for that device. If so, then this looks good to me. If, however, a device responding to a scene command reacts by transmitting a control command, then you may still have your infinite loop thing going on here. No harm in trying it out. We can learn together.

Yes, unless you want one of the included devices to control the scene. For use only within the program, no controller is necessary. I am not sure that it "pull"s the information. Program conditions are evaluated each time one or more of the included device's status changes or a control is recieved. If nothing changes, a program will not execute.

As I understand, these two programs would also loose the capability of shutting off the kitchen lights by turning off the flag before 11:14. I am not sure if this is desired, but the OP described this as "expected".

It seems to me that this is exactly what should happen from your program. As I understand it, your program conditions will evaluate at sunset, 11:14p, and at any change-of-state in your away flag. In your case-in-question, it evaluated at 11:14. At the time it evaluated, your flag was false, therefore your condition was false. At that point, it executed the "then" condition, which turned off your kitchen lights. I would, indeed, expect the else statement to execute at Sunset if the flag is false. Have you seen any evidence that it does not? I don't see where you describe how you wanted it to behave, so I assume you want is such that if the away flag is not set, then manual control of the kitchen light prevails? Given that you stated that you expected the kitchen light to go off when you come home before 11:14 and turn keypad D off, I assume you want to keep this feature, as well? Despite your concerns, I tend to like the idea of putting this program into a folder controlled by the away flag. Contrary to your suggestions, I don't think this necessitates putting the other programs controlled by that flag into the same folder. I would keep them outside of the folder and expect them to work as before. Simply putting this into a folder, hower, I would expect the kitchen light to stay on when you turn off keypad D. (I understand that programs immediately cease executing as soon as their folder condition goes false.) If this capability is important to you, then add a second program, outside the folder: if Program 'Away Flag' is False Then set 'kitchen pots' off Else