oberkc

One additional thought...even if your remote does not have built-in X-10 codes, perhaps your URC is a learning remote and you have an old x-10 ir transmitter of some type? Program codes through the learning process.

I use a URC remote, RF-20. It has a built-in library of X-10 commands, house code A, number 1-10, on, off, dim, bright, etc... I think it highly likely that your URC has such a library. If not, you may be limited to the insteon version of the IR reciever. Assuming you have the built-in library, use the remote to send an X-10 code into your system. Use an ISY program to trigger the actions you desire, triggered by the X-10 code.

Smarthome makes a plug-in IR reciever. I use an X-10 one. Both convert IR to powerline signals and could be used to trigger programs. If you choose the insteon one, I assume you could even incorporate it into scenes.

I think this is exactly the suggestion/question. I think he is questioning the value in halting a running program as a result of changing input conditions.

Don't forget that forums are public and that allows many of us like to learn from the interraction of others. I have not considered this pointless. Perhaps, too, on occasion, another can jump in and try to help. I thought it did give such an example: Reciept of a new motion trigger stops the ongoing wait and starts it fresh again. This allows one to create a program where one can have the lights go off after the LAST detected motion, rather than after the FIRST detected motion. Perhaps I misunderstood. Better, of course, is in the eye of the beholder. I prefer the greater amount of flexibility, even if it adds a layer of apparent complication. There is nothing wrong with honest differences of opinion. Keep asking questions. We all get smarter as a result.

The program condition would be evaulated any time one of the conditions (status being one type of condition) changes. In your example, if it changes to a condition other than 43%, then the condition would be false. If a wait command was originally executing as a result of a true condition (then path), then the wait would halt as a result of the condition becoming false (which would trigger the else path). There are lots of triggers, or conditions. Besides "on" and "off", there are "not on", "not off", "XX%" Status is one of several conditions, including time, and control. I have never been much good at finding things in the wiki, so I cannot help you there. I have found, however, that the logic employed here to be consistent with my understanding of "if, then, else" construct and boolean logic. The most difficulty I have had with the programming is understanding the difference between the conditions of "status" and "contol".

There are posts about these types of conditions...boundary conditions were they called? There are lots of nice ways around them. My approaches tend to be brute force... I just add another program to turn all lights off at a certain time in the morning. That way, if any were inadvertently left on, or failed to turn off, or whatever, this assures that they won't be on for days at a time.

That is a surprise to me, also. I will re-read the post, but where did you get this idea? I understood that program conditions are only evaluated when one or more of the conditions change.

I updated to 2.7.7 to purchase the X-10 module. I have had no problems. It seems 2.7.13 is pretty good. While I have yet to update, I'll bet you would see no problems with this, either.

There is also an 8-button configuration that you may prefer. Yes, you could program these as you suggest.

You may want to go re-read some of the early posts. It appears that there has been some attempt to answer this question, before we all hijacked the discussion.

Your solution is one of the more efficient options that I mentioned, but was too lazy to figure out. Nice job. Exactly. And if you turned on the scene, they would both go on.

Are these dozen switches not installed? Did someone else install them? The new one would be installed like the others. Any (there may be an exception) insteon switch requires a line, neutral, and ground. If you intend to control a load with this switch, then you need access to the load's line and neutral connections. Pick a switch that suits your tastes. As suggested, you may consider a keypad. This would allow you to control up to eights scenes. Any insteon switch can act as a "master", including any of the twelve that you already have. All insteon switches have the ability to control a load. If controlling a load is not needed, cap it off as already suggested. Communication between devices is over the powerlines (some exceptions). You may need access points or some way to communicate between various phases of your electrical system.

I understand multi-linking mode to simply be the ability to set one device (the controller) into linking mode, then linking more than one device as a responder, without having to put the first device back into linking mode between each responder. I do not understand it to have the capability to separate on and off control.

There is no doubt that one can set up an insteon switch to control other insteon switches without having an ISY. Your ideal scenerio was a bit more complicated than this, however. Your "ideal" scenerio would be to turn on 3 other devices from a single switch, but only turn off 2 of the 3 original devices. It is that particular scenario that I would have trouble doing without an ISY. If all you want to do is use a single switch to control (both on and off) 3 other switches, that is easy. Set all in a scene with the singles switch as the controller. This would be done the old-fashioned way of putting one device into linking mode, then linking other devices to it.

Does this mean that you have a program running continuously, until you stop it? Or is it that you want a programs "then" condition to run when you press the KPL buttons on, and a programs "else" condition to run when you press the KPL buttons off? I am assuming the latter. First, I suggest putting both KPL buttons into a scene, with both defined as controllers. The buttons also need to be in toggle mode, which is the default setting. This will keep the KPL buttons synced. Second, set up a program without "if" conditions, having only the desired "then" (turn lights on, for example) and "else" (turn lights off, for example) actions. Set up a second program. This program would look something like: if control KPL1 button X is switched on or control KPL2 button X is switched on then run first program then condition Set up a third program, similar to the second: if control KPL1 button X is switched off or control KPL2 button X is switched off then run first program else condition I suspect there are more efficient ways of doing this, but my brain is being lazy today.

Perhaps another way of looking at this is to recognize that household AC power varies in voltage from +110 to -110. It is not a constant 110 volts. At any given point in time the voltage could be anywhere in between. Current, is also alternating between extremes. The power factor recognizes that peak current (amps) may, or may not, occur at peak voltage. If peak current occurs when voltage is only 60, then power would be amps x 60V. The power factor is a way to define how far peak current shifts away from peak voltage. So, even with AC, power = volts times amps. It is just that you cannot assume that volts and amps are simultaneously at their peaks.

I would expect that you could do this, without an ISY. Simply put all the devices in a scene. I am having trouble envisioning how to do this without something like the ISY.

I do not like intermittent problems. My general instinct is that heat related failures would tend to be catastrophic. The fact that your problem appears to be intermittent makes me continue to suspect communication issues. Hopefully, it will stay working this time.

A couple of minor thoughts: First, I would not rely on activity of ISY front lights. I would definitely confirm by opening event viewer then trigger the scene. The event viewer should show reciept of expected signal. (Are you using X-10 here?) Second, I have generally treated "request failed" messages as communication errors. While I don't doubt failed devices can happen, I wonder if something is happening here with your comm. Are these switches on their own circuit? Is your theater A/V equipment filtered? Perhaps there are a couple of quick things to do in an attempt to determine switch failure. I think I would perform a factory reset on the switches, then attempting a restore. I might also try a manual link between another insteon device to see if there are further indications of a failed device.

Why would it be unethical?

My first reaction would be to perform a device compare, to see if the device links match those of the ISY. My suspicion with my system is that intermittent communication errors can cause mismatches between device and ISY. Perhaps you are seeing something like this. Did your device restore happen pretty quick, or did it seem like it took a long time? While your inconsistent response to restore makes me think otherwise, I would also check to make sure you do not have some mutually exclusive relationship going on between KPL buttons.

I don't have a good sense about the extent of your setup, but my first steps would be to perform some scene tests to see how broad your problem is, and to baseline you system communication. Assuming some problems are revealed, unplug any device that are generally accepted as potential signal degraders (electronics, plug-in power supplies, CFLs, computer-controlled appliances, etc.) Try the scene tests again. See if you have improvement. Don't stop until you have near 100% success with your scene tests. Others have shut off various circuits throughout the house to see if they could identify those that cause problems. This would tend to limit the search to devices on a given circuit. Of course, this may de-power some of you insteon devices, so you must account for this. The point being, you must identify those devices in your house that can cause communication problems and deal with them. It may be more than one device. There are many posts about dealing with communication errors. It is probably worth checking through them for some ideas.

I may be paranoid, but is that something you may want to keep off a public forum? Better make sure your password is something other than "admin" Sorry I stepped on this. Rand

As a quick experiment, temporarily unplug your audio equipment and TVs (and anything else on this circuit with the ISY/PLM). See if this helps. Hopefully it does. If so, then there is a very good chance that a filterlink will help.