oberkc

I expect this to work, yes. Don't forget to get rid or your old program, if you have not done so already.

No. My syntax was, unfortunately, approximate. Sorry. The difference is that your program condition is unrelated to syntax. Your program has two triggers: 1) status ..... is ON 2) time is from ... to My "next" program has only one trigger 1) time is from .... to

Compare the condition of your program: Status 'Overhead garage door-Sensor' is On And From 3:05:00AM To 2:55:00AM (next day) with that of the "next" program: time is from 0305 to 0255 (next day)

Not quite. While the "next" program may be similar to your original, it is not the same. Delete the original program (or modify to match the "next" program.)

On the surface, your program looks like it should work. However, consider the triggers of your program: Change in status, time is 0255, and time is 0315. At each trigger point, it will evaluate the total condition and respond. So...at 0305, if the status of the sensor is true, it will send a message. You may need to take an alternate approach. Try a couple of programs: if status of sensor is true then run next program (if path) else nothing Next program (disabled): if time is from 0305 to 0255 (next day) then send notification else nothing I understand you may be able to safely remove the query program, but it serves a useful function, so I would do so only as last resort. The query program can be helpful in keeping devices synced with ISY in the event of comm problems.

I would certainly think it possible to exclude a certain time period in a program to send notifications, yes. Is it possible you have an error in your program?

I tend to prefer the approach to use scenes only, non-toggle-ON button, with the sensor turning the button OFF when the door is closed. Using this approach, there is only one way for the button to be off...that is, for the door to be closed. There are several ways that a button can be ON...Comm problems could result in the KPL being ON. Pressing the button will result in the KPL being ON. This results in more uncertainty. The benefit of this approach in my mind is a higher level of confidence that when the KPL is OFF, the door IS closed. It is more important to me to KNOW when the door is closed. If one assumes the the way you want it is "right", then yes. (For the record, I happen to think the way you want it is the best way.) The sad part is that the three-wire sensor used to be standard-issue with the garage kit. Why smarthome changed it is beyond my comprehension. Yes, the KPL backlighting can be configured as you suggest. Backlighting levels for ON and OFF states are adjustable, to some degree.

I understand the point of those who suggest that having door locks and garage doors connected to an automation system may present an INCREASED security risk. On the other hand, if used properly (and no unexpected bugs) there may be an argument to suggest that such an arrangement can be MORE secure. A program to close the doors if left open by accident, for example...A program to lock the doors automatically at night....The ability to check and close the garage door from any part of the house without having to walk to the garage....The ability to close and lock the doors while away, when inadvertently left open or even automatically closing the garage door when leaving the house....The peace of mind from being able to check the status...all things which can, arguably, ENHANCE security. On balance, it is unclear to me whether I am more or less secure with these gadgets, but there are instances where having them is helpful from a security perspective. Adding to that is having some additional convenience thrown in, and I don't find it too hard to understand why some want to automate garage doors and door locks. I will admit, however, that living in an area where I don't really worry about break-ins is really nice and also a factor in my decisions about the level of security I need. It is not much risk for me leaving doors open and unlocked, so I don't think too much about the risk/reward part. It is primarily a convenience thing for me and and something I enjoy.

And, you have to make sure that when the door is closed, the sensor is OFF. The current garage door kit includes a sensor that works backwards.

Indeed, the mini remote is my fan controller!

I agree with the initial responses. I have both devices. Both are good options with the limitations being nothing more than the obvious....corded versus not. Batteries versus not. One is lit and can provide feedback regarding status of other devices, the other cannot. One is lit and can be distracting to those who like a dark room. One is more likely to get lost in a seat cushion. One is dual-band and may have more robust communication under certain circumstances and can enhance global insteon communications. All other things being equal, I would tend to go with the keypad/enclosure, but all things things are rarely equal.

Yes, give it a shot. Let me know how difficult you find it. My problem is that I want to base arrival to home and departure from home based on two conditions, one of which is the wifi connection. Tasker handles this well. I am not sure that the other solution does. Besides, I already had tasker and mobilinc. My experience, also, is that (like plumbing) projects with routers are always more complicated than they should be, fraught with unintended and painful consequences.

What kind of phone? Does he use mobilinc or, if not, are you willing to add it? I have not tried xathros suggested method, but it looks pretty interesting. I may have to try it. Until then, I use a method based upon mobilinc and tasker apps on an android phone. Ios has geolocation, but not sure if connection to wifi is a possible condition.

That sounds like a great solution. I like the simplicity of the approach.

That is a great question/point. Unfortunately, the answer is NO. If this is important, variables might be the best/only option, but you would have to supplement your approach by changing the variable initial value each time you come and go.

create the most simple program possible: if nothing then nothing else nothing In tasker create a couple of tasks. One will be the entry task for the profile. The other will be the exit task for the profile. The entry task will be, from the mobilinc add on, to run the simple program (then path). The exit task will be to run the simple program (else path). Then, in mobilinc, create a profile. The profile will be active based on conditions you choose to determine when you are home. The conditions can be GPS coordinates, cell towers, connected to home wifi, etc....When the profile is active, run the entry task. When the program becomes inactive, run the exit task. Now, when you are home, the simple program will be true, because it last ran the THEN path. When you are away, the simple program will be FALSE, because you last ran the ELSE path. Use the status of the simple program as a program condition: if simple program is false and ( back door is opened or front door is opened ) then notify me else nothing

Or, simply, create a program with no conditions or actions. Tasker would simply run the program THEN path as an entry task and run the ELSE path as an exit task, and you can use program status (TRUE or FALSE) as a program or folder condition. No variables required.

I don't fully exploit insteon ability to define different responses to different controllers. Most of my scenes are defined in such a way that, regardless of controller, the responses are the same. For people like me, an option to apply response levels to all controllers in one or two steps might be useful. However, I would not like it to impinge upon the ability to define different levels for each controller of a scene. That is not a trade I would support. In the end, I don't care about a little bit of work up front. I don't find it too much bother to create large programs because the interface to add program lines works well, in my mind. My perception, also, is that a lot of people have pinned a lot of hope on this version known as 5.X. I am afraid it is going to suffer the problems associated with high expectations....it is very difficult to live up to lofty goals.

Yes. You have two controllers. Each controller has two responders (itself and the other switch). Each responder has two parameters (ramp rate and level). 2x2x2=8.

IOLinc is not dual-band, so it will not respond, at all. The fact that some blink green is good and, I believe, sufficient confirmation that you have communication across legs of your electrical system.

Yes. I have a couple of fluorescent lights controlled by a switchlinc. For the past two years, this has worked flawlessly. Now...not so much. Things happen. Devices age. Electrical gadgets are added to your house. I am with the others. I suspect your communications is marginal. My suggestion, like the others, is to start with the basics. Do you have communication across the legs of your electrical system? Do you have your PLM plugged into an outlet and circuit that is relatively free of signal-disruptive devices? Is your garage door opener causing the problem?

No decoder ring that I remember. One can often figure out some things by inference, and I understand that smarthome publishes a developer guide, but that disclosure of that content may obligate the discloser to shoot you. Personally, I think I recognize insteon device addresses, in that they appear to be six-character hex addresses. I have also come to learn that "hops left=0" to be generally bad and "hops left=2" to be, generally, good. You might try a "scene" test, using any scene that is giving you trouble. As a whole, you are probably going to have to fall back on they typical troubleshooting methods to identify any problem-causing devices.

If a dimmer is powering the lights, and the dimmer LED indicator is moving to ON, and the attached light does not turn on, then I restate my best guesses from post #4.

Failure of the IOLinc is not my first guess. I would try a few simple troubleshooting steps first. Is the IOLinc plugged into the same outlet or circuit as the opener? Does unplugging the opener solve the problems? What is plugged into the same outlet and circuit as the PLM? Does moving it to another circuit solve the problems?

"Why would that cause a loop? I ask because the basement main control is part of the basement scene but works. " Xathros' response, above, is the same as I would suggest. It is one of those logic priorities, similar to the mathmatical "distributive" property we all learned in the fifth grade, but forgot by the sixth. Logical AND trumps logical OR.