oberkc

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.

I would not expect two panels to be a big issue (many hear report having more than one), but theory and reality are often at odds with one another. So long as you are confident you have both legs coupled, I would think two, properly located access points would be enough. Still, my recollection is that some report using four access points in 2-panel systems. Even if you are confident that yours are located properly, it is pretty easy to try different locations to see if this solves (or has any affect at all on) your problems. It is always possible that you have a faulty device (none of yours show up on the ISY device list as v35, do they?). If one assumes they are all good, any you have proper coupling of electrical legs, there is not much left but communication problems. The source of these are not always easy to identify, but if moving PLMs, access points, and plug-in modules to different locations tends to cause things to work better or differently, this tends to point to comm problems, in my mind.

The approach I have taken for this is to create a scene with the limited (you refer to them as "main") lights as responders and a few, select, keypad buttons as controllers. To this I add a program which watches for an "off" command from each of the main scene controllers. When triggered, the program simply turns off ALL interior lights (I have an ALL HOUSE INTERIOR scene, with no controller device defined), regardless of whether they are part of the main scene. Yes, this results in some devices being told twice to turn off, but I have observed no ill effects from this.

Have you tried temporarily moving your PLM to a different location and circuit (use extension cord if necessar) to see if that clears up any communication issues?

Not directly.

One must first set up a notification under tabs: configuration/email/notifications The second step is to create a program that sends the notification based on desired conditions.

If you want a couple of devices to be guaranteed off after power failures, could you not create a simple program to run at startup which simply states: Then set KPL off Set APL off Another possibility would be to send yourself a notification in the event of power failure, allowing you to remotely confirm or cnage your "away" status. This way, you can choose whether you want to be home or away whenever this happens, rather than just assume an "away" status. I was under the impression (confirmed by my experience) that insteon devices reverted to the status held before power failures. I am a little surprised yours are not. However, I don't much rely on this feature, so it is possible that mine don't and I have just failed to notice (power failures are pretty uncommon at my house.)

Perhaps you are correct. If you believe this to be a concern in your installation, perhaps this may be enough to justify staying with separate programs. I suspect, in the end, that these are not major considerations either way. I am still a little curious about the idea that these buttons don't respond while in the flashing mode. I use a couple of these as garage door indications and control. They are set for non-toggle off. Their status responds to garage door sensors. When I press one to open the garage door, the sensor sends out a signal while the button is flashing (at least that has been my perception). Even so, the button responds appropriately. Therefore, I am a little surprised that you are having this problem. Maybe there is someone around here that can confirm whether this is normal behaviour for these devices.

I don't expect that this would be any more traffic than had you accomplished the same thing with two programs. It is more traffic, however, than the earlier single-program example. Of course, there is no built-in delay.

Interesting. Yet...it is trigger by an "off" command from either of your two buttons(?). If you needed such a pause, then you could also insert a slight wait delay into your first program "then" statement. I would not expect to have this problem. Any time a condition changes that forces a re-evaluation of the program's condition, "wait" (and "repeat") statements are interrupted and the program restarts based upon the results of the most recent evaluation. Fair enough. There are many ways to do many things. Best of both worlds, then, may be:

You did this using the same approach as did I. I don't recall needing any wait statements, but this may be due to you having two controllers and I having only one. Still, I am surprised at the need for a wait statement to turn off the keypad, since this is the default (nontoggle off) condition. If you continue to need a wait statement, you could also simply add it to the first program, such as:

Tech support for Universal Devices can be found here: http://www.universal-devices.com/supp_contact.htm

I wonder if there is not a slight logic problem in your program. Using "AND" construct, all conditions would have to simultaneously be true for the program to be true. I suspect it is hard to have a simultaneous "off" and "fast off". Try: if status "bathroom motion flag" is true and status "bathroom light" is off and ( control "bathroom light" is not switched off or control "bathroom light is not switched fast off ) then set "bathroom light" to 80%

I noticed that. It looked like it would be less work to simply assume that there are missing links and to restore the PLM than it would be to feed the calculator. There was no known insteon traffic whcn I peformed the original count. All was quiet. Nobody was home. No programs were scheduled.

Thanks for the feedback. I could do the calculator thing, and it will give me a number. This, I assume, will give me a ballpark sense of whether my count is close. If not, I assume the remedy it to...what...restore PLM? I am thinking that I might as well restore the PLM regardless. Besides the time and interruption to household functions, is there a downside to this approach?

I assume you are speaking in the context of doing this via the ISY-99. Create a new scene. Add both switches AS CONTROLLERS. This is the same as manually cross-linking both devices. When you get the motion sensor, simply add it to the scene, also as a controller (I believe this is the only option for motion sensors.) I believe you need to configure the motion sensor to activate only during dark conditions, and to control the off-timing. If you want to introduce a finer level of control with the motion sensors, you could create a program. The program could include multiple conditions (darkness, sunset, sunrise, status of manual control), and the program could control the length of time it would stay on. I suspect this is the option most people prefer.