oberkc

Stusviews approach of splitting the program into two is probably good. I am not convinced, however, that this has been the cause of your problems. The only thing I see that could interrupt your wait statement (short of being triggered by another program) is the sunrise condition. (Closing the door should not trigger or interrupt the program, (assuming ON is OPEN)). Definitely check the program logs. If, after five minutes, the lights remain on (and it is not sunrise) check the status of the program. Is it true or false? False would be an indication that your program was interrupted. True would suggest a comm problem.

Keep in mind... if sunrise+20 occurs during a wait, the program will halt and run thr ELSE path.

Yes, the even continues to run, but I have never seen a problem with turning off a light that is already off. Continuing your scenario, let's say someone opens the door during the countdown (at 22:09:45 in this case). The first program triggers again, in turn calling the second program. If that second program was already running, calling it will halt the execution and restart it from zero. So, whenever you open the door, whether the light is on or off, you will get a fresh countdown. "Wait" and "Repeat" actions can (and will) be interrupted when a program triggers. If a program is in the middle of a wait condition and something happens that causes a trigger of the program, the program halts (does not continue to end), re-evaluates, and carries out the action based upon the new evaluation. This particular feature of ISY is a topic of MANY threads.

So, is not the light wired to the "zw 003 multilevel switch"? Does not turning that switch off also turn the light off?

I am not sure that I think either way, and not sure I even understand the difference. My personal approach is to minimize number and size of programs, in that order. Best approach is what fits your way of thinking and is easiest to understand after time has passed and you need to go back and look at your programs.

stusview, are you not concerned that the first statement in the THEN path would retrigger the program, interrupting the wait statement?

jon102034050, I don't find it easy trying to follow this conversation, but I believe this is your latest program (above), correct? As some have pointed out, you need to move the OFF command to immediately follow the wait command. I also believe you have a potential problem that closing the door (Elk Zone 'deck door') would end the "violated" state and interrupt the wait statement. Unfortunately, I don't use the Elk system so I do not know if there is a zone trigger similar to a "control" statement for insteon devices. Assuming not, you will need to separate this program into two: ---------------------- if elk zone 'deck door' is violated and from sunset to sunrise (next day) then run next program (then path) else nothing ----------------------- next program: ---------------------- if nothing then Set 'ZW 003 Multilevel Switch' On Wait 20 seconds Set 'ZW 003 Multilevel Switch' Off else nothing -----------------------

Interesting. I have an end-of-day program that has always seemed to run slower than I would expect, and in different order. Of course, there is zwave involved, so that may explain things. In my case, it is not a big deal, so I have never bothered to try to figure it out, but that could be it.

Are they pointing towards a ceiling fan or something? On a more serious note, I don't recall ever hearing of such a thing. Certainly I have not experienced it.

Understanding the difference is critical in fully employing the power of the ISY. If there are questions, it never hurts to re-look at user manuals and wiki.

Yours is not the first post on this subject. I had a system such as this a while back without problems. More recently, I recall that the responses from others indicate no problems.

Last line in the THEN section causes the ELSE PATH to run. (or at least that is what I intended with the last line.)

Perhaps I was a little too quick to offer a solution. Yes, in retrospect, the first program would restart the second. It looks as if you have found a perfectly viable solution. As an alternative (and an exercise) you could also try: Hot Water Request - [iD 001A][Parent 0001] If Control 'Mechanial Room / io.Hot H20 Control-Sensor' is switched On and program 'Hot Water Run Pump' is false Then Run Program 'Hot Water Run Pump' (Then Path) Else - No Actions - (To add one, press 'Action') New program just for running the pump. Hot Water Run Pump - [iD 001B][Parent 0001][Not Enabled] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $v_hot_water_calls += 1 Set 'Mechanical Room / io.Hot H20 Control-Relay' On Wait 30 seconds Set 'Mechanical Room / io.Hot H20 Control-Relay' Off Wait 20 minutes $v_hot_water_calls Init To $v_hot_water_calls Run Program 'Hot Water Request' (else path) Else - No Actions - (To add one, press 'Action')

In my experience, if nothing is in folders, then deleting your remotelinc buttons from any scenes should work, then just delete the remotelinc from your device list.

well, without getting into the variable discussion, or why (or if) your program is being retriggered, the simple solution is: If Control 'Mechanial Room / io.Hot H20 Control-Sensor' is switched On Or $v_hot_water_control is 1 Then run next program (then path) Next program: if nothing Then $v_hot_water_control = 1 $v_hot_water_calls += 1 Set 'Mechanial Room / io.Hot H20 Control-Relay' On Wait 30 seconds Set 'Mechanial Room / io.Hot H20 Control-Relay' Off Wait 20 minutes $v_hot_water_control = 0 $v_hot_water_calls Init To $v_hot_water_calls Else - No Actions - (To add one, press 'Action')

Waits do not retrigger the IF statement. Instead, waits allow a program to halt midway should the IF statement be retriggered by some other force.

Jack, Your suggestion is very similar (adding a scene) to his original post. I suspect it will work most of the time, but I was concerned about one possibility: what happens if someone, somehow, turns on one of those lights, but the motion detector fails to pick up motion? (The lights would stay on indefinitely.) While it may not be possible, I think it valuable to also trigger the 10-min countdown upon turning the lights on, just in case.

no, but hopefully the timer will turn off and see motion well before 10 minutes. If this is a major concern, perhaps you should minimize the time out of the motion sensor to that it turns off quickly.

And most of those are network resources, as I suggested. I had forgotten about the possibility of wiring a camera to an IOLinc or similar sensor, but even that is not related to the "camera". Polyglot...well...that one never comes to mind for me. I figured as much. Which model FLIR camera do you use?

Exactly!

I suspect you have the best solution. I am not sure in today's environment that I would trust a software-based ability to shut down a camera. Disabling power seems like the best option to me, and you have come up with a creative way of doing it. I have been abusing the best buy return policy. I have tried a FLIR Lorex camera, but found it, too, relied on the cloud. Even though I could see the image on my IPCamViewer, it was through the lorex servers. Camera returned.

It may be enough to change "control" to "status" of your existing program, but there may be some edge cases where the lights are turned on for some reason and mostion is never detected. Don't think variables are needed, but others might like them for some reason. Try something like: if status light1 is on or status light2 is on or status light3 is on then run next program else nothing next program: if status motion sensor is off then wait 10 minutes turn off all three lights else nothing (This approach requires that you have not disabled the OFF commands from the motion sensor)

I don't use the portal, but assume it is there as a bonus convenience for you to view your cameras remotely and securely. Does adding them to the portal give you an IP address for each camera? I use ipcamviewer to view all my cameras. Unfortunately, many of the latest generation of cameras are designed exclusively for use with the cloud, and that often makes them unavailable to many of the third-party apps. I continue to resist the use of cloud services for continued viability of a product (echo being my lone exception). One must be pretty selective with cameras today, unless one is happy using the camera app and cloud from the same company.

I know of no camera that would show up on the admin panel or that can be added to insteon scenes. I dont believe there is any connectivity between isy and cameras, short of creating a network resource.

1. Links from manual process? Residual links from prior system? Failing PLM or comm problems? 2. Not that I can think. 3. Yes. 4. 5. Some devices are part of more scenes than others?