oberkc

This sounds exactly like every other STATUS condition, correct?

That is, at least, the best working theory so far. If this is the explanation for why it is not returning TRUE when manually triggered, then that aspect of this statement is unlike other STATUS statements, and more like a CONTROL statement in this regards. I would be disappointed if this proves to be the case.

Yes. In my mind, this is an external "trigger" much like your earlier example where you invoked the "run if" command on that program. I agree, the program should react based on current condition if you invoke some type of external trigger or query. Like I mentioned before, I have no explanation why this does not work for you. I suspect TJF was speaking of triggers rather than evaluation, and suspect he would agree that a STATUS condition would indeed return TRUE if invoked (triggered) externally, whether manually or by another program. Still, I think this is more consistent with other STATUS conditions, rather than making it more analogous to a CONTROL condition. I think we all have the same understanding, but don't know why your program would not evaluate as TRUE when triggered externally.

No...I find this consistent with other STATUS conditions. These all respond to any CHANGE in status. A CONTROL condition, by comparision, only responds to reciept of the expected (whether ON or OFF) command, regardless of whether this constitutes a change (receipt of two ON commands in a row would, for example, twice trigger the program, whereas only once for a STATUS). Neither will a CONTROL ON condition will trigger from receipt of an OFF command, or vice versa. Another difference is that CONTROL conditions respond only when the specified device is acted upon locally. STATUS will trigger whether initiated locally, or as a result of being a responder to another insteon device.

Glad you figured it out. One more point that is not always obvious....user manuals that come with individual insteon devices are mostly written based upon the assumption that there is no central controller. While I believe you should continue to read them (much applies regardless), make sure you use the ISY to create all scenes, rather than the method described in the manual.

I have never used the status condition "not responding" before, so I can only speculate. But...I expect your posted program to trigger and execute TRUE only when: a) this program will trigger only when the status actually CHANGES (responding->not or vice versa) when triggered, it changes to NOT RESPONDING I must admit, however, that I don't have a theory as to why your program did not evaluate true when you manually triggered the program (run...if)

Perhaps I may be causing more confusion than helping. My response to the original poster ADDED a statement to the ELSE section. Thus, having the else section run would be detrimental, if attempting my proposed solution. I saw two problems with the OP original programs. First the timer program would trigger itself when called by the first program. I was concerned that this would halt the timer program immediately after initiation. Second, calling the timer program THEN path bypassed checking the ON condition in the IF path, so this would fire any time motion is sensed, regardless of current light status.

Xathros, Using status in this case would, I believe, cause this program to re-trigger when the timer program activates. I don't believe this is desirable in this case. I thought control might be better for the very reason you suggest...I want it to evaluate only because of direct action on the switch. One thing I am not clear about is whether there is a difference between an ON command and a BRIGHTEN command. If so, this single statement may need to be expanded to be something like: if ... and ( control is turned on or control is bright )

You might try a slight modification: If From Sunset To Sunrise (next day) And Control '3 Motion-Sensor Kit' is switched On And Control 'Kitchen Island Light' is not switched On Then Run Program 'KitchenIslandTimer' (If Path)<<<< note IF path Else Run Program 'KitchenIslandTimer' (Else Path)<<<<< Note line added KitchenIslandTimer <<< If Status 'Kitchen Island Light' < 1% Then Set 'Kitchen Island Light' 25% Wait 2 minutes Set 'Kitchen Island Light' Off Else - No Actions - (To add one, press 'Action') Depending on your sense of probability that you may activate the light within two mintes of sunrise, you may need to create a third (and mostly redundant) program to simply turn off the light at sunrise.

In my mind, the answer depends on what you mean by "integrate" and how willing you are to spend time learning about something like the REST interface and researching commands for a given camera. If you are speaking of native insteon capability, I am unaware of any camera that can send, or respond to, insteon commands.

glad it is working. So long as you remember that IOLinc sensor OFF = open, you should be in good shape. The problem with this could be if you ever choose to use a scene with the sensor as controller, wanting to use a responder with ON indicating OPEN. For this, you would have to use a program rather than scene, or the trigger reverse, and live with the other consequences.

Well, I did get ambitious. I created a simple program, consisting of two control ON statements, joined by a logical AND. If control device1 is switched on and control device2 is switched on This program evaluated FALSE every time, suggesting that with a logical AND (even with both are control statements) both conditions must be true. From this, I tend to conclude that a program such as: if control device1 is switched on and control device1 is not switched off both conditions must be true. Furthermore, I tend to continue to believe that "control xx not switched off" will always evaluate TRUE except at that point in time when an OFF command is received.

I did not know this. I assumed, in this case, they BOTH had to be true, looking simultaneously for receipt of an ON command while simultaneously confirming a failure to receive an OFF command (not OFF). While I understood the second statement is triggered only by an OFF command (evaluating false when triggered), I thought it would evaluate as true at all other times. Furthermore, a program such as: if control device1 is switched on and control device2 is switched on would ALWAYS evaluate as false (I thought) because it is not possible to simultaneously receive two commands. This would not happen if the ISY treated this as a logical OR. If I get ambitious (50/50 chance) I will run some experiments for my own gratification.

Yes, both must be true. Yes, if first one is true, second one will be true. However, purpose of the second condition is to look for OFF commands (not ON). This is the condition that drives the ELSE path. Without the second condition, this program would never trigger FALSE.

You could do that, but you could also simply change the program to look for an OFF status, rather than ON. Of course, you may have other uses for the sensor which may make this approach less desirable. The bigger point is that if your program is looking for an ON command to indicate open, yet your garage door sensor says OFF when open. Obviously there is a mismatch and something has to change.

To the previous explanations, allow me to offer an additional, if subtle, difference. A CONTROL statement will only be recieved when the device is activated locally. For example: if control switchlinc is switched on This will trigger only when someone walks up to the switchlinc and presses the button. Another difference in a CONTROL ON statement is that it will trigger upon each reciept of an ON statement, regardless of whether it is, currently, on or off. Compare this to a STATUS. A status will trigger upon a change in status, regardless of what caused the change. So if a switchlinc is changed not by direct action, but in response to a scene command from another device, it will trigger (unlike a CONTROL). Furthermore, if a device is already on, and someone presses the on button, a STATUS will not trigger (unlike a CONTROL).

no I assume the same. I don't believe there is any need to link it to anything if your only purpose is to use it as a repeater of insteon commands.

I agree with TJF1960 that your "wait" statement is not effective as used. I think, too, that a few experiments around the house may help isolate this. Open an event viewer and have someone walk around the porch. Do you see lots of ON commands from your IOLinc? If so, this tends to suggest that the beam/IOLinc configuration is extremely sensitive for some reason. Also if so, I believe your were on the right track (if not the right solution) with the approach of introducing a time delay in an attempt to solve this problem programmatically. Perhaps an alternaitve approach, with an additional program would work. New program: if then wait 20 seconds run this program (else path) else One could use this program as an indicator of whether it is in the 20-second wait period (program status is TRUE) or not (program status is FALSE). If easier to comprehend, one could even create a variable as indication, rather than using program status. Once created, an update to your current program would be necessary: If Control 'My Sensors / Front Porch-Sensor' is switched On and status of new program is false (indicating not in wait period) Then Send Notification to 'Text' content 'Front Porch Motion' run new program (then path) (initiates wait period) Else - No Actions - (To add one, press 'Action') Hopefully, you recognize that the program I suggested is conceptual only. The exact program language would be different. There may be a benefit to using a variable, rather than a progam, in retrospect. Such an approach may offer a benefit of reduced program activity in the background. This is probably not a practical concern, but some may percieve this as having value.

Given that you posted this in a UDI forum, I assume you have one of the ISY controllers. The fact that only one switch controls the load suggests to me not a wiring problem, but that you have created no "scenes". Is this correct? All insteon devices communicate with each other via powerline or RF signals. In order to enable one (or more) insteon devices to control another, one must link them via scenes. In the ISY admin panel, create a new scene, and add each device (as controller) that you want to be in your three-, four-, or X-way circuit. Once added, any switch in that scene will control all the other switches in that scene. You may want to check out the UDI wiki, and ISY user manual before going too much further.

Thanks for posting. I have a couple of thoughts going through my head on your programs, but think you said all is working, so why try to fix something that is not broken. Post back if you run into anything strange or unexpected.

we have all been there

http://forum.universal-devices.com/viewtopic.php?f=26&t=5764

You must also include a statement to turn off the light If From Sunset + 20 minutes To Sunrise - 20 minutes (next day) Then Set 'Front Porch Light' On Else Set 'front porch light' off

One of the reasons that I asked about your purpose for the variables (I missed your response to this) was out of suspicion that you have other programs in place that may also be triggered by these variables. I also asked about how you intend to open and close the door (I missed this response, as well) wondering whether you have other programs or scenes that could trigger the type of behaviour you describe. Suspecting that I am having trouble seeing the entire picture here, one thing that has gone unspoken about your program: if $armhouse is 1 then run program close-garage I assume this is a paraphrase of your actual program. In your actual then statement, does your program include something like "(then path)", or "(IF path)"? If so, make sure you run IF path. Some things you can check to aid in troubleshooting is to watch the value of the variables as the door opens and closes, to make sure that these are tracking correctly. Have you confirmed the variable is 0 when closed and 1 when open? Otherwise, I don't see anything in the programs you presented which I can identify would result as you describe.

To expand upon LeeGs comments: The motion sensor works fine because it (the motion sensor) is initiating contact with the ISY. You are correct that motion sensors save battery by communicating ONLY when they decide, as triggered by motion. This is an example of communication with the motion sensor initiated by the ISY (rather than by the motion sensor). In this case, the motion sensor is not in listening mode (to save battery) and does not respond to the ISY. As I understand it, motion sensors are in listening mode only while in linking mode, or within a short time period after sensing motion.