oberkc

I wonder if you could use one of the notifications. Depending on your cellular network, one can send an EMail message and receive it as text. (or, at least, one could in the past.) For example, sending an EMail to xxxxxxxxxx@vtext.com (xxxxxxxxxx = your phone number) would send a text message to your Verizon phone. Other carriers have similar capability. Perhaps that would work for you.

I wonder, given the modem restoration having solved your problem, if this is a sign of impending PLM failure.

I took the program listing as conceptual, not using strict syntax. For the purpose of someguy's question, that was sufficient in my mind.

I understood that a program such as this would continue to the end, unless it had wait, or repeats, in the statement. A change in the condition would NOT halt it, I thought. Perhaps this aspect has changed. Certainly, I would try stusviews recommendations.

Mr Bill. Perhaps I am confused. Your two examples: from sunrise to sunset (same day) from sunset to sunrise (next day) are clearly opposite time periods. I would not expect both to behave the same. Compare that to the original (post 1) program from sunset to sunrise (same day) Moving back to the cooper0705 program...I agree, let us keep it simple. I continue to think that there are no more problems beyond the "same day"/"next day" condition and remain unclear regarding your earlier post (#6) It is this condition that I find flawed, since sunrise (same day) occurs BEFORE sunset.

MrBill. I am not so sure this is accurate (or is at least misleading). While the sunset and sunrise conditions trigger only twice each day, they would be true at all points in between. I use the from-to condition in several programs. Works like a champ.

Ah. Thanks.

Yes, it is that simple, or even simpler, depending on what you are trying to accomplish. If you want a light to come on with the door, staying on until it closes, you could create a scene with the IOLinc relay as controller and light as responder. If you want a bit more control over when the light turns on and off, a program may be needed. Yes, it should be that simple. In your program, you might want to change your sunrise condition to "next day".

Yes, it is. But the title of your post suggest some concern about using the hue and ISY in the same room, and I still don't see a question. Perhaps none is intended, and you are only trying to point something out for others to be aware. If this is the case, thanks. But...if your intention is to seek input from others, it might be helpful to state your questions.

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