SDKv3 Zigbee Device (ZigbeeDevice) Fails to Initialize (onNodeInit/Constructor Not Called) After Successful Driver Match via CLI run --remote (ID Lock / Datek)

Developers
, , ,
1

Technical Report: ZigbeeDevice Initialization Failure for ID Lock/Datek Module (SDK v3)

Overview Issue: ZigbeeDevice class initialization (constructor/onNodeInit) fails silently after successful driver match App: ID Lock Zigbee Integration (GitHub - ArnBdev/idlock-zigbee: Homey Zigbee app for ID Lock) Date: 2025-04-13 16:37:30 UTC Environment: Homey Pro (Early 2023), FW ≥10.x

Environment Details

  • Homey: Pro (Early 2023)
  • Firmware: ≥10.x
  • Development Environment:
    • OS: Windows 11 Pro with WSL 2 (Ubuntu 24.04.2 LTS)
    • Node.js: v18.20.8 LTS (via NVM)
    • Docker: v4.40.0 (Engine v28.0.4)
    • Homey CLI: Latest (globally installed in WSL)
  • Key Dependencies:
    • homey-zigbeedriver: v2.1.5
    • zigbee-clusters: Present (peer dependency)

Device Information

  • Manufacturer: Datek
  • Model: ID Lock 150
  • Endpoint 1 Server Clusters: [0, 1, 3, 257]
  • receiveWhenIdle: false
  • swBuildId: “0.7”

Current Implementation

app.json (relevant section):

JSON

{
  "zigbee": {
    "manufacturerName": "Datek",
    "modelId": ["ID Lock 150", "ID Lock 202"],
    "productId": ["ID Lock 150", "ID Lock 202"],
    "deviceId": 10,
    "profileId": 260,
    "endpoints": {
      "1": {
        "clusters": [0, 1, 3, 257],
        "bindings": [1, 257]
      }
    }
  }
}

device.js:

JavaScript

'use strict';

const { debug } = require('zigbee-clusters');
debug(true); 

const { ZigbeeDevice, CLUSTER } = require('homey-zigbeedriver');

function zigbeeLockStateToHomeyLockedState(lockState) {
    const isLocked = (lockState === 1);
    return isLocked;
}

class IdLockZigbeeDeviceInstance extends ZigbeeDevice {
    constructor(...args) { 
        super(...args);
        this.log('CONSTRUCTOR CALLED - Device instance created'); 
    }

    async onNodeInit({ zclNode }) {
        this.log('STEP 1: Starting onNodeInit...');
        try {
            this.printNode();
            this.log(`Device info: Mfr: ${this.getManufacturerName()}, Model: ${this.getModelId()}`);
        } catch (error) {
            this.error('Initialization error:', error);
        }
    }
}

module.exports = IdLockZigbeeDeviceInstance;

Issue Description

Symptoms:

  1. Driver matching works correctly (device is recognized)
  2. After successful match, no logs appear from:
  • Constructor
  • onNodeInit
  • zigbee-clusters debug output
  1. Homey mobile app either:
  • Hangs on “adding device…” (“takes longer than usual”)
  • Adds non-functional device tile

Troubleshooting Steps Taken:

  1. Environment Verification:
  • Clean WSL 2 environment
  • Node.js v18.20.8 LTS via NVM
  • Fresh npm install with latest compatible dependencies
  • Verified zigbee-clusters peer dependency
  1. Code Simplification:
  • Reduced onNodeInit to basic logging
  • Removed all active communication calls
  • Added extensive debug logging
  • Simplified capability registration
  1. Test Methods:
  • homey app run --remote
  • homey app run (Docker)
  • Both methods fail at the same point
  1. Debug Attempts:
  • Enabled zigbee-clusters debugging
  • Monitored Homey System Logs
  • Added constructor logging
  • Added process-level error handlers

Key Observations:

  1. Driver match succeeds (verified in Dev Tools)
  2. No logs from constructor or onNodeInit appear
  3. No errors in Homey System Logs
  4. Issue persists across both remote and Docker execution
  5. Problem occurs before any user code execution

Technical Questions:

  1. What SDK/platform events should occur between driver match and ZigbeeDevice instantiation?
  2. Are there known issues with homey-zigbeedriver v2.1.5 and devices reporting receiveWhenIdle: false?
  3. Could the Zigbee interview process be failing silently due to the device’s specific signature?
  4. Are there additional debug flags or diagnostics available for the device initialization phase?

Request for Assistance:

  1. Guidance on additional debugging methods for the initialization phase
  2. Known issues with similar device signatures
  3. Possible workarounds or alternative initialization approaches
  4. SDK team input on the silent failure between driver match and class instantiation

Technical Contact:

Thank you for any assistance in resolving this initialization issue.