oberkc

One problem you will have with your program (unrelated to your posted concerns) is that if sunset occurs during an on-going wait period, the wait will halt and the fountain will not turn off. I suggest adding a command in the ELSE clause to turn off the fountain scene.

Nothing additional to purchase of which I am aware. Make sure your program uses "next day" if sunset to sunrise (next day) <<< Watch program status after sunset...does it turn true?

Perhaps updating the firmware to a newer version would help. Also, make sure your admin panel is up to date.

I agree that I also find it unlikely that being a virtual three-way has nothing to do with this.

As I understand the way things work, if a device looses link records with regards to the PLM, or vice versa, the ISY may not see commands from that device. Besides, it is simple to accomplish and is unlikely to hurt anything. Sometimes, I understand it can help to restore the PLM, also. I don't know why devices can loose link records. Do you see any other signs of comm issues or slowness?

The program is simple enough that I think we can declare that this is not the problem. I am unsure why a status would work, but not a control. Is the device part of a scene? Does the event viewer not show the receipt of the control command? What happens if you restore the device?

While I don't expect incandescent to be a problem, it is still worth temporarily removing the bulbs to see if this changes anything. The only other thing that comes to mind is proximity to switches. How far away is the lighting sensor to the trouble switches? I was also curious as to the image...is the direction of the perceived cluster of lighting strikes a clue?

What type of bulb do you have in your back porch lights? What happens if you temporarily remove them? Have you tried a different load in the fixtures?

This sure sounds abnormal to me. Have you checked the keypad manual to determine how to manually set the backlight levels? Does it involve button B somehow? I wonder is there is some failure or stuck button on the keypad that is causing this.

I don't find it hard to believe that this can't be recreated. I can't even recreate it on my own machine at this point.

I added a few new units (dual band) also during that sale. It seems to help with speed of response with my system, so I would suggest that your hope is not unfounded.

For what it is worth, I just updated to 4.1.2 (is that the latest?), including the UI, and experienced similar issues...the automatic write updates toggle buttons were not there. Interestingly, when I logged back in later, they returned, only to go away and come back in subsequent visits. I observed no particular relationship to any other event.

I suspect what you desire is not possible without extraordinary measures. Still, I am curious what you mean by "the standard HMI". Are you talking about the ISY admin panel or dashboard? (BTW...I want virtual devices for my android desktop. I have been unsuccessful so far.)

Like Xathros, I find the IOLincs quite reliable....it is the communication that can let you down from time-to-time. There are several considerations, I believe, to having confidence that your door is closed (or open, or whatever). First, one must decide which status (open or closed) is a priority of knowing truth. You have chosen CLOSED. So have I. Then one must decide how one wants to indicate CLOSED on a keypad button...do you want it ON, or OFF? I have chosen OFF = closed. Once chosen, I believe it best to continue with the sensor, both type and mounting location. Choose the type where sensor in contact is OFF (or ON, if you prefer ON = closed). I believe it best to avoid the sensor reverse option of the IOLinc, out of concerns that this may get reset during power outages. Then locate the sensor in such a way that it is in contact only when the door is FULLY closed. Then, put all the keypad buttons into NON-TOGGLE ON (or non-toggle off, if you want ON to indicate closed). Putting your keypad button in non-toggle mode will ensure that there is no way that someone can manually put the button in a status that would falsely indicate door closed. Link your sensor and your keypad buttons in a scene, with sensor and buttons all as controllers. Make sure you have no programs that can turn OFF your keypad buttons.. Configured this way, there is ONLY ONE WAY for any of your buttons to be turned OFF: if the door is closed. If you find one button on, but the rest off, you can be near certain that the one button is an anomaly. Having said this, I remain a fan of webcams.

Make sure you set the button responder levels to zero for EVERY controller.

This tends to suggest, in my mind, a keypad failure. Hopefully, it is not a sign of things to come.

Temporarily remove power from ISY?

I don't have the time right now to sort through everything, but I noticed a few items off the top: This program might be better using "control" rather than "status". In it's current form, it will trigger when the doors are closed, also. I would be surprised if this program evaluates true EVER. To run TRUE, this program must see the simultaneous receipt of two commands (one control statement AND another control statement). I am not even sure that this is possible. Perhaps whatever troubles you are having are related to these concerns?

If the folder condition is false, programs within the folder will not self-initiate. They can, however, be called from other programs outside the folder.

Yes. I missed that. Thanks.

Be aware, also, that what constitutes a "scene" is defined a bit different with the ISY that with the basis insteon devices. If you see "scene" used in the manuals of individual devices, that generally refers to a relationship between two devices. With the ISY, a scene can have practically unlimited number of devices. Are you suggesting that you have manually linked insteon devices without using the ISY...by putting one device into linking mode, and adding the responder manually. I generally find this a bad idea when one has an ISY in their system.

Perhaps, more importantly, do you know WHY this solved your problem? Understanding the difference between control and status is a key concept.

Xathros is correct, and I could have misunderstood your intentions. If you plan to initiate light levels at certain times, then I stand by my original assessment. If, however, your intention is to change the levels that your lights turn on in response to a local button press, then there would be a noticeable delay if using separate scenes and programs.

All my outdoor flood lights are LED. I have noticed no problems, though I make no attempt to dim them.

EricK beat me to it, but his is the approach I suggest, as well. Set up two scenes and invoke the proper scene based upon time.