Koenkk / Koenkk/zigbee2mqtt

[TS0002 / _TZ3210_jqg2a5yn] ???

Open
#32,627 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

problem
Dominant language
TypeScript
Stars
15.7k
Forks
2k
Avg merge
18h 55m
Merged PRs (30d)
35

Description

What happened?

For the device:

  • Model: TS0002
  • Manufacturer: _TZ3210_jqg2a5yn
  • Firmware: 0x53013001

Setting power_on_behavior_l1 or power_on_behavior_l2 from Zigbee2MQTT fails with:

Status 'UNSUPPORTED_ATTRIBUTE'

The log shows that Zigbee2MQTT sends a manufacturer-specific write:

manuSpecificTuya3.write({"powerOnBehavior":2})

which is rejected by the device.

The device does support power-on behavior, but it uses the standard Zigbee OnOff cluster (genOnOff) attribute startUpOnOff (0x4003), not the Tuya manufacturer-specific attribute.

I verified this by:

  • Pairing the same device with ZHA, where power_on_behavior works correctly.
  • Capturing the ZHA debug log, which shows:
    WriteAttributes(cluster=0x0006, attrid=0x4003, value=StartUpOnOff.PreviousValue (255))
  • Using the Zigbee2MQTT Dev Console to manually execute:

Cluster: genOnOff
Write:
{
"startUpOnOff": 255
}

This succeeds immediately, confirming that the device supports the standard Zigbee attribute and that onl

What did you expect to happen?

Changing power_on_behavior_l1 or power_on_behavior_l2 should write the standard Zigbee genOnOff.startUpOnOff (attribute 0x4003) to the corresponding endpoint, as ZHA does, instead of using manuSpecificTuya3.powerOnBehavior.

How to reproduce it (minimal and precise)
  1. Pair a TS0002 switch with manufacturer _TZ3210_jqg2a5yn.
  2. Open the device page in Zigbee2MQTT.
  3. Change power_on_behavior_l1 or power_on_behavior_l2 to any value (e.g. previous).
  4. Observe the failure:

Publish 'set' 'power_on_behavior' failed:
ZCL command ... manuSpecificTuya3.write({"powerOnBehavior":2}) failed (Status 'UNSUPPORTED_ATTRIBUTE')

For comparison:

  • Writing genOnOff.startUpOnOff = 255 from the Zigbee2MQTT Dev Console succeeds.
  • The same device also works correctly in ZHA using the standard genOnOff attribute.
Zigbee2MQTT version

2.12.1 (unknown)

Adapter firmware version

{"build":397,"ezsp":14,"major":8,"minor":0,"patch":2,"revision":"8.0.2 [GA]","special":0,"type":170}

Adapter

EmberZNet

Setup

os: #1 SMP PREEMPT_DYNAMIC Wed Jul 1 07:31:17 UTC 2026 - 6.18.37-haos - x64
node: v22.23.0
ha: true

Device database.db entry

No response

Debug log

No response

Notes
Device

definition: TS0002 - Tuya (v0.0.0)
software_build_id: undefined
date_code: undefined
endpoints:

{"1":{"bindings":[{"cluster":"genOnOff","target":{"endpoint":1,"ieee_address":"0xc02cedfffeee4c82","type":"endpoint"}}],"clusters":{"input":["genBasic","genIdentify","genGroups","genScenes","genOnOff","manuSpecificTuya4","manuSpecificTuya3"],"output":["genOta","genTime"]},"configured_reportings":[],"name":"l1","scenes":[]},"2":{"bindings":[],"clusters":{"input":["genGroups","genScenes","genOnOff","manuSpecificTuya4","manuSpecificTuya3"],"output":[]},"configured_reportings":[],"name":"l2","scenes":[]},"242":{"bindings":[],"clusters":{"input":[],"output":["greenPower"]},"configured_reportings":[],"scenes":[]}}
Health

time: Tue Jul 21 2026 22:15:29 GMT-0300 (Horário Padrão de Brasília)
os.load_average: 0, 0.03, 0
os.memory_percent: 32.9374
process.memory_percent: 3.7003
process.uptime_sec: 1804

{"leave_count":0,"messages":80,"messages_per_sec":0.0458,"network_address_changes":0}

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the TS0002 device definition and the handling for power_on_behavior_l1 and power_on_behavior_l2. Compare the current manuSpecificTuya3 write with the reported working genOnOff.startUpOnOff attribute 0x4003, then verify that changing either setting succeeds on the corresponding endpoint.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
embedded-iot
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.