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

Aperta
  • Qualcosa non va?
#33,671 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
backend, networking

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
TypeScript
Stelle
15.8k
Fork
2.1k
Merge medio
1g 6h
PR unite (30g)
38

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Koenkk/zigbee2mqtt

Tutte le issue di Koenkk/zigbee2mqtt

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.