Lutron Aurora Dimmer Custom Driver

I've bought some Lutron Aurora Dimmers with the intention of using them directly in Hubitat Elevation. I don't intend to have a Hue Bridge or smart bulbs.

There is an official driver for these devices, but the problem is that setting the level using anything else other than physical button, will cause issues.
With that in mind, the main difference from the official driver is the ability to set the level, so when you turn the knob, no matter which device or automation changed the level before it will continue from there.

I'm no HE/Driver/Zigbee expert, so if you see something that could be improved (and I'm sure there is), I'm all ears.
Due to my lack of knowledge you may need to click the "Refresh" button after changing the device to this driver.

You can also choose the behavior of the button, which can be set as a switch (turn the bulb on/off) or a push button, where you are free to use the click events to trigger any action you want.

The driver is here

For basic use you can stop reading here, but if you like details or want to tune it, here we go...

The main problem with this device is that it has an internal level, which AFAIK cannot be set sending a Zigbee command to it, so when you turn the knob it will report (simplifying) a level from 0 to 100, so let's say you've left it at 70%, then you used an automation to set the bulb to 20%, if you then turn the knob to the left, it will first report something close to 70%, let's say 65% instead of 15%. If you use external automations your bulb will be aways having these undesired level jumps when you use the knob again. For me and probably 99% of the people that would be a no go.

What I did was to ignore the device level and store a level inside the driver instance.
Then I simulate the level increase/decrease using the the rotation information and the interval between the events received. If you keep turning left after it reached 0%, it will keep sending events with the level 0%, the same on the other end, at 100%, so it is always possible to know the direction of the rotation and use this information instead of the level itself.

The interval between the events is used to simulate a rotation speed, this is a central concept of this driver.
If you are rotating fast it will change 12% for each event received, if you are rotating really slow it will change 1%, with 3 more settings in between.
Using the level information as the official driver does also makes it impossible to have 1% changes, since the device always reports more than that, 5 - 7% at least!

These settings are configurable so you can tune it to your liking, you can make the biggest change 5% and the smallest 2% for example, and also configure how the intervals influence the speed.

Have a look at the calculateSpeed method in the driver, in the first part I've left an option to use the device speed when available, so you can compare both (use the debug logs).
The important part is the second one, after the return statement.

If you have any improvement idea or problem with the driver, or just like it, please let me know! I intend make improvements and keep this driver always up to date.


Ah dang, I guess I didn't test my code enough, and it really wasn't setting the device level. This virtualized method is probably the best way to go. I'll test it out. Thanks!

Did some basic testing and it seems to work really well. I'm glad you built the options into the preferences page. I didn't have to change any of my RM stuff, since the button behavior is the same, (disregard button-to-switch logic,) but the translation layer you built for the dimmer value is really nice. I toyed with this using virtual dimmer stuff, but I found it so damn slow. This is quite responsive.

I also tried a simple RM that take increase vs decrease and that was nasty. This one works perfectly so far.

Thanks for the contribution!

1 Like

Is this just passing the raw battery value? Zigbee battery percentage is measured 1-200 where 2=1% and and the voltage is measured in decivolts where 1 = 0.1 volt.

So I don't see how this could send accurate battery information?
There is no reporting interval set either, does this device send battery info on each push of the button?

To be honest I don't have the answers to your questions. This is the first driver I've written and my knowledge on Zigbee is quite basic.
The only one I know for sure because I have just tested is that the battery report doesn't happen on the button press.
I have focused on the dimmer and button. The battery part I've copied from another driver and might as well be broken as you said.

I'm happy to accept pull requests or suggestions on how to improve the driver.

Ok I'll work on it

About 2h after I have used it today (after not having used it for about 3 weeks), it sent a battery event.
Subsequently it sent battery events in intervals of roughly 1 hour and 10 minutes.
The value looks ok. Here are the messages printed in the logs:

2021-02-21 16:22:20.558 debug sending [name:battery, value:100.0]
2021-02-21 15:12:54.910 debug sending [name:battery, value:100.0]
2021-02-21 14:03:30.028 debug sending [name:battery, value:100.0]
2021-02-21 12:54:05.999 debug sending [name:battery, value:100.0]

I'm pretty confident that if you don't use the device it will stop sending the battery events after a predefined amount of time, probably it enters a kind of hibernation state to save battery. I have left it in a drawer these 3 weeks with the battery and within the range of the Zigbee network. Before using it today I have check the logs and there were no events at all.

Also when I first used the device today it sent an "unknown" event before anything else, which I can't guarantee but could very well be a message that it is getting out of the hibernation state:

2021-02-21 10:37:55.043 warn DID NOT PARSE MESSAGE for description : catchall: 0000 0013 00 00 0040 00 27A6 00 00 0000 00 00 A6A627727DFDE70F00FFFF80

I'm trying to get double-tap to work, has anyone thought about that? perhaps a button #2 'pressed' could represent that?

actually I got this working. Though I really wish I could do runIn with millisecond input, instead of full seconds.

My driver is not pretty, and I'd need to add some logic to disable the double-tap wait by setting it to zero, or whatever.

This is working a hell of a lot better than trying to process double-click logic in RM or WC. That seemed too slow, I guess, despite good logic.

def handleButtonEvent() {
    state.oldClick = state.lastClick // saving the last click to see if we can trigger a double-click
    state.lastClick = now()
    state.diffClick = (state.lastClick - state.oldClick) / 1000
    if (debug) log.debug "Diff-click = ${state.diffClick} (compared to double-click=${doubleClickTime})"
    if (useButtonAsSwitch) {
        if (debug) log.debug "Button pressed, handling as switch"
        if (state.level == 0) {
        } else {
            sendSwitchEvent(device.currentValue("switch") != "on")
    } else 
        if (state.diffClick < doubleClickTime) {
            if (debug) log.debug "Button pressed, handling as double-tap"
            sendEvent(name: "pushed", value: 2, isStateChange: true, descriptionText: "Aurora button was double-tapped")            
        if (state.diffClick >= doubleClickTime) {
            if (debug) log.debug "Button pressed once, waiting ${doubleClickTime} seconds"
            runIn(doubleClickTime, "sendPushButtonEvent")

def sendPushButtonEvent() {
    if (debug) log.debug "Button-press confirmed as SINGLE-PRESS"
            sendEvent(name: "pushed", value: 1, isStateChange: true, descriptionText: "Aurora button was pushed")

Really sloppy, but maybe it will inspire someone else. I've got it working in some rules that allow me to single-press to cycle between my lamp, and ceiling light. Depending on which are currently on or off, certain behavior happens. The idea is that a double-tap will kill everything.

1 Like

Interesting. Are you using a completely different driver or have you forked mine?
I could incorporate the double click feature into the driver to keep it all in one place.

I just quickly hacked it into yours. The two problems I have right now is 1) I can't get the driver to react if I push the button quickly in less than 1.5s, and 2) I don't see how to add a proper delay of x # of milliseconds.

I would like to do more testing and see if a proper quick-double-tap can be achieved. I'm not sure what's preventing that, but the second press seems to be totally ignored when you try that fast.

Thank you for your work. Is the ring integration “fast enough “ for these 2 automations?

  1. I’d like my sengled led porch lights to turn on if motion is detected

  2. I’d like my lights to flash if my doorbell is pressed

Thank you

Download the Hubitat app