Motion Lighting request and commentary

📢 Feedback Feature Requests
1

I have at least one request and some commentary. After several months with HE and utilizing primarily control functionality I’m now adding some motion/presence automation.

TL;DR - is it possible to add a switch to temporarily disable motion-on? Called “Manual Off: Exit Time Delay” below. Yes, I know how to do it with adding a rule and a virtual switch. But I think it makes sense to be able to do it in the ML app.

I read a thread where Bruce said he didn’t want to add more complication to Motion Lighting. I get that. I do think there is an opportunity to simplify, streamline, and make ML more capable.

Light switches/dimmers with integrated motion sensors, smart or “dumb”, seem to all have 2 main operating modes with some sub-categories. Those modes are auto on/auto off and manual on/auto off.

For example, “dumb” Lutron motion sensor/dimmers (MSCL-OP153MH http://www.lutron.com/TechnicalDocumentLibrary/048480a.pdf). They have 4 programmable modes:

  1. Auto on/auto off. The default. Hubitat Motion Lighting does it (so does Simple Lighting)
  2. Auto on if low light/auto off. Light level is essentially the only condition. Motion Lighting does lux and adds mode and time conditions.
  3. Manual on/auto off. Also called Vacancy Mode. Hubitat Simple Lighting does it. Motion Lighting does not.
  4. Off while occupied mode. Auto on and auto off. But if the light is manually turned off while occupied, the light stays off while the occupancy sensor continues to be active. Think of a room with lights manually turned off to watch a movie. ML can’t do it without adding a RM rule.

The Lutron dimmers also have a “Manual Off: Exit Time Delay” where motion on is disabled for 25 seconds if the light is manually turned off. ML can’t do it without adding a RM rule. (This is the functionality of my request above.)

When moving from a “dumb” or “old” thing I believe it makes sense to be able to mimic the “old” ways as there is (usually) lots of history for the way those devices work. Some of the “old” is replaced and/or enhanced by “new” devices. Which Hubitat Motion Lighting does well. Being able to replicate standard flows also supports Hubitat’s goal of creating a “home automation platform upon which people can create the automations to elevate their homes”.

I get that that accommodating some of these functions in ML would require a fair amount of app restructuring. For example, to accommodate Vacancy mode, one would have to choose “Lights to Control” as compared to “Lights to turn On” and then have actions for sensor active and sensor inactive.

A potential simplification is to remove some existing options that are duplicative of a Button Controller app: “Buttons to turn on lights”, “Buttons to toggle on/off”, “Switches to turn on lights”, “Buttons to turn off lights”, and “Switches to turn off lights”.

I imagine a moderate-high level re-write would not be high on the priority list. But thanks for considering.

2

It's already there.

53%20PM

This wasn't implemented before because no one has ever asked for it. Trivial to add though, so that if the lights are not turned on by motion (for example because it's disabled as above), but are then turned on by some other means, they will still turn off from motion inactive. It is possible to disable turning them off also by various means.

This one also hasn't been requested before. ML comes close with it's override options. For example, it has "Don't turn off if already on". Easy to add the complement, "Don't turn on if turned off manually". This wouldn't reset until they are manually turned on to clear the condition.

Both of these two features have been added to ML, and will be in the next release.

3

Thanks! To accomplish my use case the switch to disable turning on in the current app needs to be turned off after X amount of time. So one needs to add a virtual switch and a rule. Not hard, but it's an additional 2 steps outside of the ML app.

4

Oh, is this the 25 second thing?

So you need a means of temporarily disabling turning on? Based on what happening?

Where is this feature of a Lutron dimmer? How does it even make sense given that their motion sensors have a minimum cycle time of 60 seconds? Is this a feature of the free standing (not RA2) dimmers with built-in motion?

5

Ahh. I've figured out part of the ML app functionality, including differences with the Lutron motion dimmers.

I'm talking about dumb (not connected to RadioRA 2 or any other system) Lutron dimmers. They have configurable timeouts of 1, 3, 5, 15, or 30 minutes. The way the Lutron motion sensor works is that if the dimmer is manually turned off the timeout delay is cancelled and the 25 second “Manual Off: Exit Time Delay” is activated. So if you have a 5 minute timeout, press the off button (toggle on a Maestro style device), the lights go off and the 5 minutes timer is reset. If you activate the motion sensor after the 25 seconds the dimmer will turn on even if it's not been 5 minutes since motion was detected.

After testing with Hubitat ML I think I can make some observations.

  1. The ML delay timeout essentially pauses the app. The app does not monitor the light status during that delay. So, if the light is turned off outside of the ML app during the delay and the sensor detects motion again during that delay the light does not turn on. That is the functionality of "off while occupied mode" (#4 of the original post). In fact, the app will send an off command when the motion is not active and the delay has passed even if the light is already off.
  2. If the ML delay is short - like 1 minute then the current ML functionality isn't that much different than having the “Manual Off: Exit Time Delay” function.

In the end I think it would make sense to have a configurable delay (mimicking the Lutron “Manual Off: Exit Time Delay” functionality) that would reset the ML delay timer, especially if the ML delay is long. But I don't think it is a high priority.

I'm sorry if this set off a lot of action on your part.

6

I'm not inclined to go down a path of mimicking dumb devices, that have had to add features so that they have some minimal functionality.

Also, it's not that the app pauses during the delay, it's that the app generally does not pay attention to manual operation of the switch. Manual operation of the switch can be used for certain optional override circumstances, but otherwise is ignored. There becomes of level of complexity with the interactions of automations and human intervention, such that attempting to ascertain the intent of and hence response to human intervention quickly becomes a losing proposition if not very narrowly defined. "If I turn the switch off in this circumstance I expect this response." The intent here is to create an automation that obviates the need for human intervention.

Actually, this set off about 15 minutes of poking at the app. The feature for "don't turn on if manually turned off" is a good addition -- useful as you point out for a watch movie situation. It has an inherent weakness though, which is that the turning off of the switch in question will always be interpreted as an action that effectively disables the automation until reversed. This would probably be a bad choice for rooms where manual operation of the switches occurs for a multitude of reasons. For example, turning off the light when one leaves the room by the switch, then coming back to the room and not understanding why the lights don't come on automatically. So it has very limited usefulness: only in a room where the only use of the switch would be to enter movie-time.

I have about 25 instances of Motion Lighting in my home. I live with it every day. I'm very sensitive to its nuances. I use it with various settings depending on the specific room. Most are very simple, just turn on with motion and off a minute after motion stops. Some are very complex, with buttons to disable and buttons/times to enable and switches that act as master-on/off switches. We very rarely touch any light switch in our house, and very rarely touch any Lutron keypad either

7

I agree with what you have written. The potential issues between expectations actual functions in motion lighting really only arise with long delays. And I understand how complex the scenarios can get with a HA system.

As I said, with short delays manual "offs" are pretty close in functionality to the dumb devices. But if one did have a 30 minute delay motion-on wouldn't reactivate until a continuous 30 minute vacancy. Which might not meet user expectations. In the case of long delays, a reset of the delay after a manual off can be valuable. The question is how often do people have long delays. I don't so it's not a priority for me. But I'm just 1 customer.

And the "don't turn on if manually turned off" already works implicitly in ML. As long as there is motion during the delay the light won't go back on. It might be mostly a documentation issue.

Thanks again.