oberkc

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

Nice! Persistance is everything.

Is the switch a CONTROLLER or RESPONDER in the scene definition? You may need to remove it from the scene, and re-add it as CONTROLLER. Given that your remotelinc button is a controller in that scene, do you also want the ON levels to change when activated by this button?

I believe this is your problem. You need to select the switch in both cases, "in scene", and "set" (as in my original suggestion). I assume that the fixture is powered by this switch? I am curious how many devices, besides the switch, are in this scene?

" I don't believe that this is a problem. Make sure, however, that when you are picking the device for IN SCENE part of your action, choose the specific controller device, rather than the scene, itself. The way your program is written, I suspect you picked the scene, rather than device, itself. I believe the point is that you should not forget to "save" the changes to your program, and that the program should NOT be disabled. This must all be done prior to the FROM time, or you will have to wait until next day for the program to execute TRUE/THEN path.