Hint for Zigbee coordinator development

[DaKa]

Hi,

I am working on a hub based on a raspberry compute module. Zigbee support is enabled by a u-blox (or Rigado) BMD340 module connected via UART to the compute module. I guess that the design architecture is the CLI co-processor design ( https://infocenter.nordicsemi.com/topic/sdk_tz_v3.2.0/zigbee_architectures.html?cp=7_7_0_3_1 ) because I am able to play with the CLI example (bdb, zdo and zcl commands using minicom).

The hardware has been designed by a third-party company and I don't really know which firmware they flashed on the module. They told me "the module has been flashed with a slightly modified version of the standard serial controller API firmware". But that sounds quite vague to me (maybe not for you?).

Is the Zigbee CLI meant to be used also for production or is it only an example that do not implement all the functionalities? I have seen in your SDK (nRF5_SDK_for_Thread_and_Zigbee_v4.0.0) that the cli_agent_router directory in the example directory is using functions from the zigbee_cli directory in the components directory. But then some commands seem to be missing in the zigbee_cli component (e.g the zdo node descriptor request). So, is it also part of the example? I am a bit lost about what I am supposed to use...

Also, to be a bit more clear, I would like to interface the BMD340 module with zigpy, which is a python3 library that implements the Zigbee stack already. I thought about using the zb_cli_wrapper but I feel like I am trying to interface two things that are at the same layer... I am a bit confused with the layers shown in the graph from the specification. Also what is ZBOSS stack actually doing in all that?

Sorry, I guess that is a lot of vague questions but I need to sort things out in my head, and I hope you can help me in that.

BR
Damien

[Edvin]

Hello,

 

The hardware has been designed by a third-party company and I don't really know which firmware they flashed on the module. They told me "the module has been flashed with a slightly modified version of the standard serial controller API firmware". But that sounds quite vague to me (maybe not for you?).

 By slightly modified, I assume they just fixed the pins and HW configurations for the module, but I suggest that you check what project they did these modifications on, so we don't have to use the trial and error and spend a lot of time figuring out. To be honest, I don't know what example they are talking about. It could be the "cli_agent_router" example from the Thread and Zigbee SDK, but I'd prefer if you could find out.

 

But then some commands seem to be missing in the zigbee_cli component (e.g the zdo node descriptor request). So, is it also part of the example?

 What is this command supposed to do? Are you sure it is not the "zdo match_desc" command you are thinking of?

I have not heard of zigpy before, so whether this is compatible with the Zigbee CLI Wrapper, I am not sure. What does zigpy do?

Sorry for the vague answers, but I am not really sure what the actual questions are here. What sort of application are you creating? To sum up what I believe you are doing, you are creating a coordinator that will run on a RPi, controlled by python? What is the coordinator going to do? I assume it is going to allow the other nodes to join the network, but anything else? Why do you e.g. need the unknown command "zdo node descriptor request", and where did you find that command? I didn't find it in the Zigbee CLI Reference.

[DaKa]

Hi,

Edvin said:

It could be the "cli_agent_router" example from the Thread and Zigbee SDK, but I'd prefer if you could find out.

I'll check with them what exactly they flashed on the module.

Edvin said:

What is this command supposed to do? Are you sure it is not the "zdo match_desc" command you are thinking of?

No, I was thinking of the node_descriptor_req... according to the Zigbee specification (section 2.5.3) it says that ZDO is using the Zigbee Device Profile on one of the interfaces. And that profile must implement the node descriptor cluster (id 0x0002) and other clusters that are not available from the CLI as well. But for example, the simple descriptor command is available from the CLI. As I said in my first post, I am a bit lost about all the layers and interfaces... so I might understand it wrong.

Edvin said:

I have not heard of zigpy before, so whether this is compatible with the Zigbee CLI Wrapper, I am not sure. What does zigpy do?

The description says that it is a python library that implements the Zigbee stack. I am new in Zigbee and it is super confusing coming from Z-Wave development, I don't understand the layers yet so it is hard for me to tell exactly what it is doing. But what I can tell is that I would like to use it because I already have something built on it. The link is https://github.com/zigpy/zigpy.

Edvin said:

What sort of application are you creating? To sum up what I believe you are doing, you are creating a coordinator that will run on a RPi, controlled by python? What is the coordinator going to do? I assume it is going to allow the other nodes to join the network, but anything else?

Exactly, my application is event based and is written in python. For now I support Z-Wave networks but I also want to support Zigbee. So, I need to write a component in my application that will use a Zigbee stack to maintain and control a Zigbee network. The compute module and the BMD340 module represent the Zigbee coordinator. And then I want to be able to connect third-party nodes to the network and control them (at least nodes that support HA and ZLL profiles). I would like to use zigpy because I already have an application component that works with an Xbee dongle and that is using zigpy. Zigpy seems to communicate low level data through UART to the different chips that it supports. Meanwhile, the nRF52840 is not supported by zigpy. I don't know at which level of the protocol zigpy is built on though.

Anyways, do you think that using the CLI and write a complete new component would be better than adapt a already created component that supports other modules (TI, Xbee, modules....). I feel like the CLI does not provide all the features required to maintain and control a Zigbee network. For example to monitor a state of an attribute, I don't know if something like callbacks can be used? Or is it only by polling a node? e.g when a node leaves the network, is there any callback saying that a node left the network?

BR,
Damien

[Edvin]

Hello Damien,

DaKa said:

according to the Zigbee specification (section 2.5.3) it says that ZDO is using the Zigbee Device Profile on one of the interfaces. And that profile must implement the node descriptor cluster (id 0x0002) and other clusters that are not available from the CLI as well

What Specification are you talking about? Can you send me a copy?

 

 

DaKa said:

Anyways, do you think that using the CLI and write a complete new component would be better than adapt a already created component that supports other modules

 I suggest that you start by famliarizing with the CLI example, and try to achieve what you want to with this, and then start looking into the python layer after that. And then I suggest you start using the python layer that we support.

[DaKa]

Hi,

I will do that. I will first try to do simple things using the CLI and the python wrapper and if I have any limitation I can try to do more advanced stuff. I will probably have more questions later. But thanks for helping so far.

Edvin said:

What Specification are you talking about? Can you send me a copy?

I was referring to the Zigbee Pro specification ( https://zigbeealliance.org/wp-content/uploads/2019/11/docs-05-3474-21-0csg-zigbee-specification.pdf ).

BR,
Damien