TS011F / _TZ3210_fgwhjm9j firmware 1.1.3 (83): electrical report loop ~5 Hz, same ZCL sequence and increasing APS sequence

Open
  • Is something wrong?
#33,671 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
backend, networking

Research direction

Start by comparing the repeated incoming cluster 0x0B04 reports and decoded ZCL frames in the issue with the related zigpy issue #939; the payload does not identify a Zigbee2MQTT source file or test. Investigate how incoming attribute reports and default responses are handled, then determine whether the evidence supports a safe recovery or firmware fix. Done means identifying a cause and a reproducible fix or documented recovery; the trigger and acknowledgement behavior remain unconfirmed.

Written by the indexing model from the issue text.

Description

problem
What happened?

One TS011F_plug_1 / _TZ3210_fgwhjm9j plug repeatedly sends an unchanged haElectricalMeasurement attributeReport at approximately 5 Hz. Device firmware ID: 1.1.3; reported OTA version: 83 (0x53). The ZCL transaction sequence stays at 253 while the APS sequence increments. This is incoming Zigbee traffic, not just repeated dashboard rendering.

Observed on 11 November 2026. In complete minutes 11:45–11:58 GMT, the affected plug generated 295–300 MQTT state publications per minute. Earlier debug logs show identical reports about 200 ms apart. The electrical report contains rmsVoltage=239, rmsCurrent=0, activePower=0, requests a default response, and parses successfully.

Checks already made
  • Reconfigure completed successfully, without stopping the loop.
  • Temporarily changed minimum reporting intervals from 5 to 30 seconds (maximum 3600), preserving/correcting voltage/current/power changes to 5/50/10. Commands succeeded but traffic persisted (306 publications in 11:40). Original reporting settings were restored.
  • The cooling automation does not poll the electrical measurements at 5 Hz.
  • No physical mains power cycle has yet been performed. Switching the output relay is not equivalent to rebooting the plug electronics.
  • No development-branch test or coordinator restart has been performed on this production system.
Inventory comparison (19 Zigbee smart plugs)
Device family / reported firmware Count Evidence in this sample
TS011F_plug_1, _TZ3210_fgwhjm9j, version 83 12 One confirmed report loop; the other eleven did not show comparable traffic
Same TS011F variant, numeric version unavailable (-1 or Not assessed) 5 No comparable loop observed; two expose firmware ID 1.1.3, three no firmware ID
Girier JR-ZPM03, _TZ3000_okaz9tjs, firmware 500+TZSKT31BS104, date code 20210625 2 No comparable loop observed

Across the same 11:44:38–11:59:22 log window, all other 18 plugs had at most 9 publications in any minute (usually 0–5; Girier plugs about 2–3). MQTT publication counts are a screening measure, not a count of every radio frame. No claim that all version-83 devices are faulty, or that other versions cannot be affected. The only firmware confirmed affected by this exact repeated-ZCL-sequence loop here is 1.1.3 / 83.

Possible relation, not a proven diagnosis

https://github.com/zigpy/zha/issues/939 describes the same repeated-ZCL / increasing-APS pattern on a different TS011F manufacturer and firmware. https://github.com/Koenkk/zigbee2mqtt/issues/33174 concerns malformed cluster 0xE000 reports; ours are valid cluster 0x0B04 reports, so it may be a different cause.

Could default-response deduplication leave this device retrying indefinitely if an earlier response is lost, and is there a safe software recovery or known firmware fix for _TZ3210_fgwhjm9j? The captured excerpt alone does not prove a missing acknowledgement or establish firmware as the sole cause. No matching outbound response was found in the short retained debug sample, but the original response may predate it. Thank you.

What did you expect to happen?

Normal bounded attribute reporting that respects the configured reporting interval, without indefinitely repeating the same ZCL report.

How to reproduce it (minimal and precise)

The original trigger is unknown. Once the device enters this state, passively observe debug logs: identical cluster 0x0B04 reports recur about every 200 ms, keeping ZCL transaction 253 but incrementing APS sequence. Reconfiguration and a 30-second minimum reporting trial did not stop it. Physical power-cycle recovery remains untested.

Zigbee2MQTT version

2.14.3 (HA add-on 2.14.3-1); herdsman 11.2.0; converters 26.125.0

Adapter firmware version

8.2.2 [GA], build 436, EZSP 18

Adapter

SONOFF ZBDongle-E, EmberZNet / ember driver

Setup

Home Assistant add-on on x86-64 HAOS VM under Proxmox. Z2M About reports Linux 6.18.58-haos, #1 SMP PREEMPT_DYNAMIC Tue Oct 27 13:48:56 UTC 2026; Node v24.22.1. 86 Zigbee devices, including 19 smart plugs.

Device database.db entry

No response

Debug log

Sanitised log excerpt (device addresses omitted):

[2026-11-11 11:39:02] zh:ember:ezsp: ezspIncomingMessageHandler type=UNICAST profileId=260 clusterId=2820 sourceEndpoint=1 destinationEndpoint=1 APS sequence=65 lastHopLqi=144 lastHopRssi=-75 lastHopTimestamp=2214039573 messageContents=08fd0a050521ef0008052100000b05290000
[2026-11-11 11:39:02] zh:ember:ezsp: ezspIncomingMessageHandler type=UNICAST profileId=260 clusterId=2820 sourceEndpoint=1 destinationEndpoint=1 APS sequence=66 lastHopLqi=144 lastHopRssi=-75 lastHopTimestamp=2214239975 messageContents=08fd0a050521ef0008052100000b05290000
[2026-11-11 11:39:02] zh:ember:ezsp: ezspIncomingMessageHandler type=UNICAST profileId=260 clusterId=2820 sourceEndpoint=1 destinationEndpoint=1 APS sequence=67 lastHopLqi=144 lastHopRssi=-75 lastHopTimestamp=2214440359 messageContents=08fd0a050521ef0008052100000b05290000

Decoded controller frame (same in each case):

{"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"transactionSequenceNumber":253,"commandIdentifier":10},"payload":[{"attrId":1285,"dataType":33,"attrData":239},{"attrId":1288,"dataType":33,"attrData":0},{"attrId":1291,"dataType":41,"attrData":0}],"command":{"name":"report","ID":10}}
Notes

No response

Dominant language
TypeScript
Stars
15.8k
Forks
2.1k
Avg merge
1d 6h
Merged PRs (30d)
38

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

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.

More from Koenkk/zigbee2mqtt

All issues in Koenkk/zigbee2mqtt

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.