Device: Lutron Aurora Z3-1BRL, firmware 0x00000c12 (Zigbee2MQTT installed_version: 3090) Symptom this solves: ZHA pairs the Aurora fine but direct binding never controls the bulbs. Fix: Migrate to Zigbee2MQTT and bind the Aurora's Level Control cluster to each bulb individually.
This guide documents a successful migration from ZHA to Zigbee2MQTT for a Lutron Aurora Z3-1BRL running the newer 0x00000c12 firmware, reported by Zigbee2MQTT as installed version 3090.
The completed setup provides:
- Direct dial-based dimming.
- Direct center-button on and off control.
- Continued operation when Home Assistant, Zigbee2MQTT, MQTT, and the Zigbee coordinator are completely offline.
- Normal bulb control from Home Assistant through MQTT discovery.
- Optional room-level Zigbee groups for dashboards and automations.
No Aurora firmware downgrade was required.
This procedure was reproduced on July 18, 2026 with:
- Home Assistant OS.
- Home Assistant SkyConnect, now named Connect ZBT-1.
- Dedicated Zigbee firmware, not multiprotocol firmware.
- Zigbee2MQTT 2.12.1.
- Zigbee2MQTT's
emberadapter driver. - Lutron Aurora Z3-1BRL.
- Aurora firmware
0x00000c12, decimal version 3090. - Third Reality ZL1 color bulbs, model 3RCB01057Z.
- Mosquitto MQTT broker.
Zigbee2MQTT correctly identified the SkyConnect as a Nabu Casa adapter using the Ember driver.
This guide is specifically intended for the newer Lutron Aurora firmware:
0x00000c12
Zigbee2MQTT reports this as:
installed_version: 3090
Older Auroras running:
0x00000c08
reported as decimal version 3080, can work correctly through ZHA binding. They expose their ordinary button and dial activity to ZHA in the standard form ZHA expects.
The newer C12 firmware presents the same basic device identity and advertised Zigbee capabilities as C08:
- Model Z3-1BRL.
- Endpoint 1.
- Groups cluster
0x0004. - On/Off cluster
0x0006. - Level Control cluster
0x0008. - OTA and LightLink support.
It can therefore pair, interview, reconfigure, and respond to reads normally in ZHA. The problem is not basic compatibility, radio range, or a failed interview.
The important difference between C08 and C12 is how ordinary physical interactions are presented to the coordinator.
During a captured sequence of:
- center press
- clockwise rotation
- center press
- counter-clockwise rotation
- center press
the working C08 Auroras produced the standard controller-visible behavior associated with On/Off and Level Control. Their dial movement appeared as normal move_to_level_with_on_off traffic on cluster 0x0008.
The C12 Aurora reliably transmitted every interaction, but its coordinator-facing traffic appeared instead as Lutron manufacturer-specific messages on:
Profile: 0x0104
Cluster: 0xFC00
Manufacturer: 0x100B / 4107
Source: Aurora endpoint 1
Destination: Coordinator endpoint 1
Message type: Incoming unicast
Presses produced a repeatable two-frame 0xFC00 pattern. Rotations produced several 0xFC00 frames containing increasing or decreasing position-like values.
During that five-action capture, the coordinator received no normal interaction frames on:
0x0006 On/Off
0x0008 Level Control
ZHA could see that radio traffic existed, but logged messages such as:
Unknown cluster command 0
No explicit handler for cluster command 0
It could not decode those messages into the normal Aurora button and dial activity used by the established ZHA binding workflow.
The link itself was healthy, with good LQI and RSSI values. The C12 Aurora also joined normally and sent setup-time Zigbee application traffic, including a Groups add command. This rules out a weak connection or radio-silent device.
The captures do not prove that C12 never emits a separate direct group command to bound bulbs — a coordinator cannot necessarily observe every group or destination-specific transmission. They do prove that the coordinator-facing behavior changed materially between C08 and C12.
In practical terms:
| Setup | Result |
|---|---|
| C08 with ZHA | ZHA sees standard Aurora control behavior and can use the established direct-binding workflow. |
| C12 with ZHA | ZHA sees Lutron-private interaction messages it does not understand, so pairing and reconfiguration succeed but normal binding control does not. |
| C12 with Zigbee2MQTT | Zigbee2MQTT can configure the Aurora's Level Control binding and hidden Zigbee group. Once configured correctly, the Aurora sends working direct commands to the bulbs. |
After the successful Zigbee2MQTT setup, the C12 Aurora produced group-addressed Level Control commands with:
255 center-button on
0 center-button off
and intermediate values for dial rotation. The complete setup continued working with Home Assistant and the coordinator physically unplugged.
For C12 firmware, Zigbee2MQTT is therefore the only verified path in this testing that provides complete direct dial and center-button control.
| Action | C08 working Auroras | C12 Kitchen Aurora |
|---|---|---|
| Center press | Standard control behavior visible to ZHA, normally associated with On/Off / normal Aurora interaction | Two Lutron manufacturer-specific frames on cluster 0xFC00 |
| Clockwise rotation | Standard Level Control command on 0x0008: move_to_level_with_on_off |
Three 0xFC00 frames carrying positive/increasing position values |
| Second press | Standard controller-visible control behavior | Same repeatable two-frame 0xFC00 press pattern |
| Counter-clockwise rotation | Standard Level Control 0x0008 command with decreasing level |
Four 0xFC00 frames carrying negative/decreasing position values |
| Third press | Standard controller-visible control behavior | Same repeatable two-frame 0xFC00 press pattern |
| Property | Working C08 | Replacement C12 |
|---|---|---|
| Firmware | 0x00000c08 |
0x00000c12 |
| ZHA-visible interaction cluster | 0x0008 Level Control |
0xFC00 Lutron-private manufacturer-specific |
| ZHA interpretation | Decodes it as move_to_level_with_on_off and records Activity |
Logs "Unknown cluster command 0" / "No explicit handler for cluster command 0" |
| What ZHA receives during normal operation | Standard commands it understands | Private telemetry/status-like messages it does not understand |
| Radio destination observed in the capture | Standard coordinator-visible control traffic | Unicast to coordinator 0x0000, endpoint 1 → 1, profile 0x0104, manufacturer 0x100B / 4107 |
| Link quality | Working | Also working: LQI about 160–168, RSSI about −69 to −71 dBm |
| Practical result | ZHA can observe normal interaction and direct-binding workflow behaves as expected | ZHA cannot treat the interaction reports as ordinary On/Off or Level Control actions |
The newer Aurora firmware can perform genuine Zigbee direct binding through Zigbee2MQTT.
Zigbee binding allows a controller and bulb to communicate without commands passing through Zigbee2MQTT or Home Assistant. Properly bound devices should continue working even when the coordinator is unavailable.
The Aurora has unusual binding behavior:
- It must be bound to each bulb as an individual target.
- It creates and uses its own hidden Zigbee group behind the scenes.
- It cannot be bound directly to an ordinary Zigbee2MQTT group through the Aurora's Bind page.
- The bulbs must support Zigbee groups.
- The useful binding is the Level Control cluster, shown as
LevelCtrlorgenLevelCtrl.
This hidden-group behavior is explicitly documented on Zigbee2MQTT's Aurora device page.
The newer Aurora firmware also sends both dial and center-button commands through Level Control. In the successful setup:
- Dial movement used
action_transition_time: 0.02. - Center-button presses used
action_transition_time: 0.07. - Center-button on sent
action_level: 255. - Center-button off sent
action_level: 0.
That means adding a separate On/Off binding is not necessary. The button's on/off behavior is carried through Level Control.
A ZHA backup is optional rather than required.
For a small network, it is reasonable to treat the move as a clean migration:
- Disable the complete ZHA integration.
- Restart the Home Assistant host so ZHA releases the coordinator.
- Start Zigbee2MQTT.
- Factory-reset and re-pair the devices one room at a time.
- Recreate device names, areas, groups, and any affected automations.
Deleting individual devices from ZHA does not release the SkyConnect or Connect ZBT-1. The entire ZHA integration must be disabled before Zigbee2MQTT can open the coordinator's serial port.
Previously bound rooms may continue controlling themselves while they remain on the old Zigbee network, even after ZHA is disabled. They stop participating in that network only when the Aurora or bulbs are factory-reset and joined to the new Zigbee2MQTT network.
A ZHA network backup may still be created when an easy rollback is desirable, but this procedure assumes starting fresh is acceptable.
Install and start the Mosquitto broker in Home Assistant.
Install the Zigbee2MQTT Home Assistant add-on. Zigbee2MQTT requires an MQTT broker connection, and the Home Assistant add-on is the standard installation method for Home Assistant OS and Supervised installations.
During Zigbee2MQTT onboarding:
- Select the SkyConnect or Connect ZBT-1.
- Use adapter type
ember. - Prefer the persistent
/dev/serial/by-id/...path when offered. - Enter the Mosquitto connection information.
- Enable the Zigbee2MQTT frontend.
- Enable Home Assistant integration.
The relevant Home Assistant discovery configuration is equivalent to:
homeassistant:
enabled: trueZigbee2MQTT uses MQTT discovery to create its devices and entities in Home Assistant.
Deleting individual devices from ZHA does not release the coordinator.
Only one Zigbee application can own the SkyConnect serial port at a time. If ZHA still has it open, Zigbee2MQTT will detect the adapter but fail with an error such as:
Resource temporarily unavailable
Cannot lock port
That exact failure occurred during this migration.
To release it:
- Stop the Zigbee2MQTT add-on.
- Open Settings → Devices & services → ZHA.
- Disable the complete ZHA integration.
- Restart the Home Assistant host.
- Start Zigbee2MQTT again.
Do not allow ZHA to rediscover and reclaim the SkyConnect after Zigbee2MQTT begins using it.
In the Zigbee2MQTT frontend, select Permit join (All). This opens the network for approximately 254 seconds.
Pair devices one at a time:
- Factory-reset the first bulb.
- Wait for Zigbee2MQTT to report a successful interview.
- Give it a descriptive name, such as
Kitchen Bulb 1. - Repeat for the other bulbs.
Pair the bulbs before pairing the Aurora.
For an Aurora that was previously paired:
- Quickly press the center button four times.
- On the fourth press, continue holding until its LED begins blinking.
- Immediately press the button three more times.
These are the documented reset and pairing instructions for a previously paired Aurora.
Keep Permit Join enabled and wait for the Aurora to complete its interview. Rename it immediately, such as Kitchen Aurora.
Confirm its device page reports:
installed_version: 3090
Decimal 3090 corresponds to hexadecimal firmware version 0x00000c12.
This is the core procedure.
For each bulb:
- Open the bulb's device page in Zigbee2MQTT.
- Open Exposes.
- Find Start bind.
- Select or submit
StartBind. - Immediately open the Aurora's device page.
- Open the Aurora's Bind tab.
- Select that individual bulb as the target.
- Select only Level Control, shown as
LevelCtrlorgenLevelCtrl. - Submit the binding.
- Press or rotate the Aurora repeatedly while the operation runs so the battery device remains awake.
The Third Reality ZL1 exposes a specific start_bind command with the accepted value StartBind.
Repeat this process for every bulb controlled by that Aurora.
Do not select an ordinary Zigbee2MQTT group as the Aurora's binding target. The Aurora creates its own hidden group and associates each individually selected bulb with that group.
Initially, Level Control binding made the dial work on every bulb, but the center button only turned the bulbs on.
After activating StartBind on one Third Reality bulb and refreshing the binding, all three bulbs began responding correctly to center-button on and off commands.
The logs show the test bulb entering StartBind immediately before the system began working correctly.
It is not certain why activating it on one bulb appeared to repair the entire hidden group. The Aurora may have refreshed or recommitted its internal group membership. For a reproducible installation, use StartBind on every Third Reality bulb immediately before binding it.
Verify the hidden Aurora group
Open Zigbee2MQTT's logs and press the center button repeatedly.
A successful center-button sequence should resemble:
{
"action": "brightness_move_to_level",
"action_group": 18667,
"action_level": 255,
"action_transition_time": 0.07
}followed by:
{
"action": "brightness_move_to_level",
"action_group": 18667,
"action_level": 0,
"action_transition_time": 0.07
}The group ID will be different for different Auroras. Do not copy 18667; that was the automatically generated hidden group in this particular kitchen.
In the successful setup, the Aurora repeatedly alternated group-addressed level 255 and level 0 commands after the Start Bind procedure.
The three bulbs then responded together to the same Aurora group commands.
Do not rely only on Zigbee2MQTT logs.
Test the room normally first:
- Rotate the Aurora through its complete dimming range.
- Press the center button repeatedly.
- Confirm every bulb turns on and off together.
Then stop Zigbee2MQTT or completely unplug Home Assistant.
Test the Aurora again.
A successful direct binding must continue to provide:
- Center-button on.
- Center-button off.
- Dial dimming.
- Coordinated control of all bound bulbs.
In the reproduced kitchen setup, all functions continued working while the Home Assistant machine was physically unplugged. This confirms the commands were passing directly between the Aurora and bulbs rather than through an MQTT or Home Assistant automation.
Some values in Zigbee2MQTT can look strange but are not necessarily errors.
Zigbee2MQTT exposes the Third Reality bulb's brightness range as 0–254. A submitted value of 255 will therefore normally appear as 254.
A bulb may also briefly accept brightness 0, switch off, and later report brightness 1 while its separate power state remains off. That behavior was observed directly during testing.
After direct group commands, the bulbs' reported MQTT state may not always perfectly describe their visible physical state. The successful logs sometimes showed brightness: 1 and state: ON after an off command even though the bulbs were visibly off.
For verifying direct binding, physical behavior during the offline test is more important than the immediate MQTT state report.
In Zigbee2MQTT, enable:
Settings → Home Assistant integration → Enabled
Restart Zigbee2MQTT after enabling it.
In Home Assistant, open:
Settings → Devices & services → MQTT
The bulbs should appear as MQTT devices with light entities. MQTT discovery is enabled by default in Home Assistant, using the discovery prefix homeassistant.
If the MQTT integration is missing:
- Open Settings → Devices & services.
- Select Add Integration.
- Choose MQTT.
- Connect it to the same broker used by Zigbee2MQTT.
The Aurora's hidden group should be left alone. It exists for direct Aurora control.
For Home Assistant dashboards and automations, create a separate normal group.
In Zigbee2MQTT:
- Open Groups.
- Create a group such as
Kitchen Lights. - Allow Zigbee2MQTT to assign a new group ID.
- Add the three bulbs.
- Do not reuse the Aurora's hidden group ID.
- Restart Zigbee2MQTT if the new group does not immediately appear in Home Assistant.
Zigbee2MQTT supports native Zigbee groups and can expose them to Home Assistant through MQTT discovery.
The same bulbs can simultaneously belong to:
- The Aurora's hidden group for direct physical control.
- A normal Zigbee2MQTT group for Home Assistant control.
A native Zigbee group is generally preferable for room-wide commands because Home Assistant sends one group command over Zigbee instead of issuing separate commands to every bulb.
You can instead create:
Settings → Devices & services → Helpers → Create helper → Group → Light group
Add the individual MQTT light entities to that helper.
This works at the Home Assistant level but does not create a native Zigbee group.
Zigbee2MQTT says it cannot lock the port
ZHA or another process still owns the SkyConnect.
Disable the entire ZHA integration, restart the Home Assistant host, and start Zigbee2MQTT again. Removing individual devices is not enough.
The dial works, but the center button only turns bulbs on
For Third Reality ZL1 bulbs:
- Open each bulb's Exposes page.
- Submit
StartBind. - Immediately rebind the Aurora's Level Control cluster to that bulb.
- Keep the Aurora awake during binding.
- Repeat for every bulb.
This was the missing step in the reproduced installation.
The center button sends 255 and 0, but nothing changes
Confirm that the messages include an action_group.
If no group is present consistently, repeat the binding while keeping the Aurora awake. A successful individual binding should cause the Aurora to create or reuse its hidden group and associate the target bulb with it.
The center button appears to use no On/Off cluster
That is expected on firmware 3090.
The center button sends Level Control commands with a longer transition time:
action_transition_time: 0.07
The dial uses:
action_transition_time: 0.02
Bind Level Control rather than attempting to solve the button through a separate On/Off binding.
Zigbee2MQTT says Aurora firmware 3080 is the latest
Firmware 3090 may appear as installed while Zigbee2MQTT's OTA metadata identifies 3080 as the latest available image. Do not attempt to force the older OTA image merely because of that display.
The successful configuration remained on installed version 3090.
Home Assistant shows the wrong state after using the Aurora
Directly bound group commands do not pass through Home Assistant. Some bulbs may report their updated level or state slowly or inconsistently afterward.
This does not affect the direct physical binding. Use the offline physical test to confirm reliability.
For each room:
- Pair all bulbs with Zigbee2MQTT.
- Pair the Aurora last.
- On bulb 1, submit
StartBind. - Bind the Aurora's Level Control cluster to bulb 1.
- Repeat Start Bind and Level Control binding for every bulb.
- Do not bind the Aurora to a normal Zigbee2MQTT group.
- Confirm the logs show one hidden
action_group. - Confirm center presses alternate levels 255 and 0.
- Test the dial and center button.
- Completely stop or unplug Home Assistant.
- Verify that all controls still work.
- Create a separate Zigbee2MQTT group for Home Assistant room control.
A Lutron Aurora Z3-1BRL running firmware 0x00000c12, or installed version 3090, can directly control Third Reality ZL1 bulbs through Zigbee2MQTT.
The successful combination was:
- Individual Level Control bindings.
- The Aurora's automatically generated hidden group.
- The Third Reality bulb's StartBind mode.
- No separate On/Off binding.
- No Home Assistant automation.
- No Aurora firmware downgrade.
Both the dial and center button continued working with Home Assistant entirely unplugged.
Search terms someone troubleshooting this exact problem is likely to use:
Lutron Aurora Z3-1BRL ZHA direct binding not working, Aurora firmware 0x00000c12 installed_version 3090, ZHA "Unknown cluster command 0", ZHA "No explicit handler for cluster command 0", Lutron manufacturer specific cluster 0xFC00, Aurora center button only turns bulbs on Zigbee2MQTT, Aurora dial works button doesn't, Third Reality ZL1 3RCB01057Z StartBind, Zigbee2MQTT "Cannot lock port" SkyConnect, Connect ZBT-1 ember adapter, Aurora hidden Zigbee group binding, migrate ZHA to Zigbee2MQTT Aurora dimmer.