Zigbee attribute reporting not reporting as configured.

RE: Zigbee attribute reporting not reporting as configured.

Marjeris Romero — Fri, 15 Nov 2019 13:58:09 GMT

Yes, this issue was fixed in SDK v3.2.

RE: Zigbee attribute reporting not reporting as configured.

WestCoastDaz — Thu, 14 Nov 2019 03:25:53 GMT

Looks like this bug

[quote userid="73423" url="~/f/nordic-q-a/49156/zigbee-attribute-reporting-not-reporting-as-configured/196872"]Is there a workaround to the bug you mentioned to store the reporting configuration?[/quote]

is fixed in SDK v3.2, see this line from the release notes.

- Fixed a bug that caused the reporting configuration to fall back to default values after the device reboot.

RE: Zigbee attribute reporting not reporting as configured.

AndreasF — Wed, 10 Jul 2019 09:47:17 GMT

Hi Patrick.

Sorry for the late reply.

I have not found any more information about attribute reporting configuration than what is written in ZCL 2.5.11.2.

I think that should clairfy attribute reportings should be sent.

Best regards,

Andreas

RE: Zigbee attribute reporting not reporting as configured.

Patrick — Fri, 05 Jul 2019 14:26:00 GMT

[quote userid="73423" url="~/f/nordic-q-a/49156/zigbee-attribute-reporting-not-reporting-as-configured/196872"]The only workaround so to speak is to set ERASE_PERSISTENT_CONFIG to ZB_TRUE.[/quote]

So do not rely on attribute report configuration in at least this version of ZBOSS for both device-side and coordinator side configuration. This configuration must take place every time the device connects.

RE: Zigbee attribute reporting not reporting as configured.

AndreasF — Fri, 05 Jul 2019 14:17:31 GMT

Hi.

[quote user="pcaddict"]a report will only be sent if the reportable attribute is also greater than the reportable change value. Is this correct?[/quote]

I will ask our developers about this so that we get a proper answer.

[quote user="pcaddict"]Is there a workaround to the bug you mentioned to store the reporting configuration?[/quote]

The only workaround so to speak is to set ERASE_PERSISTENT_CONFIG to ZB_TRUE.

Best regards,

Andreas

RE: Zigbee attribute reporting not reporting as configured.

Patrick — Thu, 04 Jul 2019 15:11:31 GMT

Perhaps I have misunderstood how periodic reporting works. I was expecting that once the maximum interval was reached for any given cluster the reportable attribute would be reported, regardless of value. I thought I had read this in the copy of the ZCL spec I have but looking again I see that the section that should describe report behavior (2.4.7) is apparently a misprint. Looking at another vendor's documentation it would seem than even when the maximum interval has been reached, a report will only be sent if the reportable attribute is also greater than the reportable change value. Is this correct?

Is there a workaround to the bug you mentioned to store the reporting configuration?

RE: Zigbee attribute reporting not reporting as configured.

AndreasF — Thu, 04 Jul 2019 12:42:02 GMT

Hi.

Could we try to summarize a bit here, there is a lot of information in this ticket now.

There is a known bug in ZBOSS that if ERASE_PERSISTENT_CONFIG is set to ZB_FALSE, as you previously had, the reporting configuration is not properly stored in NVRAM data, so it is reset to defaults after device reboot. The log file appear to show that the device is reporting correctly.

From the log file you provided, do you see that there are places, where the report is generated, but it shouldn't be? Do you see that there are places where report should be generated, but it wasn't?

See attached table for reference.

Best regards,

Andreas

RE: Zigbee attribute reporting not reporting as configured.

Patrick — Wed, 03 Jul 2019 01:31:06 GMT

Andreas,

I have attached a hex file configured as requested. Sensor readings have been replaced with values from the sensorsim library so hopefully it behaves in a similar enough fashion for testing. I did let the device run a bit and I think reporting is following the configuration set by the device, not the hub. After a period of time I did notice that reports would be delayed, though not to the extent as I was previously seeing.

Finally, in an effort to make this a little easier than me having to compile any change you need I have created a SES project. Unfortunately I was unable to get SES to play nicely with any C++ so I have removed the sensor drivers and changed over a few other calls to make it compile in C. I fear that this may change too much to have testing mean much but it is worth a shot.devzone.nordicsemi.com/.../zigbee_5F00_multi_5F00_sensor_5F00_pca10056.hex

devzone.nordicsemi.com/.../ZigbeeTempSensor.zip

RE: Zigbee attribute reporting not reporting as configured.

AndreasF — Tue, 02 Jul 2019 13:27:40 GMT

Hi.

Yes, that would be great. So that I can test it on my DK's.

Best regards,

Andreas

RE: Zigbee attribute reporting not reporting as configured.

Patrick — Tue, 02 Jul 2019 12:26:55 GMT

Will you also need me to keep the firmware from communicating with TWI devices?

RE: Zigbee attribute reporting not reporting as configured.

AndreasF — Tue, 02 Jul 2019 10:32:34 GMT

Hi.

I'm not really able to build the mutli sensor project with your main.c and zb_multi_sensor.h file, could you provide me with your output hex file that is configured for channel 16?

Would also be great if you could enable the binary trace by doing the following:

Change ZBOSS library to the one inside the <InstallFolder>\external\zboss\lib\debug folder
Configure the NRF logger module sdk_config.h
Set the trace mask to 0xC48 and trace level to 3.

It's described more in details here.

Thanks.

Best regards,

Andreas

RE: Zigbee attribute reporting not reporting as configured.

Patrick — Tue, 02 Jul 2019 01:47:38 GMT

Hi Andreas,

I am only working on an end device and do not have a coordinator or router set up on another dev kit. I did have another end device running a slightly older firmware based on SDK 3.0 that worked fine, connected to the same SmartThings hub I am using but had to replace the firmware so I could get a packet capture. The previous firmware did not have report configuration done device side (though I did try at one point and was seeing similar results).

In order to provide the information you have asked for I changed ERASE_PERSISTENT_CONFIG to ZB_TRUE in order to capture the network key. Prior to this the device had ERASE_PERSISTENT_CONFIG set to ZB_FALSE. I made no other changes to the code. I have attached both my main.cpp and multi_sensor.h files for you to look over. I'd offer to provide the entire project however I am not using any of the supported IDEs.

This is good to know and I will make this change in the future. I was originally using integers and apparently confused myself with unit conversions.
Sniffer log and pertinent source files attached.
As I mentioned above, ERASE_PERSISTENT_CONFIG was set to ZB_FALSE prior to resetting the end device so that I could get a good capture.

While performing the capture I noticed a few things that I will note below. There are a few more oddities besides just reporting that I am seeing and cannot explain them. This capture was performed on a device that had just been commissioned on the hub. For your reference, the decryption key is 06647d2cfe5166a84bc692ae0c41c658. The device address is 0xdd26.

Frame 197: ZCL IAS Zone: Zone Enroll Response. I have no idea why this is here. Nowhere in my code do I have endpoint 0x0500. This is seen sporadically throughout the capture (Frames 228, 230, 2900).
Report configuration occurs around frames 204, 236, and 246. The report configuration parameters are those set by SmartThings.
Frame 865 looks to be the first temperature report. I left the device for close to 20 minutes and only began to receive reports when I placed the device near an air vent to speed things along. The device was commissioned at 5:32 and the report came in around 5:57.
To test the device not reporting correctly after a reboot, I reset the device to observe its behavior. Frame 2349 is around the occurrence of the reboot. The device was rebooted at 6:54. The previous temperature report occurred at 6:41 and the next not until 7:22. While reporting still seems random at times, the device did settle into using the long poll interval after a device reboot faster. Perhaps clearing persistent storage had something to do with this.
Frame 2568: After reboot, humidity is reported.
Frames 2824, 3286, and others show a read attribute. I am not entirely sure what triggered this.
Frame 2880: Battery percent remaining is read. For whatever reason the data reads 39.5, actual value is 79 and this is reflected in SmartThings. This is probably not an issue, just something I am not understanding.
Frame 3434: Final temp report that I logged. This was 42 minutes from the previous report.

Unless I have completely missed the boat, the device should be reporting any value when the maximum interval has been reached. Prior device behavior had attribute reports coming in no later than the maximum interval consistently.

I am also very confused as to why I am seeing packets containing the ZCL IAS Zone cluster and some other cluster that I have not been able to identify, 0x8021. I do not know which frame might show the latter but I did notice it in both the capture and SmartThings log when the device first joined. Neither of these are defined in my project so their presence is a mystery.

devzone.nordicsemi.com/.../ZigBeeTemperatureSensor.cpp

devzone.nordicsemi.com/.../zb_5F00_multi_5F00_sensor.h

devzone.nordicsemi.com/.../ZED-Capture.pcapng

Thanks for taking a look.

RE: Zigbee attribute reporting not reporting as configured.

AndreasF — Mon, 01 Jul 2019 05:44:50 GMT

Hi Patrick.

Could you provide me with Sniffer Logs and the whole main.c? Also, are you only making the end device, do you have other devices as well?

1) Try to use integers, not hex.

2) It would be great to look at the Sniffe Logs and main.c for more information on this.

3) Do not set ERASE_PERSISTENT_CONFIG to ZB_TRUE, set it to ZB_FALSE

Best regards,

Andreas