Support for Lutron Aurora (Friends of Hue dimmer)

[TFenby]

Looking to either supplant or re-open #1672.

Looks like the necessary info is in that issue, but please let me know if I need to provide more!

[carver7]

I would also appreciate having this switch supported:

• It's the only switch that renters can fasten onto an existing hard-wired light switch while simultaneously immobilizing it in order to prevent users from cutting off power to the light bulb socket out of habit
• It screws onto the most common in North America with no electrical modifications required, no additional zigbee switches are needed to stick to the wall, it looks like a common traditional N. American dimmer switch.

Some screenshots of a test setup in deConz with a Conbee II (if more info needed, please let me know) :

Related requests for Lutron Aurora dimmer switch:
#1672
ebaauw/homebridge-hue#522

[TFenby]

I could also have one shipped to a dev if that'd help. :)

[ebaauw]

Just to be sure: this is a wireless switch that covers the 20th century wall switch, but doesn’t need any wiring? Does it work without being installed/attached to the wall switch? I wouldn’t be able to install it due to my EU mains power and wall switches.

Otherwise I’ll be happy to have a look at it. I haven’t yet gotten my hands on a ZLLRotary switch. As mentioned in the homebridge-hue issue: not sure how to expose these to HomeKit, but if we can get web socket notifications for each rotary event, it would work quite well as a Stateless Programmable Switch with automations for setting Change Brightness from homebridge-hue, or Change Volume from homebridge-zp.

[francoiscote]

I just bought a couple of those also, so I am interested in deconz support and will try to help as much as I can.

@ebaauw You got it right. It works without being installed on the wall switch.

[carver7]

Hi @ebaauw ,

To better clarify, instead of us calling it a 'switch', the Lutron Aurora as a probably more helpfully described as:

• a battery-powered Zigbee 3.0 certified remote
• it has 2 controls: it's center is an on/off push button, and the outer dial is a rotary dimmer
• It can be paired directly with up to 12 Hue bulbs (and it should be pairable others), or it can be paired to a Hue bridge via the Hue phone app
• Is friction-mounted on top of any N. American hard-wired toogle-style light switch
  (since the Aurora's mounting plate sits flush with the hard-wired switch's outer wall-plate, the mounting plate's diameter is sufficiently large enough to effectively immobilize the toogle switch--see photos. So if the wired switch actually controls power to the fixture in which the Hue bulb is screwed into, the toogle-switch should be flipped to the 'on' position before installing...otherwise it doesn't matter if the wired switch is functional or not).
• no wiring at all so, it functions whether or not it is mounted onto anything

According to their FAQ, Lutron is not intending for this remote to work only with Hue bulbs.

It seems to be very well engineered, and it's nice to use.

Lutron's https site doesn't seem to be working at the moment, but here's the product links with specs (with it's own pairing and unpairing process described):
Aurora Advanced Installation Guide

General support center for the Aurora

Hue link

Here's some photos:

Just to be sure: this is a wireless switch that covers the 20th century wall switch, but doesn’t need any wiring? Does it work without being installed/attached to the wall switch? I wouldn’t be able to install it due to my EU mains power and wall switches.

Otherwise I’ll be happy to have a look at it. I haven’t yet gotten my hands on a ZLLRotary switch. As mentioned in the homebridge-hue issue: not sure how to expose these to HomeKit, but if we can get web socket notifications for each rotary event, it would work quite well as a Stateless Programmable Switch with automations for setting Change Brightness from homebridge-hue, or Change Volume from homebridge-zp.

[carver7]

@TFenby

If @ebaauw is interested in receiving one from you and wants to give it a try, it'd be best to make sure it has the latest firmware on it first, since I don't know if the Hue app would be able to do so outside of N. America.

Would you be able to pair it with a Hue bridge and update the firmware (if available) and then unpair it from your Hue bridge before sending it to him?

Also, if you do this, I'll split the cost with you so let me know and we can PM so I can PayPal you.

Obviously we know there's no guarantee of success but I suspect he'd be successful. Homebridge-hue works so well and since I use it daily now, I wouldn't mind sending this to him out of gratitude anyhow :)

[TFenby]

@carver7: If I had a Hue bridge I'd be happy to. :) If you have one I can offer the same cost splitting.

If it's at all helpful to the devs, this device does work with zigbee2mqtt: https://github.com/Koenkk/zigbee-herdsman-converters/pull/587/files

Very different architecture I'm sure but it shows that it does seem to be a pretty standards-conformant ZigBee device.

Also, I am ultimately hoping to use this with Home Assistant if that's relevant?

[ebaauw]

Looking at the screenshots, the device is likely a hybrid, like the Hue dimmer switch, that controls lights directly and sends buttonevent reports to the gateway/hub. Looks like the zigbee2mqtt supports the first, but not the buttonevents. Typically they provide more precise control, but only when the gateway/hub is up and running.

I have a Hue bridge and would be able to link the device to it. Not sure about the firmware updates, I know they use to roll out new firmware per region, but I don’t know if they limit firmware availability to the region where a device is sold. Seems like a lot of administration/work, for no apparent benefit.

After we’ve added support in the REST API plugin, the various API clients, like Phoscon, the HA plugin, and homebridge-hue, need to add support as well. I can only do homebridge-hue; Phoscon isn’t open source, and I don’t know HA.

[carver7]

@ebaauw

Looking at the screenshots, the device is likely a hybrid, like the Hue dimmer switch, that controls lights directly and sends buttonevent reports to the gateway/hub. Looks like the zigbee2mqtt supports the first, but not the buttonevents. Typically they provide more precise control, but only when the gateway/hub is up and running.

I can confirm what looks like button and dial events being reported from the remote to the Hue bridge: once it is paired with the Hue bridge, next to the Aurora’s icon in the ‘accessories setup’ section of Hue app, time-stamped messages saying either ‘dial rotated’ or ‘button pressed’ appear when operating it.

Given that it simply states ‘dial rotated’ when turning the dial, and nothing with respect to by how many degrees or by how change in intensity, this also seems consistent with your observation that the remote likely controls the bulbs directly while simply reporting the events to the bridge.

If this hybrid mechanism is indeed how it works, then after the event is reported, does the Hue bridge then in turn poll one or all of the associated bulbs to determine what changes in on/off state or ‘brightness’/intensity have been made before reporting it to the Hue app?
(Polling since I believe I’ve read that the Hue bridge does not use websockets)

[carver7]

@carver7: If I had a Hue bridge I'd be happy to. :) If you have one I can offer the same cost splitting

@TFenby
Sure that works just fine for me...
@ebaauw , if you’re interested, I’d be happy to send you one...if you are, what would be a good way of going about communicating the relevant shipping instructions ?

[ebaauw]

Please email me, or start a private conversation on the homebridge workspace in Slack.

When paired to the Hue bridge, the Hue dimmer switch only reports the buttonevents to the bridge, and doesn’t control the lights directly. It only does so, when paired directly with a light, forming an ad-hoc network, without a bridge. I suspect the Lutron will do the same.

The Hue bridge works under the paradigm that all changes to the light are going through the bridge. When sending a command, it updates its cache with the predicted lightstate after the light has executed the command. The polling is only a safety net, and I suppose for detecting when the light can no longer be reached. This is very different from the paradigm used by e.g. IKEA, where all controllers and even their motion sensor send commands directly to the lights, and the lights report their changed state to the hub. deCONZ can do both: it updates its cache when sending a command to the light, and it eavesdrops on the commands a controller sends, to reverse-engineer that controller events.

There’s pros and cons to both paradigms. The central approach is more flexible, allowing you to map any event to any action, through rules. It only works when the bridge/hub/gateway is up and running. Predicting the light state can be challenging, especially for relative commands (like bri_inc), for group commands, for scenes, and for colours. The decentral approach scales better (no polling needed), and works even when the bridge/hub/gateway is down. However, you’re limited to the comands that the controller sends. This can be configured for professional-grade controllers, but not for the consumer-grade controllers in our budget range.

[TFenby]

Looking at the screenshots, the device is likely a hybrid, like the Hue dimmer switch, that controls lights directly and sends buttonevent reports to the gateway/hub. Looks like the zigbee2mqtt supports the first, but not the buttonevents. Typically they provide more precise control, but only when the gateway/hub is up and running.

I might be misunderstanding, but I can confirm that the Aurora switches do send events to the "hub" in my HASS/zigbee2mqtt setup. I do not have any ZigBee lights at all, and I was able to control IP/Wi-Fi lights with the Aurora switches by using HASS/zigbee2mqtt as the "hub".

[ebaauw]

What I mean is: the zigbee2mqtt picks up (eavesdrops) the commands the switch sends to the group of lights, it doesn’t pick up the Multistate Input notifications. Note that a group in Zigbee is like a multicast address, the switch will happily send the command, irrespective of whether any light is listening, or even present.

[carver7]

@ebaauw
Email sent to ###@###l.nl
Please let me know if you didn’t receive it.

(sorry for my delayed response here)

[ebaauw]

Thanks, @carver7, I did receive your email. @TFenby has already contacted me for my address on Slack. I really appreciate both your efforts, but receiving multiple units would be a waste. I won’t have use for the dimmer here in Europe, due to different standards for in-wall switches. Probably best to get the one with the latest firmware, just in case I won’t be able to update it from over here.

[carver7]

@TFenby
I don’t know your username on Slack...please email me at the address from which I contacted @ebaauw so we can re-coordinate...

[ebaauw]

Thanks guys. I forwarded the email address of @carver7 by Slack, and the slack name of @TFenby by email.

[carver7]

Unit bought and firmware updated. Shipping very soon

[carver7]

@ebaauw @TFenby @ everyone else
Lutron Aurora unit has been sent!
Emailing tracking number

Once again no expectations or pressure of course,
(if someone needs one that bad they can buy a hue bridge as well and run a which works with nearly all open and closed source platforms and run a 2nd Zigbee network)
and thanks to @ebaauw for wanting to take a crack at it

@ebaauw if you like the switch/remote Ive been thinking you can probably stick/screw/nail the mounting bracket to a wall (or maybe onto something resembling a NL-style light switch plate, and screw the latter into the wall first to if you’d rather it look fully like a hardwired switch) or stick to surface of a nightstand etc

[ebaauw]

I just received the Aurora, thanks @carver7

It pairs with deCONZ in a breeze (after factory resetting it). It's far from obvious how it should be configured, though; I need to sniff the traffic when pairing it to a Hue bridge to figure it out. It responds to bind requests alright, but it reacts to these bindings in a very atypical way.

Binding the client On/Off and Level cluster to a group doesn't seem to do anything at all. The dimmer doesn't send any message on pressing or turning.

Binding the server Power Configuration cluster to the coordinator (I would think to setup attribute reporting for the Battery Percentage Remaining) does a lot more:

• The dimmer immediately sends an Add Group command to the coordinator for group 0xf105. I assume this is the group the dimmer picked on factory reset, but it doesn't support any of the commands in the ZLL Commissioning cluster, so I cannot check this. It seems to think the coordinator is a light to be controlled.
• When pressing the button once, it sends a Read Attributes command to the coordinator, for 0x0006/0x0000, checking whether the light is on. Obviously, it doesn't receive any response. It continues to send a Move to Level (with On/Off) to group 0xf105 for level 255 (!) with a transition time of 0.7s.
• It doesn't send anything on hold nor on release.
• On the next press, it sends a Move to Level (with On/Off) for level 0, again with a transition time of 0.7s. So it remembers the light state.
• On double-press, it reacts the same as on press.
• On turning, it sends a Read Attributes command to the coordinator, for 0x0008/0x0000 to the coordinator, to request the current level. It then sends a Move to Level (with On/Off) with a transition time of 0.2s to the coordinator (?!). It seems to remember the last level sent, and adjusts the level with each command. Minimum level is 2; max is 255 (!).
• The reporting configuration for Battery Percentage Remaining is 300/4200/1. I could change it to 300/300/1. It does send attribute reports for the battery (reported in 0.5%, as per the standard).

[ebaauw]

OK, paired it to the Hue bridge.

• After reading the usual Basic cluster attributes, the Hue bridge sends a Read Attribute command for 0x0000/0x0030 (listed as Sensitivity in general.xml) with manufacturer code 0x100b (Philips). Note that the dimmer reports 0x1144 in the Node Descriptor, so we cannot support this attribute in the GUI. The dimmer responds with an enum8 value of 0x01.
• The bridge then sends a series of 0x82 commands to the 0xfc00 cluster, again with manufacturer code 0x100b. The payload for these commands is 40:00:00:00:00:40, 40:20:00:00:00:40, 40:40:00:00:00:40, 40:60:00:00:00:40, 40:80:00:00:00:40. The dimmer responds to each with a 0x83 command with a 43-byte payload (23 bytes for the last) starting with 00:40:x0:00:00:00:8c:00:00:00 (where x corresponds to 0, 2, 4, 6, 8 from the 0x82 command) and a lot of data, containing a.o. the model identifier, manufacturer name, and diversity id. Apparently, this is how the Hue bridge can identify the dimmer (and its capabilities?).
• The bridge then sends a Write Attributes command for 0x0000/0x0031 (Configuration) with manufacturer code 0x100b and a map16 value of 0x000b. I've seen that before, for the Hue dimmer switch:

  deconz-rest-plugin/de_web_plugin.cpp

  Lines 13862 to 13880 in 4187c8d

  	// Stop the Hue dimmer from touchlinking when holding the On button.
  	deCONZ::ZclAttribute attr(0x0031, deCONZ::Zcl16BitBitMap, "mode", deCONZ::ZclReadWrite, false);
  	attr.setBitmap(0x000b);
  	val = sensor->getZclValue(BASIC_CLUSTER_ID, 0x0031);
  	if (val.isValid()) // already done
  	{
  	}
  	else if (writeAttribute(sensor, sensor->fingerPrint().endpoint, BASIC_CLUSTER_ID, attr, VENDOR_PHILIPS))
  	{
  	queryTime = queryTime.addSecs(1);
  	// mark done
  	deCONZ::NumericUnion touchLink;
  	touchLink.u64 = 0x000b;
  	sensor->setZclValue(NodeValue::UpdateByZclRead, BASIC_CLUSTER_ID, 0x0031, touchLink);
  	return;
  	}

• The bridge then sends a bind request for cluster 0xfc00 to the bridge endpoint 65.
• And one for the Power Configuration cluster, followed by a Configure Reporting for Battery Percentage Remaining with values 900/900/4.
• The bridge then tries to read manufacturer specific attributes 0x0000/0x0032 (Usertest) and 0x0000/0x0033 (LED Indication), but the dimmer doesn't support these attributes.

Meanwhile, the dimmer has done a Match Descriptor Request for the OTAU cluster. Apparently my Hue bridge has newer firmware than the dimmer, and is has updated the dimmer firmware from 3.1 to 3.4.

Pressing the button results in a 0x00 command from 0xfc00, with a payload compatible to the Hue dimmer switch: the button (always 1) in byte 0 and the action in byte 4 (0 = press, 1 = hold, 2 = short release, 3 = long release). That's good news, basically the button can be supported by simply whitelisting the Aurora and re-using the code for the Hue dimmer.

Turning the dimmer also results in a 0x00 command from 0xfc00, but now with a considerable larger payload. It will take me a while to reverse engineer this.

[ebaauw]

EDIT The Hue bridge reports the uniqueid for the ZZLRotary sensor as mac-01-fc00-0014, leading me to believe the button number is two bytes, and the type is one byte.

The rotary events payload seems to have the following structure:

1400 01 30 0x 29 xxxx 21 xxxx 29 xxxx 21 xxxx 29 xxxx 21 xxxx

Comparing this to the button event payload, with structure:

0100 00 30 0x 21 xxxx

I think the schema is as follows:

• First two bytes is the button number: 0x0001 for the button; 0x0014 for the dial. For the Hue dimmer, this is 0x0001, 0x0002, 0x0003, 0x0004 for On, DimUp, DimDown, and Off;
• Next byte is the type: 0x00 for button; 0x01 for rotary;
• 30 0x is an enum8 (0x30) with value:
  • for buttons: 0x00: press, 0x01: hold, 0x02: short release, 0x03: long release
  • for rotary: state.rotaryevent: 0x01: initial, 0x02: repeat
• 21 xxxx is an u16 (0x21) indicating the duration since press for button events. It's 0x0000 for press, somewhere between 0x0001 and 0x0009 for short release, 0x000a, 0x0014, 0x001e, 0x0028, 0x0032, 0x003c, for hold (for each hold, the value increases with 0x0a) and somewhere between 0x01 and 0x09 on top of the last hold for long release. I would expect the value to increase by 800 (capabilities.inputs.repeatintervals) or 0.8 sec. Instead it seems to be 10 for 1.0 sec, suggesting a reapeatinterval of 1000?
• 29 xxxx is an s16 (0x29) indicating the rotation angle. It's negative for left turns and positive right turns. I think each rotary event contains three samples to get a feel for the acceleration. Not sure yet which of these samples (or combined?) delivers state.expectedrotation.
  EDIT The first and third 0x29 value seem to be the same, and match state.expectedrotation. The last 0x21 value is always 400, which matches state.expectedeventduration.

[ebaauw]

For completeness, here's the data from the 0x82/0x83 commands:

00:40:00:00:00:00:8c:00:00:00:20:0a:89:01:1a:86:01:0a:07:5a:33:2d:31:42:52:4c:12:06:4c:75:74:72:6f:6e:42:0d:4c:75:74:72:6f:6e:20
                              32                       7  Z  3  -  1  B  R  L     6  L  u  t  r  o  n    13  L  u  t  r  o  n  _

00:40:20:00:00:00:8c:00:00:00:20:41:75:72:6f:72:61:52:1a:08:01:18:14:22:14:08:02:12:02:90:03:5a:0c:0a:04:08:01:10:06:0a:04:08:02
                              32  A  u  r  o  r  a

00:40:40:00:00:00:8c:00:00:00:20:10:07:52:22:08:01:18:01:22:1c:12:02:a0:06:52:16:0a:02:10:01:0a:04:08:01:10:02:0a:04:08:02:10:03
                              32

00:40:60:00:00:00:8c:00:00:00:20:0a:04:08:03:10:04:5a:24:32:63:33:61:37:35:66:66:2d:35:35:63:34:2d:34:65:34:64:2d:38:63:34:34:2d
                              32                      36  2  c  3  a  7  5  f  f  -  5  5  c  4  -  4  e  4  d  -  8  c  4  4  -
 
00:40:80:00:00:00:8c:00:00:00:0c:38:32:64:33:33:30:62:38:65:62:39:62
                              12  8  2  d  3  3  0  b  8  e  b  9  b

The strings are easily recognised, preceded by a length byte. I don't recognise anything else, but presumably, the dimmer's capabilities are encoded in here somewhere.

[ebaauw]

No matter what I try, I cannot get the Lutron Aurora to send 0xfc00 commands when connected to deCONZ. I replay the querying of the manufacturer-specific atrributes using deconz-cli-plugin, confirming with help of the sniffer that the dimmer reacts to these commands.

Attached the log when pairing the Lutron Aurora to the Hue bridge:
aurora.pcapng.zip

For reference, I created a little shell script ($1 is the first parameter to the script: the NWK address of the dimmer):

echo zclattr $1 1 0x0000 000500040000400700 | nc -w 1 localhost 5008
echo zclattrmanu $1 1 0xfc00 0x100b 000004 | nc -w 1 localhost 5008
echo zclattrmanu $1 1 0x0000 0x100b 003000 | nc -w 1 localhost 5008
echo zclcmdmanu $1 1 0xfc00 0x100b 82400000000040 | nc -w 1 localhost 5008
echo zclcmdmanu $1 1 0xfc00 0x100b 82402000000040 | nc -w 1 localhost 5008
echo zclcmdmanu $1 1 0xfc00 0x100b 82404000000040 | nc -w 1 localhost 5008
echo zclcmdmanu $1 1 0xfc00 0x100b 82406000000040 | nc -w 1 localhost 5008
echo zclcmdmanu $1 1 0xfc00 0x100b 82408000000040 | nc -w 1 localhost 5008
echo zclattrmanu $1 1 0x0000 0x100b 023100190b00 | nc -w 1 localhost 5008

However, when next binding the 0xfc00 cluster to the RaspBee, the dimmer blinks quickly (like it's connected again). Afterwards, it sends 0x0008 commands on button/dial actions. I'm afraid the dimmer uses some other method to detect whether it's connected to a Hue bridge before it's willing to send 0xfc00 commands.

As a long shot, I tried configuring the RaspBee with the same endpoint as the Hue bridge (see #266 (comment)) and binding 0xfc00 to that endpoint instead. No changes.

As another long shot, I want to try and configure the RaspBee with a Hue mac address, but just changing the mac address (and leaving the extended PAN ID) led to all sorts of conflicts (a light complaining about an address conflict for 0x0000). I probably need to setup a new network from scratch - some other time.

[ebaauw]

Configuring the RaspBee with a Hue mac address doesn't change the dimmer's behaviour either.

[ebaauw]

Above commit contains the following changes:

• Refactor handling of Philips 0xFC00 cluster for Hue dimmer and Friends-of-Hue dimmer switches, like the Lutron Aurora:
  • No longer use a buttonMap, but parse the command payload;
  • Report duration as state.eventduration, so API clients can see for how long a button has been pressed;
  • Prepare for handling rotary events.
• Add provisionary support for the Lutron Aurora, based on the Level Control commands, until we can figure out how to make it send 0xFC00 commands like it does when connected to the Hue bridge.
  • Only expose a ZHASwitch /sensors resource, with 1001 for Toggle (press), 2001 for DimUp (right turn) and 3001 for DimDown (left turn);
  • No support for Press, Hold, nor Long Release.
  • No support for a ZHARelativeRotary /sensors resource.

Still to do:

• Implement ZHARelativeRotary /sensors resource. This is going to be challenging for the FoH dimmers: if we follow the Hue bridge API, we'd get two /sensors resources with the same mac, endpoint, and cluster. The Hue bridge adds -0014 to the ZLLRotary's uniqueid - I don't like that.
• Refactor IKEA SYMFONISK controller and Xioami Cube to use ZHARotary for the (analog) turn gestures. I'm not aware of any other devices that support turn.
• Figure out how to make the Lutron Aurora send 0xFC00 commands. I'm afraid I'm out of ideas, please help!

[ebaauw]

Here's the resource for the Aurora:

{
  "config": {
    "battery": 100,
    "group": "61701",
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "dfd78f4a913ade212ee3b3e91302bf91",
  "manufacturername": "Lutron",
  "mode": 1,
  "modelid": "Z3-1BRL",
  "name": "Z3-1BRL 6",
  "state": {
    "buttonevent": 2002,
    "lastupdated": "2020-02-13T22:01:00"
  },
  "swversion": "3.4",
  "type": "ZHASwitch",
  "uniqueid": "ff:ff:00:0f:e7:fd:e9:08-01-1000"
}

And here's the resource for the Hue dimmer, with state.eventduration, after releaseing the On button after holding it for 3 seconds:

{
  "config": {
    "battery": 36,
    "group": "21774",
    "on": true,
    "reachable": true
  },
  "ep": 2,
  "etag": "6a2a73d3f55fe3595578f7c5f03b2437",
  "manufacturername": "Philips",
  "mode": 1,
  "modelid": "RWL021",
  "name": "RWL021 7",
  "state": {
    "buttonevent": 1003,
    "eventduration": 30,
    "lastupdated": "2020-02-13T22:46:10"
  },
  "swversion": "6.1.1.28573",
  "type": "ZHASwitch",
  "uniqueid": "00:17:88:01:10:49:55:03-02-fc00"
}

And here's the web socket notifications:

Feb 13 23:46:07 pi1 dc_eventlog[314]: /sensors/7/state: {"buttonevent":1000,"eventduration":0,"lastupdated":"2020-02-13T22:46:07"}
Feb 13 23:46:08 pi1 dc_eventlog[314]: /sensors/7/state: {"buttonevent":1001,"eventduration":8,"lastupdated":"2020-02-13T22:46:08"}
Feb 13 23:46:09 pi1 dc_eventlog[314]: /sensors/7/state: {"buttonevent":1001,"eventduration":16,"lastupdated":"2020-02-13T22:46:09"}
Feb 13 23:46:09 pi1 dc_eventlog[314]: /sensors/7/state: {"buttonevent":1001,"eventduration":24,"lastupdated":"2020-02-13T22:46:09"}
Feb 13 23:46:10 pi1 dc_eventlog[314]: /sensors/7/state: {"buttonevent":1003,"eventduration":30,"lastupdated":"2020-02-13T22:46:10"}

[TFenby]

Thank you so much for all the work!

[carver7]

Lots of great work here! 

I'm afraid the dimmer uses some other method to detect whether it's connected to a Hue bridge before it's willing to send 0xfc00 commands.

It looks like it's been quite challenging...I wondered from the beginning if Lutron has implemented a trick or two to make it difficult to reverse engineer and use with anything but a Hue bridge or with direct Hue bulb pairing, despite Zigbee being an open protocol...from what I've read, Lutron's products and their accompanying in-house wireless protocols are known to be just as closed-source and proprietary as they are well made... 

But regardless, it looks like you've gotten the vast majority of this solved, and that's certainly very cool.
Thanks for all the work you're doing!
And for sharing it...the details are a pretty interesting glimpse as to what's going on under the hood...are you sniffing the traffic when you have it paired to the Hue Bridge, by looking at live output from the Hue Bridge's api? 

[ebaauw]

I don’t know Lutron that well (I think they mainly target the north-american market), but I don’t think they would intentionally frustrate reverse engineering. My current theory is that they only use the 0xfc00 when paired to a ZLL network. I don’t think it’s possible for the RaspBee or ConBee to actually form a ZLL network (instead of ZHA). It used to be possible to join them as a router to the Hue ZLL network, but that function was broken many versions of deCONZ ago. More recently I found using them as a router on a ZHA network formed by another RaspBee/ConBee also reveals some issues… Anyway, this is mostly academic, since no-one will be reconfiguring their RaspBee/ConBee just to connect the Aurora.

The 0xfc00 stuff is a manufacturer-specific extension, linked to Philips. Lutron probably never considered people wanting to use this in conjunction with another Zigbee gateway. Oddly, the Hue dimmer doesn’t have this restriction. It’s a pity, because the Aurora dimmer is more powerful than the Hue API supports (it actually reports how long the button has been pressed, like the Hue dimmer switch) and the deCONZ API is far more powerful than the Hue API (if only for push notifications).

Yes, I sniff the ZigBee traffic between the Hue bridge and the Aurora while monitoring the Hue API. Unfortunately, the Hue bridge doesn’t support push notifications, so there’s no (looking at the) life output. I poll the bridge every second, hoping to catch all state changes to the ZLLSwitch and ZLLRelativeRotary sensor resource.

[ebaauw]

Added support for the Hue smart button, which, on a ZigBee level, looks similar to the Aurora. Still no luck figuring out how to activate the 0xFC00 cluster, though.

[Typ1er]

how do you couple the Aurora switch to deCONZ?

[ebaauw]

• Reset the Aurora (see the manual: press / release / press / release / press / hold until the led turns on / release / press / release / press / release / press / release and the led blinks fast);
• Search for new devices in Phoscon or PUT {"permitjoin": 60} to /config using the API;
• Press/release the Aurora twice and led blinks slowly to indicate pairing mode;
• When it has joined the network, the LED blinks quickly and then stops blinking;
• A new node should appear in the GUI. If not: double-check the Node List panel, sometimes the node appears out of sight or behind another node. Double-check that no other network was open (yes, this did happen to me during testing);
• deCONZ should read the node descriptors, enabling the right drop-down circle on the node; If this doesn't happen, read them manually from the left drop-down circle;
• The REST API plugin should read the Basic cluster attributes, and create the REST resources. In the GUI, the name on the node changes from the NWK address. If this doesn't happen, read the attributes manually (from the Cluster Info panel). The Aurora's LED blinks quickly once again, as the REST API plugin sets up the bindings.

[Mimiix]

It seems this issue is resolved or otherwise inactive. If it is not, please re-open!

[Mimiix]

As I mentioned on reddit I'll re open and ask a dev to check it.

[ars4l4n]

As I mentioned on reddit I'll re open and ask a dev to check it.

daz on me

[stale]

As there hasn't been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[stale]

As there hasn't been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it isn't solved, request to get this opened again.

[rjhilgefort]

I would love to see this switch supported if it's possible. Deconz doesn't recognize it as a switch

[ebaauw]

The switch is supported by the REST API plugin. To request support in Phoscon, please see their repository.

If it's not working in the REST API plugin, please open a new issue and include GUI screenshots of the node, endpoints, and clusters; and of the Basic cluster, after reading the attributes. And attach a log file while running deconz with --dbg-info=2 and --dbg-error=1` and trying to pair the Lutron Aurora.