Would it be possible to add the option to fade out the lights over a number of seconds just like you can already fade them in when turning them on? This would only work if you have also configured Minutes to delay before off.
Configuration: Minutes to delay before off is set to 5 minutes. Fade out time is set to 15 seconds
Expected behaviour: If no motion has been detected for 4 minutes and 45 seconds (delay minus fade out time), start fading the lights out over the next 15 seconds. If motion is detected during the fade out period, return the light level to what had been configured, otherwise turn them off at the end of the fade out period.
Again, this doesn't dim over time, though that's certainly an option I could add. (I'm still afraid I wouldn't actually be able to tell if the lights were just slowly dimming on me.) My intent was to imitate the Hue motion sensors that dim the bulbs before turning them off to help users coming from this platform who want to use Hubitat-native automations.
You're right, that's what I'm looking for and I do come from the Hue automation side where it fades the lights to half the brightness as a warning before shutting off. I just thought that fading the lights might be easier to implement. Either way would work for me.
Oh, it is. Dimming instantly before turning off requires you to save the previous dim level, then restore it when motion starts, and you better hope people who turn the lights on with something outside the app with a simple on instead of setLevel don't care that the new "on" level will be the previous "dim" level. (I think this could be solved at the driver level with some sugar-coating that allows a "temporary dim" level and will restore the previous "normal" level the next time the light goes on, but the Hubitat Hue Bridge driver source is not open and I suspect my requests for this feature are niche enough to be ignored.)
A fade over time if done via a device-supported "transition time"-type setting shouldn't really change the level, but I guess it depends on whether the device itself supports it or Hubitat "fakes it" via repeated, timed setLevel commands, in which case it's possible the same as above may apply (unless the driver knows and secretly sets the original level back before turning off, which may cause a brief flash, or internally stores it and does what I suggest above when turned back on).
That being said, I think I got the save/restore thing figured out in my app, so it works well for me. Rooms Manager is another community-created app that can also do this, though it does a lot more and I couldn't quite figure out how to use it, so I've been using this instead.
This is very interesting point. Motion Lighting uses the fade time that is implemented in the device itself. But only setLevel supports the fade time parameter, not on/off. Motion Lighting uses off() for off, hence no fading to off.
The only way I can think to implement the op's case in ML (i.e., using the device fade time) would be to use setLevel(0, fade-time), followed by off(). You're right that is going to leave the dimmer in a weird state, should it be operated from the switch.
I don't think it's possible for the driver to fake this stuff, or to remember the last dimmer level and somehow magically restore it. This stuff is not happening in the driver, but in the device itself. How would the driver know that the dimmer level is supposed to be preserved, and even if it did, how would it communicate that to the device?
I was thinking an additional command (or argument to the existing one) that would allow you to set a "temporary" or "unsaved" level or similar, which, when used, would prompt the driver to store the previous level for the device when the "new" one is set. This alone would do nothing, but, then, the next time the device gets an on command, it could the "old" level instead of simply turning on (which alone would just restore the "new" level).
In an ideal world, I think this would be best handled by the device itself (either a device that supports a "set this new level but don't remember it"-type command, or one that doesn't actually turn on when a setLevel is issued so you could secretly restore the old level after the dimmer/bulb is off). However, working with what we have, I think the next-best place is to "fake it" within the device driver. Currently, the only option is an app, which is what I'm doing, but it gives undesired behavior should the user issue a simple "on" via something besides the same app that "saved" the levels. (I guess the app could provide an option to subscribe to the "on" event and try to account for external factors, but that seems problematic should the turning on be the result of an intentional setLevel, e.g., scene activation, where the restoration is not desired.)
I haven't thought through every possible scenario, so it's likely this idea isn't perfect (and I have no idea how fast/well it would work with real devices), but I've been trying to perfect my lighting automations for years and this thought just recently crossed my mind.
I can relate, me too. But, the physical switch is still the bane of getting things right. To the extent possible I've moved my own home away from using physical switches. Mike Maxwell took it even further, by burying an Aeon micro dimmer in the box behind a box mounted Pico. No physical switches for him! Just software.
This is what I might not be understanding. I figured a smart switch/dimmer (old GE and similar ones excepted...) would still send an "on" event to the hub, so the driver would then know to also restore the old state. I recognize that the dimmer itself is what actually turns the bulb on without hub involvement at all (unless you've disabled the relay and set this up via other means), but I figured the event would still be there and able to be responded to appropriately. I confess that most of my smart lights are bulbs, where the only way to turn them on or off or set a level is "smart" (so the hub is definitely involved). Do smart dimmers just do a setLevel and not an on with a tap up (to turn the lights on to the previous brightness), or does it vary by brand? (Only used smart switches...or none at all, my ideal as you mention.)
Someone could definitely make a driver do that (and I have made one do something similar to that before, in fact). But none of the in-box drivers work that way as it is not the as-designed behavior of the device.
And it is cludgy, as when you turn on from the physical switch it will immediately go to wherever the hardware wants, then the driver would see it turn on and move it down to where it was before/where user wants.
On many dimmers the ON event doesn't even get sent to the hub until the ON is complete from the switch.
So you would see - user pressed switch it goes on to, say 80%, and then the driver dims it down to say 20%.
Either way, it seems like it should work to me--as long as the hub is aware. The logic would be something like "if this is the first time this switch has turned on since the 'temporary level' was set, restore the 'original level' when turned on" (unless the turning on is the result of a setLevel, where I'd assume it was intentional).
Except for this:
Especially with a Z-Wave switch (nothing against Z-Wave, but it always seems to take a bit longer to get messages across than ZigBee or LAN devices), I was wondering whether such a "delay" would be annoying. But in real life, it would usually be the opposite of what you suggest: the lights were "dimmed" to, say, 20% as a warning before turning off, from their "regular" level of 80%. When the switch is turned on again, if it turns on to 20% first, the driver would restore it to 80%. Probably less jarring than the other way around.
The other workaround, however (currently something any app can do if the app itself doesn't want to handle "remembering" this) would be this jarring: setting the level to the original level after your "temporary"/warning level before turning off, causing them to flash a bit brighter first.
Or you can use an app and hope that the user only cares about things that app does, which is what I'm trying my best to do. But something about it seems not ideal to me.
Yep--someone would just have to write entirely new drivers for Hue, YeeLight, generic Z-Wave and ZigBee bulbs, and whatever else there is, for all types of bulbs (white, RGBW, etc.)--certainly possible but difficult given that we'd have to start from scratch unless any of them are open-sourced. There's also the issue of that, unless these are present in all drivers (as, say, an expected part of the capability), no user or app would be able to depend on it existing, so I doubt it would be widely used--probably another reason that, if done, it's best done in the drivers at the platform level (and, like startLevelChange and stopLevelChange, something custom driver authors would also be expected to include, though I'm not sure if that's an "official" requirement).
I don't entirely disagree--I just happen to have written an app that does this and am quite familiar with the limitations of the approach. I think it's not just me wanting somebody else (the driver author) to handle my problem, but I suppose I could be biased. In any case, the issue of the bulbs undesirably remembering their last "temporary dim" level instead of their "real" level remains if you use anything besides the same app to turn the lights back on again.
My goal is to solve this by making my app handle every possible situation I could ever want (and I'll probably add a "restore when this button is pressed" option too--right now it only restores on motion). I'm "only" 99% there, so the app approach is far from a total disaster, despite how much better I think it could be.