Neat ideas! I'll have to think through a few things to verify that this will work in the way I expect it to if I implement something like this, but I'm not sure about the difference between the "inactive" and "dim" request here--the "inactive" action gives you the option to choose dim then off, just off, or just dim, and I think I understand that you want the option to choose a scene for "dim" instead of literally having the app dim the group or bulbs. Just not sure about the rest!
You are correct that I did not implement this with that idea in mind. (Also, welcome to Hubitat, or at least the forums!) What you want sounds like it would be doable with Rule Machine, but if you're super-new to the platform, that might be a daunting task. However, it does have "capture" and "restore" actions for bulbs/dimmers/switches built in, so I don't think it would be a lot of work (a bit more if you plan on changing color or CT while they're "on," but I can find a post where I solved that issue for someone, too, if it's applicable). You could probably also create a convoluted mix of simpler apps like Simple Automation Rules to do the same (and restrict which one runs when--if the lights already are on or whatnot), but that seems messier and less desirable to me unless someone has a better idea.
LoMP could handle this if you always wanted to dim them or turn them off. I'm not sure how you're currently deciding this now, unless it's more or less arbitrary based on whatever you had the lights manually set to. If it's by mode, LoMP does have that much built in--you can choose a different action for inactivity per mode.
Thanks for the warm welcome and quick response! I'm relatively new to Hubitat and the forums, and have some (now rusty) experience with a couple other hub platforms. I'm looking forward to developing some expertise with Hubitat.
I haven't worked with modes yet, and at least to start didn't want to think about how I wanted to use modes and rely on them being set/maintained and so was hoping for a single app that could handle returning the light to whatever state it had been set to previously/arbitrarily (whether manually or through some other event). I've used RM a bit and experimented with setting global variables to store states to accomplish this... and then wanted to make sure I wasn't re-creating the wheel and came upon your app. Thanks for helping to clarify!
I was thinking something similar to active, with dim, then off, but with 3 scenes:
Active -> scene1
Inactive -> scene2 ("dim"), delay -> scene3("off").
I did that with scenes, using restrictions in the scenes app, so I could select all of them at once, but only have it activate the one that isn't restricted per mode. Works perfectly btw.
Maybe! But what I've done in this case is use Hubitat's unofficial "contact-motion" app to convert contact sensors to motion sensors (more specifically, just open/close events to active/inactive events within the expected capabilities and attributes), which opens up the possibility to use a contact sensor in the wider variety of apps that expect motion sensors:
Thanks! It works great! Too bad one app needs to be created per contact sensors, but it does open up some great use cases for your app, and they work great!!!
Ex.: I want the entrance light to come on when someone opens the door and stay on while people are in the entrance (motion). This allows this to work! Previously, I had two different apps for each action, the simple rules (basic lightning) and your, and they didn’t always work great that way.
If you ever end-up allowing the use of contact sensors directly, let me know! I will definitely use it!
LoMP could handle this if you always wanted to dim them or turn them off.
I'm still trying to support the use case that I mentioned above but now willing to have it always dim after inactivity. What I'm now finding, thought, is that if the light is already dim (as a result of something other than LoTM), my LoTM app instance is ignoring the "on" action.
In the logs, the last thing reported (from line ~441 of child app 5) is:
2020-10-12 04:02:27.496 pm [debug] -> 'onColor', but on and not dimmed so doing nothing
I see there is a config setting 'Don't perform "on" action if any specified lights are already on,' which seems relevant in this case, and I have this disabled. I'm not very familiar with groovy (yet) but I can't see whether/where you are checking for this setting in determining to perform the on action and I'm wondering if that's on oversight?
Note that if I manually turn the light off, the LoMP works as expected upon motion detection. And, when LoMP dims after inactivity as configured, it will set the dim level upon motion. But, when the dim (prior to motion) is set by anything other than LoMP, it does not work and I see that above debug message.
Can you help me understand if I'm misunderstanding something? I'm happy to share my config for the app instance or modify the code to help debug.
You are correct that the setting is supposed to do what you're looking for (assuming I understand what you want), but I discovered a few places in the code where I wasn't actually checking the value of this setting and should have, including the one you provided logs for above (thanks!). I don't actually use this setting myself but assumed there might be a time when someone did, so at least that much was correct.
I've uploaded v5.0.2 now (only need to update the child app if you're doing a manual install, otherwise it's also in HPM). This should fix that problem, assuming I caught all the remaining cases. Thanks!
I've released another minor update, 5.0.3, to correct an issue I noticed where sometimes the bulbs wouldn't be marked as "not dimmed anymore" after a restore, causing LoMP to keep trying to restore their original states on motion (this was only noticeable for me when I changed the color, CT, or level manually after getting stuck in this state and is how I discovered the problem, which I assume would be rare occurrence for most). This update is now available, both in the code in the first post as well as HPM.
I've also had someone report an issue with the 5.0.2 update (and presumably 5.0.3) that I am unable to replicate, where scenes will not turn on because LoMP thinks the lights are already on. If anyone else sees this, let me know, and I can investigate whether my fix broke something. If needed, you can manually downgrade the child app to 5.0.1.
After updating last night to the most recent version, all of my LOMP child apps stopped working. Reading some of the posts, I assumed it was an old vs new version conflict and uninstalled the app and then reinstalled. I wanted to make some changes to add modes with weekend variations anyways. Now that I know I've updated my modes, I still am not getting the app to trigger. The motion sensors are seeing motion but not triggering in the app. I have had the logging turned off but will re engage to get a capture. Not sure if it matters, but all of my lighting in this scenario is using Lutron dimmers, switches, and picos with Smartthings motion sensors.
Have you tried the 5.0.1 app (this should be pasted or imported as the child app) instead of the current 5.0.3? (This is in my my post right above yours.) I've had one person report a problem with 5.0.2/5.0.3 with some lights not turning on and am not able to reproduce the problem myself, but I'm wondering if the older version without the "fix" I made for another issue might work.
Yes sir, that was it. I deleted 5.0.3 and replaced it with 5.0.1 and its back up and running.
It didn't like that I had a non dimmer Lutron switch listed in the lights to turn on/off/dim with the other 3 Lutron dimmers in the bath/closet and skipped that and the toilet light. Once I pulled the non dimmer out, it worked as expected.
Great app by the way, I'm a fairly new convert from ST and learning RM is taking some time (and wife coaxing). These apps for the non programmers are the bomb!
Hmm, so the non-dimmer switch is the only problem with 5.0.3? I'll probably add a check to see if the device supports setLevel() and just do an on() if it doesn't, which would fix that (also a question I see raised by someone else above; I didn't really test this with plain switches, even though it lets you select them). But nothing should have changed between 5.0.1 and 5.0.2/5.0.3 that would affect that specific behavior--it was an unrelated fix for the "don't perform 'on' action if already on" setting and, later, a fix for LoMP getting stuck thinking the lights were dimmed and wanting to restore their states on motion even if they were currently good.
Thanks for the reports, everyone! I just released a hotfix, v5.0.4, that should fix the issues with lights not turning on in some cases (assuming the cause I found when I was finally able to replicate this was the source in all cases--it was related to a "notIfOn" setting not getting created in settings, which you could see on the gear/app status page). It is available on GitHub and HPM, as usual. Let me know if there is anything else!
PS - Still thinking about that per-mode timeout setting for a future release.
Unfortunately, I can confirm that there are still some remaining issues. The setup described in my post above still doesn’t work with 5.0.4 (Note, the code still has 5.0.3 in it...). With 5.0.4, the light doesn’t turn on. However, when I downgrade to 5.0.1, it works again, so that confirms the issue is with the code changes since then.
I have another situation that only works during the evening. The night code doesn’t seem to run as the light doesn’t turn on with 5.0.4, it does however with 5.0.1. Also, note that with 5.0.3, I have on a couple of occasions seen the light from the night setting turn on at the same time as the one from the evening setting...
For now, I am keeping it to 5.0.1 and disabling HPM auto update. However, if you think you have a fix that works, let me know and I will update it ant test it.
Also, let me know if you need anything else to help (More details of the settings in the modes, logs, etc.). I can upgrade the code again to test as necessary. I understand it is difficult to debug an issue when it cannot be reproduced...
For now, the workaround is to create two child apps with the same settings.
