Unable to Pair Legrand Wireless Remote Switch (067773) with Homey Pro

Developers
1

Hello everyone,

I am encountering difficulties pairing the Legrand Wireless Remote Switch (model 067773) with my Homey Pro. The device works perfectly on Zigbee2MQTT and Zigbee Home Assistant, but on Homey, the pairing process consistently fails with a timeout and no logs are generated.

Device Details

Here are the details retrieved via Zigbee2MQTT:

  1. 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"

  2. modelId:

    " Remote switch\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000"

  3. Supported Clusters:

    • genBasic (0)
    • genOnOff (6)
    • genLevelCtrl (8)

  4. Endpoint Used:

    • Endpoint: 1

Current Configuration

driver.compose.json

{
  "id": "wireless_remote_switch",
  "name": {
    "en": "Wireless Remote Switch"
  },
  "class": "sensor",
  "capabilities": [
    "button"
  ],
  "zigbee": {
    "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",
    "modelId": [
      " Remote switch\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000"
    ],
    "endpoints": {
      "1": {
        "clusters": [
          0,
          6,
          8
        ]
      }
    },
    "learnmode": true
  }
}

driver.js

'use strict';

const { ZigBeeDevice } = require('homey-zigbeedriver');

class WirelessRemoteSwitch extends ZigBeeDevice {
  async onNodeInit({ zclNode }) {
    this.log('Device initialized');
    
    // Handle ON/OFF commands
    this.registerClusterListener(6, 'on', this._onCommandOn.bind(this));
    this.registerClusterListener(6, 'off', this._onCommandOff.bind(this));
  }

  _onCommandOn() {
    this.log('Command ON received');
  }

  _onCommandOff() {
    this.log('Command OFF received');
  }
}

module.exports = WirelessRemoteSwitch;

Problem

  • Timeout during pairing: The device fails to complete the pairing process with Homey and consistently times out.
  • No logs generated: No logs appear in the CLI (homey app run) during the pairing process.
  • Works on other platforms: The device works perfectly on Zigbee2MQTT and Zigbee Home Assistant, confirming it is fully functional.

What I Need

  1. Confirmation on whether the fields manufacturerName and modelId need to include the exact non-printable characters (\u0000).
  2. Suggestions on diagnosing why pairing fails on Homey while it works on other Zigbee platforms.
  3. Any methods to capture more detailed information about the pairing process in Homey (e.g., logs, debug mode).

Thank you in advance for your help! Any suggestions or advice are greatly appreciated.

2

My guess is that this is related to the NUL characters (which are typically used as end-of-string markers in C/C++, so I’m thinking that one of the Zigbee drivers might be truncating the strings, or the backend is simply unable to handle the NUL’s).

The only thing you can try is to enable Zigbee debugging, which is explained here: Zigbee | Homey Apps SDK

There are not other logfiles available, if the debugging doesn’t yield a solution (which it probably won’t) you’ll have to contact Athom (you can try the #developers channel on Slack: https://slack.athom.com/ although my experience is that most bugs posted there end up being lost somewhere).

3

Are you using the Zigbee2MQTT App for Homey | Homey app? Would work most likely directly with it.

4

It looks like they’re trying to develop a Homey app for the device.

5

I’ve used Zigbee2MQTT before, but I aim to develop a direct integration without relying on Zigbee2MQTT. I’ve tested a direct link with Philips Hue, but the response time has a latency of 1 to 2 seconds, which makes it far from smooth and responsive

1 Like
6

Some more info here: Add support to Legrand Netatmo devices · Issue #2399 · Koenkk/zigbee2mqtt · GitHub

These devices seem to require some specific responses to be sent back from the controller during the pairing process, and if it doesn’t receive such a response (or an incorrect one), the device will remove itself from the network (and, hence, can’t be paired). See this code.

I don’t think it’s possible for Homey apps to implement these types of specific responses. The Aqara app also required something similar (or at least that’s how I understood how it worked at the time) and it required changes to Homey’s core Zigbee handling to be able to make it work. Homey doesn’t have a full Zigbee implementation, nor does it allow apps to do low-level things, as opposed to z2m.

1 Like
7

Screenshot 2024-12-08 at 16.20.54
Screenshot 2024-12-08 at 16.20.54508×445 23.2 KB

I’ve already tried enabling Zigbee debugging, but unfortunately, no logs were generated. From my understanding, Homey typically uses a generic driver if it doesn’t find a specific one. However, in this case, I’m experiencing a timeout, and the switch isn’t added. The issue seems related to managing the PollControl cluster, as the switch is battery-powered. Here’s a related GitHub issue dating back to 2021: GitHub Issue #196

8

See my previous post, your device is probably disconnecting from the network itself because it’s not getting the correct response on a particular request.

9

Thank you for your help! the issue is that the call needs to happen during the pairing process. the onPair method hasn’t been called yet when adding the button, which prevents the correct response from being sent at the right time

10

Yes, that’s what it sounds like. Like I said, it’s not possible for Homey apps to implement this, it has to be done on a lower level. The reason this was done for Aqara is because that is/was a popular brand amongst Homey users, and not implementing the Aqara-specific pairing code meant that the newer Aqara devices wouldn’t be able to pair with Homey.

All you can do is open an issue on Github about this (and then probably never get an answer, like with many issues).

1 Like
11

The SDK is not open source, which is very disappointing to me. It limits the ability for the community to contribute fixes or improvements for cases like this. It’s frustrating that we can’t address these issues directly, especially when they impact device compatibility. Thank you very much!