oberkc

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.

There are a variety of potential causes for this. Perhaps the ISY is not working (unlikely, in my mind). Perhaps there is communication problems between the ISY and IOLinc (possible, but not yet concerned with this). IOLinc may be wired incorrectly (given the answers so far, I am tending to discount this possibility). Garage door opener does not respond to momentary contact. Right now, I am mostly focused on this problem. You stated that you shorted out the wires connected to the opener and the door did not move. From this I conclude that either the wires are not connected to the proper connections, or that the door opener does not respond to this. Since you believe you have confirmed that the wires are connected properly, I have to conclude that your opener does not work like this. Unfortunately for those of us who use the IOLinc, some of the newer doors appear to require more than a simple momentary contact in order to activate the door. Until you are able to get the door to respond to a momentary short in the two wires, there is little that can be done with insteon and the IOLinc. My focus, were I you, would be to triple check this again. Remove the two wires from the IOLinc that connect to the garage door and, again, quickly short. Again, check for the proper connections. If you are unable to get this to work, there is little else to be done, I am afraid.

And this still concerns me. The sensor LED indicator on the IOLinc should change state when the door is manually opened or closed.

That was a question I was going to ask you. I don't have the garage door model or manual, do you? Are you able to trace the wire from the wall button to the opener? Into which positions do they go? These should be the same as from the IOLinc.