oberkc

Interesting idea! I don't see this device on smarthome web page. Has it been discontinued? This also may depend on how the circuit is wired. In some three-way configurations, I don't think there would be enough conductors.

It is, but not with B button as scene controller. The only way that I know to do this is by a program: if status b button is on then set lights to low level (best with a scene, possibly) else set lights to 100% (perhaps another scene with same devices, higher ON level)

assuming the program is correct (and it sounds like it is), my first suspicion would normally be that the load (when on) is interfering with insteon communication. But...houselinc worked correctly? Was the houselinc device plugged into the same outlet as the ISY PLM? Back to your program...is it too much to ask that you post it? Does your program have a statement in the ELSE path to turn off the lights?

Further thoughts on scenes versus discrete devices in programs.... Generally, I have few devices that are not part of a scene somehow. I have found it useful to have a few global scenes, such as all-interior, all-exterior, all-guest. I also have some large scenes such as evening, landscape, exteriorflood. In the end, I have very few devices that are not part of some scene, somewhere. Such use of scenes makes one a little less dependent on a controller, and can help make troubleshooting a bit easier. Also, when I add a new device, including it into one of the applicable scenes is all that is necessary (no program changes needed). Given these scenes, it seemed more natural to use them for timed events. In many cases, I have more than one program that turns on a given scene. Having it this way means that I don't have to duplicate a list of devices in more than one program, nor update multiple programs when adding/removing devices.

Absent other evidence, I take this as a sign of communication issues. I prefer a scene, but not necessarily for reasons related to reliability (though this may be a unintended consequence). I find scenes to be easier to manage as my system grows and my interests evolve. I don't believe there is an inherent benefit one way or another. I use both. I have an "all lights off" program which is set for a specific time. I have other programs which use the from/to construct. Once at the beginning, and once at the end. Nothing between. Of course. One way would be to create a program folder, enabled by the specific controller. In that folder, put your from/to program.

OK. Fair enough. In my mind this is the same, since we were not looking for status on/off, but status responding/not. But...point taken.

You cannot simply replace a one switch in a multi-switch circuit with insteon, leaving the others in place. You MAY be able to rewire the circuit to have a single insteon switch and no others, but this would depend on how the circuit is wired. If power is introduced at the fixture, then you would either need to add additional conductors between the fixture and switch box, or an additional insteon device (such as mircro module) at the fixture. Either way, you will need to re-purpose some conductors.

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.