oberkc

I still like PROGRAM STATUS as a program condition. In most cases, for me, program status is a natural check. Use of variables can contribute to the need for extra coding in some cases.

My working theory is that "sealed" covers keep moisture and humidity IN. When I install outside, I make no attempt to seal anything. Rather, I do my best to keep direct exposure to rain minimized and, should moisture make its way past this first line of defense, a drain path out.

That is the same conclusion I reached from reading the manaul. Unfortunately, I cannot confirm by personal experience.

From the user manual: "Because Micro module comes programmed for latching switches, 3-way toggle mode is enabled by default. Normally, a latching switch reads the switch’s up position as on and down position as off. For example, if you turn Micro module on from the latching switch and off from another controller, the switch is still in the up (on) position; turning Micro module back on from the switch would require you to tap the switch down, then up again. The 3-way toggle mode overrides this sense feature, so in that same scenario—turning Micro module on at the switch and off from another controller, so switch is in up (on) position—you could then turn Micro module on at the switch by tapping it down."

I would be very surprised if any of this would be useful with motion sensors. Motion sensors cannot be responders. Motion sensors do not acknowledge anything. Based on what I have read here, it does not appear the ISY/PLM has any way of detecting a motion sensor being non-responsive.

Ugh. This I did not understand. I assumed a simple change of state in the sense wire would toggle the output. This would be no good...I agree.

That is not much different than the historically-typical three-way. Up or down has no meaning with those, either. Yes, I prefer up=on, but we have lived with other options for a long time. Theoretically, if there was enough space in the box, one could simply keep ALL the existing switches and install a micro module somewhere to power the fixture. Instant insteon.

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.