Hi,
Based on the available options in Motion Lighting app, i THINK it will do what I need, but it is not working. Can somebody please confirm if I am expecting the working correctly?
Requirement:
In evening, lights should turn on and off as normal using a motion sensor (this is working perfectly)
In day, if somebody turned on the light manually... then Hubitat should turn it off if there is no motion (This is not working). I Know I can always try to create a seperate rule in RM for this, but it seems the app is already designed to do this, but I am not able to get it to work.
I don’t see in your post how you set it to not turn on during the day, but I set mine for between 2 times, which you can see in my screenshot. I also select any buttons or switches that I use to turn on/off the lights and don’t duplicate this function in apps like Button Controller or RM just to make sure that ML knows the lights are on or off.
Thanks a lot for looking at this and responding!!
To answer your question on how does it not turn on at day - I am using Modes. If you see my below config, then for Turn On, I have only selected Evening. But, to Turn Off, I have selected Evening and Day.
I am now randomly trying options there, not knowing what does what...e.g. I selected the "switches to turn off - to the physical switch for that light". I do not have any other RMs or rules for this switch.
If you see my setup, I selected the switch for the light in both "switch to activate on on" and "switches to turn lights off"...did you add that switch somewhere else too?
What option did you specifically choose to tell it, that the light has been turned on physically?
I don’t think that’s necessary, so long as the switch is reporting it’s state properly back to the hub. I’m using Zooz Zen77 dimmers set to “smartbulb” mode to control Hue lights in my setup, so I have included which buttons I want to have control on/off of the lights (which ML then monitors the events of and turns them on/off without needing a separate rule).
I think it might be the mode selection that’s making it not work for you. Try selecting all of your modes and fill in the brightness settings, etc. then select the “turn on only between 2 times” option to keep it from turning on when you don’t want it to. Sunrise/set are also options in the setting.
You could create a virtual switch with a rule to turn on with the mode you wish to exclude and off for other modes. Then use the switch in ML where it says “switches to prevent turning on”. This should work if you have all of the modes setup in ML, so it knows what lights to turn off. It’s also handy to have a virtual switch to keep ML from turning off lights sometimes.
I've never been able to get a ML app to work in vacancy mode. It certainly does not when trying to set up a sensor in vacancy only mode. I'm surprised to see that some have gotten an app to work in mixed occupancy/vacancy mode. ML seems like a simple app. But some of the optional settings really increase the complexity of the interactions between sensors and lights. And some of those interactions are only partially documented.
I think a vacancy app would be useful, particularly for newer users. Simple rules work frequently, but also frequently require RM rules. I think the whole ML app could use a refresh and be made more user friendly and generic, i.e., instead of "motion lighting", call it "occupancy lighting". Another example, one must use a virtual contact/motion sensor to use a physical contact sensor as the trigger for the app. Which is a small deal, but creates added complexity. Tagging @bravenel to see if there's any future improvements on the list.
ML is admittedly quite long in the tooth, given that it began before Hubitat was founded, and has just sort of grown since then with more and more options. It could definitely use a major refresh, but realistically that probably means an entirely new app.
Occupancy itself is a difficult topic without good general solutions. The suggestion to do "occupancy lighting" is biting off a lot, and I fear would end up with as much complexity as ML has now. If you look at the options ML has, every single one of these came from a user need. If you're like me, you use just a subset of these that fit your particular use case. I know exactly what my use case needs are, and the rest I don't touch. Generalize that, and you have a lot of options to cover the use cases and a fair amount of complexity that goes with. I don't know how to avoid that and meet the use case needs.
So as much as I'd like to say, sure we can make a new app that is refreshed, more user friendly and generic, there's not a clear path to defining and accomplishing that.
Support for actual contact sensors was added two or more years ago. I posted a screenshot of my ML instance that will shut the lights off while restricted to not turn them on that also includes a contact sensor turning it on. I did trigger the motion sensor in my test as I didn’t think it would turn off otherwise.
I see that contact sensor option. But from the app help:
"Select any contact sensors you'd like to use to turn On your specified lights. If you only define contact sensors to turn On the light, turning the light Off will be handled solely by motion sensor activity."
I don't want to use a motion sensor in the app, just a contact sensor. There's not much difference between motion and contact sensors other than how they're triggered.
This comes up from time to time, and I"m not keen on adding this. It's still Motion Lighting, and this would add yet more complexity to it.
Meanwhile, If you want to use a contact sensor in the app, use this app from our public repo:
This allow you to have a virtual motion device that goes active/inactive as a contact sensor opens/closes, and this device can be used in Motion Lighting for the outcome you desire.
I think there are ways to think about the app that could make it more useful than just motion events. Something like "light timer app".
a) What triggers the timer start (sensor, switch, etc.)?
b) What happens when started (lights on for a occupancy scenario, just the timer in a vacancy scenario).
c) How does a timer get reset? (motion, contact, switch events).
d) What can cancel a timer?
e) What can cause a timer to end before the time runs out?
f) What happens when a timer ends? Lights go off, etc
Some/many of these are already in the app. But it's hard to know what some of the items do and their interaction with each other. Maybe it would as much of a UI restructure as anything.
Then you cans sell it for $90 (There actually might be some useful ideas here)
A decent amount of effort has been applied to the UI in the upcoming release, mostly making it better organized for clarity.
The reason that Motion Lighting exists in the first place is that there are certain interactions of options beyond the basic motion-active-on / motion-inactive-time-off core, that it would take a number of RM rules to do, or rules that are ridiculously complex to deal with these things. For just the core automation, a Basic Rule does it quite well.
The app problems arise from overrides, and yet, overrides are important for a motion lighting automation. We use ML a lot in our home, and use modes for less bright lighting in the evening and at night (if on at all). But there arise circumstances where something purely automated will do the wrong thing if you can't easily override it, and those overrides lead to complexity in the app. So here we have a core automation concept that must admit to easy modification on the fly, and then gracefully recover from those modifications just as easily to restore its primary functionality.
I do believe that the needs for this functionality beyond Motion Lighting represent pretty marginal use cases -- even the use of contact sensors as you've requested is a marginal use case for ML. Other sensors? Please, there is just no use case demand, and we'd get to something akin to RM very quickly to satisfy a very small number of people. Ah, just like it's a very small number of people willing to pay $50,000+ for Control 4.
From my own use case the number one issue for ML is that it doesn't do vacancy on its own. And for all of what you state, I have scenarios where Simple Rule doesn't get me all the way there, so I end up using RM. I get it to work. Just not as straightforward as it seems it should be.
My point about Control4 is that their built-in motion automation isn't very good. So someone built a much better app. C4 native automation is Simple Rule level. Anything else requires RM type automation. I'd say C4's rule engine is similar to Hubitat's. Lots of clicking. C4 does have some drag and dropping. That $90 app is worth it for customers if they're paying $100/hour to program each motion rule.
Also, C4 is not really outrageously expensive. Their controllers range from $500 to $2000 MSRP as of a couple years ago, the higher end ones mostly just have more AV capacity. The way C4 systems get expensive is by adding AV equipment. Even with AV equipment there's a breakeven point where Sonos would cost more. C4 lighting is about the same as RadioRA 2. Since it's not DIY, there's obviously programming and labor.
If you mean that you want ML to turn lights off when motion stops (some time after that happens), but not to turn them on from motion, it will do that. I guess that assumes that the lights are turned on by some other means. This is accomplished by using an option to disable turning the lights on, such as selecting every mode for 'Modes to Disable Turning On', or using a Hub Variable, etc.
I know there is "Modes to disable turning off"... but is there a "Modes to disable turning on" too? If yes, then that might be the answer to my original question.
Yes, there is such an option. See screenshot above (yours may not be laid out the same way, but the option is there). ML doesn't care who turns on the lights, itself or someone/something else. The on and off logic of the app are separated, and it monitors the state of the lights.
(There actually might be some useful ideas here)
