Aqara UNSUPPORTED_ATTRIBUTE in Zigbee2MQTT, Explained

An Aqara feature can appear in Zigbee2MQTT’s Exposes panel and still return UNSUPPORTED_ATTRIBUTE when you read or change it. That response tells you the device rejected the requested attribute in that transaction. It does not, on its own, establish whether the converter, endpoint, manufacturer-specific request or firmware is responsible.

This guide explains 0xFCC0, called manuSpecificLumi in Zigbee2MQTT, and uses two reported failures to show what to inspect. Many Aqara options use it, but older models and other features can use different clusters or attributes. Match the request to your exact model rather than assuming every extra feature has one universal implementation.

The exchange is local between your coordinator and device. An Aqara cloud account does not decide whether a Zigbee attribute read succeeds. For model identification, see what Aqara’s model codes mean.

The symptom: a listed feature throws UNSUPPORTED_ATTRIBUTE

Two GitHub issues show the same failure shape. They were filed independently, on two unrelated Aqara product families.

On the Aqara ZNCZ12LM smart plug (issue #25969), auto_off, led_disabled_night and overload_protection all fail to enable. Zigbee2MQTT logs each attempt as UNSUPPORTED_ATTRIBUTE. The same report also lists OTA updates as failing. OTA runs over the standard Zigbee OTA cluster, not Aqara’s private one, so treat it as a separate problem that happens to share the thread.

On the Aqara Dual Relay Module T2 (issue #21281), the error appears while Zigbee2MQTT configures the device. A read of attribute 10 on manuSpecificLumi, endpoint 2, comes back UNSUPPORTED_ATTRIBUTE. The reporter notes that the relays themselves work normally.

The T2 reporter says the relays generally work; the plug report concerns specific settings and OTA. These examples show why a failed configuration read does not necessarily mean all device control has failed. Check the working functions separately, rather than diagnosing hardware health from this status alone.

What 0xFCC0 / manuSpecificLumi is

Zigbee defines standard clusters such as on/off, level control and power configuration. Manufacturers can also define private clusters and attributes. Aqara uses 0xFCC0 for many settings beyond those standard functions; support for an individual attribute still varies by device and firmware.

Zigbee2MQTT’s device layer names it manuSpecificLumi, after Lumi United, the company behind Aqara. Many Aqara Zigbee model IDs use the Lumi prefix (lumi.plug..., lumi.switch...). ZHA’s quirks library calls the same cluster XiaomiAqaraE1Cluster, and many devices use an OppleCluster subclass of it (zhaquirks source). Those names can help cross-reference implementations, but a ZHA class name is not proof of an identical attribute map on every device.

Depending on the model, options using this cluster include:

• decoupled/no-relay mode
• LED behaviour
• power-on behaviour
• relay lock
• multi-click reporting
• plug options like auto_off and overload_protection

Device-specific code maps these attributes to useful controls: zigbee-herdsman-converters for Zigbee2MQTT and quirks for ZHA. The model definition, endpoint, attribute ID, data type and manufacturer options all need to match the device. The current Lumi converter code is a primary reference for those requests.

The manufacturer code, and what the error line tells you

Aqara/Lumi requests commonly use manufacturer code 0x115F, decimal 4447. This code is separate from the cluster ID 0xFCC0, the attribute ID and the endpoint number. Do not substitute one for another.

In issue #25969, the plug’s log shows that code on rejected writes: attribute 514 (0x0202) for auto_off, 515 (0x0203) for the night LED option, and 523 (0x020B) for overload protection. That rules out the simple claim that the logged requests omitted code 4447. It does not prove that the endpoint, attribute, type, payload and firmware match are all correct.

Missing or incorrect manufacturer-specific options can be a converter/quirk problem. The same status can also arise when a request targets an attribute or endpoint unsupported by that firmware. Compare the complete request with the matching model definition; the short error summary cannot distinguish every cause.

Same cluster, different devices

The T2 relay and the ZNCZ12LM plug each have their own guide in our catalog: the Dual Relay Module T2 setup guide and the ZNCZ12LM guide. Here they are side by side at the mechanism level:

Aqara H2 switches also have model-specific private settings, handled through their own definitions. The relevant comparison is the exact request and device mapping, not simply that a relay, plug and switch share a cluster number.

What a closed issue does—and does not—tell you

Both cited issues are closed as “not planned” and carry stale labels. That status does not establish why the device rejected an attribute, prove a permanent firmware limitation or tell us that no later converter change matters. Use the reports as historical examples, then inspect current support for your model and firmware.

A custom external converter can correct an endpoint or attribute mapping, handle model-specific behavior or hide an unsupported option. It cannot add functionality genuinely absent from the device. Check the existing implementation before taking on an external converter that you will need to maintain.

What to do when you hit this

Use this as a diagnostic sequence, not a guaranteed fix for every manuSpecificLumi error:

1. Record the exact device. Save its model ID, manufacturer string, firmware version, endpoint and Zigbee2MQTT/converter version. A sales name alone can cover different variants.
2. Copy the complete failing request. Note read versus write, cluster, attribute IDs, manufacturer options and any written data type/value. Mask device identifiers when sharing logs publicly.
3. Compare with the matching current converter. Code 4447 being present answers only one question. Check that the request targets the expected endpoint and attributes for that model. An external converter can also override current built-in support.
4. Check related reports and changes. Search the exact model and attribute; distinguish a configure-time diagnostic from a required control that fails. Review a relevant software fix before updating, and check OTA availability/changelog separately. Do not flash another model’s firmware to test a guess.
5. Retest safely. Verify normal control and the specific option after a relevant change. A timeout or a sleeping device is a different observation from an explicit unsupported-attribute response.
6. If the option remains unavailable, choose a fallback. A Home Assistant power-based routine may reproduce an auto-off behavior while HA is running; it is not the same as device-native protection. The ZNCZ12LM guide covers that option.

Gateway telnet/HACS access is a separate integration route with specific supported hardware. It does not make a missing Zigbee attribute appear and is not a general next step for this error.

FAQ

What is cluster 0xFCC0?

A manufacturer-specific cluster used by many Aqara/Lumi devices. Zigbee2MQTT calls it manuSpecificLumi; ZHA uses device-specific classes such as XiaomiAqaraE1Cluster and OppleCluster. The attribute map is not universal.

Does manufacturerCode 4447 prove the request is correct?

No. It shows that manufacturer option is present. Model, endpoint, attribute, data type and value still need checking.

Can a converter fix UNSUPPORTED_ATTRIBUTE?

It can if the request or device mapping is wrong. If the requested function is genuinely absent, software cannot supply it inside the device. Determine which case applies before changing code.

Does the same failure apply to ZHA?

Compare its quirk and request for the same model/firmware. Shared cluster names do not guarantee the same exposed features or the same bug.

Evidence and limits

The two linked issue reports contain actual rejected requests: a T2 configure-time read of attribute 10 on endpoint 2, and plug writes carrying manufacturer code 4447. Both reports are closed without a general resolution recorded there. Current source code documents the cluster and request mappings; the reports do not establish one permanent limitation across all units or explain the closure decision.

This is source and log analysis, without a physical-hardware test for this article. The supported diagnostic is to match the exact request to the exact device, then verify the affected function on your own unit. Normal control may continue while an optional read fails, but that needs checking rather than assuming the entire device is healthy.