Changing SEA801 Thermostat setpoint - attr_write fails where GUI works fine

[B-D-M-C]

Hi,

I am trying to set the setpoint temperature of my Saswell SEA801-Z01 Zigbee thermostat.
(Reason: the setpoint is not exposed to Home Assistant in a way that would allow for automations to control it)

Through the GUI's "Manage Zigbee device" I can select and read as well as write the correct parameter:
Reading works nicely:

Writing too (confirmed, as the value changes visibly on the device itself):

Through the GUI "Developer tools" -> actions, I am using the zha_toolkit call to read the setpoint as follows:

action: zha_toolkit.execute
data:
  command: attr_read
  endpoint: 1
  cluster: 61184
  ieee: sensor.tze200_c88teujp_ts0601_32abcbfe_thermostat_hvac_action
  attribute: 615

with the following result:

zha_toolkit_version: v1.1.22
zigpy_version: 0.73.1
zigpy_rf_version: 0.42.5
ieee_org: sensor.tze200_c88teujp_ts0601_32abcbfe_thermostat_hvac_action
ieee: 5c:02:72:ff:fe:cd:ab:32
command: attr_read
command_data: null
start_time: "2024-12-23T10:44:21.863441+00:00"
errors: []
params:
  endpoint_id: 1
  cluster_id: 61184
  attr_id: 615
  dir: 0
  tries: 1
  expect_reply: true
  args: []
  kwargs: {}
  read_before_write: true
  read_after_write: true
attr_type: "0x23"
write_is_equal: false
result_read:
  - "615": 220
  - {}
success: true

But when I use the following to write a new value, I do get the same error no matter what:

action: zha_toolkit.execute
data:
  command: attr_write
  endpoint: 1
  cluster: 61184
  ieee: sensor.tze200_c88teujp_ts0601_32abcbfe_thermostat_hvac_action
  attribute: 615
  attr_val: "280"
  read_before_write: true
  read_after_write: true

with the following result:

zha_toolkit_version: v1.1.22
zigpy_version: 0.73.1
zigpy_rf_version: 0.42.5
ieee_org: sensor.tze200_c88teujp_ts0601_32abcbfe_thermostat_hvac_action
ieee: 5c:02:72:ff:fe:cd:ab:32
command: attr_write
command_data: null
start_time: "2024-12-23T10:50:32.023065+00:00"
errors: []
params:
  endpoint_id: 1
  cluster_id: 61184
  attr_id: 615
  attr_val: 280
  dir: 0
  tries: 1
  expect_reply: true
  args: []
  kwargs: {}
  read_before_write: true
  read_after_write: true
compare_val: 280
attr_type: "0x23"
write_is_equal: false
read_before:
  - "615": 220
  - {}
result_write:
  - - status: 134
      attrid: 615
result_read:
  - "615": 220
  - {}
success: false

As far as I understand, the error / status 134 means "unsupported attribute", but I do not change that attribute at all.
The write result even confirms the same attr_type = 0x23 (uint32) being used.
Manually setting it to the same type does not change the outcome. Setting a different type (33 == "0x21" == uint16) though generated an error message "type determined from read different from requested: 0x23 <> 0x267"
--> why it shows the new set type to be 0x267 I do not know! (This is the value from the attr_id ... it's a bug in the logging?)

It works with the GUI, so what am I doing wrong here?
Or could this be some sort of bug?

Any help is much appreciated.

[mdeweerd]

It's a manufacturer cluster and you probably need to set the manufacturer id as well in this case.

FYI: The GUI is provided by ZHA and while zha-toolkit uses zha it "hacks" into the API to bypass some limitations or autmatic settings - in this case that is likely the manufacturer id you need to set manually.

At some point this might have been added automatically, or when the manf argument has a certain value.

[B-D-M-C]

Thanks for the quick response.

Its the same problem and result when I use the alternative non-manufacturer (?) parameter as follows:
Cluster: ThermostatCluster (Endpoint id: 1, Id: 0x0201, Type: in)
Attribute: occupied_heating_setpoint (id: 0x0012)
attr_val: 2800

Do you know how I can find out the manf value I need to supply?

[mdeweerd]

You can do a device scan, an possibly find the details in the device information provided by ZHA (see 3 vertical dots).

(I am on a tight time schedule, so I can't check in detail).

[mdeweerd]

When you download the diagnostics for a device you'll fined "menufacturer_code" for devices in the json file:

  "data": {
    "ieee": "**REDACTED**",
    "nwk": 38757,
    "manufacturer": "_TZ3000_gbm10jnj",
    "model": "TS0043",
    "name": "_TZ3000_gbm10jnj TS0043",
    "quirk_applied": true,
    "quirk_class": "zhaquirks.tuya.ts0043.TuyaSmartRemote0043TO",
    "quirk_id": null,
    "manufacturer_code": 4098,

When you use zha-toolkit to perform a device scan, you'll also find the manufacturer code:

{
  "ieee": "f4:b3:b1:ff:fe:dd:77:28",
  "nwk": "0x7d7b",
  "model": "SIN-4-FP-21",
  "manufacturer": "NodOn",
  "manufacturer_id": "0x4747",

You can call the device scan from developer tools > services. The result will be shown in the UI and you can find a fie in the scans directory under config.

[MattWestb]

@mdeweerd The clusters (can being all or only some) on tuya MCU (or mixed real Zigbee and MCU) devices is virtual then all (MCU) commands is piped thru tuya cluster thru the quirks that ZHA have loaded for it to the MCU. Shall working OK but its little more between the normal standard Zigbee stuff and the tuya MCU.
And yes some of the devices need manufacture code in the frame (in the Zigbee network layer) but it shall being done of the quirk as can see in the screen shuts its not being used from ZHA GUI but it was working OK. If trying going around the quirk its need diving very deep in the rabbit hole for fixing all tuya abnormal things they have implemented.