oberkc

RichTJ99, Assuming garage3 is in scene garage 3-4-5, your program will NOT work as I believe you are expecting. As soon as the "then" path executes, the garage 3 light will come on, triggering a re-evaluation of your conditions, turning false, interrupting the "wait" statement, and running the else path. Furthermore, upon a second detection of motion, if the light is somehow on (even originally triggered by motion), your program will re-evaluate, interrupting the wait, and halting the countdown. It is to avoid problems like that that I suggested breaking this program into smaller pieces. You have several conditions to find a way to evaluate: are the garage lights on? If so, are they on from a manual control, or from an earlier motion detect? Is it 1100pm? Is the timer in progress when it is 1100? Your stated desires is a good little excercise in ISY programming. Make sure you check out the wiki on motion sensor programming. There is (or was the last time I checked) lots of good discussion on how to programmatically handle these decisions.

I believe that you need to create a single-device scene, and control the scene from the program.

Requires a program If Status light 1 is not off Or status of light is not off Or status...... Then Turn kpl button on Else Turn kpl button off Make this kpl button controller of the scene. Then, when the button is lit as a result of the program and you turn it off, the scene will go off.

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.