Sunricher SR-ZG9095B: fanMode responses are not processed and away_mode uses an unsupported attribute

What happened?

I used ChatGPT to help analyze the debug log and formulate this issue because I am not deeply familiar with the internal Zigbee and Zigbee2MQTT implementation.

I reproduced and verified the behavior described below on my own device. The quoted log messages are taken directly from my Zigbee2MQTT installation. The technical interpretation and suggested changes are intended as helpful indications and may need correction by the maintainers.

I am using a Sunricher SR-ZG9095B-0-10V thermostat.

Device information:

• Zigbee2MQTT model: SR-ZG9095B
• Zigbee model ID: ZG9095B
• Manufacturer: Sunricher
• Device firmware/software build ID: 6.10.3.0
• Endpoint: 1
• Fan cluster: hvacFanCtrl

Setting the fan mode from Zigbee2MQTT or Home Assistant works correctly.

For example, when I select high in Home Assistant, the physical thermostat changes to the high fan mode.

However, when I change the fan mode locally on the physical thermostat, the new value is not reflected in Zigbee2MQTT or Home Assistant.

I performed the following test:

1. I set the fan mode to high through Home Assistant.
2. The physical thermostat correctly changed to high.
3. I changed the fan mode locally on the thermostat to low.
4. The thermostat display correctly showed low.
5. Zigbee2MQTT and Home Assistant continued to show the old value:

{
  "fan_mode": "high",
  "fan_state": "ON"
}

I then explicitly requested the fan mode through MQTT.

Topic:

zigbee2mqtt/DEVICE_FRIENDLY_NAME/get

Payload:

{
  "fan_mode": ""
}

Zigbee2MQTT correctly sent a read request for hvacFanCtrl.fanMode.

The thermostat answered with:

type 'readResponse',
cluster 'hvacFanCtrl',
data '{"fanMode":1}'

In this test, fanMode: 1 corresponds to the low fan mode currently displayed on the physical thermostat.

Immediately afterwards, Zigbee2MQTT logged:

No converter available for 'SR-ZG9095B'
with cluster 'hvacFanCtrl'
and type 'readResponse'
and data '{"fanMode":1}'

The MQTT state was therefore not updated and remained on the previously cached value high.

This confirms that the thermostat stores the locally selected fan mode correctly, answers the Zigbee read request, and that Zigbee2MQTT receives the response but does not process it.

Away mode is also not working

The exposed away_mode feature does not work on my thermostat either.

The published device state always contains:

{
  "away_mode": null
}

Trying to enable away mode by publishing the following payload:

{
  "away_mode": "ON"
}

to:

zigbee2mqtt/DEVICE_FRIENDLY_NAME/set

fails with the following error:

Publish 'set' 'away_mode' to 'DEVICE_FRIENDLY_NAME' failed:

Error: ZCL command DEVICE_IEEE_ADDRESS/1
hvacThermostat.write(
  {"8194":{"value":1,"type":48}},
  {
    "timeout":10000,
    "disableResponse":false,
    "disableRecovery":false,
    "disableDefaultResponse":true,
    "direction":0,
    "reservedBits":0,
    "manufacturerCode":4644,
    "writeUndiv":false
  }
)
failed (Status 'UNSUPPORTED_ATTRIBUTE')

Attribute 8194 corresponds to hexadecimal attribute ID 0x2002.

The thermostat therefore explicitly rejects the manufacturer-specific attribute currently used by Zigbee2MQTT for away_mode.

This appears to explain both observed problems:

• away_mode cannot be enabled through Zigbee2MQTT.
• The reported away_mode state always remains null.

The device definition currently exposes away_mode as readable and writable, but the attribute used by the converter is not supported by my SR-ZG9095B with software build ID 6.10.3.0.

I cannot determine whether this thermostat firmware uses a different attribute for away mode or whether away mode is not available through Zigbee at all.

What did you expect to happen?

When the fan mode is changed locally on the physical thermostat, Zigbee2MQTT should receive and publish the new fan_mode.

At minimum, explicitly requesting fan_mode through the device /get topic should process the returned hvacFanCtrl.fanMode value and update the Zigbee2MQTT MQTT state.

For example, when the thermostat is physically set to low and answers with:

{
  "fanMode": 1
}

Zigbee2MQTT should publish an updated state containing:

{
  "fan_mode": "low",
  "fan_state": "ON"
}

How to reproduce it (minimal and precise)

1. Pair a Sunricher SR-ZG9095B-0-10V thermostat with Zigbee2MQTT.
2. Set its fan mode to high through Zigbee2MQTT or Home Assistant.
3. Confirm that the physical thermostat changes to high.
4. Change the fan mode locally on the physical thermostat to low.
5. Observe that the thermostat display shows low, but Zigbee2MQTT continues to report high.
6. Publish the following MQTT request:

Topic:

zigbee2mqtt/DEVICE_FRIENDLY_NAME/get

Payload:

{
  "fan_mode": ""
}

7. Observe the Zigbee2MQTT debug log.

Zigbee2MQTT sends:

hvacFanCtrl.read(["fanMode"])

The thermostat responds:

Received Zigbee message from 'DEVICE_FRIENDLY_NAME',
type 'readResponse',
cluster 'hvacFanCtrl',
data '{"fanMode":1}'
from endpoint 1

Zigbee2MQTT then reports:

No converter available for 'SR-ZG9095B'
with cluster 'hvacFanCtrl'
and type 'readResponse'
and data '{"fanMode":1}'

The published MQTT state is not updated and still contains the old fan_mode.

Zigbee2MQTT version

2.12.1

Adapter firmware version

20240716

Adapter

SMLIGHT SLZB-06p10 with CC2674P10, connected over Ethernet/TCP using the zstack adapter

Setup

Zigbee2MQTT Home Assistant add-on running on Home Assistant OS x86-64.

Coordinator:

• Manufacturer: SMLIGHT
• Model: SLZB-06p10
• Zigbee chipset: CC2674P10
• Connection: Ethernet/LAN using TCP
• Zigbee2MQTT adapter driver: zstack
• SMLIGHT core firmware: v3.3.1
• Zigbee coordinator firmware: 20240716

Zigbee2MQTT communicates with the coordinator through a TCP connection rather than a local USB connection.

Device database.db entry

No response

Debug log

The device friendly name and IEEE address have been anonymized in this excerpt. No technically relevant content was changed.

[2026-07-31 11:41:17] debug: z2m:mqtt: Received MQTT message on 'zigbee2mqtt/DEVICE_FRIENDLY_NAME/get' with data '{"fan_mode": ""}'

[2026-07-31 11:41:17] debug: z2m: Publishing get 'get' 'fan_mode' to 'DEVICE_FRIENDLY_NAME'

[2026-07-31 11:41:17] debug: zh:controller:endpoint: ZCL command DEVICE_IEEE_ADDRESS/1 hvacFanCtrl.read(["fanMode"], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"writeUndiv":false})

[2026-07-31 11:41:17] debug: z2m: Received Zigbee message from 'DEVICE_FRIENDLY_NAME', type 'readResponse', cluster 'hvacFanCtrl', data '{"fanMode":1}' from endpoint 1 with groupID 0

[2026-07-31 11:41:17] debug: z2m: No converter available for 'SR-ZG9095B' with cluster 'hvacFanCtrl' and type 'readResponse' and data '{"fanMode":1}'

Away mode error:

[2026-07-31 11:58:23] debug: z2m: Publish 'set' 'away_mode' to 'DEVICE_FRIENDLY_NAME' failed: 'Error: ZCL command DEVICE_IEEE_ADDRESS/1 hvacThermostat.write({"8194":{"value":1,"type":48}}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"manufacturerCode":4644,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')'

Notes

Additional versions:

• zigbee-herdsman: 10.6.1
• zigbee-herdsman-converters: 26.76.0
• Thermostat software build ID: 6.10.3.0
• SMLIGHT core firmware: v3.3.1
• Zigbee coordinator firmware: 20240716

The thermostat exposes the hvacFanCtrl cluster on endpoint 1.

The debug log confirms that:

• Zigbee2MQTT sends the hvacFanCtrl.read(["fanMode"]) request.
• The thermostat responds successfully.
• The returned value matches the fan mode selected locally on the thermostat.
• Zigbee2MQTT receives the readResponse.
• Zigbee2MQTT does not process it because no matching converter is available for this device definition.

Possible cause:

The SR-ZG9095B definition appears to support writing and requesting fan_mode, but not processing incoming hvacFanCtrl messages.

Adding the standard fan fromZigbee converter to the device definition may solve the processing of read responses, for example:

fromZigbee: [
    // existing converters
    fz.fan,
]

I did not observe a spontaneous hvacFanCtrl attributeReport when changing the fan mode locally during this test.

For automatic updates after local operation, it may therefore also be necessary to bind the hvacFanCtrl cluster and configure reporting for fanMode, for example:

await reporting.bind(endpoint, coordinatorEndpoint, [
    // existing clusters
    "hvacFanCtrl",
]);

await reporting.fanMode(endpoint);

An initial read during device configuration may also be useful:

await endpoint.read("hvacFanCtrl", ["fanMode"]);

These code changes are only suggestions based on the observed debug output. I have not tested a modified converter.

Locate the SR-ZG9095B device definition and inspect its hvacFanCtrl handling, especially the fan_mode readResponse path. Compare it with the standard fan converter and review the existing configuration for reporting or reads. Done means the returned fanMode updates state and the away_mode behavior is verified against the device's supported attributes.