oberkc

If you add an else statement to return the thermostats to how you want them when the house is occupied, you may get close to what you want, but not close enough. At risk of repeating the earlier observations, this program would run the "then" condition if '*Armed Away' changes state from true-to-false between 7:30 Friday and 7:00 Monday. This program would run the "else" condition any time the '*Armed Away' changes state from false to true during that same time period. Since this program would perform an automatic evaluation at 7:30 fridays and at 7:00 mondays, this program would also run the "else" condition at 7:30 Friday (unless a simultaneous '*Armed Away' false was received...unlikely) and at 0700 on Monday. I believe that this program will also execute the "else" statement at any other time of the week that '*Armed Away' changes state. I assume that this is not what you want. I suggest creating a program folder, with the condtions if On Fri From 7:30:00PM To 7:00:00AM (3 days later) then run the programs in this folder In that folder add a program: If Program '*Armed Away' is False then Set 'Indoor / Thermostats / Second Floor / HVAC Second Floor' Mode Auto Wait 5 seconds Set 'Indoor / Thermostats / Second Floor / HVAC Second Floor' Fan Auto Wait 5 seconds Set 'Indoor / Thermostats / Second Floor / HVAC Second Floor' 60° (Heat Setpoint) Wait 5 seconds Set 'Indoor / Thermostats / Second Floor / HVAC Second Floor' 80° (Cool Setpoint) else Set thermostats the way you want them when occupied. However, with this approach, if you happen to be in an unoccupied state at monday 0700, then there this approach offers no way to return the house to occupied. There is also a potential problem if your program is executing exactly at 0700 monday, at which point execution stops at whatever point it is. I can't help but wonder if you already have a program to return the house to occupied state at 0700 monday, but have not mentioned this.

If I may infer your intention here: is it to set the thermostats to one setting for the weekend and another for the weekdays? If so, you can add an "else" statement that would execute on monday morning at 0730 (based on your current condition). Perhaps this could be your weekday thermostat settings?

I believe your statement is accurate, but let me put it another way to see that you agree we are saying the same thing: All programs who's "if" condition is based on a given device will be evaluated any time the status of that device changes. Understand another thing...I am an engineer. This means that I am relatively good at math. I am not good with languages, including english.

Yes, it does make for a few extra programs. It is, I believe, important to understand what happens, however, in order to become proficient on this thing. You may want to do a forum and wiki search on "status". The big thing that I want to point out is in regards to your code: AND Status 'Portrait Light' is On If this is one of your program conditions, your program condition will get evaluated EVERY TIME there is a change in status of "portrait light". If status changes from on to off, then this WILL get evaluated. Changing from off to on will force an evaluation. Changing from on to off (as a result of your "then" condition) is what forced the evaluation of your program conditions.

I don't believe this to be a problem with double-presses or fast-on or anything like that. This appears to me to be the oft-discussed issue when one's program "then" or "else" responses change one or more of the "if" conditions. I am actually a little surprised that this does not result in something like an infinite do loop. I think the missing piece is a full understanding of when it is that a program evaluates the "if" condition. My understanding is that an if condition is evaluated at any change of state, or at reciept of included control input. In your case, for example, your "portrait lights" are off. You press your harmony button, which sends the "IR_001" signal to the ISY. This receipt of the IR_001 signal forces an evaluation of your conditions, which is, at this point, true. As a result, your "then" statement executes. Your then statement results in your "Portrait Light" turning on. Unfornately, this is one of the events which forces an evaluation of your program conditions. Now that the light is on (and the fact that there was no IR_001 signal recieved) the condition reports as false, and the "else" statement executes. I suspect the better way to solve your problem is to break this into two programs. If IR 'IR_001' is Pressed AND Status 'Portrait Light' is Off Then Set 'Portrait Light' On Else If IR 'IR_001' is Pressed AND Status 'Portrait Light' is On Then Set 'Portrait Light' Off Else

Yes. I am not necessarily disagreeing. I just wanted to offer a potential programming solution given the way things currently stand.

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?