oberkc

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

It appears that, perhaps, it is not working as well as you thought. Even if devices eventually respond, sometimes the response is slower if the communication is marginal. If too slow, I think there is a chance of signal "collision" and subsequent problems. I would definitely dig out the instructions for these and make sure they are on separate phases. Since this costs nothing but a little time, I suggest starting here. Once you are sure they are on different phases, run the scene test again and see if it passes. If so, problem solved (maybe). Being on separate panels does NOT guarantee being on separage phases. Furthermore, there can be problems if your panels are on seperate feeds from the transformer. Assuming you have a single feed to the house supplying power, I am guessing you are likely able to communicate between panels. You still have to ensure they are on separate phases. Again, the instructions describe how to do this. Based on my experience and from my readings of this forum, I think it likely that you are seeing communication problems resulting from interference and signal degradation from your computer system. If the access points don't solve your problem, then I would start with a filter on your computer electronics. (Keep your plm off the filtered power.) If you would like to do a crude check to see if this is an issue, get an extension cord and plug it into a circuit separate from that which powers your computer system. Plug the PLM into the extension cord. Run your scene test.....see if this helps. If, after confirming access points are properly located and powering plm from different circuit, your problems persist, the next steps are likely finding other offending devices in your house and filtering them.

It appears that, perhaps, it is not working as well as you thought. Even if devices eventually respond, sometimes the response is slower if the communication is marginal. If too slow, I think there is a chance of signal "collision" and subsequent problems. I would definitely dig out the instructions for these and make sure they are on separate phases. Since this costs nothing but a little time, I suggest starting here. Once you are sure they are on different phases, run the scene test again and see if it passes. If so, problem solved (maybe). Being on separate panels does NOT guarantee being on separage phases. Furthermore, there can be problems if your panels are on seperate feeds from the transformer. Assuming you have a single feed to the house supplying power, I am guessing you are likely able to communicate between panels. You still have to ensure they are on separate phases. Again, the instructions describe how to do this. Based on my experience and from my readings of this forum, I think it likely that you are seeing communication problems resulting from interference and signal degradation from your computer system. If the access points don't solve your problem, then I would start with a filter on your computer electronics. (Keep your plm off the filtered power.) If you would like to do a crude check to see if this is an issue, get an extension cord and plug it into a circuit separate from that which powers your computer system. Plug the PLM into the extension cord. Run your scene test.....see if this helps. If, after confirming access points are properly located and powering plm from different circuit, your problems persist, the next steps are likely finding other offending devices in your house and filtering them.

What starts and controls the "initial run"? How long does the initial run last? To clarify, does this variable not become true until "after" the initial run? Is it possible that the delay in starting your program is due to the fact that the initial run var takes some time (waits for completion of initial run) to become true?

Perhaps. I do not recall reading of any such problems, but now I have. Given this, I understand your hesitancy. Perhaps, as you say, this was an older version of the ISY firmware, since taken care of. I use an X-10 reciever (IR-543) and the ISY see's these signals without problem. If you don't want to use something like the IR linc, and plan to put the ISY-99 in a room other than the one where you use the remotes, then your options may be limited to an ISY-99IR with some type of IR extender to get the remote signal from the remote room to the ISY room. If you happen to have a remote with RF capability, you may also consider an RF extender at the ISY location.

I understand that the scene test is an indication of communication difficulties. I understand that the scene test is simply a check of communication with fewer attempts than normal, so, yes, it can fail a scene test and your programs still work, but I would take this as further evidence of a rough communication environment. This would certainly explain why your system takes so long to write changes. I would not ignore the failed scene test. Do you use access points or dual-band devices? Are you confident that they are set on different legs of your electrical system? Do you have mulitple electric panels? Do you use any filters on any electrical devices in your house (and, specifically, the computer system itself)? Is the PLM on the same circuit as your computer system or home theater system? Answers to these questions may help isolate your problem.

Yes, I thought one of the recent versions allowed holding off writing changes until they were all done. Like Brian H said, I also suspect intermittent communication issues. When communication is good (at least in my house), writing changes is relatively quick.

I would expect that, like any insteon device, it would integrate beautifully. Whether you hook it up amongst a bunch of home theater electronics, or amongst a bunch of computer electronics, I suggest planning to put such things on a filter, so to limit the potential for inteference. Of course, the PLM itself should not be on a filter. When on filters, I would expect little trouble from these devices.

My understanding is that the IR version has a built-in IR sensor that one can send IR signals into. These signals could be a trigger as conditions in an ISY program. I don't believe there is provisions for an external sensor. I don't believe additional hardware is required. One could locate the ISY in an entertainment center and use a TV remote to send commands. Or, one could locate the ISY anywhere and use some type of IR extender to input IR commands from another room. Or, there are insteon IR recievers available that can be programmed to do similar things. For that matter, there are X-10 RF recievers which can be used to transmit X-10 signals over the powerline and used to trigger programs (this is the solution I currently use to trigger lighting control from a TV universal remote). There are several solutions, including the built-in IR reciever. I don't think you have to be limited due to the fact that you don't have the IR version of the ISY-99.

With the ISY, all controllers are also responders, by definition. Make both devices controllers, in your example, and they will respond to each other.