I tried that. It works in all modes. 
I like your future plans! Here's hoping you get to it one day. For now, I just made a copy of your code in a new app & child and commented out the parts that turn the lights on. It seems to work, but it would be nice to have it all in one! 
The "don't turn on" switch coupled with the "always turn lights off" option should still work. 
So essentially, There are two options for this.
The first is to setup a switch that will tell it not to turn on lights when the switch is on.
The second is to not select a sensor in: "When motion is detected on sensor(s)", but only select one from "Select additional motion sensors to keep lights on (but not turn them on)".
Tried out the second one and it works! Thanks!
Ooo, good find--never thought of that second idea! (Honesty would have thought I'd make that first sensor required rather than optional...definitely been a while since I looked at the code that does the core functionality of this app!)
I'm glad you didn't! Saves me from having to create a virtual switch... 
I am finding that the app shows me debug information even though I have debug turned off... Is there something else I need to do to not see those in my logs?
app:9322020-04-03 22:31:17.322 debugMotion detected; cancelling dim/off timers and deciding what to do
app:9322020-04-03 22:22:50.448 debugMotion detected; cancelling dim/off timers and deciding what to do
No, some logging remains even with "debug" logging turned off; when turned on, it just shows you greater detail (useful if you are actually debugging why something isn't working how it's expected). I'm working on some changes that will make this more consistent--this was one of the first things I did on Hubitat and I wasn't as familiar with the conventions (which really still aren't as established for apps as they are for drivers) then, nor did people care as much then when "Past Logs" wasn't a thing.
In the meantime, if you do want them all gone, you can comment out any lines with log.debug (or log.anything, I guess).
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.
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.
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:
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!
@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).
Download the Hubitat app
