oberkc

Of course one can and an "or", or an "and". In the program, create a new conditon. In the condition window, choose "or" or "and". Select "add to "if"". Done.

There is a good discussion on motion sensor programs on the wiki. In addition, there are LOTS of threads on the forum on this topic. It is arguably the singlemost programming example brought up, in my estimation. RichTJ99, your program would work fine. Each receipt of an "on" command would halt any "wait" period, and restart the timer. Unfortunately, it did not include checking for the status of the lights. I am thinking we will have to check for three conditions: motion sensor, light status (no such thing as scene status), and program status. If Control 'Garage: Motion5-Sensor' is switched On and ( status 'one of the garage lights' is off (assumes relay on/off only) or status 'light timer program' is true ) Then Send Notification to 'Default' content 'Garage Bay #5 Motion' run 'light timer program' (then path) Else - No Actions - (To add one, press 'Action') I would create a second program "light timer program" if then Set Scene 'Scene: Garage 3 way' On Wait 20 minutes Set Scene 'Scene: Garage 3 way' Off run 'light timer program' (else path) else I would add a third program: if time is 1100pm and 'light timer program' is false then set scene 'scene: garage 3 way' off else I would configure the motion sensor to have a relatively short time-out period. If you give this a try, let me know how it works.

My first inclination would be to make sure I had the latest version of ISY software

Yes, you may be right. I think I misunderstood.

I believe that this fails to meet the requirement of his initially-stated desire to be able to go from 45% to full on when his wife enters the room. I thought we were setting up a scheme where, if the wife enters the room with the 45% scene (and button D) on and presses the main button, the lights go to full bright? Maybe I misunderstand.

I don't believe old christmas lights are a problem. They are, I assume, incandescent, which is almost certainly not an issue. More likely it is another cause.

I am also intrigued by the fact that every other "ON" command appears to be followed by the log note: "Process Message: Ignored" Is this related to that yet-to-be-discovered unidentified activity?

Scene test is an option under tools>diagnostics (from memory...if not exactly correct, it is not too hard to find). The scene test gives one a clue as to the quality of communication between and among the various devices within a given scene, I understand. Like much of insteon troubleshooting techniques, I have not found it to be conclusive, but it does provide useful clues and can act as a common standard by which you may judge your communication environment.

Do you have any scenes? Can you perform a scene test?

I intend to try it out, someday. I must confess that I fear that I will like it, and compulsively spend the next months-worth of evenings and weekends learning a new hobby. Given one with my lack of experience with HTML and REST and stuff like that, I expect a steep learning curve. You seem to confirm my perception that iRule is king if one is looking for customization and flexibility. I have too many hobbies already.

When programs and commands appear to work SOME OF THE TIME, I tend to suspect communications. My experience suggests that computers, programs, PLMs, either work always or not at all. The intermittent part of insteon tends to be the electrical system and communication between devices.

The way I understand that this would work is that if the "status" of your two sensors would change during the three-minute wait period, the program would trigger an evaluation, halt execution of the wait period, and start fresh down a new path, based upon results of the evaluation. Wow! I think I just created a 100-word sentence to say "no".

Unfortunately, I am not familiar with the REST interface. What I can say with a certain confidence, however, is that if your choice of status is between "scenes" and "variables", you will have to choose variables. There is no such thing as scene status from an ISY, or perhaps insteon, viewpoint. Yes, it would. I assume that it is, but you would have to convince universal devices to do so. I also suspect that this is more complicated than many give credit. How does one define when a scene is on? Any given scene can have multiple "on" levels, based on each controller. Regardless, I think there is a "product feature request" place to put such requests if you are inclined to do so.. I continue to look for that ultimate remote and find myself focused on iRule/android/ipenabledirblaster as a potential solution. While I don't want to hijack your topic, I am definitely interested in your thoughts on this.

No I believe you will need a program for this. if status device 1 is on and status of device 2 is on and status of device 3 is on then else You could then use the state of the program (true or false) as indication of scene status. If you prefer, you could create a variable and set it to some value based on "then" or "else" path execution.

Yes, a variable could work. Alternatively, one could use one of the scene responders as a surrogate indicator of scene status. This is one of those cases, I believe, where the requirements are not fully examined and will result in unexpected complications. On the other hand, this would be a good excuse to improve one's ISY programming skills.

This is an interesting concept. I don't believe I would have thought to adjust ramp rate to avoid the "undesirable" off>on transition. Unfortunately, there are no conditions which test for "scene" status, so you may need to find another condition which accomplishes a similar goal. My suspicion is that the OP may want to take a lot of time to consider what he wants to happen under a variety of conditions. Examples include: - If button D is on, and he presses button A, what should happen to button D? - If button D is off and he presses button A, what should happen to button D. - if the lights are on, is it necessary to be able to turn them off? If so, what button would do that? -if button A and D are both on, and the lights are full on, what should happen when one presses button D? There are a lot of combinations here and I still think the entire control scheme needs to further thought out.

This problem may not be solvable, given that your KPL actually powers some of the lights in a scene. I think, too, that you may run into additional use cases issues. If the kitchen lights are full on, including KPL-main, how do you intend to turn them off (or do you not intend to)? If you create a set of programs that reverts the scene back to 45% when you turn KPL-main off, what means do you intend to use to turn them fully off? Fast off? Button D? You may need to consider a different approach. Do you have an unused button on the keypad? Could you use this extra button as controller of the same scene as button D, but with "on" levels at 100%. The main button would have to be redefined as responder only.

In my case, I have two global scenes: all lights interior, all lights exterior. Every device that I have falls into one of those two scenes. Of course, most of these devices fall into other scenes, as well. The point that I make is that these are pretty large scenes (by my standards) including dozens of devices and nodes, with a pretty large range of type and version. I have never noticed any problems or adverse consequences. Furthermore, having these scenes can, at times, be a help. In addition to using these scenes for "all on" and "all off", such scenes can be useful for troubleshooting (my original reason for creating them). Scene tests on these global scenes can act as a benchmark for system performance and an indicator if something has gone bad.

Your original program (with "control") was the correct way to do it. Change "status" back to "control".

or you can create a third scene, that includes the devices of both scenes one and two, all as responders. Then you can do as you state: watch for a fast off, and have a program turn off scene three. This is, generally, how I handle the all lights scenerio.

Well...I just ran a few tests and experiments. I first confirmed that the ISY still showed my button (call it KPL button C) as non-toggle off. I opened the event viewer. I pressed the button and the backlight changed from off to on. Another press and it went from on to off. Watching the event viewer, it appears that the commands sent from the KPL were consistent with the backlight indication. I restored the device (wow! that took several minutes). I performed the same test with the same results. I went back to the toggle properties, changed it back to toggle mode, then back again to non-toggle mode. It now works as expected. Go figure!

I don't believe this is a factor in my case. On a keypad, a while back, I configured one button as non toggle off. All was well. Later, on the the same keypad, i tried the the same thing on another button (most certainly on a newer version of ISY software)...no luck. This suggests to me a cause other than keypad version.

It all sounds about right. The only thing that I can think of is the "on" level when the other keypad button is controller. From the device list, in the foyer scene, select the controller button. Once selected, note the "on" level for the load keypad. Is it set to zero?

What kind of device is your friend trying to discover? If it is a plug-in module, try plugging it into the same outlet as the PLM. While you have tried moving the PLM around, make sure to do your best to ensure it is not plugged into an outlet and circuit which powers a bunch of other electronic gadgets, power supplies, things like that. How many insteon devices (besides ISY/PLM) does your friend have? If more than one, can they be manually linked to each other? If so, this tends to suggest that the devices, themselves, are working. If you are on a clean circuit, have confidence that the modules, themselves, are good, tried communicating with a module and PLM on the same outlet, then I would reach the same conclusions as you: faulty PLM.

I have also recently attempted to adjust settings on a KPL to make one button as "non-toggle" off. This would be the second button configured in such a way, though the first button was certainly configured using an earlier version of ISY software. My current version is the most recent release candidate, I believe it is called. While all admin panel indications suggested that this button is in the desired mode, the button LED backlight continued to behave as if in toggle mode (the first button continued to operate as one would expect when in non-toggle mode). I never considered the possibility that the button was operating in a mode different than indicated by the LED backlight, so I did not perform any experiments to confirm. I did not perform a factory reset, but I did cycle power. Perhaps I will perform some further tests to dig a bit deeper.