[RELEASE] Lights on Motion Plus (dim before off, remember individual bulb states, etc.)

⚙️ Custom Apps and Drivers Custom Apps
1

I've written an app for my own use and figured I'd share it. I originally wrote it for a certain other platform, then another platform (see? not the one you're thinking of), and finally re-wrote it for Hubitat and fixed some longstanding bugs I tolerated. I figured I'd share it with the community in case anyone has any use for it.

At its core, it's similar to most motion-based lighting apps, but none of them could do a couple things I wanted. They all could more or less turn one or more lights on with motion and off with an optional delay after motion stops, and so can this. But most of my rooms have multi-bulb fixtures, and I don't always want all bulbs on. I also don't want them all to turn on or back to a specific state if motion is detected but one or more of them (not necessarily all) is already on-- a weakness of most apps I've used. Finally, I wanted to dim the bulbs as a warning before turning them off (imitating what Hue lets you do, but I wanted my logic on Hubitat). My app solves this by:

  • allowing you to choose one or more bulbs (generally a whole room)
  • allowing you to choose a motion sensor (one you'd want to use to turn on/off those lights)
  • when motion stops, remembering the on/off states (and dim level) of each bulb and only turning those that were previously on back on (and to the saved level) when motion resumes (if not prevented by restrictions configured in the app: mode, lux, time of day, etc.)
  • dimming the lights for 30 seconds (or whatever you choose) before turning them off, restoring them to their previous state if motion resumes during this time (regardless of mode/time/etc. restrictions--you had them on in the first place, after all) or after this time (if not in a mode/time/etc. condition where "on" is restricted).
  • some of the above are optional features, but I've really only tested it with them all on since that's why I wrote the app and what distinguishes it from most others, but the options are there. :slight_smile:

Note: I primarily use smart bulbs and say "bulbs" throughout, but the same applies to smart dimmers, where it will remember each dimmer. It should also work with plain switches but I haven't tested that much and the benefit of this over stock apps there is questionable.

New in summer 2020: version 5.0 of the app is a complete rewrite you can read about in post 71 below with many new features, including unlimited "per mode" settings.

Here's the folder in my GitHub repo for this app. It's a parent-child app, so you'll need to add the code for the parent app, then add the code for the child app under "Apps Code," then under "Apps" you can install a new instance of the (parent) app.

Or direct raw code links/URLs:

(NOTE: Existing v4.x users should add 5.x child as new app, keep 4.x child installed, and upgrade the parent. Do not upgrade the 4.x child to a 5.x child, as 5.x is a complete rewrite and 5.x apps must be created new.)

Please note that this is community/user code and, like all user code, is not officially supported by Hubitat.

27 Likes
2

Sounds great. I look forward to trying it out!

1 Like
3

Sounds like a better version of an occupancy app I wrote. I'll add this to my "must try" list. Thanks for sharing

4

Hmm, I'd be curious to try that too! This took me years of perfecting it to my needs on three different platforms (confession: between ST and Hubitat, I rewrote it as a Python script for AppDaemon on Home Assistant), but I think I've finally got it to the point now where it actually does what I wan't, doesn't have glaring bugs, and I felt like sharing. :slight_smile:

Also, in case anyone is curious how I use this, I have a few cases:

  • I have "regular"/ceiling lights and under-cabinet lights in my kitchen. The regular lights are on almost all the time when I'm in the room; I turn the under-cabinet lights on (Pico remote FTW) when I'm preparing food. I don't want the undercabinet light to turn on with motion like the rest, but I do want to to turn off with the rest after motion stops for a while. (But if I had it on, I do want it to turn back on if motion is inactive long enough that the lights eventually dim or turn off, until I turn it off manually, choose a new scene, etc.).
  • All my bedrooms have had two-bulb ceiling fixtures, but I usually really only need one bulb on at a time. I always want both to turn off (if motion stops), but I don't want the second to turn on when motion starts unless it was previously on when the room was last occupied.
  • In most cases, I prefer the lights to dim as a warning before turning off. (Hue motion sensors do this if set up through the Hue app and paired to the Hue network, and this is the feature I was trying to emulate.)

I'm also hoping to add a "night mode" feature as described above to use this in my bathroom (theoretically I could offer different settings for each mode, but this would cover my particular case).

5

Like I said...yours sounds better :grinning:. Mine is pretty basic and includes what I consider the most important missing feature in motion lighting...dim before off.

Screenshot_20181213-235537_Chrome
Screenshot_20181213-235537_Chrome810×2207 269 KB

6

Agreed on that! if any of the stock apps had this, I probably wouldn't have made this app (but because of my multi-bulb and multi-fixture rooms with a single motion sensor, i also like the ability to "remember" the state of each rather than blindly turning on all or setting a specific scene or similar regardless of how it was before). I don't think either of these things would be super-hard to do individually in RM, but both together plus doing it for all of my rooms seemed impossibly daunting.

1 Like
7

Awesome!, I guess you use smart bulbs instead of switches? I have smart dimmers that turn on the whole multi-bulb fixtures so that part would not be useful to me but the slow dimming to off sounds really cool.

Thanks for sharing!

8

I do indeed (mostly) use smart bulbs instead of smart switches. (There's a lot of reasons, including the fact that I started this habit when I was renting and it was the best option from that perspective, but I've kept doing it because I've grown to like the numerous things smart bulbs can do that switches can't, like color and color temperature modification, to say nothing of bulb-level control--to get what I'm used to, I'd need a switch for practically every bulb in my fixture before I'd be happy. :slight_smile: )

I should mention that the "dim before turning off" feature isn't a slow dim to off--it dims to a "low" level as a warning, then turns off, both more or less instantly (technically not instantly; it's whatever your device's transition time is, which I think Hubitat recently changed to 1 second for all bulbs unless you choose otherwise). It would should be possible to add a "transition time"/duration parameter (or an option to make it the same as the interval for which it would otherwise just be dimmed) if anyone wanted it. I don't think I'd have a use for it myself--I imagine it would take me a bit to realize the bulbs are dimming and to do something to stop them, and I'd rather just know and do (or not) it instantly if needed.

9

I like this feature you have stated of dimming a light before off. Usually how many seconds do you do?

@bravenel any chance RM and ML could support something like this? Prefer to keep everything native. I use the delay off pending cancellation for all of my motion lighting and the idea for 15 seconds prior to shutting off have either fade to off OR dim and then off.

10

Started using the app this morning. Well done.

One thing that jumped out at me as soon as I started making my first child app is the that there isn't a kill switch. For every room, I have an Override device (virtual switch) that I can use to make sure the light stay on (or off). Great for when we are having a get together and people may be moving around the house and don't want to freak them out with the lights going on and off by themselves, lol.

This is what I use in my apps...

enable%20disable%20switch
enable disable switch.png1018×179 9.56 KB

1 Like
11

Same here. Kill switch is a must.

20181214_104848
20181214_104848.jpg810×484 56.9 KB

1 Like
12

I usually do 30 seconds, which I think is the default value, but I've done up to 60 depending on the room. (I think Hue, which I'm trying to emulate, does 30, and when I was using it on a certain other platform that doesn't guarantee execution times except to within the same minute, I think I also stuck to 60.)

I think I left a "disable" option in the app itself, but I understand that that's not as easy to change as a virtual switch. I'll consider this for future updates. For me personally, I was thinking of adding the ability to use a switch (or a timeout after a button press) that will extend the delay instead of using the "normal" delay (rather than just entirely never turning the lights off--I just really don't want to forget to turn mine off, including remembering that I'd need to turn the virtual switch off in this case to return to expected behavior). It seems you could use this feature and then set the delay to an extremely long value, but I'll consider both cases.

Also, one thing I forgot to mention: there is an option to always turn off the lights even if you're in a mode when the lights wouldn't normally turn on (use case: it's "evening mode" but my location automatically switches into "night/bedtime mode" where they wouldn't automatically turn on--I still want any lights that turned on before to turn off, and I'd like to keep them on if I'm moving, but I don't want them to not turn off just because I'm now in a mode where most of the automation wouldn't normally run). I always have this option enabled. But you could work around this problem by disabling this option and changing to a "prohibited mode" instead of using a switch if that works for you in the meantime.

13

No problem, I just put one in myself. :grin:

Really like the dim before turning off feature though. This could bring the WAF up a bit.

1 Like
14

I was thinking about this myself, and while an app is the best I can do now, I'm wondering if this wouldn't make more sense to do at the driver level--in addition to a hard "off" command like the current, maybe have one that dims it before truly turning off but also remembers the non-dimmed brightness (and other settings) when turning it back on. That would probably lead to desired outcomes more consistently; an app is just the best I can do now, and still works pretty well as long as the same app is the only thing that turns the lights back on.

In case it's not clear why: if you use another automation that just turns the lights/switches back "on" after they get dimmed and then turned off by this app, they will get restored to the state they were previously before turning off. That would be the "dim" level, not their original level (that's why this app saves them and then restores them when it turns the lights back on, but that's saved in the app and not on the device). Since I wrote this for myself and pretty much do use this app exclusively for turning lights back on, this isn't a problem for me. It's also not a problem if the other automations you use to turn them on also set a brightness level rather than sending a simple "on," which is also not a problem for me (the only other way mine usually get turned on is a Hue control paired directly to my Hue network that sets a scene anyway; not sure what other people do).

I could also work around this "problem" at the appp level by setting the bulbs to their original state before turning them off. Doing so would cause a brief "flash" back to the original brightness before turning the light off, but it may be helpful for people who use other automations that send a simple "on" to the light without also setting a level, etc. (Theoretically, a bulb could support setting a brightness or other setting while off and remain off, but I'm not sure any support this at the hardware level, and no Hubitat driver that I'm aware of does either--they'll turn on if off.)

Just something I've been thinking about. Nothing that affects my usage, but I'm not sure if it could be a problem for others. Maybe I just want it at the driver level so it's less I have to worry about in the app, but I think there are a lot of reasons it would make sense to do it there regardless. :slight_smile:

15

This is great, and a feature I've wanted for a while. I know this is also available in the full-featured Rooms Manager. Nice to see it as a small bite-sized app as well.

I agree, this could easily be added to RM, Simple Lighting, or Motion Lighting. @bravenel - any thoughts on adding a "Dim (to level) before off" ?

I checked the app and I'll have to rework a lot of things to use it - I have most of my bulbs doing levels and color temps per mode, with override Picos and a rather tangled web of rules.

1 Like
16

@bravenel
+1 to separate ramp on and off times (currently known as fade) in ML apps.
IOW, I want to ramp on fast, and ramp off slow.

17

I'm planning on making some changes to accomodate use in other rooms and halls/etc., where I want one of three things to happen with motion, depending on mode:

  • lights turn on normally (currently supported)
  • lights don't turn on (currently supported)
  • lights turn on to "night mode" level (this would be new).
    Additionally, I'm also thinking of something like:
  • when specific switch on (guest/party-type switch), use a different/longer delay instead of the "normal" one before dimming and turning off, or do the same for x period of time after specific button is pressed (would be a new feature)

Would any of this help? I really only need a specific setting for one additional mode (besides the existing "do something or don't do anything" dichotomy)--in my case, my "night" mode--but I'm not sure how much harder it would be to expand this into an arbitrarily number of "special" other modes. (It's definitely possible, but I find it a bit of a pain to write UIs and store the settings in apps that support dynamic, arbitrary numbers of inputs like this.)

For those who want a "kill switch," would the longer delay take care of that? And would the kill switch cause nothing at all to happen? Does the switch automatically turn off or should the app take care of that after a period of time? One main reason for me writing this was to prevent me forgetting to turn the lights off, which is why there's even an option to always turn them off even if it means ignoring mode/time/lux/etc. restrictions if they're on. :slight_smile:

1 Like
19

Greetings, all! I've updated the child app to version 3.1 (no changes in parent app), where I've added some new functionality:

  • Requested "kill switch" option: when this switch is on, the automation is completely disabled (i.e., will not turn on or off lights)
  • Changed existing "disable app..." toggle (boolean) in app to a "soft kill switch" that will disable turning lights on when this (physical or virtual) switch is on; turn-off behavior is, as always when not using the "hard" kill switch, determined by other options in the app;
  • Ability to use more than one motion sensor to turn on light (it always let you select them; it did not always work, so this is more of a bug fix)
  • New: ability to select additional sensors that will keep the lights on but not turn them on

Note that Hubitat now has an option in the App list to disable an app, so I did not think a boolean in my app (that you had to go in and toggle) was necessary anymore, especially a "soft" one that other app settings could override. The "don't turn on if switch on" setting should make up for this if anyone used that (you just need to create a virtual--or use an existing real--switch for that purpose). But I think most people really wanted the "hard" kill switch, which I've now added.

Note to existing users: after updating the code, go into each child app and click "Done." (At least one setting has changed and you'll get an error when the app runs if you don't.)

GitHub repo in first post above, or see here for raw code to update child only: https://raw.githubusercontent.com/RMoRobert/Hubitat/master/apps/LightsOnMotionPlus/LightsOnMotionPlus.groovy

1 Like
20

This works perfectly, thank you. I'm using it in two rooms.

21

A feature request if I may please... Ability to set the dimmer level, when setting up which light or lights I would like to turn on.

1 Like