oberkc

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.

Your original program used "control": I do not believe that this condition would cause lights to come on at sunrise, regardless of door condition. It sounds like you made changes to your program. Did you change it from "control" to "status"? Did you add anything to the "else" path. Perhaps you should post your latest program.

You may be correct. I never remember much of the details, reacting instead to trial-and-error. The solution could be to create a scene, with the KPL button as only device, and to turn the scene off by program. I also don't recall if you can set a secondary KPL button "on" level to zero. Assuming you can (as you suggest and suspect are correct), the concern that I have is that I want the secondary keypad to go off not just in response to a primary button scene "on" command, but in response to ANY command, be it brighten, or dim. I am concerned that relying entirely on a scene approach may not be flexible enough.

So...let me get this straight....you want to use the main button to turn ALL kitchen lights on full bright and use button D to dim these same lights to about 45%? If that is correct, I would approach this with two steps. The first step is with scenes. I would make the primary button controller of a scene with the other lights as responder, making sure that the "on" level is set to 100%. I would make button D controller of a scene with the same lights, setting the "on" levels at the lower level. The second step is to ensure I have the ability to return the lights to the lower level from the full-on condition without having to press button D twice. In order to do that, I would write a program to turn off button D when I recieve a command from the main button. Without being able to test options, I suspect the proper program would look something like: There may be more elegant ways of programming this, but this should get some ideas coming, hopefully. I am concerned about using "status" of the main button as a condition for fear of the consequences resulting from a press of button D.

This is not necessarily enough to confirm being on opposite legs of your electrical system. You also need to follow the included directions for this test. Given your description, it sounds as if you have good RF communication between remotelinc and access points. Given this I would start to suspect comm is not reaching PLM. One thing I would check for is other equipment on the circuit with the PLM. D you have a quantity of other devices on this circuit? Computers? Surge suppressors? UPS?

Yes, really. Wish I could help.

I will be watching. Very possible. Which is why I have a rule that first responses can be no longer than original post.

Programs run even when admin panel is off. No computer is necessary for programs to run.

If you simply change your existing program to substitute "control" for "status", I belive your program will ALWAYS evaluate as false. The use of control must be accompanied by other changes in your logic, as best I can tell. My suggestion is to perform a few experiments. First, I would manually run the program's "then" and "else" path to confirm that your dust collectors are responding as you intend. If not, solve that problem first. It could be a communication problem or it could be a logic problem. You could manually set vf - speed3 and vf - default. Does you dust collection system respond as you expect? Are you cofident that these are the correct command sequence? You could open an event viewer window and watch for evidence of communication problems. You could check ISY-tracked sensor status and compare it to actual. When you turn on the two torches, did you confirm the IOLincs (LED) reflect this state? Does the ISY status follow the LEDs? If not, perhaps you have a communication problem. Break your problem into smaller pieces to better understand which part is broken, then further to understand the root cause.

I am not sure I understand your system enough to critique your "then" or "else" path. But I can offer an opinion on your "if" condition. Perhaps my observations will give you an idea to help further troubleshoot, Your "if" condition will trigger an evaluation at ANY change of status of EITHER sensors. When triggered, it will evaluate as "true" only if BOTH sensors are off. If one or both sensors are on when triggered, it will evaluate false and run the "else path". Another thing that may happen is that the program may evaluate true and run the "then" path, which starts the three-minute wait period. If the program is triggered again before the wait period is over, it will halt execution and restart the "then" path or execute the "else" path, based on evaluation results. Could this be happening to you? What error? Is this an insteon error, or an error with your dust collection system?

Did you change "cotrol" to " status" in your program? I would not expect this to happen based upon your earlier proagram.

Mrtinker, As a result of this thread, I checked my mobilinc scenes and devices and reach the following conclusions: A. Mobilinc does not display a status for scenes. B. one can see status of individual devices, including iolinc relays. C. One can control iolinc relays, either via device or scene I hope this helps