oberkc

Benefit of hue versus ISY? The hue hub has very little automation, but apparently integrates with a bunch of other things such as the harmony and echo. I have been assuming that the ISY communicates to the hue system via the hub (network resource) so I view the hue system as a supplement to insteon and the ISY. My interest has been the color options, wall wash lights, and strip lights...those have worked out very well.

Is there a questions somewhere? I would think that the physical location of the hue and ISY would be irrelevant. They communicate via the local network, and both are wired, correct? Mine sit right next to each other.

My experience is much based on single-band devices, so it may not be as important as it once was, but I filter all UPS and surge suppressors as a mater of course.

Is the UPS filtered? Is it on the same circuit as the PLM? In my experience, those things cause problems for insteon signals. If you temporarily remove the UPS, does the problem go away?

Sometimes, power supplies of such systems can interfere with communications. (Sometimes not, however.) I have a few of those types of fixtures, and my system seems to work. Every now and then, though, one of those does not turn on when expected. Whether it is due to the power supplies or something else, I have never bothered to attempt to isolate. My gut feel is to go ahead with your plans if you are really sold on those fixtures. But, I would keep looking at other fixtures in case there is something you missed that you would like just as well. Besides, do not LED bulbs have little internal power supplies? I am not sure one can avoid them.

My only experience is to delete it and redownload. Did you update your firmware recently?

OK. If the program is disabled, then it should be no problem. It may be worth checking program log to see if any programs are triggered by your KPL buttons. Hopefully not. Continuing to use the cooking scene as an example, if those are the responder levels to KPL button C, then I would expect KPL buttons D-G to turn off when KPL-C is toggled ON. (Are your KPL buttons in non-toggle mode?) If this is not happening, then my first guess would be link problems. Have you tried restoring the KPL? (There are no funny little symbols suggesting comm issues or updates pending, are there?)

For the screen shots of the "cooking" scene, which controller was selected? (For which controller device are these the responder levels?) Should the scene be working properly, a program would not be necessary. In my mind, this program contradicts the scene and may be causing the problems. Why do you have this program? Is it possible that you have programs that are interfering with proper scene operation?

If the scenes are configured correctly yet the KPL buttons are not responding as expected, it seems to me that there are three possibilities: - communication problems - a program is somehow being triggered which is causing this - link problems Still, I think it is worth posting a screen shot of the scenes just to have the smart folks around here check it out. Sometimes it is easy to stare at something for so long that one can no longer see it.

I would describe the "mutually exclusive" option a little differently. Rather than say that it doesn't work, or that a scene is the only way to do this. Rather, the mutually exclusive relationship is enforced only within the individual keypad. In other words, the relationship between keypad buttons is only in effect when activating that specific KPL. It is not enforced when a given KPL button changes state as a result of a scene relationship. Otherwise, lilyoyo1 nailed it. ​If your scene is not working as you expect and described by lilyoyo1, consider the possibility that you must set responder levels for each-and-every controller in each scene. From the admin panel, select not just the top scene, but select each controller. Ensure that the responder levels are also set as described for each controller device.

No. Not necessary.

Are you certain about this. I believe STATUS conditions will be fine. CONTROL conditions will most likely evaluate false (unless, as you say, it is triggered simultaneously, if possible even.)

Disabled programs will not self-initiate, but can be called from other programs. If yours is not running when called, I would look into potential programmatic concerns.

Is motion sensor part of any scenes, or is the relationship between motion sensor and other devices established entirely by programs?

The wait does not force a re-evaluation. The wait simply provides the opportunity for re-evaluation, should a triggering event occur. If no such event occurs, the program will continue uninterrupted.

yes

Good. My best guess up to this point has been that the ISY thinks one of the devices from the program condition is still ON (when it is actually OFF). This causes the program to turn your KPL button ON. In your new program, it would surprise me if the query was necessary. I believe a program will send an OFF command even when a device is already OFF. I wonder if it was the increase to 5 seconds (from 2 seconds) that helped more. In the end, there is only one way for your KPL to be ON: this program. And this program will only turn on the KPL button if it thinks one of the conditions is true. I am with you in that I don't fully understand how the timing of the communication works, and also wonder if the amount of time it takes for your devices to turn off are affecting this program.

Everything that I see here appears correct (or at least how I would do it). The only thing I begin to wonder about is whether ISY status for some of these devices does not match actual device status due to some communication issues or similar. I would still try my suggestions from a couple of posts prior, but I am running out of ideas, besides checking to confirm ISY is accurately tracking device status.

Your analysis of the log was deeper than anything I have ever done. I have looked for gross indicators of programs triggered or comms issues, but never a line-by-line analysis. Certainly interesting and seems accurate. What is not clear to me is why you have a program that turns OFF the KPL button? Is this a program that simply checks the status of all the pertinent devices and turns the KPL ON if at least one of the devices is on, and turns the KPL OFF if they are ALL OFF? Is that the program 001D? If you look at the programs list is this the only program triggered by such a series of button presses? Care to post this program? My inclination would be to try a couple of things. 1) Toggle the kitchen fluorescent lights and observe the KPL button. Does toggling the switch from on-to-off cause the same reaction to the keypad button? 2) Temporarily disable program 001D. Does your problem go away if you perform similar experiments?

Wow. I would have never thought this could happen. Is this device a controller or responder in the scene (responder, I assume)? How easy would it be to temporarily remove the load connection from the switch and see if the problem goes away? Have you watched the event viewer for clues? With the switch still part of the scene, press the "Bedroom KPL - Kitchen Button" and immediately check the program log to check (triple check?) to see that there was not a stray program running out there triggered by the fluorescent light switch which might cause the KPL button to come on.. most that I have seen add a screen shot or snippet of the admin console.

It is not your understanding of the "IF/THEN/ELSE" logic that has me concerned. Do any of your programs have any "waits" or "repeats"? Before fully restoring it, check to be sure the non-toggle mode works as you expect. Make sure you disable any program that may affect this device, also. What do you mean by "link it directly"?

In this mode, the button will not turn itself on. If it comes back on after turning itself off, then something is commanding it to do so, either by it being part of a scene and a program turning on the scene, or someone toggling that scene somehow. I strongly suspect you have something funny in one of your programs that is commanding this button to come on. I doubt that resetting and restoring this device will solve this problem. I would take inventory of this button in two ways: - identify all the scenes that this button is part of, and whether there are any controller devices part of those scenes. - identify any program that triggers any of those scenes. Feel free to post the results of your inventory and of the programs. I suspect someone can find the problem.

I still get things wrong and continue to learn (or relearn) things here. Questions are usually welcomed and helpful. Besides, your question was completely understandable....the wait (and repeat) statements can be tricky until you learn to exploit them fully.

I am sorry, but I am unfamiliar with a couple of these settings. From where do you access these settings? Are these paraphrased from the "options" available via admin panel selection of the IOLinc? Why did you enable the "relay set via sensor input"? What do you believe this option does that benefits you? (it sounds like a potential cause of your door opening by itself.) It sure seems that things have gotten complicated in your case. My suggestion is to back up a step and describe WHAT you want to happen? Do you want the button B to consistently reflect door status (is open=ON or open=OFF)? Do you want a single button press to trigger the door? Have you read the wiki article describing the suggested setup for this?

I suspect otherwise. If the status of the sensor turns off during the wait period, the program will retrigger, evaluating false, and the message will never be sent.