Sorry, I had not seen this documentation.
No wonder it doesn’t work, hahaha!
The values are in the st.zigbee.defaults library which is loaded into the init.lua.
So those defaults can be changed in preferences?
Sorry, I had not seen this documentation.
No, the preferences act as parameters that you can enter into your Driver, and you can use them as you like. This would be in case you would like to constantly change the reporting interval but it is not certain your device will accept a new reporting value after being joined.
The other option is to change the value set when the device is joined (this is what I’m checking, I’ll give you an example)
Thanks, i will wait.
The use of default configuration values of the devices greatly facilitates the writing of drivers, but if they cannot be overwritten it will limit the options for using the devices.
To change the settings of the temperature report intervals for the smartthings multisensor is not a whim, it is a matter of excessive battery consumption.
These have a CR2450 battery and with the default values:
- minimum interval: 30 sec
- Maximum interval: 300 sec
- Reportable change: 0.1º
In practice, it sends a report for every 0.1º change or every 5 minutes, whichever occurs first if temperature change.
Whoever designed this device with this battery, I don’t think they thought it was going to be used by default with a precision of 0.1º. Temperature sensors on doors and windows are not suitable for use as thermostats. They do not give usable and reliable information unless they are posted on interior doors of the house.
I use the modified dth to save battery with values since 9 month:
- minimum interval: 30 sec
- Maximum interval: 3600 sec
- Reportable change: 1º
With these values, it sends a report every 1º change or every 1 hour, whichever occurs first if temperature change.
The battery has consumed 17% from the end of Nov 2020 until yesterday August 30, 2021, when I installed the edge driver.
When I installed the edge driver the battery showed the same level as with the DTH, 83%.
In just 24 hours with the default values it has consumed 4% (79%)
In 3 days the battery has already consumed 15%, it shows 68%
I have three smartthings sensors, now aeotec, and I use them for door and automation control and the temperature only as statistical information. If they can’t be modified I’ll have to throw them away when groovy disappears. I do not plan to change batteries every 20 days or put a glob of AA batteries attached to the sensor, hahaha …
On the other hand, another “Health poll” seems to be another default value, which is seen in the logcat every 30 sec. I don’t know what impact this will have on the devices with battery. With DTH I am not aware of this being the case on all devices.
I rather assumed it must be the driver being polled by the device health subsystem for the latest health status metrics, rather than any interaction going on with the device.
It is another thing to be documented really. If we can view the logs we need to be able to know what extras we might see.
Update: I now rather assume I was wrong in my assumption. I think it is probably more like a mechanism to implement a checkInterval and a ping() on a per attribute basis. However I still don’t think it is going to cause any extra device activity on a properly working device. Or to put it another way, on a Zigbee device it ends up running check_monitored_attributes() which might not be what I just wrote at all.
Unless we can change the default reporting values you’re going to have people spamming the network unnecessarily. Say you have 8 ST Open Close sensors that experience 25 degrees variation in a day, that’s 25 divided by .1 equals 250 calls for a single device, and 2000 calls for 8 devices a day!!
Thanks to @Mariano_Colmenarejo and his work on the Groovy dth, I don’t make 2000 calls a day and spam the network, but only 150. It’s a full time job limiting the amount of traffic devices send that aren’t necessary, please @nayelyz, make it easier for us.
Ok, just to be in the same page, the preferences are not needed if you want to change the reporting interval one time.
I reviewed this with the engineering team and they mentioned that we could overwrite the default configuration by doing this (you just need to change the reporting values):
Please, help me test it and let me know your results.
@nayelyz This kind of settings/preferences are always needed.
This is Monoprice PIR Multi sensor
When i select Settings
This Page comes up, with settings for units, data refresh, etc…
And another example Zooz Double Switch Dimmer
And now settings page
Users should be able to cusomize devices as they wish.
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
- In that case, you could:
device:send(device_management.build_bind_request(device, TemperatureMeasurement.ID, self.environment_info.hub_zigbee_eui)) device:send(TemperatureMeasurement.attributes.MeasuredValue:configure_reporting(device, 1, 0, 3200))
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!
Thank you!!! @nayelyz
I introduced the changes eliminating what I thought was not necessary, since the example code is for a temperature sensor driver, not a multipurpose one.
In order for the configuration to be carried out, it must be uninstalled and paired again.
With DTH only need update DTH in IDE.
It would be good if the configuration was updated when the driver is changed in the APP, since if you change the driver you should reconfigure the device too
I put the values:
- minimum: 30 (1E)
- maximum: 3600 (E10)
- Reportable change: 200
The answer seems to have been correct.
By the way in the message library the Maximun_reporting_interval is wrong, Repeat “Minimun”
I will report if sensor report with those new intervals
I put the capture of the configuration response
That’s awesome! I’ll be pending on the final result.
I’ll share this comment right away, good catch!
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.
The “doConfigure” handler is part of the defaults and is also executed in the driver without modifying, by default with driver: run ()
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”)
It is quite well defined that each one does in the driver documentation:
The execution flow that I have seen for the usuals procedures with the devices and comparison with DTH, if there is one:
New installation of a device:
EDGE: init → added → doConfigure → infoChanged
DTH: installed → configure → parse
Uninstalling the device:
EDGE: removed (in documentation says “deleted”)
Change of EDGE driver for another one for a device in app:
EDGE: init → added → driverSwitched → infoChanged
DTH change in IDE: configure → parse
For zigbee devices, it might be useful to also run doConfigure, since when you change the driver it may be necessary to reconfigure the device, as is done in IDE when changing one DTH for another.
Another solution could be to put a button in the details or settings menu of the device, option to “run configuration” as there was in the classic app a tile "Configure"
When you slide your finger on the details of the device, you see in the logcat how “refresh” is executed. The configuration could be executed in the same way with a tile or menu option.
Device name change:
EDGE: infoChanged ( I see the name changed en API and IDE immediately, but in the logcat the execution of infoCanged was about 2 hours later and it updated the name of the devicer)
Device preferences change values (temperatureOffset for example):
Finally there are the lifecycle_message_handler and ZigbeeMessageDispatcher: default_handlers
- That they would do the work of the “parse” method. Handle the received events, process them and send the messages to the devices and events to the platform.
The fact that all this is already written by default in the libraries, makes the construction of simple drivers is much easier. with less than 50 lines of code you have made an edge driver.
What I still do not see clear is how to modify these default values, which may be necessary to customize the operation of some zigbee devices.
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.
The handlers ini, added, doConfigure (modified) and finally infoChanged are executed in this order.
I have the complete installation log in a text file. How can I send the file?
I also have in another file the log of the installation with the original driver, which is correct and the difference is perfectly appreciated.
With the modification, it makes an incomplete configuration, only temperature, the rest will be data the device saves by default when you reset it to pair it.
In fact, the device is not configured well, it responds very slowly, 10 seconds or more delay in processing the opening events, closing vibration …
Please, send the files to email@example.com so I can check them, it would be really helpful.
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.
Ok, I think I figured it out.
I updated the previous Gist so you can take a reference:
The change is similar, but:
- It is done in a subdriver.
- I added the
device:configure()instruction which configures the other capabilities with the defaults (thank you for that)
- I removed the
temperatureMeasurementfrom the supported capabilities list as this is sent to register the defaults.
- I added a handler for the
measuredValueattribute) and call the parsing method in the defaults
These are my results:
- The updates are sent when there’s a change in the temperature of 200 or above
- This can happen at any interval of time
- The values are shown correctly in the device history (in the corresponding timestamp)
- This is a comparison table of the values:
|Timestamp||Reported Value||Parsed Value|
|13:10||3238||32.38 > 32.4|
|13:12||3498||34.98 > 35|
|13:16||3711||37.11 > 37.1|
|13:22||3365||33.65 > 33.7|
|13:24||3143||31.43 > 31.4|
|13:29||2927||29.27 > 29.3|
|13:37||27.13||27.13 > 27.1|
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’ll try it tomorrow, now I’m a bit busy and tell you something.
Thank you so much!!
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.
If you think it is necessary and you want to move these posts to another new thread about Configuration of custom reports.