markens

Your statement is correct about needing to add both devices as (only) controllers in a cross-linked scene. What I was trying to say, however, was that the ISY automatically (and transparently) adds the required responder links in each of those devices in this same situation. So: The ISY only shows the devices as controllers in the cross-linked scene. But the devices themselves each have controller and responder links written to them. Exactly as if you manually cross-linked the two devices in a setup without the ISY. --Mark

A key concept with regard to the ISY: In general, when the ISY adds a device to a scene as a controller, it automatically adds that device to the scene as a responder as well. This makes creating cross-linked scenes a snap, since the switches are all added as controllers and the ISY takes care of creating all the proper responder links as well.

This allows you to combine both the ON and OFF actions in one program. As written, if any of the lights goes on, the IF is TRUE and the program's THEN executes (turning on the KPL-A scene). But if all the lights are off, the IF logically evaluates to FALSE causing the program's ELSE to execute (turning off the KPL-A scene).

The simple answer is because the ISY does not allow you to directly control (as a "device") the non-load buttons of a KPL. I have no idea why, whether it's an Insteon limitation or a design choice in the ISY. Putting a button in a scene and controlling it that way works fine though. Hmmm. My answer to this would be: A scene is a grouping of devices that you want to be able to turn on and off as a single event. Each device can have individual response (light and ramp levels), although all member devices respond at the same time to a scene command. Scenes are fully supported by Insteon devices, and ISY scenes provide the same functionality. Programs add a higher logic to the process, allowing additional functionality and processing. They definitely serve a different purpose than scenes, although complement them very well. Programs allow you to be much more creative in designing your automation events. The UDI Wiki has lots more good info: http://www.universal-devices.com/mwiki/

Rand gave a quick answer to this. I went back and reread your original post, and here's some additional info based on what I think you want to do: - You have some kitchen lights and a KPL-A button. - You want KPL-A to turn them all on when it's turned on. (And presumably turn them all off when it is turned off.) - You want KPL-A to light up when any of the kitchen lights are turned on individually. And turn off when the last one is turned off individually, if individually controlled. Right? Then here's what might work for you: 1) Put all your lights in an "all kitchen light" scene, as responders. 2) Put KPL-A in that same scene, as a controller KPL-A will now turn the "all lights" scene on and off, and the KPL-A light will go on/off accordingly. You probably already have this part done. So now you need to address the other desire, to control the KPL-A light for the other conditions. Continue... 3) Put KPL-A in a scene by itself as a responder (in addition to the scene it's already in above as a controller). You can now control the KPL-A light independently of the "all lights" scene by turning this scene on/off. If you want KPL-A to be on whenever any of the lights is on, and off when they are all off, then this program is one way to do it: If Status 'kitchen light 1' is not Off Or Status 'kitchen light 2' is not Off Or Status 'kitchen light 3' is not Off Then Set Scene '[KPL A]' On Else Set Scene '[KPL A]' Off By using Status in the program, it monitors lights no matter how they're turned on/off. By using "not Off" then the lights don't have to go all the way on (100%) to trigger the KPL-A light. And, of course, the "all lights" scene still works as expected. One nice side benefit is that KPL-A can always be used to turn all the lights off even if only one of them has been turned on. I hope this helps and makes things more clear. It's very similar to functionality I have running in my own setup. --Mark

The KPL button must be part of a scene for the ISY to control it. If you want to control the button light independently of any other device, then put it in an ISY scene by itself. If it's part of other scenes, then it should behave as you expect in those scenes as well, as either a responder or controller. --Mark

The ISY is actually pretty smart about this, and it's easy to do. When you add a device to a scene that can potentially be a controller in that scene, a popup appears that allows you to select controller or responder for that relationship. A device can be a controller in no more than one scene, so once that is done you can add the device only as a responder in additional scenes. You can use the Tools->Diagnostics->ShowDeviceLinksTable function to display current links table for a device, and then click Compare (bottom of window) to compare that to what the ISY thinks it should be.

Yes, this almost certainly is what's happening. The Program Summary tab is useful to monitor. The Activity column shows if a program is executing or not, and you can easily see if a long wait has terminated prematurely. Tools->Diagnostics->EventViewer is also handy to monitor control and status events (see below). That would probably do what you want, depending on what other controls might be influencing things. This is a good time to point out the difference between Control and Status events. So far, it seems you've been using Status. Control might be more what you're looking for. The ISY maintains its idea of what the status of each device is. A Status condition monitors this latched status. A Status event happens only when the ISY's idea of that status changes, and is independent of what caused the status to change (switch event, ISY scene, etc). A Control condition, on the other hand, looks for an event caused by a physical operation of a switch or sensor (ON/OFF/DIM/etc event) and is received (and evaluated) regardless of the current status of the device. So, your example program will work as you expected if you change Status to Control: If photobeam control ON Then set scene pathlights ON wait 10 minutes set scene pathlights OFF This program does not check for photobeam control OFF (a different event than control ON). So when that happens (and its status also goes off), this program does not see an event and happily continues waiting until the 10 minutes is up. If it happens to turn back on during that time, then another event will be received: the wait will terminate, the condition will evaluate (true), and the THEN will start again, effectively resetting the timer to 10 minutes. Note that, as written, there is no way that the IF of this program can ever evaluate to FALSE, and so the ELSE of this program will never execute via evaluation of the IF. This is why you often see the following very useful construct in programs: If someswitch control ON and someswitch control not OFF Then do something when switch turns on Else do something else when switch turns off --Mark

But it will reevaluate the IF. Here are some principles, restated: 1. The conditions in an IF part of an enabled program are always evaluated when any of those conditions change (creating an event), regardless of whether the program is idle or executing THEN or ELSE parts. 2. If the program is running when this happens, then that instance of the program is immediately terminated before the conditions are reevaluated. 3. Whenever the IF conditions are evaluated, either the THEN or ELSE then executes based on the TRUE/FALSE result of the evaluation. --Mark

Maybe this will help clarify: Rand said "when any of the conditions change the program is evaluated" -- which means that the IF clause containing those conditions will be evaluated, and either the THEN or ELSE is executed based on the result. The not-so-obvious side effect is that this evaluation happens even if the program is currently already running (either THEN or ELSE) when any of the IF conditions change state. So the observed behavior is that the program stops, reevaluates the IF, and then could run the ELSE instead as you have seen. Note that the IF is not actually continuously evaluated (which implies continuous IF->THEN/ELSE->IF->THEN/ELSE->IF->etc execution). It is only evaluated when any of the conditions in it change state. For example: a switch status going from ON to OFF, a switch control event received (which is always a new event, regardless of current switch status), arriving at a specified time, etc. A subtle semantic distinction, but it will help understand the behavior. Look at it this way: The conditions in the IF will always be reevaluated when any one of them changes, and then the THEN or ELSE will run once until it's done. If the execution part is long lasting (with repeats or waits, for example, perhaps indefinitely), then it will be interrupted as described above when one of the conditions changes, forcing reevaluation and starting the process over again. It is perfectly acceptable for a program action to actually cause that to happen, which I think is what you are suggesting.

There are two different things happening here. Your disabled program does run when "manually" invoked by the initialization program. Since it is invoked via the IF clause, those conditions are evaluated and the resulting (THEN) part is run. And it waits. Presumably as you want. The problem is that the disabled program does NOT see the switch events when not manually called (even if it is already running via the previous invocation). The program must be enabled to allow the switch events to (re)start the program and evaluate the conditions. So, you'll need to come up with some other way to enable those events when desired. (Sorry, no suggestions on that part.)

No mystery here: The program status simply indicates whether the THEN (True) or ELSE (False) section was used last time it ran. So, status of the Queryall program will normally always be True (assuming at least one 3am run has happened). When you run it manually, the time is not "right" and the ELSE runs, yielding FALSE status until the next 3am run.

Why is your timer program disabled? This is why your switchlink actions won't cause the wait to terminate. Looks like all you need to do is enable that program so it sees the control events.

Program status shows whether the program executed the THEN part (True) or ELSE part (False) on its most recent run. As you observed, it has nothing to do with whether the program is currently running or not.

IndyMike's suggestion is good, although it doesn't address your desire to "latch" the C1/On when received prior to sunset so the light will turn on at sunset. And, as written, a C1/Off event has no effect at all (for reasons better explained elsewhere). I don't think you can do what you want with one program. Here are several simple programs which should do what you want. First, a trivial program which just remembers whether most recent C1 command was ON (program status TRUE) or OFF (program status FALSE): Program "C1 status" If X10 'C1/On (3)' is Received And X10 'C1/Off (11)' is not Received Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') And the program to actually turn lights on and off based on time and C1 status: Program "C1 porch lite" If From Sunset To 2:00:00AM (next day) And Program 'C1 status' is True Then Set Porch Lite On Else Set Porch Lite Off //see below//Run Program 'C1 status' (Else Path) The Run Program action in the Else resets the C1 status if the light is turned off because time expires (ready for the next day). [Edit to add] Ooops, my suggestion has a bug, too. You can't put the "Run Program" at the end of the Else, because it will incorrectly reset the C1 status when C1/On is received prior to sunset. So remove the line from that program, and create a third program which runs at, say, 3am with that line in the Then. Sorry! --Mark

That's exactly the effect of the original program, although with respect to the ELSE part, not the THEN part. Remember that individual components of the IF are evaluated whenever they happen. So the evaluation of Light value happens indepedently of whether it's sunset or not, and the program continues accordingly. So, yes, the original conditions are ANDed. But this also means that the inverses are ORed: If either condition is FALSE, then the whole condition is FALSE and the ELSE part of the program runs. In this case, any time the climate module spits out an event that says the light value is not 0, then the Landscape Lights will come on 10 minutes later via the ELSE part of the program.

Hi Michel, I'm quite certain that this flag is not controlled by any other program action. I set it manually, and it should stay that way! At the moment, all is still well. And, frankly, I don't expect to see any problems. I suspect that the flags got cleared in some fluke interaction while upgrading/rebooting/etc and will not easily be reproduced. But I wanted to mention it to add to collective data. --Mark

In the program that 'someguy' posted, shouldn't it run forever once started? He reports that it has stopped, in addition to the "run at startup" status being turned off. Here's another data point: I have three programs that should have "run at startup" enabled. I just noticed that none of the three currently have it enabled. Unfortunately, I have no idea when that happened. I am running 2.7.6. I have a separate power supply connected to a UPS, so this isn't a huge issue for me. But I enabled the "run at startup" again for those three programs and will monitor more closely to see if they get cleared. --Mark

I'm pretty sure I saw a discussion recently that conditions on folders merely enable contained programs to evaluate their conditions, they don't cause them to be evaluated. So setting specific times on a folder probably won't do what you want, as you've seen.

I have 1 and 2 installed. My ISY is still set to auto sync every 24 hours to pool.ntp.org (no change), and I have not seen a repeat of the 1941 problem since the first occurrence Sept 2. --Mark

Post your questions in the iLinc-specific forum here: http://forum.universal-devices.com/viewforum.php?f=53 The iLinc developer monitors that forum pretty closely and can probably give you some good help. --Mark

Interesting. I think the evidence is pretty strong at this point that we both hit a bum ntp server which was giving out bogus time info Weds night/Thurs morning. Unfortunately, it's difficult to know which server it was since pool.ntp.org resolves to many different ip addresses (round-robin), so the actual server we each used is somewhat indeterminate. I'm in Oregon, which does lead some credence to the possibility that we did get the same server. Suggestion to the UDI folks: As a safety precaution when processing ntp data, dp not allow a time difference greater than some reasonable amount to be applied automatically. Or at the very least note and log the time update, with IP address of the ntp server the data came from. (It would actually be useful for all ntp server queries to be logged in the downloadable log, with server ip address.) --Mark

Will do. Thanks, --Mark

Hi Rand, Last time I updated firmware was end of July, to 2.7.6. So no recent change in that department. Interesting about possible java cache interaction. But that seems unlikely in this case since the time obviously was reset when no admin client was connected to the ISY. Right? At any rate, simply syncing the time was all it took to fix it for me. This is one of those things I'm not going to lose sleep over unless it happens again. But it was curious enough to bring up in the forum! --Mark

My ISY decided to time travel last night for some unexplained reason. I noticed this morning that some timed events had not occurred and saw two interesting things in the console: - System time was about 8am on 8/16/1941 - last start/end times in program summary were all 9/20/1977 or 9/21/1977 Hmmm. First step: "Synchronize Now" to reset time. This worked fine. System time is correct, as are "next run" times in program summary. Next: downloaded log and saw the following two entries of interest: 0 CLI-WBu Wed 09/02/2009 05:11:59 PM System -140002 [Hall C] DR light Status 100% Fri 08/15/1941 01:02:44 PM System Log So the time decided to reset itself some time after 5:11pm yesterday, leaving no trace in the log. Any ideas? My ntp server is configured to pool.ntp.org, and syncs every 24 hours. But it seems hard to believe that the time could change this drastically via an NTP update. Thanks, --Mark