Green Power: same frame (same srcID + frameCounter) published again ~137 s later when relayed by a second proxy (ZLinky router), follow-up to #33287

Open
  • Is something wrong?
#33,661 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
22/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
networking

Research direction

Start with the Green Power debug lines in the report, which show the same srcID and frameCounter arriving 137 s later via a second proxy (gppNwkAddr 61329). Then look at hasAlreadyProcessedMessage and its 10 s TTL, which the report links to zigbee-herdsman-converters commit 649dbaa, and at how zigbee-herdsman's greenpower controller passes frames through. Done would be a test where a repeated srcID and frameCounter arriving after the TTL is dropped. The fix needs maintainer agreement on how frame counters are stored, so treat this as a design-level discussion before writing code.

Written by the indexing model from the issue text.

Description

problem
What happened?

Hello,

I'm seeing the same problem as #33287 on a separate Z-Stack network. The reporter closed #33287 after a workaround (switching the ZLinky out of router mode), but the cause was never found.

One press on a Green Power switch is published to MQTT twice. The first publish is immediate. The second comes 136–137 s later, when the same GP frame (same srcID, same frameCounter) arrives again through a second GP proxy. As in #33287, that late proxy is a LiXee ZLinky_TIC running router firmware. In #33287 the delay was ~200 s.

Because of this, Home Assistant automations that toggle on the action run twice. In my case, a washing-machine plug switches off about 2 minutes after I turn it on.

Debug log for one press:

[2026-11-09 18:46:49] debug: z2m: Received Zigbee message from 'Inter GP - SDB', type 'commandNotification', cluster 'greenPower', data '{"commandFrame":{"raw":{"data":[2],"type":"Buffer"}},"commandID":105,"frameCounter":3475,"gppGpdLink":220,"gppNwkAddr":20817,"options":21664,"payloadSize":1,"srcID":22236731}' from endpoint 242 with groupID 2948
[2026-11-09 18:46:49] info:  z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Inter GP - SDB/action', payload 'press_2'
[2026-11-09 18:46:49] debug: z2m: Received Zigbee message from 'Inter GP - SDB', type 'commandNotification', cluster 'greenPower', data '{"commandFrame":{"raw":{"data":[0],"type":"Buffer"}},"commandID":106,"frameCounter":3476,"gppGpdLink":220,"gppNwkAddr":20817,"options":21664,"payloadSize":1,"srcID":22236731}' from endpoint 242 with groupID 2948
[2026-11-09 18:46:49] info:  z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Inter GP - SDB/action', payload 'release'

--- 137 s later, same frames via another proxy ---

[2026-11-09 18:49:06] debug: zh:controller:greenpower: [UNHANDLED_CMD/PASSTHROUGH] command=0x69 srcID=22236731 gpp=61329 rssi=28 linkQuality=Moderate
[2026-11-09 18:49:06] debug: z2m: Received Zigbee message from 'Inter GP - SDB', type 'commandNotification', cluster 'greenPower', data '{"commandFrame":{"raw":{"data":[2],"type":"Buffer"}},"commandID":105,"frameCounter":3475,"gppGpdLink":92,"gppNwkAddr":61329,"options":21664,"payloadSize":1,"srcID":22236731}' from endpoint 242 with groupID 2948
[2026-11-09 18:49:06] info:  z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Inter GP - SDB/action', payload 'press_2'
[2026-11-09 18:49:06] debug: z2m: Received Zigbee message from 'Inter GP - SDB', type 'commandNotification', cluster 'greenPower', data '{"commandFrame":{"raw":{"data":[0],"type":"Buffer"}},"commandID":106,"frameCounter":3476,"gppGpdLink":92,"gppNwkAddr":61329,"options":21664,"payloadSize":1,"srcID":22236731}' from endpoint 242 with groupID 2948
[2026-11-09 18:49:06] info:  z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Inter GP - SDB/action', payload 'release'
  • gppNwkAddr 20817 (0x5151) is the usual proxy (a router light), link 220. It forwards on time.
  • gppNwkAddr 61329 (0xEF91) is the ZLinky_TIC (router firmware), link 92. It forwards the same frames 137 s later.
  • options 21664 (0x54A0) means security level 2 (full frame counter + MIC), so frameCounter 3475/3476 had already been processed.

This is systematic. In one afternoon, 8 of 11 presses were published twice, always 136–137 s apart:

Real press Duplicate Delay
16:45:19 16:47:36 137 s
16:51:36 16:53:52 136 s
16:56:49 16:59:05 136 s
17:15:27 none
17:16:07 none
17:16:23 17:18:39 136 s
18:14:49 18:17:06 137 s
18:27:41 none
18:33:34 18:35:51 137 s
18:39:55 18:42:12 137 s
18:46:49 18:49:06 137 s
What did you expect to happen?

Z2M should drop a GP notification whose srcID + frameCounter it has already processed, whichever proxy forwards it and however late it arrives. As I understand the GP spec, a sink must discard GPD frames whose security frame counter is not greater than the last one accepted from that GPD.

In #33287 the reporter suspected the 10 s TTL added to hasAlreadyProcessedMessage (zigbee-herdsman-converters commit 649dbaa). A 137 s or 200 s delay falls outside that window. Keeping the last accepted frameCounter per GPD, with no TTL, would solve this.

The ZLinky forwarding this late is probably a problem in its own firmware. Still, Z2M should not publish a replayed frame as a new action.

How to reproduce it (minimal and precise)
  1. Z-Stack coordinator, with a Green Power switch paired.
  2. A ZLinky_TIC running router firmware, close enough to the switch to act as an extra GP proxy.
  3. Press a button once.
  4. On zigbee2mqtt/<device>/action, the same action is published again ~137 s later. The debug log shows the same frameCounter with a different gppNwkAddr.
Zigbee2MQTT version

2.14.2 (Home Assistant OS add-on), zigbee-herdsman 10.10.0. These are the same versions as #33287.

Adapter firmware version

CORE v3.3.1 , Radio 20240716

Adapter

SMLIGHT SLZB-06P7 (TI CC2652P7), Z-Stack, Ethernet/PoE, Z2M connects over TCP (tcp://<host>:6638).

Setup

Home Assistant OS 2026.10.4, Zigbee2MQTT add-on.

  • GP device: PTM 216Z
    ZLinky_TIC: router firmware, build 16. All logs above were captured on build 16. I'm now testing build 17 and will report whether the late re-forwarding still happens.
Device database.db entry

{"id":27,"type":"GreenPower","ieeeAddr":"0x0000000001534e3b","nwkAddr":20027,"modelId":"GreenPower_7","epList":[242],"endpoints":{"242":{"epId":242,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}}},"interviewCompleted":true,"interviewState":"SUCCESSFUL","meta":{},"lastSeen":1794246546986}

Debug log

z2m-gp-debug.log

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.