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.

[AHaug]

Hi,

I'm glad to hear that the case helped somewhat on the way!

I will ask my colleague if they have any idea what may cause this, but the response may be delayed until next week as there is a holiday coming up before the weekend.

Meanwhile you could take a look at the NCS resources if its an option to migrate from nRF5 to NCS

Kind regards,
Andreas

[AqibK]

HI Andreas, 

I tried reading the battery value from read_attr command and I can read it correctly but unfortunately I still cannot subscribe to it. I think I am very close to the solution if you can get some ZIgBee engineer to look at it it would be great. For migration to another SDK is not possible for now.

If you see the below screenshot(1st line) I can bind my power config cluster(0x0001) but cannot subscribe to it. I can subscribe to 0x0402 cluster though. Then if you see 3rd last line zcl attr read f4ce36c29f9d38f6 10 0x0001 0x0104 0x0021. With this command I can read attribute value and it is giving me correct value. The only problem is I cannot subscribe to this cluster and get it to reporting.

 

Here is my code where I am setting the value of battery may be this can help. May be because it is hard coded value of battery and that why its not reporting? Because temperature and pressure sensor values are changing using sensorsim function but my battery value is fixed(for now). But if this is the case at least I should be able to subscribe to it.

[AHaug]

Hi,

Thanks for supplying this additional information. My colleague and I will dig into this when they return to the office on Monday. I believe these attatchments will come in handy.

One more thing that might help is if you are able to generate and attach a sniffer log for us to investigate. The installation/tutorial process can be seen in this guide for Wireshark sniffer for 802.15.4. We will then need the entire pcap file generated if if you get that far. If you don't have the available resources or time to set this up, we'll do with what you've already supplied!

Kind regards,
Andreas

[AHaug]

Hi again and thank you for your patience,

After discussing it with my colleague we came to the conclusion that we might need more information. If you could either set up the Wireshark Sniffer and take a closer look at the ZCL: Configure Reporting Response status to see if it contains any information about what may cause the configure reporting command to fail. It should state something in the status message as to why it fails (screenshot below gives you a hint about what to look for). Else you may also zip your project and upload it here (as long as it does not contain any sensitive information), and we'll have a look with Wireshark to see if we can deduce anything from the trace.

As far as we saw from the Zigbee ZCL spec and your screenshots everything looks correct with the exception that the configure reporting command fails. The power configuration cluster battery information attribute set should be reportable/subscribable, and what you're doing looks to be correct regarding to formatting. The cluster identifier is 0x0001, the battery percentage remaining is 0x0021, and the type of 0x0021 is uint8 (i.e 32 in decimal).

 

This leads to one new hypothesis, and that is if the cluster somehow have been implemented wrong, but still is readable (which is a far assumption to make). Anyways, if you could supply us with either details about the configure reporting command or Zip and send us your sample, we will take one more look into what may cause this issue!

Kind regards,
Andreas

[AqibK]

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