It is true that the users can create their own versions of the handlers that customise the reporting intervals, with or without Device Preferences. So I suspect a technical explanation of how to do it does help those raising this issue.
However I think there is also a non-technical element to the issue, which is that the reporting intervals should already be a user preference in the stock handlers. Users shouldn’t need to do anything other than tweak a Setting in the mobile app to make these changes as it is too common a requirement. So in that respect I believe it is a feature request.
Yes, I understand. For Z-Wave is easier to change the reporting values using the configuration parameters. That’s something we do in this sample and you could add more parameters there as you wish, as they’re sent in a loop, it wouldn’t be complex to grow the list:
In this case, we’re referring to a Zigbee device which reporting configuration is set when the device is joined (with the help of the default handlers)
I mentioned before that it is also possible to change the reporting configuration using the preferences and sending a TX Message to the device but:
We don’t know if the Zigbee device will accept a new configure reporting command after the first one, but is worth trying. (Does someone here had tested that?)
In that case, you could:
Avoid using the defaults for the specific capability
Use your own attribute/command handlers and call the defaults to handle the events.
Send the binding and configure reporting events from the doConfigure lifecycle.
For example, in the ST Multipurpose sensor sample, we set our own handlers to compare the value of the garageDoor preference first to decide how the event will be handled. If the device is not used as a garage door sensor, we call the default handler which makes the conversion and sends the event.
Don’t worry. I’ll surely share this suggestion for the samples.
Thank you all for sharing your opinions/experiences, they’re really helpful for us. Keep them coming!
Unfortunately it does not send the temperature reports with the modified values.
According to the logcat, the configuration is sent to the device and is received: Cluster TemperatureMeasurement> ConfigureReportingReponse || ZclStatus: SUCCESS>>>, but it continues to send the reports with 0.1º increments, but it is not configured correctly.
In the logcat, when doConfigure default is executed, it configures all the reports, temperature, battery … of the device.
I believe that with the proposed modification, when assigning “do_configure” function to the "doConfigure" handler “doConfigure = do_configure”, it no longer performs any default configuration, and only performs temperature reports configuration and they are not configured well.
I surely didn’t do it right the implement of recomendation.
For those of us who are not professional developers and we like this platform and community for giving us the opportunity to create and modify controllers to customize or use new devices, I think could be useful to expose my comments about how I have seen Lifecycle Event Handlers work by default and how they are described in the documentation, to understand how they work with the edge drivers in comparison with the methods used in the well-known DTH groovy.
removed: (In the documentation it calls it “deleted”)
Before the message in do_configure, are there any other TX messages that send the reporting configuration to the TemperatureMeasurement cluster?
I just want to confirm there wasn’t send another command previously and the new one was “rejected” despite the “success” message.
With the modification sent to configure the temperature reports, only those reports were configured because it was necessary to add device: configure () in the do_configure function.
When run the lifecycle doConfigure:
If device: configure () put it before the modified temperature configuration code: it performs all the default configuration and then reconfigures the temperature reports
If device: configure () put it after the modified temperature reports configuration code: it performs the temperature configuration and then all the default configuration.
It always answers: the configuration ZclStatus: SUCCESS > > >, but device always send the default configuration intervals. Tested several times.
On the other hand, About the default configuration and how it should work if it is recorded correctly on the device. How it works with a DTH:
This seen in the logs and app with a zigbee device configured with a DTH:
-The device only sends a message to the log and the app when a temperature change occurs that complies with:
Minimum interval: fulfilled
Maximum interval or Reportable Change: fulfilled
Device with an edge driver and configured with the default values (Min: 30 sec, Max: 300 sec, Reportable Change: 0.1º) this seen in the logcat and event history of the app:
In logcat every 300 sec (5 minutes) a temperature measurement event is received, even if there has been no change in temperature or it has been less than 0.1º. In the logcat the precision is 2 decimal places (xx.xxº).
In the history of the device in the app, only events with a temperature change => 0.1º arrive, even if more than 5 minutes have passed.
The device is the same for the DTH and for the edge driver. The configuration must be saved in the device and it is the one that sends the reports complying with the configured intervals.
With edge driver I don’t understand what is seen in the logcat:
Or the device is not configured correctly.
Or there is another routine in the driver libraries that interrogates the device with the default interval and generates the event if applicable
Or what see in the logcat is not what it seems.
Also add, with edege drive when you slide your finger on the device details, the refresh command is generated and the device sends refrech logs of all capabilities, including battery level.
This is not seen to happen with the DTH, which has the refrech () method.
There will be differences between DTH and Driver behavior. What must not change is the configuration set up for the device. If you want less often reports, change the 200 for a greater value or the minimum interval allowed for reports.
I set it to 30, 3600, 100, which is how I had this sensor with the custom DTH and it worked fine all night.
I have seen that it does not send temperature event in the configuration response, showing 0.0ºC until it sends it in the next configured interval.
As an update of the comparison of the battery consumption of the st multipurpose sensor with the default configuration values of Temperature reports (30, 300, 0x10) and the custom one with the code that you sent me with the subdriver (30, 3600, 100):
Default setting (30 sec, 300 sec, 0.1º):
In 4 days it consumed 15% of battery.
Custom configuration (30 sec, 3600 sec, 1°):
In 5 days 0% battery consumption
I still have it installed in case you want updating the consumption data.
In case it is taken into account for the final version of driver of st multipurpose sensor.
I can’t replicate the error, the list of my drivers is showing correctly, have you reported this to the Customer Support team? There might be a global issue that is causing the Automation deletion and this behavior.
I agree it’s weird, I’ll be monitoring it and checking if someone else reports it.