oberkc

I have forgotten most of my boolean logic, but I remember that "and" takes natural priority over "or": x and y or z = (x and y) or z All contiguous "ands" are naturally treated as within parenthesees, separated by "ors".

No. If the status of the sensor changes, the program will trigger an evaluation (false). At the end of the next wait period, it wil halt execution and run the "else" path.

Yes. Programatically, this can be done. The question becomes how you want to trigger this program halt? Is the light controlled by a switch? Perhaps using an "on" command initiated by this switch? Yes, but like LeeG states, there is no such thing as scene status. More likely you would use light status as the condition to evaluate on whether to ignore a countdown. But I suggest thinking about this a little longer. Assume that the light was already on as a result of a recent driveway trigger and you get a second driveway trigger? You say you want to "ignore" the existing countdown because the light was already on. Does this mean halt the countdown? reset the countdown? Continue the existing countdown? Do you want different program reaction if driveway is triggered, but the light was already on for reasons other than a recent driveway trigger, such as a manual control? The series of programs necessary to differentiate a light on for one cause versus another may get pretty complicated. It is important to accurately define what you want here in order to avoid wasting time and effort rewriting programs that don't do what one wants. It is better (in my mind) to spend time understanding your needs rather than spend time writing programs in whch you end up disappointed. This may, or may not be important. The only practical reason that I could see this matters is if you turn it off with 10 minutes (for example) remaining, then turn it back on less than 10 minutes later, the light may turn off once the timer completes. However, if you set this up in such a way that a manual light "on" halts the program, none of this matters. Programmatically, in english, I think you asked for: if driveway is triggered and light is not already on and light is not turned on during the countdown then turn light on wait twenty minutes turn light off else halt the countdown wait period I cannot help but suspect you will be disappointed with this.

I don't have any 2-way X-10 devices. I queried a couple of mine, just in case. No response. Unfortunately, that is the limit of my knowledge about such things.

Really!? Yet when I attempted to create a test program (to provide confidence in earlier responses), it appeared to allow such a condition. I wonder if this suggest that the condition is a placebo, or that I missed something.

My initial reaction, given that you have removed two dual-band devices is a concern about whether you have lost communication between the legs of your electrical system. While I know you have other dual-band devices, have you taken positive steps to confirm proper communication? Also, I wonder about how you "replaced" the old devices. Did you first remove them from you ISY? Is is possible that there remain electronic link records of these old switches in the remaining devices, and that the remaining devices continue to try to communicate with the now-missing switches?

If you don't care about speed control, you could simply use an inlinelinc relay to control the fan. Unfortunately, I still cannot think of a two-device/scene insteon switch. I believe you will be limited to a keypad if you want to control more than one device (fan AND lights) from a single wall box.

These will have NO effect on the ISY. However, they could interfere with insteon communication across the powerlines. While I recall one or two folks report interference from AC or heating, my impression is that this is not typical.

Having followed this topic for a while, it seems to me that this has been a case of trying to hit a moving, and sometimes undefined, target. Often times, "adding features" drives a whole different programming approach, necessitating starting from the beginning. I suspect your requested feature is one such example. Now that you have gotten your program to work, my suggestion is to live with it for a bit, then re-evaluate your requirements. Once you have done so, write them down and post them here. For example: a) trigger lights from driveway sensor. If lights are currently off, turn on, wait for 20 minutes, turn off? If lights are currently on, do nothing? (or restart 20 minute countdown?) manual control of lights? How do you want your driveway trigger program to respond if you had previously manually turned the front lights on? How do you want your driveway trigger program to respond if you manually turn the front lights on during the countdown period? c) if the front lights are currently on, do you want the response to adriveway trigger to be different based on how the lights were originally turned on? For example, respond one way if the lights are currently on as a result of a manual action, and respond a different way if the lights are currently on as a result of recent driveway incursion? d) Do you want other insteon devices, besides the sensor and main front door switch involved? For example, do you want (or are you willing) to add a third device (keypad button, switch) to act as a manual override? My experience is that it is best to contemplate WHAT you want do do before determining HOW you want to do it.

yes. The second program "then" statements would duplicate those currently in the first. The second program would have no "if" statements. Yes. Typically, the first program "then" statement would be modified to read something like: then run "program 2" (then path)

I checked mine, and X-10 device status is available and, apparently, tracked. Given the lack of two-way communication, I assume the status is assumed, based on reciept and transmission of commands. It also appears to provide the ability to use X-10 device status as a program condition. I can tell you that there is a "query" function, but I have no X-10 devices, to my knowledge, that respond to status request, so I cannot confirm.

No. "If X10 'D4/On (3)' is Received" would be triggered only by reciept of an "on" command. Bright, Dim, and Off would not trigger an evaluation of the condition and no "false" evaluation would ensue.

To expand upon LeeGs response, one way that these relays may get out of sync is if you issued an insteon command to one, but operated the other via the mechanical button or remote. This relay status, by itself, does not necessarily represent a problem or even an indication of anything amiss. If your system is otherwise working as you expect, no need to spend any more time on this.

Well, then. Clearly I misunderstood. Ignore my suggestions. Thanks for pointing this out.

Theoretically (I have not attempted), I believe one could come up with a solution based on an ISY program. It may require variables to define fan speeds, but I see this encompassing multiple programs with logic something like: if status fan is off and control switch set on then set fan to low if status fan is low and control switch is set to on then set fan to medium etc....

I stll believe you have only two legs in your electrical system, despite having two panels. I can't say how reliable are dual-band devices (don't have any beyond access points). If you haven't done so, I think I would still confirm you have legs coupled, following the directions in the manual (encompasses four rapid button presses, I think).

Is that not the current section "how are you using the ISY"?

How many of these are dual-band devices and have you ensured that you continue to provide a communication bridge across the legs of your electrical system?

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?

It sounds like this one is solved, then. I am glad you got it working.

Good to know. I was not sure (would have guessed not).

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.

I don't know. However, if you want something that triggers from on an "off" command AND evaluates as true when thus triggered, one can use: if control .... is switched off. In my mind, this is the opposite of the "if not switched off" construct, so both options are covered.

I have lost track of what your program is doing/not doing that you don't/want it to do, but it appears to me that LeeGs point is insightful: there does appear to be some confusion about triggers versus evaluations. In case this helps: Will act as a trigger only upon reciept of a "fast on". Will evaluate as true when triggered. Evaluates false if program evaluation is triggered by another condtion. As opposed to: 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.

For ANY insteon device, including a remotelinc, to control another insteon device, both have to be part of a scene. That is the nature of insteon.