oberkc

Very likely the latter for both of us. Regarding scenerio 1, last bullet....I am actually surprised that the timer program kicks in. Since the light was already on, running a query would yield these results, with no change in status detected, and no program evaluation conducted. The only explanation that I can think of is that the ISY thinks the light started as off. Did you check the ISY-assumed status for the light prior to performing the manual query? Understand that it is possible for a light to be physically on, but the ISY think it off (and vice versa). I am still unclear whether you checked ISY status for these devices. My suggestion is to confirm ISY status for both light and swlinc prior to running these two experiments again.

I am only theorizing, but how did you add the remotelinc to the ISY? Start Linking? Manual? Is it possible that the ISY thinks this button is something other than a remotelinc? My understanding is that remotelincs cannot be queried or commanded....they only send commands. The ISY understands these limitations, so the fact that it is trying (and failing) to communicate makes me suspect that the ISY has this device identified as something other than a remotelinc.

I understand manual and programmed queries to yield the same results. Did you happen to notice whether the status of your light was changed? Programs based on status only evaluated if the status CHANGES. If your light status already showed "on", and the programmed query resulted in "on", then there was no change in the status, and the program conditions would not evaluate. I am unsure about whether device status is more or less reliable than reciept of device control signals, but you may give "control" a try as a condition of your program, rather than "status". Perhaps you will find it more reliable. Also, while I share your suspicion of the various power supplies being a problem, I feel compelled to ask what are your bathroom lights? CFL? Low voltage? LED? Is it possible that the lights, themselves are contributing to the communication problems?

I am not familiar with the "x10 security system", but assume it broadcasts X-10 messages at defined security events, correct? If so, you can use these X-10 messages as triggers for ISY programs to perform any action within the capability of the ISY, including email alerts.

My experience is that these surge suppressors can attenuate powerline signals, including X-10. Can you temporarily unplug the surge suppressor? What is plugged into this suppressor? Lots of power supplies? Computer? If you can determine that this contributes to communication problems, a filter would likely solve this. I still use a few X-10 devices, also. In a few situations, I prefer them.

There are often intermittent conditions which could cause communication issues, especially if your normal condition is marginal to start with. There are likely devices in your house which run only some time, such as washers, dryers, refrigerators, HVAC, water heaters, etc.... Perhaps you have some noisy fluorescent lights which are not always on. Perhaps this is why one of your devices fails some of the time and not all of the time. If you have insteon devices which turn on reliably, but not off, it is possible that the load is causing problems (CFLs, low voltage lighting). I also could not tell whether your troubled device is part of the scene in which you tested. If not, then run a test on a scene that DOES include the troubled device. I understand the scene test to be less than fully 100% conclusive. Rather it is a general representation of the communication between the PLM and devices within the chosen scene. It does not offer any troubleshooting ability, in terms of identifying problem-causing devices on your electrical system. I don't know your system. I assume you have access points or dual band devices or some means of coupling your electrical legs of your house, correct? Is your PLM plugged into an outlet or circuit that includes lots of other electrical gadgets, such as the computer and related electronics (UPS?).

So you have one attempt at a scene test that failed, and one that passed. I take this as less-than-ideal communication. One thing I like to do during scene tests is watch the event viewer. I have found that when communication is good, events occur at quick, regular intervals. If one sees delays, this is a sign of potential problems. Otherwise, it looks as if the scene test confirms your experience. You have one device that sometimes fails to responds. You have a scene test that sometimes fails. If it were me, I would begin the trial-and-error process of fault isolation.

This sounds pretty conclusive....for some reason the signal is not getting from the original location to the PLM. Are your electrical legs coupled somehow? Is your PLM plugged into a location that includes computers, UPS, power supplies, surge suppressors, etc....?

I agree that it shouldn't be this hard. My worst case so far is that writing changes to multiple devices would get only part-way complete. At that point, again (a second or third time) selecting the option to write changes completed the task. I am assuming you have no RF devices that require enabling the link mode in order to accept changes?

You can use dates as program conditions. Is this what you are asking?

Yes. Nothing quirky.

Software version? Is there not a tag on the motion sensor which identified the version?

I use windows mobile still, and closing the browser window does not necessarily close the browser program. I understand android is the same way. I guess this is the price we pay for multi-tasking capabilities on the phone. In windows, I can shut the process down using a task manager. I understand android has a similar app that can be downloaded. Perhaps a solution such as this can work for you.

When you factory reset the switch, did you remove it completely from the ISY? If not, this is what I would try. After the factory reset, read it to the ISY. Hopefully, it will continue to not control anything.

When you factory reset the switch, did you remove it completely from the ISY? If not, this is what I would try. After the factory reset, read it to the ISY. Hopefully, it will continue to not control anything.

You are having entirely too much fun with this.

Possible. I can think of nothing more to do than to temporarily disable the lighting and see if that helps.

My recollection, supported by limited experience, is that the durations have no effect at this time. A beep is a beep is a chirp. Hopefully, they can get this working some day.

Is "kitchen light" part of the scene "kitchen:scene"? If so, then I am concerned that this program will not re-trigger at each motion detect (because the first condition will evaluate false when the kitchen light is on). Also, I suspect you could have better luck with "control" rather than "status" on the motion sensor condtion: control 'MotionSensor' is turned On There is a very thorough example on the wiki, in case you have not found it.

A scene would be faster, but capabilities limited by the motion sensor. If you want to take advantage of any of the conditional logic or timing control provided by ISY, you are better off with a program. So...it all depends on what you want to do. Most people, I suspect, use programs.

I don't believe so, but it is possible that I misunderstand your question.

It sounds to me, then, as if you may be in for a bit of troubleshooting, trying to identify what it is causing the communication problems. I would still try the option to remove from the ISY/factory reset/add. If you are able to identify an outlet close (same circuit) as your living room light, you can run an extension cord from there to the PLM. Perform the remove/reset/replace action while on the extension cord and see if this helps. If so, you may need to filter the devices currently sharing a circuit with the PLM. Otherwise, I am running out of ideas, besides trying to identify the devices in your house that are interfering with the communication.

That is my understanding, also, all other things being equal. I believe I have experienced wiring connection problems only once. This is not high on my list of suspects. I am curious about your use of access points. Do you currently have ANY? Is your electrical system 240V with two legs of 120V? The original scene test failure is still curious. I am still suspicious of communication issues, whether the result of lack of access points, loads, or whatever. This is the area to which I would look. Regarding scene tests, make sure that any program which could affect a device in the tested scene is temporarily disabled. If this is the case and you still experience scene test failures, I would be finding the reason. One easy thing you may try is to remove the offending device from the ISY. After this, perform a factory reset on the device, then re-add it to the ISY. It is possible, I suppose, that something got messed up during this process originally. This (removal and re-add) should happen quickly. Watch for suspicious delays during this process. Open the event viewer (set to level 3) and make sure that commands are coming and going at regular and quick intervals. If not, I would take this as further evidence of communication problems.

As I had suspected (vaguely recalled this being the case). BTW, by "direct" I meant manually pressing.

I thought you said there were four scenes. Let me rephrase this, to make sure I understand. You want to define a button on each of two keypads to control four scenes. Correct? I would create a mutually-exclusive relationship between buttons CEGH on KPL-8 and ABCD on KPL-6. This relationship would ensure that only one of the four buttons is on at any one point. After that, I would create the four scenes with the applicable two KPL buttons as controllers in each scene. The only doubt in my mind is whether the mutually-exclusive relationship is maintained when a KPL button is responding to a scene command, rather than direct control. Perhaps someone can confirm this.