apostolakisl

I am pleased to hear that things are working. However, you should still check your link records. You might have differences between ISY and your actual devices since it sounds as though you made changes to your devices and then did an ISY restore to prior to the changes. Under Tools/diagnostics/show device links table. After it pulls all the records from the device, hit the compare to ISY button and see if it all checks out. If not, you need to fix it.

I don't know really what's going on here. It's kind of hard to tell without being there. You may have some bad links. The fact that you restored an ISY backup after having made changes to links on your devices is a definite no-no. Your link records on your devices will not match what ISY thinks is there. Restoring an ISY backup does not change the links on the devices. You can always factory reset your devices and then use ISY to restore the devices. This will ensure that ISY links tables and your devices are the same. You could also use ISY to check the link records and compare to its expected links and only restore devices that are wrong. I don't know how many devices you have. If you only have a few, it might just be easiest to factory reset all of them and then have ISY restore each device.

What type of bulbs do you have? Sounds like noisy load issue (cfl bulbs?)

Replace with is exactly what you need. Remove the old switch, install the new one. Add it to ISY (no need to name it), then use the "replace with" function. Done. Everything transfers over to the new switch including it's name, all programs it might be listed in, and all scenes that it is a part of. Oh, and one important point. Both the new switch and old switch need to be in the root folder. In other words, under "my lighting" in the tree. . . not in a subfolder.

You shouldn't delete the 4 stop program commands. Those don't produce any insteon traffic and will still be necessary.

There is a section of the wiki with a bunch of sample programs as well as explanations.

There is a good chance it is a comm failure. As I mentioned earlier, when you have a program send a bunch of individual light commands all at once there gets to be a bunch of traffic and failures are more likely. I suggest creating a scene and entering those 4 lights into it, all as responders only. Then set your program to set the scene off. A scene "off" command is a single piece of Insteon traffic regardless of how many lights are in it.

A program such as this If KPL C is switched off Then anything Can not have any affect on anything unless KPL C button is physically clicked from on to off (in which case your then will run). Unless you added that "if" clause to one of your other programs . . . in which case it would cause them to run false (since the button wasn't pushed). As I mentioned your first set of programs is valid and it would be a very odd program that could conflict with it . . . at least the turning on part. It does happen sometimes that the "enabled" box defaults to unchecked when you first write the program and you don't notice it. I have had that happen. The best way to trouble shoot is to change the times on your program to just a minute in the future. Then watch the program summary page to see which programs run and whether they run true or false.

As I understand it, disabling a folder will only stop included programs from self-triggering. I don't believe it will halt on-going programs, nor will it prevent initiation of these programs from other sources (such as being called from other programs). Perhaps (I don't remember) there is a program action that can halt a currently-executing program? Correct. Programs in a disabled folder won't self trigger. End of story. To stop programs from running. If KPL C is switched off Then Stop Program 1 Stop Program 2 . . .etc Also include Set light 1 off set light 2 off In this way, when you come home and switch kpl c off, it will disable the folder, turn the lights off, and stop the programs from turning the lights off at 10pm (in the event that you had manually turned it back on).

The first set of programs you posted screen shots should have worked. Reasons for not working: 1) The program wasn't saved 2) The program was disabled. Be sure to check that the "enabled" box is checked. 3) There was an insteon failure to communicate and ISY didn't know kpl c was on.

My guess is you had it set to "control switched on" for your dusk activation. If so, it needs to be "status on". Your dusk program is triggered by dusk occurring. . . kpl c status on is an additional condition that must also be met. Control switched on program only run true at the instant you push the button (provided everything else is true). Your off program is triggered by pushing the button (control switched off).

You'll need a new scene that contains the lights, but not button c. If button c is in the scene as a controller the lights will turn on when you turn the button on. You only want the lights to turn off when you turn the button off, not the opposite.

"control off" is probably going to be more appropriate than "status off". Control off will only respond to actually pushing the button where status off would respond to other means of turning button c off. You should make a scene. It is much less insteon traffic. . . one insteon command can take care of as many lights as you want. Listing each light separately in the program is way more traffic all at once which is going to have a higher failure rate. Plus it is easier to add and remove lights from a scene than it is to add/delete parts of a program.

I attribute it to ISY being "event driven". Events seem to trigger programs simultaneously. They may not execute to completion simultaneously, but they at least all queue up based on conditions at the instant of the trigger. The only caveat is that I have not tested this when there are multiple conditions. If that has any affect on speed of processing/order of processing I don't know. But I would hope not, since then you would get inconsistent results.

So I guess to put it into a "pearl" When a single trigger condition changes the state of a folder and is a trigger condition for a program inside that folder, the program will either execute or not execute based on the folder's status at the time of the trigger (not the state after the change). Wow, that is kind of hard to say.

Given that the programs in the folder are disabled if KPL C is off, I am not sure that such a program would run. I believe it would be best to keep this program out of the folder. This is a good option in my mind in that this allows a bit easier maintenance and updates for new devices into the affected scenes. The program runs regardless of whether it is inside or outside of the folder. I had the same thought and tested it before posting.

Create a scene with all of the lights as responders. Whenever control kpl c is switched off Then set scene xxx off

Will act as a trigger only upon recipet of an "off" command. Will evaluate as FALSE when triggered. Evaluates as TRUE if program evaluation is triggered by another condition. This (finally) explains the behavior but as a developer I still feel strongly this is a bug. Logical statements should not evaluate to 'FALSE' when the evaluation succeeds. That is bug #1 however if you accept that is how UDI did this (a bit backwards from about any other system I can think of) then bug #2 is that the statement evaluates as TRUE in any case when triggered by another condition (an If Control should only evaluate to TRUE if the controlled item was activated) I realize both aren't bugs (one negates the existence of the other) but do you 3 really think this is 'intended' behavior? Yes, ISY is event driven. "If" statements are affected by any event regardless of how it came to happen (that includes its own then/else clauses). Your first program ran true, the variable changed, this triggered the program "if" again, this time it ran false and ended. This all happened in microseconds. Your second program ran true, the variable changed, this triggered the program "if" again, it ran true again (because "is not" was true and included as an "or") which kept looping back. If you just switch to an integer variable this won't happen since integer variables are never a program trigger. They do evaluate when something else triggers the "if" clause, but they don't cause the evaluation. If you need that same variable to act as a trigger somewhere else, you can have both a state variable and integer one representing the same thing and set both at the same time, but only use the integer variable in your "if" clause of this program. Note: When you name variables, include an "s" or "i" in the name for ease of differentiating. ie $sDefault_Occupancy_Time_In_Hours or $iDefault_Occupancy_Time_In_Hours

That appears in complete opposite to what LeeG stated "Press the device On paddle/button, the Programs | Summary will show the Last Run Time does not change. With If Control the command received has to match the command specified in the If for the Program to be triggered." This is because Lee was referring to a different program that only contained a "switch off" command I agree your reading *should* be how it works... Bill Just to be 100% certain I ran that program last night and it worked as expected. In other words, click "on" and the program runs true click "off" and the program runs false any other action on the switch does nothing (ramp up/down fast on/off etc). edit. . . I just read your program. The loop is from the variable. You are probably using a state variable which is triggering the program. Try an integer variable EDIT

Just be careful not to mess your equipment up. On heat mode there is a reversing valve and it usually turns heat strips on as part of a defrost cycle. You wouldn't want to mess that up and cause damage or freeze up your unit.

Lee's above program will run true when you click "on" on the icon dimmer, and false when you click the "off" side of the dimmer. It can not create a loop. The design of this program has 2 triggers (clicking "on" or clicking "off" on the referenced dimmer). No other action will cause the program to run (natively). "On" click triggers the first line. . . it is true. The second line also evaluate as true because indeed clicking on "is not" clicking off. "Off" click triggers the second line. .. it is false. The first line is also false because indeed clicking "off" is not "is" clicking on. A note: Using the terminology "clicking" instead of "control" might help you. It really drives home the point that you have to actually push the switch and make it "click". No other action besides actually pushing (clicking) the switch triggers a "control" condition.

This is just another hot water heater instead of your current tankless. No this is a point of use instant water heater. I think I could put it under my sink so there is no little under sink tank to keep warm. Would this work? Yes, it is another hot water heater. It is a smaller electric version of what you already have hanging on the outside of your house. It will work. . provided you have a 240v 60 amp circuit available under your sink.

These are what I was talking about. They only turn on when they are actually going to be used. They don't necessarily give you "instant" hot water, but they do greatly speed up the process. Especially if used with a motion detector so that they flip on prior to you actually turning the sink on.

I don't recommend this. It forces your tankless heater to cycle all the time. Every few minutes the pipe cools down and this thing turns on. Notice it says "be sure this doesn't void your warranty" because it usually does .. . for good reason. Although, you can add a small holding tank under the sink and recirc to the holding tank. The holding tank takes a lot longer to cool off so you don't get the constant cycling.

This is just another hot water heater instead of your current tankless.