I am trying to figure out the current logic of the reporting configuration of a connected device but it is a bit too complex and I would appreciate a help.
I have few temp sensors and they are draining the battery pretty fast. I wanted to see what is the current logic for their reporting configurations since according to the device manufacturer, the battery should last more than a year when the reporting is configured to 2 minutes min.
I took a quick look at the source code of the Zigbee binding, and it seems that all devices get configure to report in 1-second minimum, not sure if that applies to end-devices as well.
AFAIK, this is not configurable by the user at the moment, but I don’t mind compiling a version myself and use it to fix this, all I need to know is what is the current logic and what is the best way to change it.
I do know his bindings have some restrictions due to the OH architecture. I also know he has written and Zigbee certified version of the binding. I am not sure if the OH one meets that standard though.
This is correct, hhwever, that does not really matter - or it shouldn’t. The reporting configuration uses two sets of logic - times, and change. So, we have 2 times - a minimum and maximum reporting period, and a change detection level.
It works as follows. If the level changes quickly (more than 0.1C), then you will get a report at the minimum reporting period. If the value never changes, or changes very slowly, you will get a report at the maximum reporting period (2 hours).
So, unless the temperature is changing rapidly, and continuously, the reporting will be very slow. I guess the real question is how often you are receiving reports? Really I expect it to be very low unless the device is not stable.
Thanks for the clarification @chris
It’s just like what I understand, and I agree with you about the change vs time.
But in my case, some sensors are located close to the HVAC duct, and I believe they might have temperature changes faster than 2 minutes for a good portion of the time. I think increasing the min temp change would differently set a bar for how fast they report even on fast changes (5 min is more than good for me).
The question is, where is the right place to implement this?
I found that we are doing some custom polling logic for RFDs in the ZigBeeThingHandler, and I assume it should be the place to implement a custom reporting logic as well, but I also found that current reporting configuration is being done in the respective ZigBeeBaseChannelConverterimplementation and it is not clear what is the correct way to pass the desired custom reporting values to the ZigBeeBaseChannelConverter. I would appreciate your input on this.
I went through the logs and found some sensors are reporting twice in a minute. The idea is, my device is a multi-sensor and it has 6 channels (battery voltage, battery level, temp, humidity, light, presence) and many of these values get multiple changes per minute. With configurable reporting, I can force all attributes to report no faster than 5 minutes, which is more than good.
It is just a way to make sure that the reporting is not what is draining the batteries.
I am also fine with implementing that myself for a private version of the binding and testing it, then later if it improves we can merge that change back.
Ok, thanks. I just wanted to make sure that there was some chance this might make a difference. I do tend to think that even 30 second reporting should last a long time, but if the device has a lot of sensors, then it’s always going to suck the battery a little.
Some converters have the ability to set the reporting. Take a look at the ZigBeeConverterSwitchLevel converter. You will find ZclReportingConfig - take a look at this, and feel free to retrofit this into the temperature converter.
