Could I ask for some more detail on AO mode bit settings please?
According to the documentation:
Bit 0 - Output in Native/Explicit API format
Bit 1 - Supported ZDO request pass-through
Bit 2 - Unsupported ZDO request pass-through
Bit 3 - Binding request pass-through
Bit 4 - Echo received supported ZDO requests out the serial port
Bit 5 - Suppress all ZDO messages from being sent out the serial port and disable pass-through
So I’d like to know:
What is “supported” vs “unsupported” ZDO request? Is it that certain ZDP clusters are not supported? Or would a Simple_Descriptor_request (Cluster Id 0x0004) for an Endpoint other than E6 or E8 be considered as “unsupported”.
Is there another type of Zigbee message beyond “supported” and “unsupported” request? For example, I can see Node_Descriptor_responses (Cluster Id 0x8002) whether or not Bit 1/2 are set.
Does pass-through strictly mean that the Xbee’s ZDO takes no notice of it?
I’m looking at developing a simple ZHA device, so my understanding is that I need to implement the ZHA profile on one or more custom endpoints. So since the Xbee’s ZDO only knows about E6 and E8 endpoints, do I need to turn on bit 1 (Supported ZDO pass-thru) and, in my host program, respond to the Active_EP_request (0x0005) by supplying my endpoint list, and respond to the Simple_Desc_request (0x0004) by supplying the profile,clusters,etc for each of my endpoints?
Having turned on bit 1 (Supported ZDO pass-thru) it means I’ll also need to handle any other ZDP commands that the Xbee would have handled automatically. Is that correct? So I’m thinking of the other boilerplate stuff like IEEE_addr_req, NWK_addr_req, Node_desc, etc, would need to be explicitly handled. At least until, I turn bit 1 off again.
I know there’s a few Xbee libraries around, but I’m just thinking through what needs to be implemented and what I can assume the module can carry on doing for me.
That answer invites a homologous question, which is:
what is a cluster that “references the Digi application directly on the XBee product” ?
There’s few dozen clusters that are specified by ZigBee as part of the ZDP; isn’t there any documentation on how the XBee’s ZDO handles these individually and whether they fall into the supported/unsupported/other category?
I’m trying to find this out asynchronously to waiting for an answer, by experimenting with firing various clusters at my XBee, but it would be good to get this more on a manufacturer’s spec basis, so we can do grown up stuff, like change management, QA, …
You’re either referring to the final line on that page which says “Refer to the Zigbee specification…”, which is just another level of indirection of the same homologue.
Or you are saying that the 7 clusters listed on the page is the definitive list of supported clusters which will be need to be handled by the host program if bit 1 of AO is set? Which would then beg the question: what about node_desc_req, power_desc_req, simple_desc_req, active_ep_req, at al, which are listed as Mandatory by the ZigBee spec. Especially since without active_ep_req and simple_desc_req, there’s not much a peer ZigBee compliant device could do with us. Are these not supported ZDO requests then?
I had already looked at that page, but felt it hadn’t answered my question fully, so if you can confirm it’s definitive (complete) that could be a useful clarification.
You mean 0004, the Simple_Descriptor_req? 0005 is the Active_EP_req which returns (as we all know) the Digi end points of E6 and E8.
But now, if we attempt to send a 0004 to ask for the ZDO clusters supported on EP 0, it returns (0x82 - INVALID_EP), which is in accordance with the ZigBee spec p207, i.e. “The supplied endpoint was equal to 0x00 or 0xff.”
However the question was: which ZDPclusters on EP 0 are a) considered to be supported, b) non-supported, c) something else. I believe the explicit answer is expressed in the form of 3 lists of 16bit cluster ids drawn exhaustively from the list of cluster ids documented in the ZigBee device profile. Thanks for trying to help me out, but if you don’t have an explicit list, maybe someone else does, or I’ll just find out through experiment.
(The experiments are yielding some success which is good news, so I can at least now write a host program which allows itself to be registered on a Smartthings system as a simple On/Off device, and the user button can be integrated into an Automation via the Smartthings App)