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?

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:

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

Parents
  • Hi Jonas,

    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?

    If you want to receive attribute reports from both clusters then yes. You need to create a binding for each cluster you want to receive reports from, and you do that by sending individual bind requests to each cluster.

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

    It looks correct to me.

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

    No you do not need this callback. In the CLI example this callback is used to check the status of the Configure Reporting Response command received after sending the Configure Reporting command, to see if it was successful or not.

    Unsubscribe is for disabling reporting. In both the case where you subscribe and where you unsubscribe you send the same command to the remote device, the Configure Reporting command. The only differences between these two are the min and max interval fields of the command. When you subscribe these are set to valid values to configure periodic reporting, while unsubscribe will set min to 0x000F and max to 0xFFFF, indicating that it should not periodically report.

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

    Make sure to register the device context before registering the endpoint handler. For example:

    ZB_AF_REGISTER_DEVICE_CTX(&device_ctx);
    ZB_AF_SET_ENDPOINT_HANDLER(DEVICE_ENDPOINT, ep_handler_report);

    Also make sure you are using the correct endpoint. From your ZB_AF_SET_ENDPOINT_HANDLER it seems like you might be using the light switch example, since you are using m_device_ctx.bulb_params.endpoint. If that is the case, then the endpoint given by m_device_ctx.bulb_params.endpoint is the endpoint of the light bulb. The endpoint handler you register with ZB_AF_SET_ENDPOINT_HANDLER will handle ZCL packets incoming on the endpoint you use when you register it, so this endpoint must be an endpoint registered on the device, and it must be the same endpoint as used for the device context. So for the light switch you would have:

    ZB_AF_REGISTER_DEVICE_CTX(&dimmer_switch_ctx);
    ZB_AF_SET_ENDPOINT_HANDLER(LIGHT_SWITCH_ENDPOINT, ep_handler_report);
    2) After a while the network crashes, any idea what this is? The Connected LED on the sensor goes out.

    A beacon request is sent by a device wanting to join a network as a part of scanning for networks. Devices can do passive or active scans. In the case of active scans the device will send out a beacon request to try to discover networks on the channel. If there is a network, then nearby routers will send a beacon in response.

    Do you have any indication as to why the network crashes? If you upload a sniffer log of the issue as a pcap I can look at it and see if I can find what the issue might be.

    Best regards,

    Marte

  • Hi Marte,

    Thank you very much for answering my questions. I have included the light switch in the coordinator, so the lamp can be switched on and off (Is another project, but I have changed a lot here). That's why some variable names are still on the old name.

    Short question: the coordinator has the endpoint 0, right?

    The endpoint (Sensor) has the end point 10.

    Below I listed my "ZB_AF_REGISTER_DEVICE_CTX" and "ZB_AF_SET_ENDPOINT_HANDLER". Can you maybe take a look if this is so correct? Have about the same Configurations as the CLI.

    Because of the network crash, I have tested again. This only occurs after the binding request with the "ZB_ZCL_CLUSTER_ID_TEMP_MEASUREMENT". Attached, I send you the sniffer data and the code that performs the binding. Maybe you will find a problem. The funny thing is that the sensor responds to the binding request, with Success, but after that the callback function is not called Disappointed (Look down below in the image sniffer data (marked yellow)).

    Still attached is my bind function as well as the corresponding callback function, maybe this helps you a bit. The long addresses are passed correctly after own checks (NRF_LOG_INFO...).

    Sniffer Data:

    If I do not call the "bind_device" function, the sensor remains connected in the network. This means that it should be the "bind_device" function that is the problem.

    Thanks again and best regards,

    Jonas

  • Hi Jonas,

    Jonas T said:
    Short question: the coordinator has the endpoint 0, right?

    You cannot use endpoint 0 for your application, as it is reserved for the data interface to the ZDO. 

    Jonas T said:
    Below I listed my "ZB_AF_REGISTER_DEVICE_CTX" and "ZB_AF_SET_ENDPOINT_HANDLER". Can you maybe take a look if this is so correct?

    It looks correct, just make sure to change COORDINATOR_ENDPOINT to a valid endpoint (1-254).

    Jonas T said:
    Because of the network crash, I have tested again. This only occurs after the binding request with the "ZB_ZCL_CLUSTER_ID_TEMP_MEASUREMENT". Attached, I send you the sniffer data and the code that performs the binding. Maybe you will find a problem.

    From your sniffer log and what you say about the bind callback not being called it seems like the coordinator stops working either right after sending the bind request or immediately when it receives the response but before it is able go into the callback function. The issue might be related to your coordinator endpoint, since you are creating a binding on an endpoint that is reserved and should not be used in the application. You should change COORDINATOR_ENDPOINT to something else and see if that fixes the issue. Other than that I do not see any obvious issues with your bind request and callback. If you are still seing the problem after changing the endpoint value you can upload your project here and I can test it on my side.

    Best regards,

    Marte

  • Hi Marte,

    Thank you very much for response. I did the coordinator number wrong and have now changed it. Thank you for the advice. Slight smile However, unfortunately, the error can not be fixed Hushed. I also copied the main and loaded into a new ZigBee light example (light_coordinator [ZigBee_3_2\examples\zigbee\light_control\light_coordinator"). But again the same error came out. Slight frown

    The aim of the project is to read out the multi sensor with a coordinator and to output it on the interface (e.g. uart, display...).

    But I'll try to get only the temperature values from the sensor, later the pressure will follow.

    I have now enclosed the entire project folder for you and will point out the locations. Additionally I have attached the Main File to them again.

    All code has been implemented in the "main.c" file. All functions are listed below and can be found via the project search in the main (Would recommend). They have also been labeled and numbered in large ASCII text. I then also adjusted the naming of some variables, as well as from Coordinator to "Sensor logger".

    Function names for the search:
    Signal Handler: "zboss_signal_handler". (Line 1039)

    1) Send a match request: "send_match_desc_req" (Line 968)
    Callback function: "cmd_zb_match_desc_cb"

    2) Long address request: "zb_ieee_addr_req"  (Line 894)
    Callback function: "ieee_addr_cb"

    3) Send bind request: "bind_device" (Line 779)
    Callback function: "zb_bind_callback"

    4) Subscribe function: "subscribe_device" (Line 670)

    Do I also make a little bit of a mix-up with the buffers? If so, do you have any tips or internet sites?

    Now I wish you still good luck with testing and thank you again. Hope everything works. Ok hand

    With kind regards

    Jonas

    multi_sensor_data_logger.zip

  • Hi Jonas,

    Thanks for the detailed and clear explanation and code! Makes it much easier for us to debug projects and understand what is actually going on Slight smile

    I have started looking at your issue, and it seems to be buffer leak. The device gets a hard fault in zb_get_buf.

    When I commented out p_buf = ZB_GET_OUT_BUF(); in bind_device(), as well as the if statement for the buffer (lines 793-798), the device continued to run after the binding, and ran for about a minute before stopping. After also commenting out = ZB_BUF_FROM_REF(param); on line 677 in subscribe_device() so that the line was only zb_buf_t * p_buf; it ran for longer, about 4 minutes. All three times it crashed because of hard fault in zb_get_buf, and I suspect that is because it is not able to allocate a new buffer because they are all used. I have not had the chance to go through the entire project and find all possible problems yet, but I see that you are allocating a lot of buffers and scheduling alarms, so I would suggest starting by looking at this, so the places you use ZB_GET_OUT_BUF, ZB_BUF_FROM_REF, ZB_SCHEDULE_ALARM, etc. 

    When the device was running it worked as expected, successfully creating a binding, receiving attribute reports and calling the endpoint handler, so that part works as it should until the hard fault.

    I will keep looking into the problem tomorrow.

    Jonas T said:
    Do I also make a little bit of a mix-up with the buffers? If so, do you have any tips or internet sites?

    ZB_GET_OUT_BUF is used to allocate a new out buffer, while ZB_BUF_FROM_REF is a helper function to get a buffer by using its reference, and is used instead of buffer pointers. You can read more about this in Zigbee stack memory management subsystem.

    Best regards,

    Marte

  • Hi Marte,

    It works for me even after commenting out the lines, thank you very much. I will also still look around the problem, if I can get it to work Rolling eyes. Yes, the network crashes after about 4 min.
    Then I will hear from you again regarding last answer. Thumbsup

    Again quick question: For me the Attributes report works even if I don't call Subscribe function, is that normal? 

    Thanks a lot and best regards
    Jonas T

  • Hi Marte,

    Good news Tada. I managed to subscribe to both clusters and output them afterwards. 
    The solution was to write the buffers according to the CLI Agent. (I have attached it in case you are interested Thumbsup)

    Attached is the Main.c Code for the coordinator to read a multi-sensor (....\examples\zigbee\experimental\multi_sensor) example. (Works, but can be improved)

    On the sensor side, I have of course replaced the two measured (temperature and pressure) values by potentiometers. If someone needs the code for this, please contact me.

    Thank you, Marte, for answering the questions.

    Best regards,

    Jonas T

Reply
  • Hi Marte,

    Good news Tada. I managed to subscribe to both clusters and output them afterwards. 
    The solution was to write the buffers according to the CLI Agent. (I have attached it in case you are interested Thumbsup)

    Attached is the Main.c Code for the coordinator to read a multi-sensor (....\examples\zigbee\experimental\multi_sensor) example. (Works, but can be improved)

    On the sensor side, I have of course replaced the two measured (temperature and pressure) values by potentiometers. If someone needs the code for this, please contact me.

    Thank you, Marte, for answering the questions.

    Best regards,

    Jonas T

Children
No Data