oberkc

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.

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

Then I would do the following: 1. create a scene where all the lights you are interested in tracking are responders, and all the KPL buttons that are to display the status (and turn them off) are controllers. 2. put the KPL buttons in non-toggle off mode, so that a button press will send only off commands. 3. If you have multiple KPL buttons you wish to use to display status, create a second scene with all KPL buttons as responders only if status switch A is not off or status switch B is not off . . . or status switch N is not off then set KPL button display status scene on else set KPL button display status scene off of course, device names would be consistent with your actual devices and scenes. The ISY will not allow you to put a single device as controller in more than one scene. There is also no way to do this manually.

If you want to be able to turn on TL1 independent of TL2, and have the KPL buttons illuminate (turn on) when either is on, then I believe a program is your best option. I have such a program. It looks something like: if status switch A is not off or status switch B is not off then set KPL button on else set KPL button off I think there would be some potential inconsistencies if attempting to do this with scenes. If you want TL2 to come on when TL1 is toggled (and vice versa, plus KPL buttons) then set all four as controllers in a single scene.

If I were forced to give a one-word answer, it would be yes. Keep in mind, however, that when done with the ISY, you are including the ISY/PLM as a controller in the scene. If you manually link two insteon devices, the ISY is not included and the scene could not be used in programs, won't show up in your lists, and may show up as a mismatch in link tables between the device and ISY. There is another thing to remember. When manually linking, you start by putting the controller device in linking mode then adding the responder. If you want multiple controllers, you have to be sure to add the other controllers as a responder (where LeeG and insteon manuals refer to this as cross-linking). When done with the ISY, all devices defined as controllers in the scene are also responders by default. No cross-linking necessary. If you create a scene on the ISY as you describe, there is no need to set up any additional scenes. Because controllers in a scene are also responders, TL1, TL2, and KP2 would be responders to KP1. TL1, TLs and KP1 are responders to KP2. Individually turning TL1 or TL2 on or off will have no effect on any of the other devices within the scene.

Is this to say that sometimes your programs work, but sometimes not? And that your "off" program is more intermittent than the others?

I don't know whether your devices are dimmers, but I understand that dimmed is not necessarily "on". I have a similar program to yours, but with a subtle difference: If Status 'Bedroom / SW MBTH Master Bath Vanity Li' is not Off Or Status 'Bedroom / PM MBR Candle' is not Off Or Status 'Bedroom / KP KBA Nightstand Lamp' is not Off Or Status 'Bedroom / OTL MBR Front Wall' is not Off Then Set Scene 'Bedroom Control' On Else Set Scene 'Bedroom Control' Off Perhaps using the condition "not off" would work for you?

I am unsure about the timing of this, but I suspect this never turns true. If at the time the control is recieved the light is off, the status is false and the condition evaluates false. If the light (switch status) was already on from the motion sensor, then turning the switch on manually does nothing. (I don't believe it sends another on signal.) You can confirm this by opening the event viewer. Turn your garage light on. See if you see the command in the event viewer. While the light is still on, try switching it on again. If my understanding is true, you will not see another on event in the event viewer. I am concerned that there is not way to activate a program or event by attempting to turn on a switch that is already on. Hopefully, someone can confirm this. Wait 25 minutes Set 'Garage Light' On Are you sure you want to set garage light "on"? Would this not be "off"?

This is pretty much limited to programs, using a program to send X-10 commands. If one purchases the X-10 software module for the ISY, you can add X-10 devices in your device tree, giving them names, and using those name in programs.

This sounds like you intend to manually add devices. While I am sure that this can work, there is an easier (and better) way. From the device tree, remove the device (I recall that this is an option when you right-click on the device). Then, using the icon along the top, or from the menu, choose start linking. A dialog box will open up. I believe the default selection is to eliminate existing links from your device. This would be the correct selection. This puts your ISY/PLM into linking mode. Now, go to the device and put it into linking mode (press and hold the main button on). After a few seconds, the button (and load, if any) will flash. At this point, you will have a new device in your tree. Take the ISY out of linking mode. Your new device should be properly identified with all the keys. This whole process will remove the old device from your ISY, including scenes and programs. Once readded, you will have to go back and add the new device back in.

I organize my devices generally by room. I don't organize scenes in folers. The only folders I use in programs are dicated by functional purpose, where folders have conditions (dusk-to-dawn, April-through-September, etc).

In my lighting tree, they show up under the primary button, accessible by clicking on the little + next to the name. I recall that this view has changed over the various iterations of the software. Mine is v2.7.14. You did not happen to manually (typing in the address) add the KPL, did you?