Koenkk / Koenkk/zigbee2mqtt

Legrand 064884 Wireless control sleep / wakeup

Open
#32,788 3 comments 1 reaction 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?

What happened?

After upgrading Zigbee2MQTT from 2.11.0 to 2.13.0, a previously working Legrand "Remote switch Wake up / Sleep" (commercial ref. 064884, Zigbee model 752189) stopped publishing action events on button press.

  • Before the upgrade (2.11.0): both buttons correctly published action: "sleep" / action: "wakeup".

  • Immediately after the upgrade to 2.13.0: pressing either button produced no action in the MQTT payload. Only device metadata (battery/device info/linkquality) was republished, and pressing the bottom button also triggered a full network rejoin (ezspTrustCenterJoinHandler status=STANDARD_SECURITY_SECURED_REJOIN) instead of a lightweight check-in.

  • The device's health stats showed leave_count: 1 for this device, and its network address had changed (1747360029 / 0xEA7D) between the original pairing log and the current state — consistent with the device having dropped off and rejoined the network around the time of the upgrade.

  • Debug logs at the moment of a button press only showed a genPollCtrl commandCheckin (standard end-device wake-up poll) and a device_announce — never any command tied to the actual button click, on either manuSpecificLegrandDevices or genOnOff.

Workaround found

Adding a local external converter (data/external_converters/legrand_064884.js) that re-declares the same fromZigbee converters as the built-in definition, but with an explicit configure() step forcing a fresh bind:

const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
const tz = require('zigbee-herdsman-converters/converters/toZigbee');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const reporting = require('zigbee-herdsman-converters/lib/reporting');
const e = exposes.presets;
const ea = exposes.access;

const definition = {
    zigbeeModel: ['752189'],
    model: '064884',
    vendor: 'Legrand',
    description: 'Commande sans fil Lever / Coucher',
    fromZigbee: [fz.command_on, fz.command_off, fz.legrand_master_switch, fz.battery],
    toZigbee: [],
    exposes: [
        e.action(['sleep', 'wakeup', 'on', 'off']),
        e.battery(),
    ],
    configure: async (device, coordinatorEndpoint, logger) => {
        const endpoint = device.getEndpoint(1);
        await reporting.bind(endpoint, coordinatorEndpoint, ['genOnOff', 'genPowerCfg', 'manuSpecificLegrandDevices']);
    },
};

module.exports = definition;

Loading this external converter (which triggers configure() again on the device) immediately fixed the issue — both buttons now correctly publish action: "sleep" / action: "wakeup".

This points to a stale/broken bind on the device after it rejoined the network during/after the upgrade, rather than an issue with action decoding itself, since the exact same fromZigbee logic works once the bind is redone.

What did you expect to happen?

The device should keep publishing button actions across the upgrade, or at least automatically recover a working bind after a network rejoin, without requiring a manual external converter as a workaround.

How to reproduce it (minimal and precise)

  1. Pair a Legrand 752189 (Remote switch Wake up/Sleep, commercial ref 064884) on Zigbee2MQTT 2.11.0. Confirm action: sleep/wakeup works on button press.
  2. Upgrade Zigbee2MQTT to 2.13.0.
  3. Press either button and observe that no action is published — only device metadata / device_announce, and in debug logs, only a genPollCtrl.commandCheckin is decoded.

Zigbee2MQTT version

2.13.0 (regression from 2.11.0)

Adapter firmware version

Ember (EZSP), coordinator via /dev/ttyUSB0, adapter: ember

Adapter

Ember (EmberZNet / EZSP-based coordinator)

Debug log

[2026-08-07 18:16:30] debug:    zh:ember:ezsp: ezspTrustCenterJoinHandler: newNodeId=17473 newNodeEui64=0x0004740000c3130c status=STANDARD_SECURITY_SECURED_REJOIN policyDecision=NO_ACTION parentOfNewNodeId=11404
[2026-08-07 18:16:30] debug:    zh:controller: Device '0x0004740000c3130c' joined
[2026-08-07 18:16:30] debug:    zh:controller: Device '0x0004740000c3130c' accepted by handler
[2026-08-07 18:16:30] debug:    zh:controller: Not interviewing '0x0004740000c3130c', interviewState=SUCCESSFUL'
[2026-08-07 18:16:30] debug:    zh:controller:device: check-in from 0x0004740000c3130c: declining fast-poll
[2026-08-07 18:16:30] debug:    zh:controller:endpoint: ZCL command 0x0004740000c3130c/1 genPollCtrl.checkinRsp(...)
[2026-08-07 18:16:30] debug:    z2m: Received Zigbee message from '0x0004740000c3130c', type 'commandCheckin', cluster 'genPollCtrl', data '{}' from endpoint 1 with groupID 0
[2026-08-07 18:16:30] debug:    zh:controller: Received ZDO response: clusterId=END_DEVICE_ANNOUNCE, status=SUCCESS, payload={"nwkAddress":17473,"eui64":"0x0004740000c3130c", ...}
[2026-08-07 18:16:30] debug:    zh:controller: Device announce from '0x0004740000c3130c:17473'
[2026-08-07 18:16:30] debug:    z2m: Device '0x0004740000c3130c' announced itself
[2026-08-07 18:16:32] debug:    z2m: Retrieving state of '0x0004740000c3130c' after reconnect

No manuSpecificLegrandDevices or genOnOff command was ever decoded for the actual button press, before the workaround was applied.

What did you expect to happen?

No response

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

2.13.0

Adapter firmware version

Révision: 7.4.4 [GA] EmberZNet

Adapter

EmberZNet

Setup

#86009 SMP Wed Nov 26 18:19:17 CST 2025 - 4.4.302+ - x64
CPU: Intel(R) Celeron(R) J4025 CPU @ 2.00GHz (x2)
RAM: 5776 MB

Device database.db entry
{"id":50,"type":"EndDevice","ieeeAddr":"0x0004740000c3130c","nwkAddr":60029,"manufId":4129,"manufName":" Legrand\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000","powerSource":"Battery","modelId":" Remote switch Wake up / Sleep\u0000","epList":[1],"endpoints":{"1":{"profId":260,"epId":1,"devId":6,"inClusterList":[0,3,32,1,15,64513],"outClusterList":[5,3,0,25],"clusters":{"genBasic":{"attributes":{"modelId":" Remote switch Wake up / Sleep\u0000","manufacturerName":" Legrand\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000","powerSource":3,"zclVersion":8,"appVersion":0,"stackVersion":69,"hwVersion":7,"dateCode":" \u000020210525\u0000\u0000\u0000\u0000\u0000","swBuildId":"0052"}},"genPollCtrl":{"attributes":{"checkinInterval":144000}}},"binds":[{"cluster":32,"type":"endpoint","deviceIeeeAddress":"0x08b95ffffed8a948","endpointID":1}],"configuredReportings":[],"meta":{}}},"appVersion":0,"stackVersion":69,"hwVersion":7,"dateCode":" \u000020210525\u0000\u0000\u0000\u0000\u0000","swBuildId":"0052","zclVersion":8,"interviewCompleted":true,"interviewState":"SUCCESSFUL","meta":{},"lastSeen":1786209583240,"checkinInterval":36000}
Debug log

No response

Notes

(https://www.legrand.fr/pro/catalogue/commande-sans-fils-2-scenarios-levercoucher-pour-installation-connectee-celiane-with-netatmo-blanc-sans-plaque)

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 with data/external_converters/legrand_064884.js and compare its explicit configure() binding with the built-in Legrand 064884 definition. Reproduce the 2.11.0-to-2.13.0 upgrade and rejoin sequence, then inspect the binding and device-rejoin flow. Done means the device reliably publishes sleep/wakeup actions after the upgrade without requiring an external converter.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
embedded-iot
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.