oberkc

I use MobiLinc. Yes, scece levels are accessed through the admin console. It is not an alternative to access through MobiLinc. I agree that scenes are best in this case rather than a program.

A single button to turn lights on and off is a natural, and most basic, function of a keypad button. It sounds to me like a simple scene would work (and I would consider the optimum solution). It is possible, however, that I don't fully understand what devices you are trying to "link" together. I know that you have a keypad, and want to use "a single switch" to control a light. Is the light connected to the keypad, or the "single switch", or another device? If you have two or more devices, both (all) of which you want to control each other, simply create a single scene, with both (all) as controllers. If, however, you have devices that turn on, but not off, you may be fighting comms issues as suggested by LeeG. If so, this won't be solved programmatically or via scenes.

Yes...find and replace...though you don't actually have to replace anything.

not that I know of, but one can perform a search within all programs for specific scenes, devices, other programs, etc...

How about the most basic of automation tasks: if time is from sunset to sunrise (next day) then turn lights on else turn lights off Agreed. There may be a couple of others who get an honorable mention, however. I would guess more like 95%

I am not, either. In fact, I find greater pleasure in getting the job done with fewer numbers of programs. I enjoy finding the simplest solution to the problem. I also have enough trouble keeping track of my limited number of programs that I cannot even imagine having hundreds of programs. Clearly, however, I do not even attempt much of what the real hard-core automators do.

I am not worthy to even be in the presence of this group. All have not counted, but believe I am WELL below 50 programs and can count my variables on one hand with enough fingers remaining to play a little Scott Joplin on the piano.

The addition of slight delays in key programs seems to be one of the recommended steps one can take to mitigate the effect. Pay attention, apparently, to programs with triggers by devices which are also scene controllers/responders, or programs that command those devices to do something. I remain a little fuzzy about these combinations, but it seems to be about avoiding signal "collisions". I had always assumed that the PLM would naturally handle such things, but this is not the case, apparently.

It is all about triggers. The first program will trigger (self initiate) upon ANY CHANGE OF STATE of the sensor. The next program will filter those, however, eliminating any not between the specified time period. The second program will NOT trigger at 0255 or 0305, however, since it is disabled. It is this last point that marks the difference between the approach I suggested and your original program. Your program was triggering at the two points in time defining your time range. Once triggered (at 0305, for example), it was, I suggest, evaluating true, and sending your dreaded notification. You may also want to consider CONTROL, rather than STATUS, of your sensor node as a program condition. Since the query returns an ON/OPEN when, in fact, the door is closed, the first time after the query that the door is truly opened, there will be no change in status. Using CONTROL condition should help solve that problem. Having said this, I believe you are still relying on a trigger reverse setting of the IOLinc, no? This may get reset from time-to-time, such as power outages. Once reset, sensor ON will equal door closed.

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