oberkc

It sounds, then, that you understand things well enough to make a decision about which way you want to go. Good luck.

OK. I will take your word for that. Should I dare suggest that is not the insteon definition of a scene being on and run the risk of being called silly again? If you choose to use the programming logic of the ISY, it could address the logic to turn the keypad on. To do so, however, the keypad button in our example would not be part of the defined scene. However, if you define an insteon scene as including the keypad button, then you are relying on the inherent insteon capability of the devices rather than the logic of a program. I don't know about whether this is silly. I will leave that to your expert judgement. I am just a simple user of an insteon system. Yes, indeed, a scene can be defined three different ways. The ISY-99 creates such scenes. Perhaps the ISY-99 use of the term "scene" is sometimes a combination of pure insteon "scenes". Regardless, in my mind, this makes establishment of relationships between devices a bit easier to accomplish. Where you have three "scenes", the ISY-99 construct has one. It works for me. Apparently, this is not your preference. I actually find the ISY-99 model of a scene works pretty well. Perhaps the trade-off is that the definition of scene "status" becomes a bit more difficult to define. Design, as in life, is about tradeoffs. Apparently, powerhome has made different design choices.

Suppose one has a scene with a controller keypad button and two responder dimmer switches. Suppose the "on" levels for each responder is set at 50%. Suppose, then that each individual dimmer was manually set to 50%. The keypad controller would not be on. Is the scene on? That is all that it means. Suppose one has a scene with three devices, all controllers and responders. Each scene is defined differently, depending on which controller is used to activate it. When is this scene on? This topic has been discussed before, and I don't believe the omission of scene status is due to a failure to consider it. Certainly, it can get complicated pretty quickly.

I suppose the answer to that would also depend on whether there are any controllers of the scene, such as a keypad button. In the end, the answer really doesn't matter. I don't believe the ISY has what you are looking for. Good luck with whatever option you choose.

My understanding with regards to scene status is best shown by rhetorical question. If one has a hypothetical scene with two dimmer devices, each with scene "on" levels defined as 50%, is a scene on or off if both devices are currently operating at 60%? While I am sure there are logical ways to respond to questions such as this, I agree with apostolakisl: the ISY-99 does not monitor scene status. I continue to believe that you will find the ISY-99 to be lacking in this "intelligence" that you seek.

The ISY-99 is based on if/then/else programs, with conditions consisting of device status, program status, time, temperature, etc... joined by "or" or "and" conditions. If you can describe your needs using boolean logic, the ISY-99 can do it. Also, insteon sytems with the ISY-99 can take advantage of insteon scenes, so combinations of scenes and programs are typical. Your example sounds like something where you would use a combination of scenes and programs. However, you state that such a construct is "unmanagable" and "ugly". Given this, I cannot think of anything to offer that you would find otherwise.

Good catch. That is exactly the change that I would suggest, as well. Simple is all I can understand.

On what evidence do you base your conclusion that this never fires. What is the status of this program in the program summary? (if "true", then it fired at some point.) If you manually run the "then" path of this program, are the results as you expect? If you manually run the "else" path of this program (turning the program "false"), does the program status become "true" at midnight? Is it possible that something happens to OUTLIGHTS.S3.BODY between now and midnight that turns it false?

I am sorry, but I must disagree. The program example I offered would turn the fan on when the light came on. So long as the light stayed on, the fan would stay on. The 15 minute timer does not start until the program is evaluated as false (which happens only when light status changes to off), and runs the "else" condition. Perhaps I should have added spaces to make this easier to read: if status 'shower light' is on then set shower fan on else wait 15 minutes set shower fan off

Using the "status" condition, rather than "control", I expect the "if" clause to be triggered at any change in status, whether from off-to-on, or on-to-off (I am assuming your light switch is a relay, rather than dimmer....otherwise, one may have to emply a different type of condition). If the condition is triggered and evaluated as "true", I expect any running "else" clause to cease, and the "then" clause to initiate. If the condition is triggered and evaluated as false, I expect the "else" clause to initiate. It is easy enough to try out. Create the program and observe the program status as you toggle the light from off-to-on, and vice versa.

I have not made a lot of changes to my system in the last few months. All is, generally, working well. Therefore, my programming may have lost a step or two. Would the original requirements not be as simple as: if status 'shower light' is on then set shower fan on else wait 15 minutes set shower fan off

Perhaps I am the only one, but I am a little confused by your terminology. Scenes and programs are different. Scenes are created at the device list and have no "if" or "then" conditions...only controllers and responders. Scenes do not require presence of the ISY to operate correctly. On the other hand, programs have "if", "then", and "else" statements. Having said this, are you having trouble with a program failing to operate as expected, or with scenes not responding to one of the controller devices? It is starting to sound as if you have a program that is giving you trouble. If so, do you mind posting it. I am with apostolakisl here: I am now suspecting a program error.

You are mostly correct. It has been dealt before (a lot). Whether it is simple I will leave for you to decide. You will probably need an insteon program or two to make this work and make a few changes to your scene. My suggestion is to first look over the wiki articles on this subject. I have found them useful. The link below uses an X-10 motion sensor, but the logic is valid regardless. There is also a wiki article on using motion sensors in a bathroom. Much of this is applicable to you, as well. http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Using_X-10_Motion_Sensors If your question is more basic (how do I write a program with the ISY), I expect the wiki to be a good place to start, also. http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:How-To_Guide#Programs'>http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:How-To_Guide#Programs or the user manual; http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:How-To_Guide#Programs

I must admit that the ability to read those events would, in times of trouble, be nice. Still, I have too many hobbies already and, as much as I enjoy my playing with my lighting system, I enjoy it even more when I don't have to play with it.

You are, of course, correct. Thanks for the amplification. My opinion is that the term "scene" is the one that we external users see in the literature and ISY admin panel. The intoduction of a "group" term helps such users not (at best) and adds confusion to some, based on my observation of the forums here. I percieved PBusby as an external user, such as myself.

Thank you for posting your programs. I expect these to do as you have stated that you want. Unless I misunderstand your expectations, I would look somewhere other than the program. Now that we know the names of the devices, please describe what your system is doing that is contrary to your expectations. Please use the device names when you describe this behaviour. Many of LeeGs questions are aimed at the possibility of communication failure or device failure. Answering those will help narrow the solution to your problem. In general, I would compare the status of the actual devices in your program to the status shown in the ISY admin panel (does the ISY say it is off when the actual device is actually on?). See if there are any that don't match.

I have no clue what is Insteon Group Messaging. So far, this lack of understanding has not hindered my use of insteon. I suspect the phrase used in the insteon standard is "scene". In my mind, a scene is analogous to a set of devices all having the same X-10 address, with the ability to define some as transmitters of, others as responders to, or some as both transmitters AND responders to that address. To me, introducing "group" terminology adds an unecessary complication into the picture.

"direct source of the switch"? Another statement that I am having trouble understanding. My perception is that you are making us guess too much what it is you want to do. Please identify the names of every device to which you want KPL-H to respond. Then post your programs as they exist. Then describe what is is that you are trying to achieve and which of those objectives are not being met. This is a pretty simple programming example. I suspect that we are failing to understand what it is that you are trying to do.

You would still require this scene if you want your lights to come on or turn off in response to a press of the button (KPL button H, in your case).

I am sorry, but I have no idea what this means. Yes Was the button the only controller of the scene? I would expect that if you turned this scene on via ISY admin panel, the button would come on. Yes, I suggested this. You would create this scene just as you would create any other. From the admin panel, choose the new scene button. Give it a name. Add the button to that scene, as a responder. No "wording" is required.

If you want a KPL button to come on if one or more other devices happen to be on, then I believe you need to make a program such as: if status device A is on or status of device B or ... then turn KPL on Depending on KPL button, you may need to create a scene that includes only the KPL button, then use that scene to turn the KPL button on or off.

If you don't already have a filter, you can temporarily remove the surge suppressor. Alternatively, find an extension cord and use it to power the PLM from another circuit. See if this makes any difference.

Every time I hear of this condition, I recall issues I had with communication between the PLM and the rest of my system. Is your PLM on a plug or circuit with lots of other computer stuff? It is not on a surge supressor or power conditioner is it? What about next to one of these devices?

I must admit that I wanted to respond to this one, but, after reading through it a couple of times, I was simply not sure that I had the brain cells left to follow the trail. One question that bothered me regarding your first program: Why are are doing it this way? Why not just create a scene with both Bsmnt.Ceiling and Sc.Test.Light.Status?

This is so simple I am concerned that I am misunderstanding. How about: If Control 'LightsOnDemand' is switched On And Status 'Rope Lights (Main)' is Off Then Run timer program "then path" Else - No Actions - (To add one, press 'Action') Timer Program: if then Set 'Rope Lights (Main)' Fast On Wait 20 minutes Set 'Rope Lights (Main)' Fast Off Set 'lightsOnDemand' off else I know you didn't like my override suggestion, but this is the exact scenerio for which it was intended....manually delaying the automatic shutdown. You could do both, and use the same button for the override as you do for your 20 minute timer. I actually heard my wife admit she liked the automation. Unfortunately, this did not happen until four years and several thousand dollars was gone. You will convert her, if she is not already. Me too.