oberkc

I have always viewed this as a design decision rather than a bug. It does have its advantages in certain cases, and disadvantages in others. Others, however, have voiced similar viewpoints to your own. I believe that there is a way. It is the one I suggested. Alternatively, you can "disable" a program, which restricts a program from self-initiating (allowing the status to be reevaluated). I think you will find sufficient flexibility in programming the ISY, but it does have some learning curve to fully exploit.

I have always understood a togglelinc to be a switch that is manually turned on or off. How does this indicate whether a door is open or closed? Are you sure that this is the actual name of the device you are using? Regardless, I can offer some conceptual ideas and you can fill in the details based on your setup and devices. Create two programs: if status tooglelinc is ON <<< assuming ON = OPEN and control motion sensor is set ON << then perform action1 else do nothing If status togglelinc is OFF and control motion sensor is set ON then perform action2 else do nothing Keep in mind that this action will be triggered EVERY TIME the motion sensor sends the ON command. The frequency of this is based, in part, on how you have your motion sensor configured. Also, the fact that your togglelinc does not indicate current state is, in my experience, a symptom that something is wrong. This is not normal.

Like LeeG suggests, I and I concur...I believe something in your program is changing and triggering your program, likely changing status to false during the 30 minute wait. Look at your program list and find the current status of this first program? Is it false? When was it last executed? After 7:30 and before 8:00? The purpose of breaking it out into it's own program is to avoid it being interrupted by a change in status. Once running, unless called manually or by another program, it will continue to the end. No wait statements will be interrupted.

Without knowing what are the names of these two programs, or knowing what makes programs "IsShabbatOrYomtov", 'is9Minyan', or 'isRaining' to be true or false, it will be hard to say what is causing your programs to halt execution during the wait statement. Assuming the conditions of these two programs accomplish your goals, my temptation would be not to worry about attempting to isolate your problem. Instead, break out the THEN paths of each program, putting them into separate (disabled, without IF conditions) programs. For example, create a program (disabling it) that looks like this: IF THEN Set 'Dafna's Bathroom' On Wait 30 minutes Set 'Curlers' On Set Scene 'Master Bathroom' On Set Scene 'Closets' On Set 'Upstairs Bathroom' On Set 'Jerry's Bathroom' 50% Wait 2 hours Set 'Curlers' Off Set Scene 'Master Bathroom' Off Set Scene 'Closets' Off Set 'Upstairs Bathroom' Off Set 'Jerry's Bathroom' Off Set 'Dafna's Bathroom' Off ELSE Then modify your first program to look like this: If Program 'IsShabbatOrYomtov' is True And ( ( Time is 7:00:00AM And Program 'is9Minyan' is False ) Or ( Time is 7:30:00AM And Program 'is9Minyan' is True ) ) Then run new program (then path) Else - No Actions - (To add one, press 'Action') Take the same approach to the second program.

I assume LeeG is speaking of my response to your question originally posted on smarthome forum. I paste it here: The answer to this question will partly depend on how you have set up your sensors and IOLinc. Does sending an OPEN command cause the door only to open, and CLOSE only to close? Or...does OPEN or CLOSE cause the door to move, regardless? The simplest might be to create three programs: if status garagedoor1 sensor is open <<< depending on setup, could be ON or OFF. then wait 15 minutes close garagedoor1 << else nothing Do two other programs just like it for the other doors.

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.