oberkc

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.

I have an "override" button, programmed to delay turning the interior lights off at 1100p. So long as the override button is on, the lights will stay on. I have achieved this in different ways, as my needs have changed. The easiest, probably, is to simply add a condition in your program that turns the lights off: if time is 1100 and status "override button" is off then turn lights off This approach may give you an idea for your pool. LeeG probably has the best approach, though. Post your programs and others can help out.

I am not sure what the "exeption state" is, but perhaps a compromise would be a button for each zone, on and off. Then another, single, button for a global exception state. Put a little color slide behind it to have it stand out. Still, the only value to this is the avoidance of insteon traffic and any affect that may have, if any, on other insteon commands. For me, I try to minimize insteon traffic, but that may be more phobia than anything else. Of course, if you try it one way and if don't like it, you can always change it! Have fun! Thanks for all the ideas that I should try someday.

Mink, I don't know if you have unused keypad buttons to play around with, but if insteon traffic turns out to be a problem, you could always use three keypad buttons to display status, instead of one. My instincts tell me to put the three in a mutually exclusive relationship, and illuminate only the one that represents the current state. My personal preference is to avoid indefinitely repeating insteon signals for the reasons already stated. At one or two second intervals, the chance for signal collisions seems high to me.

Did you mean "or" rather than "and"?

I don't believe that there is an inherent flashing mode for keypads. Perhaps this could be simulated with programs (wait statements, on, off, repeat, etc...). Given this, it sounds to me as if setting the keypad to non-toggle mode and triggering a program would be a viable option. Perhaps the program could increment a variable between 1 > 2 > 3 > 1 >..... to keep track of your three states. I suspect you could also do the same thing using program status, rather than variables, to keep track of which state your system is in.

I believe it to be extremely unlikely that a program, once working, stops. More likely it that something is interfering with communication. Either a trigger event is not reaching the PLM, or the programmed response is not reaching the affected devices.

I must admit that my initial reaction was of interest, as well. In my mind, I was wondering if this technique (as applied here) was an attempt to cause the light to come up to 25% through a continuous (looping) bright command. I then began to wonder if this technique, along with some variables, could be used as a method to add defined steps to a dimmer-controlled circuit. Regarding the orginal question....initially, I was unsure what device controlled the light "X" and whether it was part of the "MultiwayX" scene. Not knowing, I thought there was a chance that the scene bright command had no effect on the device "X", which meant that the device "X" status could remain below 25% indefinitely (a loop). Unlike you, my curiosity ended at the pondering stage.

It just goes to show that you go to much greater lengths to be helpful. This is how I suspected it would perform, but I have never actually tried such a program construct, where a program calls itself. I understood the disable function would stop the inherent program triggering conditions, but does not prevent another program (or, apparently, itself) from triggering the evaluation through an if or else statement. So...am I getting stupid, or is there at least some potential (so long as X < 25%) for a program loop here?

I guess, then, I am missing the purpose of the statement in your ProgramX25: Run Program "X25" (If Part) If this statement has no effect due to the program being disabled, why is it there? Perhaps I, too, am not grasping what it is you are trying to accomplish and why a simple scene is not working for you.

Is this the same ramp rate and on level for scene level and for each of the three devices? If you select one of the devices within the scene, does it show these same levels? Is it possible that you have different on level for the three devices? When your program is called and is evaluated true, the "then" statement runs, which first calls for a bright command (Set "Multiway: X" Bright ) , then calls to run itself at the "if part" (Run Program "X25" (If Part)) . If it is, again, evaluated as true, it will send a bright command, the call itself to run again, and continue this indefinitely, so long as it is evaluated as true. That is why I was concerned about the program looping.

??!! I am not sure I understand this statement. One can set on levels and ramp rates for devices within scenes. One can even set different on levels and ramp rates for a scene devices, dependent on which controller activates the scene. I am a little confused. What insteon device actually powers light "X"? What are the three insteon devices used to contol light "X"? Does the scene include all four (or is it three? Five?) devices? If you, from the admin panel, my lighting, choose the scene, what are the on levels and ramp rates for each of the included devices? If you select each of the devices within that scene, are the ramp rates and on level different? It looks to me as if your program potentially causes itself to enter an infinite loop. Your last "else" statement causes the program to restart, which runs the "else" which restarts the program, which,.... My gut suspects it has something to do with the content of your "multiway-X" scene.

I took this second quote (from the third post) as indication the PBusby has a certain level of confidence in the communication across electrical legs of his/her electrical system. Perhaps I read too much into this.

Exactly. I use this scene in several programs. Also, I use this scene for troubleshooting purposes. A scene test on "all house interior" can be revealing. It is my test for when I add new electronic gadgets.