oberkc

Yes. I would concur with that assessment.

I use conductor also. If adding and updating ISY programs is the goal, conductor is NOT the answer, unfortunately. Conductor provides a bit more finger-friendly interface to your scenes and devices. It allows access to existing programs and allows the creation of widgets for such purposes. It does NOT give program status or access to the program language. I have found it to be a less reliable indicator of device status. I don't think I would use conductor for the purposes of going "around the house programming and tweaking".

Well...I suspected you had considered everything that I could think of. You know more about most of this than do I. But it was worth a shot. I know that, theoretically, insteon is not subject to those dreaded signal collisions, but it is easy enough to try out the insertion of some wait statements in key places. Unfortunately, that makes your program subject to some self-induced stoppages, should the right conditions arise. Still, perhaps it is worth a try. But there is nothing jumping out at me that is obviously wrong here. Will continue to ponder and keep watching this thread.

I use an android phone (v2.3.4). I can tell you that the web-page part of the ISY works fine, but the admin console page (I assume the java part) does not come up. I can access the devices, program status, scenes, etc. I cannot add or edit programs. Unfortunately, I have never investigated whether java for android even makes sense or exists....never felt the need to get to that level of detail on a cell phone.

Those two lines were the ones that caught my eye as candidates for triggers for your other program. My first inclination would be to try a couple of experiments. I would try running the button-b program with the can lights in various starting configurations (off, 25%, and on). This is an attempt to identify if there is some predictability regading when the first program reacts ton the "b" program, or whether it is truly random. If some pattern or relationship emerges between the two programs, or you can find a way to reliably trigger the first program from the second, I would be tempted to remove, one at a time, the can lights and the KPL main button from the program to see if they, indeed, act as triggers. Given both of our understanding that insteon signals do not "cascade", I would be a little surprised if this is the problem, but it is the only thing that jumps out at me.

It is my understanding that when one deletes scenes from the ISY, the ISY will delete the "locaL" scene records within any affect device.

Thanks for the clarification. This is as I suspected. I still wonder why you originally stated that: "Only the main "off" on the kpl should initiate this program."? In my mind, the "off" of the other switch would also initiate this program. I continue to consider the possibility that some of the keypad-b program is triggering this program, but can only suggest experimentation with different starting conditions (mostly associated with the can light switch) to discover any cause-effect relationship. Of course, it could be some type of anomoly as suggested by gviliunas.

I am a little unclear the difference between: 'Master Bedroom / Master-Cans over Bed L', (from program) 'Master Bedroom / Master Bedroom Keypad', (from program) and "main" (from post text) I wonder if your b-button-initiated program actions are triggering this program and, perhaps, the reason that this program does not always evaluate as true is because sometimes the 'Master Bedroom / Master-Cans over Bed L' is not initially off. Assuming that your master-cans is a device other than the keypad, it seems to me that this could be triggered by actions beyond "only" the main button. For example, if your cans were initially off, and then turned off, this would trigger your program AND evaluate as true, even though no keypad main button were pushed.

apostolakisl understanding is consistent with mine, but I think there can be times when the ISY DOES assume status. I understand that if the ISY does not recieve an acknowlegement, it WILL assume that a device responded properly. Also, I understand that scene commands are not acknowledged, by design. Regardless, a system being out of sync tends to point to communication problems, in my mind. I think it is a little bit more (barely) than a guessing game, but apostolakisl point is well made. It is often not easy to identify electrical devices that cause problems with insteon communication. The ISY does provide a tool that I can be useful in this task: the scene test. While it does not identify sources of noise, it is a baseline against which one can judge the presence of interference (noise or other types) and changes to communication integrity as one attempts to troubleshoot problems. Otherwise, yes, identifying sources of problems is often little more than observing cause-and-effect relationships as one isolates and removes potential sources of "interference". Often times, it is the summation of multiple devices that can cause problems.

There are a lot of those posts. I suggest starting with the wiki.

I don't know if it is too much, but the fact that you feel there is a need would concern me. If you are getting a lot of devices out of sync, I would be trying to find out why.

I assume that "flood HVAC" is the inlinelinc that controls the two floodlights and that "B1-Porch/B5" is the keypad button. Is this correct? What is the device "Flood Master"? Is this the scene you reference (if so, I expected the program line to read set SCENE "flood master" on)? I assume you have checked the event log to confirm receipt of the trigger condition. If not, I would. If you are receiving the trigger condition, have you checked program status (programs>>summary>>last run time) to confirm that it is running or not? Assuming you are receiving the trigger condition, and the program is running, I only assume that there is something going on with one of your scenes which counteracts the effect of the program. Regardless, I don't understand the purpose of your second "then" statement. Why not a more simple program: If Control 'B1 - Porch / B5 - Floods Master' is switched On or Control 'B1 - Porch / B5 - Floods Master' is switched Fast On Then Set 'Flood HVAC' Fast On Else - No Actions -

To "cross-link" two insteon devices, create a new ISY-99 scene, with both devices as controller. I doubt that the creation of scenes broke anything. I suspect is was the adding them to the ISY that removed the existing link records. I am unsure what your "expected behavior" is. It may help to describe what you want to happen in response to an "on" and "off" command from each switch.

No problems in my mind. I have been considering doing the same thing for some ceiling fans.

I am not sure that one can query a "scene". Sounds like the program ran, but the device failed to respond. Make sure your PLM is not plugged into surge suppressors or UPS. Make sure your PLM is not plugged into the same outlet or circuit with lots of computer stuff, including surge suppressors and UPS, power supplies, etc.... I understand that the PLM status and actual device status can be different during times of communication difficulties.

That looks like a nice solution, if a bit pricey. Plus, it adds volume control. I may have to consider for my own use.

While I have not attempted this, would not an EZIO40 suffice?

One of the consequences is that if the "scene" is turned on by another mechanism (manually, other program) between time yyyy and xxxx, it will stay on. If this "scene" is turn off by another mechanism between time xxxx and yyyy, it will stay off. This program does not enforce the scene being on or off, other than at those two specific "from" and "to" times.

But still, it is rated for incandescent loads, 120V, 400watts, 2.5 amps. Unless you are suggesting that one is a transient rating and another is steady state, there appears to me to be an inconsistency here.

I thought the same thing...except that it is "rated" for incandescent lamps only. Pure resistance. No power factors.

Agreed. This seems a little strange.

Last I checked, I still had the option for a "mutually exclusive" relationship, programmable from the ISY. It has, however, been a while since I looked. In addition to this ability, I vaguely recall that one can program this behavior directly at the keypad (I think it is called button grouping in the keypad manual). I also percieve a bias here in favor of scenes. As I understand, mutually exclusive relations are managed by the device itself, and apply only within a single device. Your desire to turn muliple secondary buttons off in response to a scene "on" command suggests that a mutually exclusvie relationship would not work for you. A program would be necessary.

How about an inlinelinc at each fixture? I am not sure that you are going to be able to avoid climbing the ladder. I have heard of folks around here who use a relay, controlling the relay with an IOLinc, but that would be for others to provide any details.

I use Gmail, and continue to get notifications. I use the "default" server, as well. I don't expect or get a lot of messages, but I continue to get them as expected.

The program looks to me as if it should work. Have you checked to see whether the ISY is tracking the correct status and seeing the commands? While I don't believe it makes a difference, have you tried switching the order of the "status" and "control" conditions?