• State Verified Answer
  • Replies 14 replies
  • Subscribers 75 subscribers
  • Views 2631 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 289266
Options

Battery monitoring of end device (door lock) from coordinator (central device) over Zigbee

AqibK

Hello,

I am developing a door lock system. Where in final product door lock will be controlled and monitored by BLE+Zigbee. So far I have complete success of controlling door locks over BLE with battery monitoring + OTA DFU. Now I want to have same functionalities with ZigBee. I am using nRF52840 DK and "nRF SDK for Thread and ZigBee v4.2.0" SDK.

For now I want to monitor battery level of my end device/devices (which will be nrf52840 DK or our custom board based on nrf52840 chip) from a central device ( which will be a coordinator, also nrf52840 DK). As I am complete beginner in ZigBee I am finding it very difficult to achieve this task.

I have gone through the documentation of SDK and implemented light control example but still unable to achieve above task. When I was developing using BLE there were some tutorials like this one, which helped a lot. I am looking for same kind of tutorial or any other resource which can help me monitor battery status or any GPIO status of end device from coordinator over ZigBee. 

Any help in this regard would be highly appreciated.

Parents
  • 0

    Hi Andreas,

    I am uploading my project, you can have a look at it. Meanwhile I will also setup wireshark and send its results by tomorrow. I modified multi_sensor example in "nrf5_sdk_for_thread_and_ZigBee_v4.2.0" to be my server and using CLI_agent example of same sdk without modifying it. I am using segger embedded studio for Arm v5.6 (64-bit).

    multi_sensor.rar

  • 0 in reply to AqibK

    HI,

    Please find sniffer result in below screenshot. I am not sure if you can find what you are looking for and I have screenshot the right packet because it is not making much sense to me as this is my first time with sniffer tool

  • 0 in reply to AqibK

    Hi again, 

    We did some more investigating into the specs and found a change that should make the sample you sent work properly! If you change B_MULTI_SENSOR_REPORT_ATTR_COUNT from 3 to 4 in zb_multi_sensor.h it should work. The Power Configuration cluster has 2 attributes that are mandatory for reporting, which requires you to increase this count one higher.

    This works for us at least, so let me know if this solves your issue!

    As for the sniffer trace what we wanted to investigate is the packages with type ZCL: Configure Reporting and Configure Reporting Response to see if the commands went through with success or if they failed setting up the reporting routine as seen in the image (now with arrows and circles). If if would not have been a success, then the status line could contain some information about what have failed with the routine setup.


    Kind regards,
    Andreas

Reply
  • 0 in reply to AqibK

    Hi again, 

    We did some more investigating into the specs and found a change that should make the sample you sent work properly! If you change B_MULTI_SENSOR_REPORT_ATTR_COUNT from 3 to 4 in zb_multi_sensor.h it should work. The Power Configuration cluster has 2 attributes that are mandatory for reporting, which requires you to increase this count one higher.

    This works for us at least, so let me know if this solves your issue!

    As for the sniffer trace what we wanted to investigate is the packages with type ZCL: Configure Reporting and Configure Reporting Response to see if the commands went through with success or if they failed setting up the reporting routine as seen in the image (now with arrows and circles). If if would not have been a success, then the status line could contain some information about what have failed with the routine setup.


    Kind regards,
    Andreas

Children
Related
Terms of service