oberkc

regarding your second program never turning off the lights, I can only assume that some event happens that interrupts the wait statements and forces the program ELSE path to run. Unfortunately, I am unfamiliar with how Elk rules work in this regard to offer any specific advice.

No variable is required. Your program should work as is, unless your motion sensor time-out is set higher than ten minutes. Of course, motion sensors are not 100% reliable and issues such as that can come into play, but I would first check to make sure the time-out period is not set too long. Remember, from the ISY, these settings can be adjusted, but the motion sensor must be put into linking mode for the ISY to write the changes. I believe, too, that jumper 5 must be properly set for the ISY or any other controller to make changes.

Is your variable a state or integer?

I have found some value in have an "all devices" scene. I use this for a couple of reasons, including an ALL-OFF program. Yes. There are a handful of key concepts that are good to understand with insteon and the ISY. One of those concepts is that turning on or off a controller device from the ISY admin panel will not affect any devices that are a responder to that controller....the only time a device acts as a controller is when it is activated locally (press the button).

Only for a few days, up front. I go for months without touching mine. Then, when I do, it is often to experiment or change the way my system works. I encounter nearly NO need for maintenance or babysitting.

That's some great food for thought, I'll try to answer... Yes, technology does intrigue me. Spending an hour or so each night for a few days is fine, but every day, then you can't exactly call it automated. I hate paying someone to do a job just because I'm too lazy. I'll gladly pay somone who actually knows what they are doing. Half of the time when I pay for a job to be done it ends up being no better than if I'd done it myself. I do just want to get it working. I hadn't opened the admin panel in well over a year. But let's be honest- Insteon devices are not built to last, so as they stop working, you do need to deal with them. My house is somewhat static. Maybe once a year I'll think of something I'd like to add to the lighting system. VCR blinking 12:00? No, I did try to keep it set, and I was happy when I bought one that could set its own clock. I rarely programmed it to record. I spend way too many hours a day on the Internet. I use Chrome at work, and Firefox at home. I have no idea why on don't use the same browser in both places. I think the reason might be that there was a version of Firefox that broke flash, and that day I switched to Chrome. I never had that version at home. My smart phone is an iPhone, not because I have a gay crush on Steve Jobs, and not because I love Apple telling me what's best for me, I use an iPhone because it not just can't be tweaked, it doesn't need to be tweaked. Yes there are things I wish it could do better, but I like not having to think abut it. I need it to just work when I use it. I need home automation to be like my iPhone. When I, the household geek pushes a button, I don't want to wonder if it will work. More importantly, when my wife, who quite frankly could live the Amish life style, presses a button, there better be no mystery or trouble shooting involved. It needs to work just like a normal switch that normal people have in their homes. I just feel guilty taking so much from all of you when I have so little to contribute. But if you're willing to hold my hand though this process, then I'd rather just do it myself so I can fix it when it breaks. Thanks, ~Jay I apologize for being unclear, but I intended these as rhetorical questions to help guide your decision. But...I have seen enough. Your attention to detail and willingness to read the responses leads me to the conclusion that you should give this a shot without professional help.

I am having a senior moment with my memory, but this sounds like the common problem where folks can fail to fully account for program triggers versus evaluation results. I can tell you that I avoid programs who's THEN or ELSE path can cause a change of the IF condition. For example, you have a THEN path which turns the "light" off. This would change the STATUS of the light from "not off" to "off". This change of status would trigger (again) the program, which could cause the ELSE path to run. In worse case you may have an infinite do loop. There are a couple of options to avoid this problem. One is to use integer variables as a representation of light status (integer variables, when used in a program IF condition, do not trigger an evaluation when they change). Using this method may require a couple of programs to accomplish, such as: if status light is not off then set integer variable to 1 else set integer variable to 0 if control remote button is set on and integer variable is = 1 then set light off else set light on Another option should you care to avoid the variable approach would be to break your single program into separate programs: if control remote button is set on then run second program (if path) second program (must be disabled): if status light is not off then set light off else turn light on Take your choice. There may be other options, but that should be enough to get you started. Report back if you have any problems. edit: looks like LeeG beat me to it again.

I think you should consider the possibility that there is something about the condition of your power (surges, over-voltages, spikes, noise) that is causing these failures. While I am sure there are plenty around here that will complain about insteon "quality", 5/13 is absurd for the first six months. Something strange is going on somewhere. Is it possible you have a wiring issue that is causing a gross distortion to your AC waveform?

One factor in whether you want to pursue outside help is your interest level. Does technology, in general, and home automation specifically, intrigue you? Do you find spending an hour or so for a few evenings on the computer early in your life with insteon and the ISY to be time well-spent? Do you like understanding how things work? Do you fix your own appliances because you hate to spend a hundred dollars for someone to come out to fix it for you? If so, then save your money and take advantage of the wonderful folks around here. Do you just want to get things working? Do you look forward to the day when you no longer have to open the ISY admin panel? Do you think your insteon system will remain static once installed? Do you hate smartphones and digital cameras? Did your old VCR clock continue to flash 00:00? Do you get a blank stare in your face if someone asks you what browser you use to surf the internet? If this is more your style, then the use of outside help may not be something to quickly reject.

I must admit that my initial concerns about your program were the same as those of xathros. I also vaguely recall a similar discussion a while back about status and control within the same condition I had a while back, so my confidence is not absolute. Unfortunately, I think your "wait" statement is the factor that will cause the retrigger and halting of the timer.

There is a sticky post somewhere about configuring ISY for internet access. I understand it is best to change the ports in the ISY settings, then configure port forwarding rules in the router. I inderstand that some antivirus can make things troublesome as well. Check out the long sticky post ...I suspect it will answer the detailed questions you have. As far as remote control in the car, I have chosen the phone route, but the insteon remote seems viable. I suspect it will boil down to what you want to control and the user interface you are looking for. IOS devices will compel you to open an app to control you system, so it will usually entail multiple steps to turn on a light or open a garage door. In my mind, android has the advantage here for those who want a button on the home screen that will perform a function with one press.

I understand that the query can be a problem if one uses the sensor reverse option on the ioloinc. That is, however, a good point that I did not remember.

The keypad button is set to non-toggle ON. ON will be the only command sent to the relay. Unless you have another way to send commands to the relay, the momentary mode chosen should not matter. If this concerns you, set the relay to be in momentary mode, responding only to ON commands.

Perhaps, too, this is another example of some capability in iOS versions versus Android? (I use android. I do not use mobilinc connect.)

EricK's suggested solution is an interesting thought. The only potential concern I have is that the lamp will go to the same preset level (local ON level) each time the ON button is pressed. From that level, it would go to the scene levels when the program executes. This may be noticeable in some cases, but with a judicious use of long local ramp rates, you may be able to mitigate this effect. This could work well. Keep in mind that using this approach, there is no need to define the lamplinc as a controller in the scene. Another issue to work around is what happens when a lamp is turned on by it's switch. Is this a concern for you? Expanding upon EricK's suggestion, you may also consider triggering programs from an OFF command.

The notifications about which I am aware are EMail and Text. I am unaware of notifications "to mobilinc". Perhaps we will learn together.

I understand that you can (as pointed out by franklyn7895) make the lamplinc a controller in your scene. However, I suspect this will not keep your keypad buttons in sync. A scene controller, as I understand, can turn a scene ON or OFF only. I do not believe it can have multiple ON settings, nor turn a scene to 50%. I believe you would accomplish this with a program. First, however, you would have to decide what you want as a relationship between lamplinc status and keypad buttons. Do you want button E lit when lamplinc hits 50% exactly? Or do you want button E lit when it is between 0 and 50%? Or something else. You will need to make similar decisions with regards to button F. Once decided, it would be relatively simple to create a couple of programs; if status lamplinc is whatever you decide then set keypadE on else set keypadE off if status lamplinc is whatever you decide then set keypadF on else set keypadF off

I don't have zigbee or zwave (yet) but I understand you can only have one at a time. My perception from reading here is that this works without external antenna, but may work better with one. Like insteon, apparently, z-wave works better as you add more devices.

The IR is useful only if you intend to control your system by IR remote control pointed at the ISY-994. If you have no such need, then skip the IR version. You can always add later, or use an IRLinc if you change your mind.

This is a pretty common topic. If you haven't, it is worth searching the forums under "garage". Also check under the wiki for a good article on this. I prefer to have a single button to control the door AND display status. This requires no program. Install the sensor in such a way that the sensor is ON when the door is open. Create a scene with the sensor as controller and button as responder. Then create a scene with same button as controller and relay as responder. Configure the button as NON-TOGGLE-ON. I assume you have the relay configured for momentary, responding to ON commands. Keep in mind that recent sensors shipped as part of the garage kit will be ON when the magnet is close. Earlier versions gave both options. This requires pretty close attention to details, so check back if you have difficulty.

It sounds as if your understanding of scenes, controllers, and responders is very good. I am not sure that I can add anything, but will try, just in case. I assume your scene "all on" is a scene you created. Make sure it has all the outletlincs and corresponding keypads, all as responders. Are there any other buttons that you intend to use to turn on or off ALL ON? Make sure that button or device is a controller. Your understanding is the same as mine with regards to back lights...that just sets the level for when a button is ON or OFF.

I would be surprised that the query, alone, sends an EMail. Can I assume that you have some other program that sends an EMail based on factors including garage door status? My first instinct is to suspect that you have a garage door but that the ISY does not know the correct status. The query corrects this problem, which the ISY perceives as a change in status. This change in status triggers a program. Of course, it is all conjecture without seeing any of the programs you have.

You can do a lot worse than following the suggestions of xathros. Please be aware that his approach did NOT rely on creation of a scene, nor did I see where he suggested creating one. Turning the lights on and off was handled entirely by the program. If you create the scene you suggested, there will be one duplication of activity and may create some unnecessary insteon commands on the power lines. The suggested approach was based on receipt only of ON commands from the sensors, which would trigger only THEN paths. This takes advantage of of a capability within the ISY to interrupt any ongoing WAIT statements, restarting the countdown each time motion is sensed.

How it works with relationship to the programs depends on your program, the motion sensor settings, and any scenes you create. First, about the motion sensor. All I know is that which I read from the manual. I understand that a motion sensor will transmit an ON command when motion is sensed (also potentially based on other factors such as darkness). I know that there is an adjustable timeout period, after which the motion sensor will send an OFF command (unless disabled by one of the jumpers, and unless motion is detected again). I also surmise from the manual that there is an 8 second period after motion detection that the sensor will wait before being able to detect motion again. If you were to create a scene with between a motion sensor (as a controller) and another insteon device as a responder, the other insteon device would come on when motion is sensed, and turn off when (and if) the motion sensor transmits an OFF command. If you were to create a scene with multiple insteon motion sensors and multiple insteon devices, the insteon devices would come on if any single motion sensor transmits an ON command, and turn off if any single motion sensor transmits an OFF command. No program would be needed in this case. Another option would be to create a scene with motion sensors as controllers and your other lighting devices as responders. Configure your motion sensors to transmit only an ON command and rely on the scene relationship to turn the lights on. Supplement this with a program to turn the lights off after a period of time after last motion sensed (based upon reciept of an ON command). In this case, the timeout period of the motion sensor is irrelevant. This is the option I prefer for my own use. A third option would be to not create a any scene, but use a program to both turn lights on and off. This is the approach suggested by the three of us in response to your questions and stated desires. All three of our suggestions appear to use a program to turn on the lights in response to receipt of an ON command from one of the motion sensors. Xathros and Franklyns approach is to start a countdown immediately, but the countdown would be interrupted any time a subsequent ON command was recieved by any of the motion sensors. (I must admit that I prefer the relative simplicity of Xathros version.) My version waited for all three motion sensors to be OFF before initiating a timer (after which it would turn the lights off), based on a very literal interpretation of your stated wishes. As with most cases, there are multiple ways of doing things and no single right or wrong answers to many of the questions you ask. Given your stated state of confusion with the whole "controller/responder" thing, my suggestion is to temporarily put on hold your motion sensor scenario and simply to experiment around with scenes only. Link one motion sensor to some lights and observe the results. Become familiar with the purpose of the motion sensor configuration settings and how that affects scene performance. Link one insteon device with another, varying options of controllers and responders and turn these devices on and off manually, observing the results with the other. Do this until you are less confused with what a scene does and the difference between a controller and responder. From there, start experimenting with programs. Once you have a level of confidence with this, you can make good decisions about your needs and how you wish to configure motion sensor settings, what scenes you need to create, and how to supplement those scenes with programs.

When I read: "My goal is to have all 3 sensors trigger an ON and not throw an OFF until ALL THREE sensors timeout (aka there is no more motion anywhere in the basement for X amount of time)." I understood this to mean to wait for all the motion sensors to turn OFF before initiating a countdown. It is for this reason that I was wondering aloud whether your solution met the stated need. In a practical sense, given that the countdown period is a known and fixed interval, it makes little difference unless one planned to routinely re-configure the motion sensor timeout period and did not want to fool with the program. (I don't know why someone would want to do that, but that would be for another day.)\ BTW, I prefer your solution, and is the one that I use at my house. This has the benefit of being able to use a scene to initiate the lights, but using the power of the program for deciding when to turn them off.