oberkc

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.

This depends on the devices in the scene, and is not an accurate statement in the global sense. One could, for example, define a button on each of multiple keypads to be controllers in a scene. In such a case, the KPL buttons WOULD accurately reflect the status of the scene. Your particular problem, however, may be in trying to set a zero scene level for responders, or it could be the consequence of trying to control one KPL button with another button from the same KPL. So...this statement could be true in your particular case. I recall similar things as described by LeeG...in some versions (maybe all) of keypads, it may not be possible to set a setting of "off" in response to a scene "on" command. (This is a limitation of some insteon devices.) I also recall that certain versions of KPLs don't allow direct control of one button from another. Perhaps you are experiencing one of these problems. I don't have any spare KPL buttons with which to experiment, but, based on your experience and the experiment of LeeG, it sounds as if you will need to use a program for your particular case. I am unclear as to the purpose of your various keypad buttons, but you may also find a solution in the use of the mutually exclusive feature of the keypad. This feature allows one to define a set of buttons where only one is allowed to be on at any given point, and the rest will turn off when one is activated. Whether this serves your needs depends a great deal on the larger design of your lighting scenes and programs.

Sorry, but I have no idea what you are asking. A little more background may help. Hopefully, I am just stupid and others can figure this out.

OK. My mistake. I would have expected this to work, then, but also consider the possibility that the motion sensor would also have to be put into linking mode for this to be successful.

My understanding of this device is only conceptual, but I understand the in-linelinc is the only insteon device in this kit. The motion detector is hardwired to the inlinelinc, is it not? If so, there would be no insteon motion sensor showing up...only the inlinelinc, itself, would be displayed in your "my lighting" tree.

I agree that the original post was difficult to comprehend. I am still trying to figure out: "still flashed the sing incond..." I also wonder about competing phase couplers. Is it possible that some old versions of x-10 boosterlincs or similar device could be trying to repeat commands in some form of a loop in such a way as to cause a flashing of the load?

I am not sure that I completely understood the details of your first post.... I have not experienced flashing loads, except during the process of linking. Is this condition repeatable for you? Does it happen randomly? Certain times? In response to some action on your part? I would think that it would be pretty easy to eliminate the ISY as a potential cause. Remove power and unplug it from the PLM. If your problem goes away, then I would conclude most likely that the tech support at smarthome was correct. If the problem persists, then there is some additional troubleshooting to look forward to.

Yes. Some of my older versions require cycling of power. I understand that this is a relatively recent feature. I have some switches v27 and these DO require cycling of power. The dimmer switch that I have that worked was v38.

Besides the light going on, nothing. There is no condition in your program which would be triggered by turning your light on. However, if you turn it on again , then turn it off again (all during the ten minute wait), the program will trigger an evaluation (one of your conditions is control...off). This will halt further execution of your program and start another "then" or "else" path, depending on the results of your evaluation.

Just to be clear.... 1. You created a program that included a statement "adjust scene" 2. You chose the scene, then the device within the scene 3. The new level you set to 30% 4. The scene now shows 30% 5. You don't believe it is working because, when you press the switch of the changed device, it does not respond with the new value. Is this all correct? As suggested by LeeG, and then by sub-routine, rather than selecting the scene at this step, select the actual switch. I think this is the single change that you must make. You would do the same thing, again. Just to be sure we are speaking clearly, could you provide us with the actual name of your scene, and the names of the devices within that scene. While I am certainly not overly experienced on this command, what I suspect is happening is that you are setting the "on" level for that switch that is applied at the scene level, rather than at the local level. I performed a quick experiment on one of my newest dimmers. I created a simple program where it adjusts the scene. Instead of selecting the actual scene in which the device resides, I chose the device itself. From there I chose the device, itself, again, from the choices given. When I executed the program, the device now responded to the new setting. I believe this is how you want yours to respond.

This option (enable internet access) is to enable one to log in to the ISY from a remote location, outside your home network. The types of problems you are experiencing are usually followed by questions about routers and firewall settings. I have tried my best to stay ignorant of such things, so I will not try to fool anyone into thinking I know anything about them.

Easier is in the eye of the beholder, I guess. I am just not percieving any of these changes as so. To me, these are just different ways of achieving the same goal...no easier or harder to understand. Sorry...I am having trouble getting excited about this type of change. People have told me that different opinions are what makes the world interesting. In my mind, too, if you are sufficiently advanced to desire (or even understand the purpose of) separate triggers, you are sufficiently advanced to understanding existing trigger mechanisms. This change is not going to benefit those who have no clue about programming (in my mind, at least). But I enjoy discussions on these topics. I guess we will see if, and how, Universal Devices responds.

I don't disagree with this either, but your proposal for a wholesale change in criteria wording is not (as near as I can tell) part of the proposal to which I was responding.

I must count myself among the skeptical regarding this point. While it appears that this may add some flexibility for the advanced user, and may make the ISY more consistent with other advanced programming languages one may be used to, it does not reduce the level of understanding required. On the contrary, I see this as potentially adding one more thing that can go wrong. Example new thread: One still must understand the concept of triggers and conditions. One must still understand the existing defualt triggers. No....I don't see this forum going out of business any time soon. It is just that the questions will change.

Indeed, it is. I just wanted to make sure you were not laboring under a false pretense.