Sounds good. Thanks @bertabcd1234!
BTW, great app, even more considering it was one of your firs ones on Hubitat!
Is it possible to set the brightness level, color temp, or color per mode triggered by motion with this?
Not exactly. In general, it remembers the last level and color/color temperature (from before the app last dimmed the bulbs and turned them off), then restores those the next time motion becomes active. There is a special exception: the app allows you to specify one or more modes to consider an in-app "night mode," where you can specify specifc settings (a specific level/color/CT or a CoCoHue scene--I use this setting only in the bathroom and hallway and it goes to a saturated red at a very low level, enough to see at night without appearing jarring to the eyes). Nothing gets "remembered" from night mode: the app will use your night mode settings any time motion goes active when your "night mode" criteria are met, otherwise it will recall the "regular mode" settings.
I'm not sure how it would handle multiple modes. Because it dims, it has to remember the last level (this is all "faked"/remembered at the app level--I wish devices supported dimming and remembering their "old" levels when they get turned back on again), and because of the "night mode" setting, I made it remember the color/color temperature too (since night settings may disturb those). I could add one or two more "special" modes like night but that allow even more different settings if that would be helpful, but then it seems a lot like you just want Hubitat's own Mode Lighting/Motion Lighting, except they can't dim before off. I'm open to ideas on how to handle this (remember settings per mode? forget about remembering anything and just use your settings all the time when motion becomes active? preferences for behavior if the lights are already on?) and can't guarantee anything but would consider it for a future version.
2 Likes
Yeah I was thinking something like the built-in "Mode Lighting" app where it just always defaults to the settings specified in app, but checked every time the switch, in this case motion, is triggered. So all changes made while the lights are on are lost and reset once they turn off.
The biggest reason I am using this over the built in Motion Lighting app is because of the Night Mode feature that not only allows a specific brightness/color/scene but also the ability to keep some of the lights off.
Also I don't know if its possible, but when setting those dimmer levels, it would be nice to use global variables, so if I want to change anything, it is in a central place. That is another thing that the built-in apps do not support.
I would also really love to have this as an option!
If you want to make it even more complex, it would be nice if a mode or a sensor could be used to decide the setting. As an example, if it is dark outside (because of a rainstorm, cloud cover - low lux detected by a sensor or because it is the evening - mode), the light could be dimmed down, but if it is light out, it could be set to a brighter level.
1 Like
This would be sweet.
Also as a side note, idk if you have been following the thread, but a guy is trying to make a package manager that would track, install, and update drivers/apps. It is still in the early stages, but he is looking for as many developers as possible to try it out and give feedback, here is the link:
1 Like
I am a HUGE fan of CocoHue and with the ability to turn scenes OFF now (which is awesome), could this app be modified to recognize this capability? I understand that there was a lot of conversation on different philosophies regarding this, but am so glad you decided to add the ability to do it as it allows me to focus on developing scenes in the regular HUE app to do what I want and keeps everything manageable and in sync.
What I am after is the ability to specify scenes for different modes and name them appropriately in the Hue app and then just reference those according to what mode is in use in your Lights on Motion Plus App. Even though I know we can attach more than one mode to each setting in Lights on Motion, it would be great to be able to specify more than two behaviors. For example, a day mode referencing a fuller brightness scene, an evening mode with medium brightness, and a night mode with a very low brightness scene referenced. Being able to have your app reference the scene for each one of those modes and be able to turn them off rather than specifying groups of lights, would make things very simple. Right now it just doesn't seem to work with scenes the way I would like.
Finally, as you did with CocoHue and your dimmer controller, it would be great to have this app added to Hubitat Package Manager.
Thanks very much for all the work you have done in so many areas.
Actually, to get very close to what I am after, if in the 'Night' mode you could specify a different "switch" than what is used for the Day modes (which could end up being a CocoHue Scene) rather than have the same "switch" used with different parameters, I think everything would work. Right now the day mode switch specified (even though it is really a CocoHue scene) turns off as expected, it is just the night mode scene that will not turn off and just stays on.
Hmm, that second request seems like it would be easy--if it's in "night mode," just turn off the CoCoHue Scene that was turned on instead of the "normal" device(s)? My assumption is that these would be the same devices (in my case my night scene is one that just turns on fewer bulbs at a lower level, but the same room/devices), but I can see there being issues if not. I could do something to address that.
The first request would be a lot more work, but it sounds similar to things other people have asked for. I'll probably re-think the entire app itself at some point and would consider adding something like that. It's a bit different from my original intent with the app (basically I lived in an apartment with two-bulb fixtures on the ceiling, and I often only wanted one light on, and I didn't want the SmartThings-at-the-time motion lighting apps to turn on both just because motion was detected, even if one was already on; and I wanted the previous settings restored the next time motion was detected, under the assumption I'd manually change things when I wanted them to change and stay that way). I'm guessing the appeal here for a lot of people is the "dim before off" thing, which I added as an extra for myself because I was jealous of a friend who was all-in on Hue, where that can be done natively. 
The second option would be great and yes, you are correct as far as the night scene featuring either a subset of the bulbs of the normal scene or all of them set a lower level/different color/hue.
The dim before off thing is also awesome though unfortunately seems to break things where it doesn't end up turning the scene off if it is enabled. I know I'm probably using scenes in a different way than intended but it seems to be the best way to fuse everything together and not duplicate work in different areas.
Thanks for considering an adjustment and thanks agin for the awesome apps all the way around!
1 Like
@nnelson, @cjkeenan, @Sebastien, and others:
I'm working on a complete re-write/re-think of this app and am trying to accommodate as many of the requests above as I can. To do this, I do think it is best to allow arbitrary per-mode options (the one special "night mode" thing fit my particular use quite well, but I can see where more would be useful). However, I'm not quite sure what settings people are looking to configure per mode. Here's one UI design I toyed around with:
The idea is you choose "default" settings first (motion sensor, lights, actions for sensor active/inactive) and can configure specific per-mode exception for some of these settings (e.g., different lights for a specific mode, Night Mode in my example).
You could also effectively restrict the app from doing anything at all in certain modes (or make it only turn lights on or off but not vice versa) by choosing to do nothing when motion becomes active or inactive:
However, I'm struggling to see how CoCoHue users would like this to work. Lights on Motion Plus was originally written to imitate the "dim before turning off" feature that Hue allows with their Bridge automations, but you can't dim a CoCoHue (or Hue) scene, only bulbs or a group/room/zone. So, choosing to "Turn on scene X in mode Y" won't work unless you also specify a group/bulb to dim. (If all you want is on/off, this works.) So the issue is, when it comes time to dim the lights, would it make sense to use the "default" lights from above if you chose a scene? (Again, a scene can't be dimmed from the Hue API.) Or would it be better to have that specified per mode as well?
Also open to any ideas or mockups as to what you think the UI would make sense to look like. The above is what worked best for me in terms of being easy to write given the Hubitat app UI constraints while providing some options I think people are looking for, but then there are some question like the above, so I figured I'd ask others who might actually use this before I go too far in one direction.
I like the change. Knowing myself, I probably will have more comments after I try it...
Will we no longer be able to select the dimming level? It might be useful to be able to dim at different levels based on the mode.
Also, Would it be possible to select both motion and contact sensors to turn on and keep on?
This is just a UI right now...it doesn't do anything yet, and I haven't added back all the features I was thinking of. Just wanted to check with people before I got too far into it. I was wondering if one "dim to" setting or a per-mode "dim to" setting would be better, but I'm guessing I should do per-mode (or again, a "default" and optional overrides).
That would be my vote. 
Could you do a restrict between two times? I wanted the outdoor floodlights to dim before off, but can’t do it with it restricted to night.
Hi I'd be interested in being able to do the following:
I want to set up some outside lights that will come on dusk until dawn or between set times, set to Warm White at a certain level but when motion is detected go to Cool White and increase in brightness once motion has stopped go back to Warm White and reduce the brightness again or switch off depending on initial setting.
thanks.
My 2 cents. I basically want the stock Motion Lighting app, but with the addition of a dim before off. And clean up some of the confusing wording in stock ML app.
I don't know if I would use anything beyond what is available in the stock ML app. I don't have Hue, so I don't have any opinion either way on that.
Yeah, I have time- and lux-based restrictions in mind to add back (I say "add back" since this is a total re-write...just trying to get the harder parts figured out first).
It wouldn't be impossible to add this here (but there are a few things I didn't have in mind, like changing color/CT instead of just dimming). However, I think that what you want might already be possible with Simple Automation Rules--one automation that sets the light as desired based on motion activity and another that sets it as desired based on inactivity (the latest hub firmware update added "turn on and set color," which also allows you to choose a color temperature), then probably another set to turn the light on/off at the specific times.
I once had in mind a project to basically re-create the ML app as open-source so people could modify whatever odd things they wanted, but...still working on that. 
I think the "dim before off" thing makes this difficult to do with an ML-like UI, especially when coupled with deciding what to do when it comes time to decide what to do when motion becomes active again (restore the saved states? go to pre-specified ones? what if one or more devices is already on?), but I'll look at ML again and see if there is any inspiration I can draw from that. Otherwise, maybe something else in the future...
Thanks, all!
EDIT:
Added a few things to the UI...still playing around with how I want the options to be laid out before I make any of these do anything. 
and
Also, think I figured out the CoCoHue scene thing. You need to specify the corresponding group (or lights)--awkward, but no good way around this without making everything CoCoHue-specific. Basic set up:
(Not pictured: if you choose a scene for your non-exception active/on action, then you also have to choose that group; the checkbox above saves you from needing to choose the same one each time. If you don't choose a scene for your "regular" on action--meaning you aren't forced to also choose a group--then I suppose I'll use the individual lights like v4.x currently does.)
2 Likes
I'm wondering - I am removing all logging to try to help resolve major slow down issues with my hub (It appears to make a difference!). I am finding that even though I have debug logging turned off, I still get debug logs from this app (or its children). Is there something I can do to fix this? (If it is something I am able to do, I may also go and modify other drivers to do the same... I'm not a developer, but who knows!)
First, I'm secretly working on LoMP (as my beloved beta tester calls it) 5.0, which will have finer logging control. I'll try to release a preview soon and see what people think, though there are still some logic gaps I have to work out in it. It's drastically different from 4.0 (not an in-place upgrade) but far more powerful...still looks a bit like the above mockup I shared on June 9, though.
For the current/4.x version, the current logging hails from a time when people didn't really care about this because "Past Logs" didn't exist yet. "Debug logging" does indeed enable debug logging--it's just that there's more sort of informational logging that's always there, too. LoMP 5 will address this.
(that being said, we've also been told logging should have minimal to no impact unless maybe it's "exessive," which you'd probably have to try to do)
1 Like
