Rollbacks and actions from another zone

What triggers resetting the rollback timer for a zone? Is it only actions caused ON devices in the zone? As in, only with button presses on actual hardware? Or would a scene from another keypad or occupancy sensor also reset the timer countdown?

This would sort of allow both a timer rollback and an occupancy sensor. But it'd only work if the sensor's triggering of a light would also reset the rollback for the zone containing the light. The sensor would be in a separate zone, as rollbacks can't be configured with a sensor present in the same zone.

wkearney99-
See this thread- https://forums.lutron.com/showthread...nd-Time-Clocks

It appears once rollback is selected for a given room, any "on" for that room triggers the timer for the rollback. This would include sensors, scenes, and time clock events.

Quote:

---

Originally Posted by SanDiegoRep

wkearney99-
See this thread- https://forums.lutron.com/showthread...nd-Time-Clocks

It appears once rollback is selected for a given room, any "on" for that room triggers the timer for the rollback. This would include sensors, scenes, and time clock events.

---

I find this to be a baffling design decision by Lutron, and in my case, negates the use of rollback. What is the underlying logic for having a timeclock event trigger a rollback? If I want a certain light on at a certain time, and then have it come off shortly thereafter, I can always program the appropriate timeclock event. However, if there is a light I want to use the rollback feature on (say my kids bathroom lights, which they always forget to switch off), but sometimes I want to stay on for an extended period (say those same lights dimmed overnight), I can't do it.

Quote:

---

Originally Posted by freeoscar

However, if there is a light I want to use the rollback feature on (say my kids bathroom lights, which they always forget to switch off), but sometimes I want to stay on for an extended period (say those same lights dimmed overnight), I can't do it.

---

What would you be doing that somehow told the system that you're overriding the rollback or sensor detection?

Short of changing the system mode (home, away, etc) there's nothing that'd do this effectively. There aren't any conditionals in the programming. There isn't a way to tie actions to the state of something. You'd need to use a 3rd party system to add that kind of logic.

One thing that helps with unintended rollbacks or sensor timeouts is using different timing for both the off and the delay. I use this for keypads. There's an "Area Off" scene tied to the bottom button on most of them. This has several devices set to be immediately turned off, with a very quick fade. This way the person using the switch knows it's been activated. But a few of the lights have a delay until they turn off, and sometimes a longer fade. This gives the person a chance to leave the area with some remaining light. Or it tells someone still in the area that lighting is about to fade and gives them time to press a button bringing it back. It's not perfect but it's pretty good for most situations.

One situation where it doesn't really work is a front porch light. I have one set up with an occupancy sensor (a since-discontinued black one :( ). This works great for bring up porch light anytime someone's on the porch. Except for summer nights on the porch swing. There's no good way to leave the occupancy sensor 'in charge' for that as it sees use of the swing as motion and turns the lights back on. Now, I can do something like set timeclock that suspends the sensor for a while. But then I'd lose sensor control for detecting foot traffic when there's nobody on the swing. Or block the sensor so it doesn't 'see' the swing... or anyone sitting in chairs near the foot traffic path... won't work. Or I could duplicate ALL of my timeclock events into a new mode and toggle that using a keypad button. This kind of works but makes for a pretty cluttered programming environment, and requires making sure to put the mode back again.

I think Lutron's implementation is about as good as it can get without there being conditional logic supported in the devices.

Well there is some basic level of conditional logic available to the Lutron programmers as the rollbacks are, as I understand it, re-set due to activity in the area, even if not the exact switch the rollback has been placed on. And of course there is basic conditional logic available as well - the timeclock function. So I'm not sure that Lutron itself can't change the functionality of the rollback to something like I propose, where a timeclock event doesn't trigger it, or even if rollback status (active/not active) can change based on the active mode of the system. That is what I am hoping for - under normal mode the timeclock would be active, under a 'night' mode it would not.
Alas, these should be the biggest problems in my life. Also, wanted to thank you for your many posts I perused as I was setting up my system - I used your suggestion dimmer/keypad placement functionality and found that it works great for me, my wife and guests.

Quote:

---

Originally Posted by freeoscar

So I'm not sure that Lutron itself can't change the functionality of...

---

Several things come to mind here. One, the controller used for the main repeater is pretty ancient tech. It's not terribly powerful and I'd venture it doesn't have a lot of RAM for doing much more than it already does. I know, this is a pretty lame excuse in the days of $35 Raspberry Pi computers. But know the Lutron hardware is pretty darned reliable. Set and forget, no babysitting. This has value. Enough to offset the lack of emerging market needs? Hard to say.

The next thing that comes to mind is Lutron's inscrutable handling of the market segments. They've been hell-bent to keep all of these product lines separate. Why, well, that's why I wrote 'inscrutable'. I'm sure there's folks firmly entrenched in management that are completely convinced their approach is best. The Titanic thought it was on a good route too. But even without icebergs, air travel would eventually kill steamships anyway.. and all the suppliers dependent upon them. The market pivots and entrenched players get left behind. But, through it all, Lutron continues to make quality gear. There's cheaper, there's more versatile, but they're really not as good. Can they get better sooner than Lutron wakes up and pivots? That's the $64k question.

Quote:

---

Originally Posted by freeoscar

Also, wanted to thank you for your many posts I perused as I was setting up my system - I used your suggestion dimmer/keypad placement functionality and found that it works great for me, my wife and guests.

---

Glad to help. I've long espoused the notion that any kind of automation depends entirely on the WAF (wife acceptance factor). Keep it straightforward, unintrusive, reliable and always avoid unexpected results.

The unexpected results thing is tricky when it comes to scenes and button presses. We've been conditioned with regular lighting that buttons are usually toggles. On and off. It's a real leap to get to using scenes on a regular basis. Most of the time we don't. The most common scenes are the ones that are set up for "Area Off" control. As in, we're done with the space, now tidy up the lighting. We're starting to make more use of scenes with the advent of voice control via Alexa devices (Echo, Dot, etc). I bridge between RA2 and Alexa through Homeseer. Lutron's offering doesn't quite cut it, yet. It works but then you run up against the lack of conditionals. With HS3 I have some Area Off scenes additionally tied to schedules. Hitting an All Off button from the office, after 9pm, brings down the office lighting, but also brings up a low dimmed path of light into the rest of the house. Those are timed out after 2 minutes. Makes for a nice bit of assistive automation without being over-the-top.

You can do this in HWQS but the initial entry is STEEP and there's no upgrade path. Well, if you've read my other posts you know how I feel about that.