oberkc

It sounds as if you are well on your way. The only thing I would offer at this point is to further refine your thought process and requirements. What do you want to happen if you turn the switch on while the light are currently OFF? Is this different than what you want to happen if you turn the switch on while the lights are currently ON? How does this affect your program?

I am back. With regards to your second program (the one with the 30 second wait period), I continue to suspect the problem was not a programming issue, but a motion sensor configuration issue. From the ISY, select the motion sensor in question. Select "options". You may need to now put the motion sensor in linking mode. Notice there are a couple of options with regards to sensitivity and continuous ON commands. Make sure the continuous ON commands are checked, or that you select a timeout period much less than 30 seconds. Note, too, that the physical jumper 5 must be set to allow for software control of the motion sensor. (This is described in the manual for the motion sensor.) "this program" would be whatever was the name you gave for that program itself. Regardless, clearly the two programs you tried originally had no relationship to each other. One incremented and cleared the value of a variable. The other responded to a motion sensor without regards to the value of the variable. In your original post, I was under the impression that you had an idea what you wanted to do with the variable and how to do it. Your only question, I thought was simply how to clear the variable after 30 minutes. That was the question to which I was responding. If you want some thoughts on how to use a variable to vary the response to the motion sensor, I may be able to offer some ideas.

My original program suggestion was in response only to the only question that I noticed: "I'm not sure how to do it but I want to set that variable so that it gets reset to zero when the motion sensor has not sent the ON command on anything over 30 minutes." I should have been more clear as to the request to which I was responding and the limit of scope I was offering. That is exactly what that program should do, unless you get another ON signal from the motion sensor within the 30-second wait period. I don't have a lot of time right now to offer deeper suggestions, but I would start by checking the configuration of your motion sensor. In it is a setting that defines how long to wait until re-enabling the sensor. If that is higher than 30 seconds, then there is no way for the sensor to send ON commands quicker than the program wait period, thus the program will always turn off the light. If you don't get additional suggestions, I will be checking back and offer more.

This could depend on how you relate the remotelinc to the garage door. Is it via a scene? A program? Both? I do not expect that the remotelinc to be sending multiple commands. It could also be unrelated. Perhaps there is something that suddenly blocks your safety sensors. Perhaps there is some binding in the door motion. If this happens when the door is opening as well as closing, I would tend to discount this possible cause.

I have already offered a suggestion. Whether or not it is better or more efficient, I will leave to you. Certainly, it is fewer lines of code. The ISY keeps a log that would provide the clues you are looking for. I don't believe, however, that there is a native way to Email this log to anyone, however.

As you say, the grace solo can be turned on and off through the app, but the necessary amp remains unaffected by the grace app. Also, the grace does not draw enouh power to trigger one of those smart power strips (at least none that I have tried). One of these days, I may take some time to solve this problem, but we dont use music enough to make it a priority for me.

I use insteon motion sensors outside, though protected from direct exposre from rain. I am not sure if this is as bad as th humidity of a shower, though. I can think of no reason that your logic cannot be implemented.

My tmptation, from a logic standpoint, would be something like: If Control motion sensor is switched on Then Set integer variable to integer variable +1 Wait 30 minutes Run this program (else path) Else Set integer variable = 0

I use a grace music streamer, controlled by various iOS or android apps. I dont believe it can play from the cloud locations, but it can play music from a network server or your computer. It also can play from things like pandora or iheartradio.

I would problably take a different approach logically. I would not like the two-second delay when the pantry light turns off, then on. First, I would take the sensor out of any scene relationship. Second, i assume that the pantry lights are responder to the "particular" scene and will turn on and off with that scene. Then, i would create a couple of programs If Control sensor is switched on And Status pantry spots is off Then Set pantry spots to 37% Else Nothing If Control sensor is switched off And ( Status kitchen mud is not on Or status kitchen hall is not on Or status kitchen dining is not on ) Then Set pantry spots off Else Nothing Regarding your program, i am surprised that a wait would be required. What happens when you take it out completely? On first inspection, I dont see much wrong with your program, but am unclear about the scene relationships you have and wonder about the same issue raised by erick. Is the door sensor controller of a scene that includes the mud, dining, or hall lights?

I agree with xathros...I see nothing in that program that would cause an ALL LIGHTS ON result. Is it possible there is another program, based on those variables, that would cause this. I am also under the impression that these random ALL ON events can be triggered by a failing PLM.

This program would be much simpler. If all you want is to cycle your pump/heater every 20 minutes between 5am and 6am, try: if time is from 0500 to 0600 (same day) and elk is not armed then repeat turn on pump wait 20 minutes turn off pump wait 20 minutes else turn off pump

Thank you for catching this. I had to look it up at the time, but forgot to include it. To the first program ELSE path, add "stop pump program" Hopefully, that will solve the problem you correctly identified.

Perhaps, then, you could simply identify key times throughout the day (such as mornings or evenings) and run it continuously, then based on other conditions the rest of the day.

Perhaps. You may be correct. Unfortunately, I am not in a position to understand the needs or lifestyle of jmed999 and his family. I will leave it to him to decide if your suggestion has merit for his use.

Sorry for being late to the party. Like apostolakisl, my mind first went to folders, but did not like the possibility of getting stuck on if the timing was not perfect. Neither do I like programs to solve a structural issue...fix the issue. Instead, I though more like breaking tasks among two programs a little differently. First program is to determine whether to turn the pump ON or OFF (run second program or not). Second program determines whether to include a cycle, or continuous. Try: If ( status bath is on or status kitchen is on or status motion sensor is on ) and elk is not armed then run pump program (if path) else turn off pump Pump program (must be disabled) if bath is on or motion is on then turn on pump else repeat turn on pump wait 20 minutes turn off pump wait 20 minutes I will leave it to you to figure out exact syntax, but I hope the concept is clear.

Then, attach two shorts, one to each applicable block. Touch the end of the wires together quickly. The IOLinc relay does little more than short the contacts together, like a simple doorbell button or garage door button. Try to find a way to simulate this to see if your opener is compatible.

I have a program that does this. I simply include a condition based on relationship to sunset/sunrise and a condition based upon the status of a few key switches (indicating certain scenes and lights are on or off). Your example 2 is an additional factor I dont attempt to deal with, but I think andyf0 has a good idea. Create a program that looks for status or control of a few key devices (to indicate you just turned off all the lights) and disable the garage door program for some pre-determined period of time, then re-enabling it.

You can actually perform a quick, and simple, test. Get a short wire. Locate the two terminals on the opener where the wall button is wired. Quickly (less than a second) short the two terminals. If the door responds, the IOLinc will work fine.

I don't know for sure, but my guess is that it will work. I cannot help but suspect that this is similar to a chamberlain model that I have (which does work with the IOLinc). If you are reasonably handy, I also suspect that were this not compatible with normal methods, you could tap the IOLinc into the wall button contacts, somehow, and make this work.

I can tell you both that I have not two, but three, keypad buttons which both control my garage doors, with all three providing an indicator regarding status (ON= OPEN). I did it just as I described, just as the wiki described. The suggested approach handles just fine the condition where one tried to close a door, but the door automatically reverses itself. . No problem. I use NO programs, so if your goal is specifically to use a given program rather than rely exclusively on scenes, then my suggested approach will fail to meet such a given "need". If, however, your goal is simply to have an indication of door status with the same button that controls the door, I continue to recommend the wiki approach. I suspect you are thinking in terms of solutions rather than requirements. I think you should think of your needs in terms of function and interface (press button, door closes/opens. same button displays status.) rather than solution (use a program). Yes, I think you are making it harder than it needs to be.

I looked back upon your original post. Unfortunately, the problem you describe (false OFF conditions) is not one that I experience. If set up as described (with the KPL in non-toggle ON mode), there is only one way for the keypad to be off (barring comm problems)...if the sensor tells it to be so. So...I remain a little confused as to what problem is being solved here. Of course, there is more risk of false OPEN indications, but I consider this the lesser of two problems. Another thing I am struggling with is the evolving approach of jdm5. As I read through the various posts, I start to suspect I am unsure what he is trying to accomplish and what problem is being solved here.

There are, I notice, a couple of other programs referenced: 'Garage Left Door Close', and 'Garage Left Door Open'. It might help to post those, as well. It is hard to picture what you are trying to accomplish with some of the pieces missing. Is 'Master Bedroom 8KL / Master Bedroom 8KL - Garage R' part of the scene 'Garage Master Bed KPL Right B'? I have looked back at the thread, and I am a little uncertain what "this" is. If your intention is to see the status and control a garage door from the same keypad button, or from several buttons around the house, I prefer scenes. I find the method in the wiki to be the best approach. - Locate the sensor in such a way that ON = Open. The location should be such that it is OFF only when fully closed, otherwise ON. - configure the keypad button (or buttons, if more than one) as NON-TOGGLE ON - configure the IOLinc relay to respond to ON commands - create a scene with the button (or buttons) as controller and relay as responder - create another scene with sensor as controller and button (or buttons) as responder Everything works together in such a way that if you don't have the IOLinc configured properly, the keypad configured properly, the sensor mounted in the correct location, the correct sensor, and the controller/responder relationship properly set up, it will not work well. Using programs is likely just as dependent on attention to these details.

To add to Michel kohanin, though there are links to the PLM, device-to-device scenes work just fine were one to loose the ISY for some reason.

LeeG, Early you suggested (I think) using a direct command to trigger the relay. I vaguely recall other posts where I thought I understood the IOLinc responds in momentary mode only to scene commands. Am I recalling incorrectly? Yes, I agree that the button looks like a simple momentary contact button. This should work, yes! Pintu1228, If you wall button still works, make sure that the wires connected to the IOLinc go to the same wires as the wall button.