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
Well... I'm not sure what is considered excessive... I have 325 devices and apparently only 38 apps (though most have children), and as I was going through them yesterday and today to disable their logging, most of them seemed to have logging enabled...
Now I am trying to clean up other apps that are logging. I'm dabbling in the code, adding inputs that provide me with an on/off switch, but I can't seem to find how the code knows to not display in the logs afterwards... I hesitate to modify other people's apps, but for some of them, I don't think the devs are very active... (I am not a developer, but I do know enough to be dangerous... 
)
Hey, me too 
Also, I’ve mostly kicked the habit of pushing my toys well past their limits (my wife calls this breaking them), and have started to appreciate stability.
FWIW, I didn’t appreciate any difference in stability or speed when I disabled all of the logging from apps and devices. It was just wasted effort.
Haha! How do you know their limits if you don't test them! 
That said, I have so many devices, and so much going on on my hub that I figured it couldn't hurt. At the very least, now I have a much cleaner log!!! I have it up for over 5 minutes now, and have only 3 items in the log!!! (I use to have at least 3 a second...)
Don't know for sure though if it is making a difference. I just rebooted, so it is blazing fast! (Okay, maybe not blazing, but faster than when it has been up for a while)
And running my heat map is now taking half the time... I'm not yet at 2 seconds for step 2/4 yet, but 30 seconds is better than 60!
1 Like
Greetings, everyone! I've released a beta of LoMP 5.0 (as I have now affectionately heard it called...and liked), which is a complete rewrite of 4.x and similar versions along the line of a post I made above a while back. Important for 4.x users who want to upgrade: see the note at the end of this post, in the first post, or in the repo README for how to upgrade (do not overwrite the 4.x child app code if you want to keep your 4.x apps).
This adds several new features, including:
- optional per-mode settings instead of one optional specific "night mode" setting
- ability to dim instead of turn off
- ability to completely configure any "active"/on or "inactive"/off-type action, including not only the new option above (dim only without turning off) but a multitude of other combinations, such as not turning on at all and only turning off (or dimming or dimming and then turning off) and any combination of per-mode "override"
- mode-lighting-esque features: besides optional per-mode "on" settings, LoMP can change current light states to specific per-mode states if mode changes while lights on (will not turn on in response to mode change if not already on)
The downside is that some setups may take a bit more clicking than before. The upside is that everything is now much more configurable.
I don't have everything well documented yet, but the basic idea is this: create a "default" configuration that you want to happen in most cases (choose sensor, choose lights, choose "on" and "off"-type actions). If you want this to happen all the time, you're done. If you want this to be different in some mode(s), check the box to configure per-mode exceptions, and configure any mode you want to be different. Non-configured modes will use the default settings. (Note that if you only want the lights to turn on in one or two modes, it may make more sense to have the defaults not turn on the lights and simply configure those one or two modes as exceptions instead of all other modes. It took me a while to figure out that this would work better for me in some rooms.)
Let me know if you try the new version and have any problems or feedback!
Important note for existing 4.x users: there is not a direct upgrade path to 5.x, but you can keep using both child apps together. Simply upgrade the parent code and add the 5.x child code as a new app. Keep the 4.x child code installed (or grab it from the deprecated folder in the repo if you forgot) as long as you still have 4.x child apps in use, which you can continue to use indefinitely.
7 Likes
Going to give it a try!
Thanks, and PM sent.
I see that in V4 of the child app, "When motion is detected on sensor(s)" was not a mandatory selection but it is for "Turn on lights when motion detected on" in V5, but instead you have an option under "When motion is detected..." to do nothing. Nice!
Also really like all the great additions!
Could turn on and turn off be available as separate option in to: "If lux above this range, then..."? Usecase: It is cloudy. Light turns on. Sun comes out, but now I assume the light will no longer turn off after the set amount of time...?
Lux behavior is configurable; the two options now are:
- "Do nothing (do not turn on or off/dim)", or
- "Do not turn on, but dim/turn off if configured"
The idea here is to ensure the lights never get accidentally left on, while leaving you the option to make it a "naive" restriction (a la Simple Automation Rules, to the confusion of many) if you like. As long as you have that second option selected, I think it will do what you want--as long as you have some sort of "off"-type action configured for inactivity (either in general or for the current mode if using per-mode settings), unless I'm misunderstanding something (either what you said or what I wrote 
).
1 Like
The only "odd" thing I see with V5 is that debug logging (and lots of it at that) seems to be permanently on, despite selecting that setting. It isn't the parent app, it is the child.
So is there a way to turn off the excessive logging?
Thanks.
Honestly thought I did that before release, but maybe I uploaded the pre-edit version--sorry! I had a ton in to help with debugging during development so that I could see the code path if anything went wrong. If you don't want any logging at all, commenting out or just removing any line that contains the sequence "log." (like log.debug, log.trace, or log.warn) would be a quick-and-dirty way, though if you want it where it was intended you should leave the log. lines only inside the logDebug() method.
Or...eventually I'll upload a version how I intended it to be. So far I haven't received any reports of major problems, but I'm not sure if it's because nobody has used it or tried any strange combination of settings that my dedicated beta tester did not, or if it's just good-to-go as is. 
1 Like
I’ve been using it since you posted the new version and haven’t noticed any problems.
1 Like
Almost everything works good here too. Just the logging options button apparently is not working correctly. 
Pretty please!
Errors are always welcome to log, but it is excessive to log everything even if the light does nothing or is working as intended. I will give it a shot commenting out the logs. Whats the worst that could happen?? 
Thanks again for the app, it really does make a nice difference in how things act.
1 Like
Hmm, can't seem to get it to install on my new C-7. Keep getting "Unknown exception occured while saving App code". Any ideas?
