1
\$\begingroup\$

ZigBee as a standard doesn't believe in direct connectivity of devices, its more of a floating network. But if I am to have a network of devices in a HAN (Home Automation Network), I need to know if these devices are still discoverable.

Each device has a neighbour table of devices that are in physical proximity of itself. I can query this table for each device using an LQI request, however, as many of the devices contain similar devices in their neighbour tables, I would be checking each device against an increasingly large list. It is also entierly possible that some devices may not be on this network.

If I had (lets say) 200 devices in my network, this is a **** load of requests and comparisons to do on a uController.

I can create a list of devices as they join the network and store them in eeprom, but is this actually the best idea?

I am working with the Atmel Bitcloud stack on an 8-bit AVR, however these are standard requests specified in the ZigBee specifications.

I need to know this in order to see if any device in my network is faulty.

\$\endgroup\$
2
  • \$\begingroup\$ I think it depends a lot on how often you are running this check. It could take a few seconds to do, but if it is only like once per day... \$\endgroup\$
    – MadHatter
    Commented Nov 5, 2015 at 2:24
  • \$\begingroup\$ True. A Neighbour table of 4 large, 2 requests per device, 10ms per request, 4000ms. Is there a cluster you know of that could send an update to my coordinator with its information upon joining the network? As a main source, this could assist. \$\endgroup\$
    – Larry
    Commented Nov 5, 2015 at 3:54

1 Answer 1

0
\$\begingroup\$

In HA all devices must support the basic cluster. So you 'could' broadcast a read attribute to a basic cluster mandatory attribute. However this is not guaranteed to work, as broadcasts are not acknowledged at any level.

For this same reason you can not rely on Device Announce to build up you device list. In the past I have used the the security manager, most stacks (I have used this in TI zstack with zdoCBFunc[ZDO_TC_DEVICE_CBID]) offer an API/callback to allow the application to know when the Trust Center has given out a key, if this does not happen then the device can not be on the network. This means that your device list built up when devices join the network is definitely capturing all devices. After that you can use read attribute of one of the mandatory basic cluster attributes to 'ping' the device to see if it still on the network.

If you can not access a trust center API to know when the network key is given out then you should use the ZdoMgmtLqiRequest. You should not rely on device announces as there is a possibility they will never be heard (due to various rules and network parameters on rebroadcasts and also the network size). You should not rely on any broadcast mechanism for this including broadcasting a read attribute. The only way I know of doing this is by unicasting the ZdoMgmtLqiRequest, first to you self, then you neighbors and then you neighbors neighbors. Painful, but guaranteed to work and if devices do not reply then they are not there anymore.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.