Commands for Sonoff ZBDongle-E to enable join of a SNZB-02P sensor

[Andrew-io]

Hi all,

I'm writing a minimal library with NodeJs to interface with zigbee devices via a USB ZBDongle-E (in short the junior version of the zigbee-herdsman :D ). I'm following the Silicon Labs documentation and I've reached a good point, that is, I can send and receive commands on the serial-usb and use some of the functions of the EmberZNet Serial Protocol: I can create a zigbee network as a coordinator and start the PermitJoin of the devices. The problem is that once the pairing mode is started I can't connect the SNZB-02P sensor (I don't see frames arriving from the sensor). I'm probably doing some wrong configuration of the EmberZNet protocol. Could someone help me? I'll share the parameters I use for formNetwork. Thanks

[Andrew-io]

Hello,
I'm updating this thread by tagging a person who I hope can help me: @Nerivec forgive me for tagging, I know you've made a big contribution to the zigbee-herdsman with the Ember Znet part. I would kindly need your support (as I wrote in the previous post) to have the correct sequence of commands to send to a ZBDongle-E with Ember Znet to form a simple star network and allow the joining of a SNZB-02P temp-humidity sensor.
Can you help me? I just need to receive the command sequence (command id) and a real example of parameters to pass to them. Unfortunately, the Silicon Labs documentation provides the specification of the commands, but does not give examples of how to actually form a network.

[Nerivec]

As mentioned before, [0x00-0xff], with 0x00=disable, 0xff=forever.

[Andrew-io]

thank you. May I kindly ask you for help on 2 things:

1. On the frame incomingMessageHandler there is wrong messageLength

{
  header: {
    isLegacy: false,
    sequence: 33,
    frameId: 69,
    frameIdHex: '0x0045', // => incomingMessageHandler
    isResponse: true,
    networkIndex: 0,
    sleepMode: null,
    overflow: false,
    truncated: false,
    callbackPending: false,
    callbackType: 'async',
    hb_securityEnabled: false,
    hb_paddingEnabled: false,
    hb_frameFormatVersion: 1
  },
  parameter: [
     4,   0,   0,  19,   0,   0,   0,   0,   4,
     0,   0,  88, 255, 237, 250, 239, 255, 255,
    12, 129, 250, 239, 254,  46,  56, 254, 255,
    18,  39, 132, 128,   2
  ],
  rawData: [
     33, 144,   1,  69,   0,  4,   0,   0,  19,
      0,   0,   0,   0,   4,  0,   0,  88, 255,
    237, 250, 239, 255, 255, 12, 129, 250, 239,
    254,  46,  56, 254, 255, 18,  39, 132, 128,
      2
  ],
  parsed: {}
}

the length byte says 12, but there are 13 bytes after it (what's the final 2?). Right?

2. Where can I find documentation on how to interpret the messageContents bytes of the SNZB-02P sensor? I didn't find this acronym in your code, is there a standard way to interpret the messageContents bytes?

[Nerivec]

1. check your parsing logic (that you didn't skip a byte before or something).
2. like I said, that's ZCL/ZDO specification. Note: implementing this is a massive task.

[Andrew-io]

Hi,

UART Frame

{
  ctrlByte: 82,
  rawBytes: [
     82,  99, 177, 169,  17,  42,  21, 182,  88,
    141,  74,  36, 171,  85, 147,  73, 156, 223,
    216,  66, 172, 141, 152, 116, 241, 215,  82,
    136, 252, 248,  45, 160, 227, 205, 255, 111,
    143, 253,  10, 152, 126
  ],
  type: 'DATA',
  checkOk: true,
  data: [
    33, 144,   1, 69,  0,  0,   4,   1,  25,  0,
     1,   1,   0,  1,  0,  0, 145, 255, 233, 65,
    67, 255, 255, 12, 17, 49,   1,   0, 134, 18,
     7,   8,   0, 33,  0,  0,   2
  ],
  calcCrc: [ 10, 152 ],
  ackNum: 2,
  frNum: 5,
  reTx: 0
}

The CRC is OK and also Byte Stuffing and Data randomization they should be OK.

Parsed for EZSP

{
  header: {
    isLegacy: false,
    sequence: 33,
    frameId: 69,
    frameIdHex: '0x0045',
    isResponse: true,
    networkIndex: 0,
    sleepMode: null,
    overflow: false,
    truncated: false,
    callbackPending: false,
    callbackType: 'async',
    hb_securityEnabled: false,
    hb_paddingEnabled: false,
    hb_frameFormatVersion: 1
  },
  parameter: [
     0,  4,   1,  25,   0,   1,  1,   0,   1,
     0,  0, 145, 255, 233,  65, 67, 255, 255,
    12, 17,  49,   1,   0, 134, 18,   7,   8,
     0, 33,   0,   0,   2
  ],
  rawData: [
    33, 144,   1, 69,  0,  0,   4,   1,  25,  0,
     1,   1,   0,  1,  0,  0, 145, 255, 233, 65,
    67, 255, 255, 12, 17, 49,   1,   0, 134, 18,
     7,   8,   0, 33,  0,  0,   2
  ],
  parsed: {
    name: 'incomingMessageHandler',
    messageType: 'EMBER_INCOMING_UNICAST',
    aps_profileId: '0x0104',
    aps_clusterId: '0x0019',
    aps_sourceEndpoint: 1,
    aps_destinationEndpoint: 1,
    aps_options: '0x0100',
    aps_groupId: '0x0000',
    aps_sequence: 145,
    lastHopLqi: 255,
    rssi: -23,
    sender: '0x4341',
    bindingIndex: 255,
    addressIndex: 255,
    messageLength: 12,
    messageContents: [
      255, 12, 17, 49, 1,  0,
      134, 18,  7,  8, 0, 33,
        0,  0,  2
    ]
  }
}

What do you say? messageContents it has wrong length : ( .... Help please

[Nerivec]

https://github.com/Koenkk/zigbee-herdsman/blob/97b8dc0afa1ebb6b0079cefd82049ecef3991023/src/adapter/ember/ezsp/ezsp.ts#L763

[Andrew-io]

Hi @Nerivec,

I'm sorry I asked you for help many times for errors that I could have solved by myself. I deleted the previous messages because they were useless and partially solved. I'm getting familiar with the zigbee protocol and the devices, but I still haven't reached my goal: that is, receiving humidity and temperature from the sensor.
There are still some unresolved doubts:

• Often when I start my sw and activate the sensor in join I receive an indefinite list of callbacks trustCenterJoinHandler: EMBER_STANDARD_SECURITY_UNSECURED_JOIN. I think it depends on the fact that the sensor keeps the keys of the old network in memory, while I start a new one (after a few reboots it seems to do the join)

• I see that the zigbeeKeyEstablishmentHandler callback responds with EMBER_APPLICATION_ERROR_14/EMBER_APPLICATION_ERROR_15 what could it depend on? How can I solve it?

For example:

>> zigbeeKeyEstablishmentHandler: EMBER_APPLICATION_ERROR_14, nodeEui64:254,46,56,254,255,18,39,132
>> zigbeeKeyEstablishmentHandler: EMBER_APPLICATION_ERROR_14, nodeEui64:254,46,56,254,255,18,39,132
>> zigbeeKeyEstablishmentHandler: EMBER_APPLICATION_ERROR_15, nodeEui64:255,255,255,255,255,255,255,255

• Even if there are 13 bytes in the ZCL message while the messageLength=12, I will read only 12 bytes (the thirteenth byte is always 2).

• When the join procedure is completed, after the first data exchange frames, the sensor sends a series of OTA update request messages (I have now decoded the data correctly, I hope). I imagine that if I reply to the device that there are no updates, then it will send me the humidity and temperature values? I will find out as soon as I implement the response for the OTA

My last frame decode:

{
    "header": {
        "isLegacy": false,
        "sequence": 32,
        "frameId": 69,
        "frameIdHex": "0x0045",
        "isResponse": true,
        "networkIndex": 0,
        "sleepMode": null,
        "overflow": false,
        "truncated": false,
        "callbackPending": false,
        "callbackType": "async",
        "hb_securityEnabled": false,
        "hb_paddingEnabled": false,
        "hb_frameFormatVersion": 1
    },
    "parameter": [0, 4, 1, 25, 0, 1, 1, 0, 1, 0, 0, 126, 255, 223, 197, 194, 255, 255, 12, 17, 86, 1, 0, 134, 18, 7, 8, 0, 33, 0, 0, 2],
    "data": [32, 144, 1, 69, 0, 0, 4, 1, 25, 0, 1, 1, 0, 1, 0, 0, 126, 255, 223, 197, 194, 255, 255, 12, 17, 86, 1, 0, 134, 18, 7, 8, 0, 33, 0, 0, 2],
    "parsed": {
        "name": "incomingMessageHandler",
        "messageType": "EMBER_INCOMING_UNICAST",
        "aps_profileId": "0x0104",
        "aps_profileIdDesc": "ZCL",
        "aps_clusterId": "0x0019",
        "aps_sourceEndpoint": 1,
        "aps_destinationEndpoint": 1,
        "aps_options": "0x0100",
        "aps_groupId": "0x0000",
        "aps_sequence": 126,
        "lastHopLqi": 255,
        "rssi": -33,
        "sender": "0xC2C5",
        "bindingIndex": 255,
        "addressIndex": 255,
        "messageLength": 12,
        "messageContents": [17, 86, 1, 0, 134, 18, 7, 8, 0, 33, 0, 0],
        "zcl": {
            "clusterId": "0x0019",
            "header": {
                "fc_frameType": 1,
                "fc_manufaturerSpec": 0,
                "fc_dirToClient": 0,
                "fc_defRespDisabled": 1,
                "fc_reservedBits": 0,
                "manufactureCode": null,
                "transactionNumber": 86,
                "commandId": "0x01",
                "commandIdDesc": "Query Next Image Request"
            },
            "ota": {
                "fieldControl": 0,
                "manufactureCode": "0x1286",
                "imageType": "0x807",
                "currentFileVer": 8448
            }
        },
        "zdo": "null"
    }
}

Thanks for any new suggestions you can give me about them.

[Andrew-io]

Hi @Nerivec please can you give me feedback on point 2? can you write me the steps to follow for "you will have to implement ZCL features."?

[Nerivec]

1. You were looking at the wrong enum for the status code given by zigbeeKeyEstablishmentHandler, EmberKeyStatus is the right one.
2. The configuration of the device is entirely device-dependent. See in zigbee-herdsman-converters, what Z2M does for your device, and go from there. Implementing the ZCL features is a massive task (the docs are about 1000 pages), this is not something I can give you steps for. Look at the docs and spec I linked before, everything is in there. My advice, limit the implementation to whatever you need for your device (see the appropriate chapters in the docs), and go from there, it will be less of a daunting task than trying to implement it all.

[Andrew-io]

Hi, first of all, thank you very much for your reply!!! :-)

1. I'm really distracted, thanks for the tip! So with the "new" Enum the states are:
   first ESTABLISHMENT_TIMEOUT
   and then TC_REQUESTER_VERIFY_KEY_SUCCESS
   Can you help me on how to avoid ESTABLISHMENT TIMEOUT? With which command can I extend the estabilishment time?

2. You are right, in fact I don't want to implement the entire ZCL protocol, but I want to get the humidity and temperature readings: now it is a question of principle to be able to read them :). I can't find my case in the specifications you linked: I would simply like to activate the SNZB-02P sensor to receive humidity and temperature readings.

[Andrew-io]

Sorry @Nerivec , I need some guidance on how to read the humidity and temperature attributes, I'm quite frustrated because I don't understand how to send commands to a battery-powered device. I tried sending Discover Attributes and Read Attribute ZCL commands, but I don't receive any incomingMessageHandler callbacks. If you tell me the sequence of commands (even just the name) then I'll see how to implement them. I can't find what Z2M does for my device. :'(

[Andrew-io]

Hi @Nerivec forgive me for the tag, could you tell me which are the appropriate chapters in the ZCL doc that are relevant to my case? Thank you