oberkc

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.

The instructions that come with each insteon are written based upon the assumption that there is NO ISY. Given that you have one, you pretty much ignore them and follow the UDI wiki and users manual for all link management activities.

I suspect that the limitation is with the insteon protocol that would make this suggestion difficult to implement. I don't use it, but there is a command to adjust devices within a scene within the ISY. Folks around here have used this to change responder levels at defined times (reduced brightness after 11pm, for example). Perhaps this would offer an opportunity to do what you desire. It would also require a program.

I can imagine only that it may increase wear and tear on the motor. Perhaps is would impact electrical use. I suspect neither will be noticable. Probably doable with variables, but I suspect the effort is not worth it. You could create a different scene with the same members (all may have to be responders, however). Adjust "on" levels to suit, such as kick lights dimmed, the rest off. Trigger this scene from a program. I think the "off" levels are not adjustable by insteon design.

I don't think iOS would support this (probably best for android) but my dream app would create a resizable widget that emulates a keypadlinc. This would include real-time status, toggle modes, etc. I want to use tablets as controllers at various places throughout the house, and don't want to have to go through multiple steps to turn a light on or off.

This does not necessarily guarantee physical proximity from a wiring standpoint. While it sounds like you have a lot of dual-band devices, have you ensured you have at least one on each leg of your electrical supply?

All "scenes" have "on" levels for each controller of the scene. When you activate the scene, are you sending an "on" command or an "off" command. Have you checked the "on" levels for each controller? Where is you ISY plugged in, and with what other devices in that outlet and circuit?

I use a computer printer and transparent/sticky media. Works on both remote and keypad. While the eventually wear, they last longer than most solutions, and are pretty easy to replace when necessary.