Failure to connect with some Devices

[remijn]

Hello,

When I try to connect some devices ( it happens with both the SmartThings multisensor and the Xiaomi MI Smart Home wireless switch ) I will recieve this error

  cc-znp:AREQ <-- ZDO:tcDeviceInd, { nwkaddr: 6556, extaddr: '0x00158d0001549d8b', parentaddr: 0 } +13s
  cc-znp:AREQ <-- ZDO:endDeviceAnnceInd, { srcaddr: 6556, nwkaddr: 6556, ieeeaddr: '0x00158d0001549d8b', capabilities: 128 } +364ms
  cc-znp:SREQ --> ZDO:nodeDescReq, { dstaddr: 6556, nwkaddrofinterest: 6556 } +1ms
  cc-znp:SRSP <-- ZDO:nodeDescReq, { status: 0 } +10ms
  cc-znp:SREQ --> ZDO:nodeDescReq, { dstaddr: 6556, nwkaddrofinterest: 6556 } +10s
  cc-znp:SRSP <-- ZDO:nodeDescReq, { status: 0 } +10ms
Cannot get the Node Descriptor of the Device: 0x00158d0001549d8b
Cannot get the Node Descriptor of the Device: 0x00158d0001549d8b

The Error appears to be caused by a timeout when sending controller.request('ZDO', 'nodeDescReq', { dstaddr: nwkAddr, nwkaddrofinterest: nwkAddr })

Looking at the code, it appears the device is not responding, however both of these devices have been confirmed as working, and worked flawlessly with their respective hubs

Thank You,

• Nick Remijn

[jackchased]

Hi @TheKillerremijn,

The Xiaomi ZigBee devices uses their own proprietary encoding and will only work with their own hubs. And zigbee-shepherd is follow zigbee alliance's standard, so it can't get the Xiaomi device information.

[splitice]

We see this same problem with the Samsung Smart Things devices. They are HA certified.

[simenkid]

Hi @TheKillerremijn and @splitice, thanks for the feedback.

ZS currently has tested with Philips Hue, GE light, Netvox sensors/plugs/lights, ASUS sensors, and some other devices from our customer. We've tried Xiaomi's device as well, unfortunately it doesn't work with ZS for its proprietary encoding. We not yet give it a try with Smart Things devices (and we will).

Do you have any suggestion on devices from other manufacturers? I wonder that it would be nice if we can have a list of the supported devices on the WiKi. Everyone can contribute to put the tested device on the list for others convenience.

[splitice]

We can contribute feedback on Heiman sensors/lights (working), chuangkesafe (latch not working, motion low quality), Smart Things (immediate disconnect on join), TI CC253X based end devices (working), Digi XBee hardware (not working).

We have orders for a couple other companies products getting delivered next month too.

We would love it Smart Things worked, since we have alot of that hardware from a previous project. We are toying with an upgrading to Zigbee 3 (Z-Stack 3) to see if that helps.

[jackchased]

Hi @splitice,

The Heiman sensors and lights is this company products ?

[splitice]

@jackchased Yes, although I believe the lights may be whitelabeled.

[jackchased]

Hi @TheKillerremijn and @splitice,

I think the SmartThings devices can not join the network, perhaps because of the device is a IAS Zone device. And IAS Zone device can not find the IAS CIE on ZS, so the SmartThings devices can't smoothly join the network.

In addition, I implement a simple example of zapp-cie that use zive and ziee modules to create a ZigBee Application. I hope this can help you.

[splitice]

Ziee looks interesting but I have to say I don't know much about it. Is there some comprehensive documentation on it? It looks targetted towards endpoint applications, while ZS does coordination... Anywau this looks very similar to something we are already doing where we are writing to ssIasZone IAS_CIE_ADDRRESS. Your way is far better though, we just wrote to the address field and then fired off a response on a timer (we assumed that the req was sent) because we didn't have a way to capture it.

Unfortunately in the case of smart things, they disconnect immediately after joining. Before enrolling can begin.

Here is a screenshot of a packet capture. I can supply the capture if you want it.

[jackchased]

The zapp-cie similar to third-party plugins(ZigBee Application plugin), it need work with ZS.

Invoke this .mount() API, the zapp-cie will be registered to ZS as a local endpoint. If ZS receive any message to be sent to zapp-cie (for example, enrollReq or statusChangeNotification msg) , ZS will pass to zapp-cie.

Will the SmartThings devices send the enrollReq command?

Perhaps SmartThings devices need find a CIE endpoint(Device Id is 0x0400) on ZS?

[splitice]

Perhaps SmartThings devices need find a CIE endpoint(Device Id is 0x0400) on ZS?

Either that, or perhaps they don't like non Zigbee 3.0 coordinators (or perhaps something in the early Z-Stacks is non-standard according to Samsungs implementation). Those two have been my two theories. We know it works with another coordinator running ZBoss.

Will the SmartThings devices send the enrollReq command?

I'd assume so. Once they get past this step normally we write to the appropriate cluster, then the ED send the req. Some devices i.e chuangkesafe send the enrollReq immediately and don't require the address to be written (as to where they get the destination ieeeAddress, I didn't investigate - assume it's broadcast or coordinator).

Unfortunately at the moment Smart Things is not currently our priority, however I'd be happy to do some more research when I have time. We have the hardware after all from a previous project.

Our next batch of hardware features some Green Power devices (depends on Zigbee 3.0, requiring a Z-Stack upgrade) which is a higher priority for us due to the long battery life & small size, There is a chance our work on getting Z-Stack 3.0 compatibility for this will resolve ST compatibility.

On top of that we still need to get reliable device status (joining), our experiments with lqiScan are mixed. Although that's not relevant for this issue.

[splitice]

FYI, I'll try and integrate your ziee-cie with our system tomorrow. If I have time (speculative) I'll run over to the lab and dig up a Smart Things sensor for testing. Else I'll give it a try after Easter.

[remijn]

Alright, I have integrated ziee-cie, and this seems to make the difference, The smartthings sensor is able to join now, I will try the Xiaomi later. But this seems to work, Thank you

[splitice]

We tried the zapp cie code and while now the Smart Things sensors are able to join no (yes!!!) with the zapp the enrollReq is never triggered.

There is also an error which is always returned in the callback to mount(): "Error mounting CIE app - Error: Timed out after 10000 ms"

We tested these too with the Heiman sensors and the enrollReq was never triggered with them too. I'll try next week with our non zapp way of enrolling and see what's what.

[splitice]

what the cie app is missing is a write to the cieaddress, all the devices we have require this before enrollreq is triggered.

[Frans-Willem]

Any news on the Xiaomi devices ?

[mruiter]

Still no news about Xiaomi devices ?

[LeMyst]

What about that video ? https://www.youtube.com/watch?v=qmAjwrll0w4

Same guys talk here : https://forum.athom.com/discussion/comment/57091/

[jpbarraca]

With the Xiaomi Aqara Temperature and Humidity sensor the device will join the network but I'm seem unable to retrieve any value. Also, I'm not sure the enrol process is really completed.

Is there any information around the net describing what needs to be done? (Yes I searched over ST and other sources).

[LeMyst]

@jpbarraca Hi, for me, with the Xiaomi Non-Aqara Temp and Hum sensor, I can see the device, but when ZS request endpoint (1, 2 and 3) I receive a timeout because I only receive the first endpoin asked. If I limit the number of gateway asked (only the 2), the sensor answer and ZS add the device in the network. After that, there is nothing more, I can't get any value.

If you need more information, try to translate this french article : http://faire-ca-soi-meme.fr/hack/2017/04/24/hack-xiaomi-mi-smarthome-decouverte-de-clef/ especially the part "Lancement du « sniffage »" where he sniff packet betwen xiaomi gateway and the door sensor.

[jpbarraca]

I have the same behaviour both with read and report requests. Openhab is also trying to integrate these sensors, so I will follow the work there.

[mruiter]

Also the Homey platform is working hard to get it working ;)

Verstuurd vanaf mijn iPad

Op 26 sep. 2017 om 15:44 heeft João Paulo Barraca notifications@github.com het volgende geschreven:

I have the same behaviour both with read and report requests. Openhab is also trying to integrate these sensors, so I will follow the work there.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[LeMyst]

For me, a thing to do is to delay the "ZDO:simpleDescReq" after a "ZDO:activeEpRsp". Seem like the sensor doesn't like to be "flooded" by simpleDescReq and only answer to the first received.

I don't know how to implement a delay between each request.

cc-znp:AREQ <-- ZDO:activeEpRsp, { srcaddr: 38970, status: 0, nwkaddr: 38970, activeepcount: 3, activeeplist: <Buffer 01 02 03> } +3s cc-znp:SREQ --> ZDO:simpleDescReq, { dstaddr: 38970, nwkaddrofinterest: 38970, endpoint: 1 } +5ms cc-znp:SRSP <-- ZDO:simpleDescReq, { status: 0 } +14ms cc-znp:SREQ --> ZDO:simpleDescReq, { dstaddr: 38970, nwkaddrofinterest: 38970, endpoint: 2 } +2ms cc-znp:SRSP <-- ZDO:simpleDescReq, { status: 0 } +15ms cc-znp:SREQ --> ZDO:simpleDescReq, { dstaddr: 38970, nwkaddrofinterest: 38970, endpoint: 3 } +2ms cc-znp:SRSP <-- ZDO:simpleDescReq, { status: 0 } +14ms

[AndrewLinden]

I got Xiaomi switches working: https://github.com/zigbeer/zigbee-shepherd/issues/26

[itsmepetrov]

Hi @splitice,

Did you manage to enroll IAS Zone devices? Could you please share your code for that?

I managed to enroll some devices with this code:

async function enrollEndpoint(endpoint, coordinatorAddr) {
  try {
    const writeRec = {
      attrId: zclId.attr('ssIasZone', 'iasCieAddr').value,
      dataType: zclId.attrType('ssIasZone', 'iasCieAddr').value,
      attrData: coordinatorAddr,
    }
    const enrollRec = {
      enrollrspcode: 0x00,
      zoneid: 3,
    }
    await endpoint.foundation('ssIasZone', 'write', [writeRec], { direction: 0 })
    await sleep(2000)
    await endpoint.functional('ssIasZone', 'enrollRsp', [enrollRec])
  } catch (err) {
    console.error(err)
  }
}

But sometimes it works, sometimes not. I think it depends on current device status (offline/online). I don't know actually when I should call this function, but I always call it right after devIncoming message. But I think I should do it on another indication message or something else.

[splitice]

Our code involves lots of retries as well as tries both methods writing to ssIasZone and enrollrsp (yours does only once). We also respond to enrollreq's, @zigbeer shared code for that in the form of a Zive app.

It's also important for some devices which do not data request (and instead rejoin on event) that you are quick to enroll and enroll whenever they come back online (in case they have forgotten / been reset).

For the first type of device we observe a 100% success rate. The latter type isn't 100% reliable for us yet.

[itsmepetrov]

@splitice thank you for the explanation.

I tried zapp-cie, but it never triggers enrollReq event if I write to the cieaddress, maybe there are some issues in zigbee-shepherd, I don't know. Did you manage to make zapp-cie work? Or how you handle enrollReq event, how I can subscribe on it?

Also I've updated my previous function, now it sends enroll request till success response:

const zclId = require('zcl-id')

function sleep(time) {
  return new Promise(resolve => setTimeout(resolve, time))
}

function write(endpoint, coordinatorAddr) {
  const writeRec = {
    attrId: zclId.attr('ssIasZone', 'iasCieAddr').value,
    dataType: zclId.attrType('ssIasZone', 'iasCieAddr').value,
    attrData: coordinatorAddr,
  }
  return endpoint.foundation('ssIasZone', 'write', [writeRec], { direction: 0 })
}

function enroll(endpoint, zoneId = 3) {
  let enrollRec = {
    enrollrspcode: 0x00,
    zoneid: zoneId,
  }
  return endpoint.functional('ssIasZone', 'enrollRsp', [enrollRec])
}

module.exports = async function runEnrollLoop(endpoint, coordinatorAddr, zoneId) {
  try {
    await write(endpoint, coordinatorAddr)
    await sleep(1000)
    await enroll(endpoint, zoneId)
    console.log('enroll success')
  } catch (err) {
    console.log('enroll error, trying again...', err.message)
    await sleep(1000)
    await runEnrollLoop(endpoint, coordinatorAddr, zoneId)
  }
}