oberkc

My process was, simply, trial and error. Start unplugging things. Start removing light bulbs. Turn off circuit breakers. After each, determine if comms got any better (scene tests, things that once failed now worked, etc...). I never found a magic troubleshooting method. My hot water heater is gas fuel, but uses electric for control system. I simply plugged it into a filterlinc. I had two access points (range extenders) originally installed about two feet (actual wire distance) from the panel. Over time, I added enough dual-band devices that I decided to remove the remove the access points to see if they mattered any more. They did not. On the other hand, others report good results with the passive phase coupler (signalinc?) which is mounted very near the panel in most cases. In my mind, near the panel makes sense, but I cannot say my experience either confirms or denies that theory.

I certainly did, and this forum has more than a couple of examples of others with similar experience. Ultimately, besides the basics (phase coupling, clean circuit for PLM), I needed to identify the big culprits causing this problem. For me, it was some home theater stuff, an on-demand hot water system, an electronic keyboard. There were probably other things, but filtering these helped a lot. Like stusviews said, one must positively identify the culprit(s). This is rarely easy.

Unfortunately, things are looking bad for your comms. Could it be a bad PLM (maybe)? Could you have something on your electrical system that is really fouling things up (maybe)? The trick, of course, is trying to narrow it down a bit. I remain curious about my unanswered questions: whether you have tried moving the PLM, and what other devices you have on your circuit including the PLM. Answers to these questions can provide some clues. I wish I had a nice, easy process for figuring this out. Unfortunately, all I know to do is create hypotheses based on others experience and test them out by unplugging, turning off circuit breakers, and moving things.

And you want these levels to be something other than defined by the scene? Create a second scene having the same devices, with other desired ON levels. Use a program to turn on the second scene. Regarding keypad button, that is one of those silly secret tricks: create a scene having only the KPL button. Turn that scene on or off.

There is a process described in the manual for most of the dual-band devices. Generally, it consists of rapidly pressing the "set" button of one device four times, and observing the response of the other dual-band devices. You should perform this test to be sure.

On what do you base your understanding that the programs quit working? Lights don't respond? Program log "last run" is incorrect? A failed PLM would not cause the programs not to execute, as far as I know. Is it possible that, somehow, your programs became disabled?

I do not suspect ISY. Maybe PLM, but I more suspect random comm problem. Have you confirmed communication between legs of your electrical system? What other electrical gadgets are on same circuit as PLM? Have you tried moving PLM to another circuit?

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.