oberkc

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

I retrofit an existing house, but have done as you suggest: add keypads at key locations for major scene control. Like you, I do not like the the appearance of mixing keypads with single switches, so each keypad gets its own box (generally mounted higher than the single control boxes). I also have a couple of keypads in desktop enclosures for some locations. Additionally, i access lighting control from a couple of android tablets throughout the house. Mostly, however, I rely on automation for scene control. Lights automatically come on key times, mornings, dusk, dawn, weekends, upon arrival, when doors are opened, upon motion sensing, etc... This is, in my mind, the more omportant part of automation: not having to use light switches. Also, don't forget that singleminsteon switches can be controllers of scenes. Perhaps it makes sense in your situation to program one of your single switches as a controller? Also, don't forget to include outlet and table/floor lamp control. A single switch for this can be very convenient, depending on the quantity of fixtures you end up with. I have a friend with so many table lamps that I am sure it takes 10 minutes each night to turn them all off.

I did not believe that scenes had "status". In mobilinc, I rely on the sensor to determine door status. I use the relay to control the door. Alternatively, you could use the scene (with relay as responder) to control the door. I also have a webcam to verify, if I am concerned. Unfortunately, I don't believe there a single device that one can use with moblinc, or as a moblinc widget, to display status AND control the door. If you find something different, I would love to hear about it.

It would not be the first time a brand new device is faulty were that your case. I am not sure that it is. Could be on a different circuit, even if in the same room. Could be the load attached to the device. Could be production variance in the two devices.

Is it even possible to link a PLM to an insteon device without the attached controller? I would be very surprised if the kinds of problems you are having are related to PLM-to-ISY communication problems.

Yes. Always the same. Button A, or 1, depending on which version. That would be my inclination, also. If not that, at least have a fallback plan to be able to remove your insteon should that prove necessary or desirable.

A series of commands to turn off any light that you want off once the sun rises and don't want left on all day. The bigger point is that (unless you have another program that handles this) the two garage lights and kitchen lights will be left on indefinitely from this program should sunrise occur within the ten-minute wait period. If that is acceptable to you, then no action need be taken. If you want to make sure they will not be left on all day, put three commands in the "else" path to turn the three lights off. While there may be other ways to handle this type of condition, I find this simple and effective.

It certainly suggests that these devices are working. What is the electrical environment near the PLM? What other devices do you have plugged into the same outlets and circuit? Is your PLM plugged into any power strips or surge suppressors?

I expect this program to work EXCEPT when you happen to open the door less than 10 minutes before sunrise. If sunrise were to occur during the program wait period, it would trigger the program evaluation, turn false, halt the wait, and execute the "else" path. In other words, the lights would remain on indefinitely. One way to solve this is to add a step to turn your lights off in the "else" path.

Whether or not a fixture or lamp can be dimmed is dependent entirely upon the insteon device which actually powers it. A Keypad can be purchased in either dimmer or relay version. The consequence of this is only related to the load which is directly powered by the keypad (connected to the red, load wire from the keypad) via the "primary" button on the keypad. In addition, ALL keypad buttons can be virtual controllers of other insteon devices. That is, ANY keypad button can virtually control another insteon device such as a lamplinc, outletlinc, switchlinc, dimmerlinc, another keypad, etc. On a keypad, buttons other than the "primary" button can act ONLY as virtual controllers, since they have no ability to supply power to a fixture. So, if you have a lamp that is plugged into a dimmable lamplinc, and use a keypad button to control the dimmable lamplinc, then, yes, that keypad button controls a dimmable load, regardless of whether the keypad, itself, has an on-board dimmer capability. In my house, I have many insteon switches that power NO load directly, having nothing connected to the load wire, instead acting only as virtual controllers of other insteon devices. Whether or not they can dim a fixture as a virtual controller is completely independent of the dimming capability of that switch.