This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ZigBee problems with coordinator to subscribe the multi sensor

Good day.

I am currently developing with two NRF52840 DK boards, and I also have two NRF Dongles. On a dongle a sniffer for ZigBee. I am working with SDK 3.2. This is my first project with ZigBee, so I don't have much know-how yet.

My goal is to implement the coordinator as like CLI agent. So that it subscribes to the multi-sensor and receives data. Is so to speak an A to B communication.

With "zb_zdo_match_desc_req()" I get the short address and the endpoint of the sensor. Then with "zb_zdo_ieee_addr_req()" I get the long address  (EUI64) of the sensor. After that the "zb_zdo_bind_req()" request starts (Between coordinator and sensor) and in the callback function ("p_resp->status") this is confirmed successfully with ZB_ZDP_STATUS_SUCCESS. However, I only connect to the ZB_ZCL_CLUSTER_ID_TEMP_MEASUREMENT cluster.

My questions:
1) Is it necessary to connect both clusters (temperature/pressure) to subscribe to the multisensor? If so, is the bind request simply done again with the ZB_ZCL_CLUSTER_ID_PRESSURE_MEASUREMENT?

2) Is subscribing the sensor in the first step as below, correct?

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// Step 8:
// Subscribe on Sensor
static void subscribe_device(zb_uint8_t param)
{
zb_buf_t * p_buf = ZB_BUF_FROM_REF(param);
configure_reporting_req_t req;
tsn_ctx_t * p_tsn_cli;
zb_uint8_t * p_cmd_ptr;
zb_ret_t zb_err_code;
//zb_bool_t subscribe;
zb_ieee_addr_t sensor_ieee_adr;
NRF_LOG_INFO("----------------------------------------");
NRF_LOG_INFO("Step 8: subscribe_device");
req.profile_id = ZB_AF_HA_PROFILE_ID;
req.cluster_id = ZB_ZCL_CLUSTER_ID_TEMP_MEASUREMENT; //ZB_ZCL_CLUSTER_ID_PRESSURE_MEASUREMENT; //
req.attr_id = ZB_ZCL_ATTR_TEMP_MEASUREMENT_VALUE_ID;
req.attr_type = ZB_ZCL_ATTR_TYPE_S16; //ZB_ZCL_ATTR_TYPE_16BIT;
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

3) Does it even need "cmd_zb_subscribe_unsubscribe_cb" and what is that unsubscribe for?

My problems:
1)  The "ep_handler_report" is not called, but I see in Wireshark that a Report Attributes has been sent?

Is there still something to change at the sensor, because there I have left everything as is.

My ep_handler_report Handler:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
static zb_uint8_t ep_handler_report(zb_uint8_t param)
{
NRF_LOG_INFO("Ep Handler Report");
zb_buf_t * p_zcl_cmd_buf = (zb_buf_t *)ZB_BUF_FROM_REF(param);
zb_zcl_parsed_hdr_t * p_cmd_info = ZB_GET_BUF_PARAM(p_zcl_cmd_buf, zb_zcl_parsed_hdr_t);
tsn_ctx_t * p_tsn_ctx;
if (p_cmd_info->cmd_id == ZB_ZCL_CMD_REPORT_ATTRIB)
{
NRF_LOG_INFO("print_attr");
print_attr(p_cmd_info, param);
ZB_FREE_BUF_BY_REF(param);
return ZB_TRUE;
}
else if (p_cmd_info->cmd_id == ZB_ZCL_CMD_CONFIG_REPORT_RESP)
{
// Find command context by ZCL sequence number.
p_tsn_ctx = get_ctx_by_tsn(p_cmd_info->seq_number);
if (p_tsn_ctx != NULL)
{
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

The other functions as well as the output of the data I took from the CLI as well as from other discussions.

With the function "print_attr()" the data is output (Same function as with CLI), what am I doing wrong here with subscribe?

2) After a while the network crashes, any idea what this is? The Connected LED on the sensor goes out.

I would also be glad if you could give me a quick rundown on the process for subscribing to devices. If you want the whole code, I can share it with pleasure.

Thanks in advance. Slight smile

With kind regards

Jonas T