oberkc

Nice! Persistance is everything.

Is the switch a CONTROLLER or RESPONDER in the scene definition? You may need to remove it from the scene, and re-add it as CONTROLLER. Given that your remotelinc button is a controller in that scene, do you also want the ON levels to change when activated by this button?

I believe this is your problem. You need to select the switch in both cases, "in scene", and "set" (as in my original suggestion). I assume that the fixture is powered by this switch? I am curious how many devices, besides the switch, are in this scene?

" I don't believe that this is a problem. Make sure, however, that when you are picking the device for IN SCENE part of your action, choose the specific controller device, rather than the scene, itself. The way your program is written, I suspect you picked the scene, rather than device, itself. I believe the point is that you should not forget to "save" the changes to your program, and that the program should NOT be disabled. This must all be done prior to the FROM time, or you will have to wait until next day for the program to execute TRUE/THEN path.

Same question I have...is "bedroom lights" a scene, or a controller within a scene, or a single device which has no scene relationships?

With a program. The condition is straight forward. It would be something like: if time is from 10p to 9a (next day) Then- and Else-path is a bit more obscure. When you create the action for the THEN path, choose "adjust scene". Within the "In Scene" field, choose the controller device from the scene in question. In your case, choose the switch from the bedroom lights scene. In the "set" field choose the responder device. If the lights, themselves, are powered by the same switch, choose it. In the responder levels, set it to 5% when in the THEN path. Take the same steps for the ELSE path, except responder levels would be whatever you want during the normal hours. Keep in mind that if you have multiple controllers or responders, you will need to create multiple actions, one action for each combination of controller/responder.

I have a home theater reciever that consumes nearly 40 watts when powered down. I find out that this is due to enabling HDMI-CEC. Once disabled, the receiver uses very little power. Perhaps the cisco set top box has a similar aflliction. Does it have HDMI-CEC capability? Do you use this capability? Can it be disabled?

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.