oberkc

Is it possible that this keypad began life as a six-button version and later converted to eight? (When one factory resets a six button keypad that was converted to eight, it reverts back to six.)

It may be a technicality, but a scene cannot simultaneously turn ON some lights and turn OFF others. While it may be possible to set responder levels to zero, those devices are, technically, ON. Remember, responder levels can be set differently for a given controller of a given scene. Even if the scene level is zero, make sure that the responder levels are zero when triggered by the BEDTIME button. They CAN be different levels.

I believe you understand correctly. Your scene should include, simply, the two motion sensors and target switch. If other insteon devices hear the commands from the motion sensor, they should repeat them without including them in the scenes. That your two switches actually showed opposite "circuits" (I expect, instead, this should be considered opposite legs of your electrical system) is an indication that these two switches are, in fact, communicating. Now comes the fun part of trying to identify why the communication is failing, then. There are not many tricks that I can offer other than brute force. Identify the circuits that include the two switches and what other electrical load are on those two circuits. Do you have a lot of CFLs or LEDs? Home theater stuff? Computer stuff? Unplug or unscrew those loads, where possible. Does this help? Open the event viewer window and set to level 3. Activate the motion sensor somehow, and observe the event viewer. Past the results here. Some around here are pretty good at reading these things, but I tend to look for the lines with "hops remaining". If this is 0, that is not a good sign. There is a scene test available that can help quantify communications among the included devices. Unfortunately, this is not a big help in troubleshooting...identifying any offending devices. You may also perform a "show links" for a given device, and then "compare" to the ISY records. Sometimes, link records on devices can get corrupted. "Restoring" a device can, more often than not, correct errors in link records. If all else fails, sometimes one can simply remove devices from the ISY, factory reset those devices, then re-add and recreate the scenes. Sometimes that is all that it takes.

All insteon devices will relay and repeat commands. This is built into insteon. No special settings or links required. Perhaps there is a different question to ask....why is the middle switch (which IS in range of the motion sensor) not able to communicate with the target switch. A couple of things might be important to know: which models of switches (are they dual-band) do you have? Have you performed the phase bridge (aka beacon, 4-tap) test? Are the two switches on the same circuit? What else is plugged into that circuit?

Reading these forums is a wonderful form of studying. Consider the theoretical construct where switch A is controller only of switch B, which is controller only of switch C. Manually pressing switch A will cause switch B to turn on, but this does NOT cause switch C to turn on. Only manually pressing switch B will cause C to react, besides manually controlling switch C directly. It is the same relationship between the PLM and switches. The PLM is controller of all switches and devices, but controlling of those switches (even if those switches are, themselves, controllers of other devices) via the PLM will not cause the responder devices to react.

What is it about which you are unsure? Is it how your scene relationship came to exist? Is your uncertainty about how removing the scene solved your problem? Or are you wondering how it was possible that I had the answer?

I also prefer an approach similar to mike ippolito. I would like to add, however, that if you want to use a program to trigger lights from motion, be sure to make sure that there is no scene relationship between the motion sensor and lights.

A couple of points... I dont believe two programs are needed or bebeficial. To your existing program, add an action (else path) to turn off the lights. Second, i dont believe it is this program that is causing your lights to come on when manually turned off. This prgram, by itself, will run twice, and only twice: at sunset and sunrise minus 4.5 hours. There is something else going on

Yes, it is possible. From the admin console, control the scene rather than the individual devices.

I find techman's question quite insightful. Not sure I would have thought to ask that one. How many other programs do you have? While watching the admin console and program tab, details, what happens when you run (then path) the query program? Do you see any other program activated?

First, I see nothing in this program that would turn lights off at any certain time, if that is what you are trying to accomplish. Second, I see nothing in this program to explain the problem you describe. (This program will run only twice: once at sunset and the second time at sunrise - xxx.) I suspect you have another program, somewhere, triggered by the keypad. Is this keypad button a controller of any scene? My suggestion is to turn on and off this keypad button and observe wnat other programs run. This can be done through the ISY admin panel>>>programs tab>>>details.

If it were a bulb setting problem, I would not have expected it to run any better when choosing "run then", as you stated originally.

That sure looks like the right way to me. It won't be +/- 30 minutes, but any time between sunset and 30 minutes after sunset. Is it possible that your ISY clock is off? Your location (from which to calculate sunset)?

Control it via a scene relationship, or via program? Given what you have described so far, I think I would rely on a scene, with all three devices as a controller. Set the motion sensor to ON only, and use a program to decide if and when to turn the lights off. Of course, this approach would change if you have conditions under which you would not want the light to turn on when motion is sensed.

Yeah, I haven't really been worried about it. I was partly reacting to mike ippolito's comment that v0.0 was an indication of a faulty linking process, but I have seen nothing that makes me suspect any problems (other than one ALL ON event that happened simultaneously with one sensor triggering). Status seems correct every time I check, and the update is pretty quick, making me suspect good comms. Both of my sensors have heartbeat and battery nodes, along with open/close. I thought these were relatively new to me, but my ability to judge time is not as good as it once was. I am simply more curious than anything. I enjoy the experimentation.

Blackbird...in your original post, you state that "all three are set as controllers" yet in your response to LeeG, you stated that "you did not add the motion sensor to the scene because....". I am confused. Is the motion sensor a controller or is it not a controller? BTW, the motion sensor CAN be a controller while still having the ISY control the time the lights stay on. Just put the sensor in the mode that sends only ON commands. If, in fact, the motion sensor is controller in the scene with the switch and keypad buttons, check responder levels of the keypad button when the motion sensor is controller. Is it set to zero? Make sure it is set to full ON. If settings look otherwise good and you motion sensor is controller of the keypad button, and responder levels are good, then I would conclude a comm problem. I would attempt to solve this issue rather than get around it by adding a backup program layer.

I am certainly interested if further experimentation, but may not have the opportunity soon. Yes, I reset the device before removing from the ISY. I saw no errors displayed, but the process appeared to be performing some write action without the sensor being in linking mode. Perhaps this contributes to the mystery. Yes, the sensor was in linking mode when initiating new insteon device. Next chance I get, I will try a few more options and report back.

Well, I tried a couple of different approaches. After a factory reset of the sensor, and removing it from the ISY, I chose link management>>>New Insteon Device. Set to autodiscover, nothing happened. I then tried link management>>>:Link a sensor>>>Open/Close sensor. I entered the address, found the autodiscover option, and chose it. The link process failed. I then went back to link management>>>:Link a sensor>>>Open/Close sensor and added the device, keeping default settings. Link worked, but I am back to v0.0. Teken...throughout this process, I never had to rebuild any programs. The one program I had with this sensor as a condition came back as good as before, without any intervention on my part.

Perhaps "not viable" is a little too strong, but mike ippolito suggested that having v0.0 (which is the consistent result when my approach is taken) is an indication of a device "not added properly". If this is true, this sounds to me not to be viable. At this point, however, your point is taken and I suspect I am arguing semantics with myself.

I will try your approach. I have been using the "link sensor" method as asked by Michel. Perhaps this is why I have not noticed the "autodiscover" option? Interestingly, I recall the open/close sensor being a specific sensor choice when my approach was taken, suggesting (in my mind) that this is a viable approach. I also recall a different method for versions prior to 1.9. Perhaps, also, I took the wrong route here. Will try again and report back.

Indeed, I am using link management>>>link sensor option from the dropdown menus across the top. I do not recall an "autodiscover" option, and I have always had to manually input the address, but I will check again soon, trying to pay a little more attention.

Yes, you make good points. As to my own experience, I never had ANY all-on events until recently. I never had any door sensors, until recently. Yes, this could very well be a coincidence. In my most recent event, it appeared that Keypads were not affected. I don't know what one can conclude from that. I suspect if anyone knew with certainty what is causing it, it would be fixed by now.

Up until yesterday, I was not worried (ignorance). My only concern right now is what effect, if any, this may have on the ALL-ON events. If none, I probably won't spend a lot of time trying to figure this out, as all seems to be working fine otherwise. I can accept that this may be one of those devices that doesn't show version number (though these are relatively new for me...perhaps less than a year old installed). It is comforting to know that I am not the only one with sensors in this condition, though. Thanks. The only reason I wonder about the relationship between these sensors and the ALL ON events is that one (but not all) of my events occurred simultaneously with this door sensor changing state.

I understand. In fact, this is the first time that I specifically looked at the version number an noticed this. Full disclosure: I have two of these door sensors. Multiple retries, resets, etc. have resulted the same...version 0.0 for both sensors Three nodes. Status changes to ON and OFF in response to the door opening and closing. Each attempt at linking required me to manually enter the address. I am unsure if this is normal, but it works (if one ignores the v0.0 problem). Given that the sensor is attached to the door, and that I did not want to remount, I tried different locations for access points. None of this seemed to matter. Functionally, both sensors appear to be working without fault. I begin to wonder, however, if this could be a contributor to those ALL ON events.

Mine shows up as a (2843-222) Open/Close sensor v0.0