ZHA - Lutron Aurora Dimmer Blueprint

Zigbee is a protocol and then there are sub protocols within such as ZLL (Zigbee Light Link) which is what hue runs - which is (in theory) Zigbee 3.0 compatible (I believe).

There are various bridges out there that support various flavors of Zigbee: Ikea, Hue, Aquare etc. - as well as dropping in a Zigbee stick into the pi and then running your own server such as ZHA.

Then to get more complex I think you can run “emulated-hue” or “diy-hue”? on the server to make it so some of the hue apps think the devices are “hue” compatible.

I haven’t gone down that route yet.

This is like genius! Thanks! I’d purchased a Hampton Bay ceiling light that is supposed to integrate with a Wink hub, so I crossed my fingers and hoped that it would work with my Philips Hue hub but that hasn’t worked out. But, it integrated easily with ZHA. I’d never added an Aurora switch into HA, before, which would have been difficult as I’ve also never created an automation using a JSON event result. With your blueprint, I didn’t have to bother with a single line of coding.

1 Like

Only partially working for me. Spinning the dial changes the brightness but pressing the button will not turn them on, can only turn on with the dial. Pressing the button to turn them off only works if you first spin the brightness all the way down.

Hmmm. I’d be interested in seeing what events are coming through when you push the button on the dimmer. If you’d like to see the events that this blueprint is looking for, you can run through the following steps in home assistant…

  1. Go to Developer Tools → Events
  2. Set ‘Event to subscribe to’ to zha_event
  3. Click ‘Start Listening’

This will display events coming in through the zha integration. When you click the button on the dimmer you should see an event that looks something like this…

Event 53 fired 7:17 AM:
    "event_type": "zha_event",
    "data": {
        "device_ieee": "xxxxxxx",
        "unique_id": "xxxxxxx",
        "device_id": "xxxxxxx",
        "endpoint_id": 1,
        "cluster_id": 8,
        "command": "move_to_level_with_on_off",
        "args": [
    "origin": "LOCAL",
    "time_fired": "2021-06-24T12:17:35.790651+00:00",
    "context": {
        "id": "xxxxxxx",
        "parent_id": null,
        "user_id": null

Depending on what other devices you have in your Zigbee network, you may see some other events too. But you can look at the device_id/unique_id values, which should be the same for all of the events that come from your dimmer.
The key fields in this event are the command, which should be “move_to_level_with_on_off” and the first number in the args list. When you push the button you should see that first args entry toggle between 0 and 255 with each push. When you spin the dial that number will increase and decrease, with the range between 0 and 255.

Off the top of my head, either an event isn’t making it through when you push the button, or one of the event values that comes through when the button is pushed is unexpected.

If you want to dig in a bit, take a look at the zha events and let me know what you see and we can try and determine where things are misbehaving.

Thanks, this is the first and only zigbee device on my network. It appears that clicks are not being sent as events only when I scroll the wheel. Maybe 1 in 100 press I get the event button. Perhaps the device is defective?

Edit: I just paired a second lutron aurora and have the same issue. I only get wheel events.

Edit2: if the are are [2,2] if I press the button then I will get the args [0,2] otherwise it seems the button never fires a vent.

Are you using a Nortek HUSBZB-1 USB stick for ZHA? I wonder if you are seeing this. It’s been around for a bit. But I’m not sure that its been fixed.

1 Like

Well I can confirm that I have the same behavior, and am using that device. Of course… lol I’ve been using one Aurora paired directly with some bulbs, but I just tried your blueprint so I could include some wifi bulbs. Sooooo close…

Yep I am using the HUSBZB-1 so maybe thats the issue. Luckily I had already ordered something else and will be returning this when it gets here. Hopfully I have success with the other coordinator, I’ll report back…

VERY likely it is. Many have seen this issue and I had 2 sticks that both had the problem. I even worked with Walt (zigbee dev) and tried updating the firmware and scanning zigbee packets with wireshark. He concluded that it was a limitation of the zigbee stack on the Nortek devices.
No problems whatsoever with the Conbee 2.

I got a new coordinator from TubeZB based of EFR32 chipset, still has the same problem :frowning:

Working now with conbee2 but if anyone knows a controller with a bigger radio this works with let me know! Also I altered the blueprint to take over control of dimming from the adaptive lights integration.

  name: ZHA - Lutron Aurora Dimmer v1.3 Adaptive
  description: 'Control lights with a Lutron Aurora Dimmer Pressing in the dimmer
    button will toggle between turning lights on to full brightness, and turning the
    lights off. Rotating the dimmer will increase and decrease the light brightness.

    Adjust the sensitivity if updates from the dimmer are being sent too quickly '
  domain: automation
      name: Lutron Aurora Dimmer Switch
      description: Lutron Aurora Z3-1BRL
          integration: zha
          manufacturer: Lutron
          model: Z3-1BRL
            domain: sensor
            device_class: battery
      name: Light(s)
      description: The light(s) to control
            domain: light
      name: Sensitivity
      description: Reducing sensitivity will reduce rate of changes being sent to
      default: 3
          min: 1.0
          max: 3.0
          mode: slider
          step: 1.0
      name: Adaptive Switch
      description: Adaptive light brightness switch for zone
            integration: adaptive_lighting
            domain: switch
  source_url: https://community.home-assistant.io/t/zha-lutron-aurora-dimmer-blueprint/292421
mode: restart
max_exceeded: silent
- platform: event
  event_type: zha_event
    device_id: !input 'remote'
- variables:
    sensitivity_input: !input 'sensitivity'
    selected_light: !input 'light'
    selected_switch: !input 'adaptive_switch'
    sensitivity: "{% if sensitivity_input == \"3\" %}\n  1\n{% elif sensitivity_input\
      \ == \"2\" %}\n  5\n{% else %}\n  15\n{% endif %}  \n"
    prior_brightness: '{{ brightness | default }}'
    command: '{{ trigger.event.data.command }}'
    brightness: '{{ (trigger.event.data.args[0]|int) / (sensitivity|int) * (sensitivity|int)
- choose:
  - conditions:
    - '{{ command == ''move_to_level_with_on_off'' }}'
    - '{{ brightness != prior_brightness }}'
    - service: light.turn_on
      target: '{{ selected_light }}'
        brightness: '{{ brightness }}'
    - service: >
        {% if brightness == 0 or brightness == 255 %}
        {% else %}
        {% endif %}
      target: '{{ selected_switch }}'

1 Like

I’ve been using that blueprint for a few months now. Works weel, there is only one problem.

If you use the home assistant app to turn on a light (or if you turn on the light through an automation), using the Lutron switch will not work, you have to press it twice, e.g.:

  1. Turn on light in HA app
  2. Press Lutron Aurora
  3. Nothing happens
  4. Press Lutron Aurora a second time
  5. Light turns off

Is there any way this can be fixed? (I wouldn’t mind changing my automations…)

I’ve been experimenting with the Aurora myself, albeit through zigbee2mqtt instead of ZHA. The reason you’re experiencing this behavior is that the Aurora has its own idea of whether or not your lights are on. At least with my setup, if you have just turned your lights off with the Aurora, and then turned your lights back on with HA, and then press the Aurora, the Aurora will send a brightness of 255 with group 45187 and transition time of 0.07 because it thinks it needs to turn the lights on. This automation will respond by making sure the lights are at maximum brightness.

This is unavoidable without making the automation significantly more complicated, which is what I am working on. The combination of the brightness, group, and transition time is enough to distinguish button clicks from knob turns, but the more elegant way to solve the issue would be to send a Zigbee message to the Aurora to update its internal state whenever you interact through HA. This must be possible, as you can use two Aurora’s for the same room using the Hue hub, and certainly they don’t have this problem. I’m new to Zigbee, so I haven’t figured out how to do that yet.

This is fantastic. I learned so much from your blueprint (I didn’t even know blueprints were a thing), and it “just worked” for light dimming (and on off). I’m using it to control a light zone that’s configured through the Hue gateway.

One issue I was having was orthogonal but felt related to some of the comments above. Thank you for mentioning how to subscribe to events in the developer tools. I saw that I was testing a device a bit too far away from my radio, so the button presses were not detected, and the dimming events were only occasionally being received. Moving closer to the radio made things work as expected.

I’ve been playing with this. Is there any way to tell if the button was pressed? I see the events coming from button pressing as identical to when you twist the dial. The difference is just in the args[0] value. Is there a way to interpret the args[1] value? Thanks again.

@deaton.dg - where do you see transition time and group? It would really help if you can share your automation.

Sorry to take so long here, just seeing this now.

My blueprint is for Zigbee2MQTT and not ZHA, but here it is:

  name: "Aurora Broker v0.1"
  description: 'Create lutron_aurora events from the state_changed of an Aurora.'
  domain: automation
      name: Aurora
          domain: sensor
- platform: event
  event_type: state_changed
    entity_id: !input dimmer
- condition: template
  value_template: >-
      trigger.event.data.new_state.state == "brightness_move_to_level" and
      trigger.event.data.new_state.attributes.action == "brightness_move_to_level"
- choose:
  - conditions:
    - condition: template
      value_template: >-
          trigger.event.data.new_state.attributes.action_level > 0 and
          trigger.event.data.new_state.attributes.action_transition_time == 0.02
    - event: lutron_aurora
        entity_id: !input dimmer
        type: "level"
        level: '{{ trigger.event.data.new_state.attributes.action_level }}'
        attributes: '{{ trigger.event.data.new_state.attributes }}'
  - event: lutron_aurora
      entity_id: !input dimmer
      type: "toggle"
      attributes: '{{ trigger.event.data.new_state.attributes }}'
mode: queued
max: 10

In my experience, this is able to correctly distinguish between a press and a twist 100% of the time.


I was excited to give this Blueprint a go, but the Blueprint isn’t even allowing me to select the Aurora. I’ve got it paired directly to HA through ZHA, but I can’t create an automation with that switch. Any help would be appreciated!

@padlocked17 there are a couple of attributes that the blueprint looks for in order to select devices. Would you be able to look at the device page for this dimmer in HA and verify the Manufacturer is Lurton and Model is Z3-1BRL. Also, there should be one entity for their device, the battery.
Just want to make sure the there isn’t a slightly different model out there.

1 Like

@sorrygofish I missed this conversation earlier. My notifications weren’t making to my mailbox.
I haven’t found a real good description for what the second arg in the event is. But it appears to be set to 2 or 7 depending whether the button was pushed or the knob was turned. Sounds like that maps to the transition_time in @deaton.dg ‘s blueprint.