@orangebucket,
Have you tried if the app’s utility works for you, in the device’s tools menu, to change the driver?, Which would be similar to how you change dth in IDE.
I have asked in several posts and nobody answers.
I just have the Motion Sensor driver installed and there aren’t any alternative drivers offered for the IKEA sensors so I have nothing to test with.
1 Like
I have managed to test the app’s tool to change the device driver from the device details menu.
The error it gave was due to the fact that the driver available to change was not compatible with the device. But instead of saying that, “he said to make sure the phone was connected to the network”.
To test it I have created another driver with a different name and key package than the one that is installed, I added -v1 to the name and key package.
When clicking on use another driver in app, the existing -v1 offers you and the driver change works fine, it is similar to the DTH change in IDE.
In the live logging you can see the process, taking place.
What I have seen that the response of the device is not the same as when you pair it after uninstalling it:
-
When paired, you can see the response of the interval configuration of the battery reports and others.
-
When changing one driver for another, there is no response to the configuration of report intervals.
I don’t know if someone can confirm or clarify it. It would be important to change the temperature reporting intervals without having to uninstall the device.
1 Like
Regarding your comment here:
When you changed the Driver and received the error, there was no content in the Hub logs?
You can change the reporting intervals without having to uninstall the device by adding the “preferences” section in your device profile.
This will depend on what your Zigbee device supports (min, max, etc.). Look at these preference samples:
The first reporting configuration occurs when the device is joined but you can try to send a TX message directly with the new configuration and see if the device accepts a new reporting interval. See:
When I change to an incompatible driver (device figerprint not in fingerprints.yml file) it gives me the error “Be sure that your phone is connected to the network”, but in the Hub log with CLI nothing appears and neither in the Hub events in IDE.
On the other hand, I saw that from time to time I have IDE Hub events, there are error events of the two drivers that I have installed “zigbee smoke sensor” and “smartthings mutiporpuse sensor”. I put some screenshots for what it’s worth
HubUpdated event appeared after pairing a device with edge drive
This example of aeotec multisensor is a zwave device and I think it is different than for zigbee.
I sent to @Zach_Varberg a PM to comment on the changes he had made in the configure reports code for the smartthings multiporpuse sensor beta and it did not work for me.
I put the link, maybe I should have written it public instead of private, sorry
Oh, that makes sense. Maybe we would need a better message for the error, I’ll share that with the engineering team.
If you call the Driver change and you see no logs in the “logcat” command, it means the Driver is not being executed. The main reason is that the device fingerprint doesn’t match the ones in the fingerprints.yaml file(as in your case).
It’s normal that there are no logs in the IDE about that, as the Edge Drivers are not fully supported there, I would suggest you use the ST API as a reference of your device configuration and status and of course the CLI logcat.
I meant only the section of preferences in the profile, the syntax is the same for all types of devices. (what changes is how they’re sent to the device)
You can also see them in the documentation, here:
https://developer.smartthings.com/docs/devices/preferences/preferences
What didn’t work for you? No problem, I cannot see the content of the PM but you can add it here again (avoid sharing private information such as IDs, emails, etc.)
I have been testing the edge driver st-multiporpuse sensor of your link posted and I wanted to make the following comments:
- Created the package and installed in hub correctly.
- I modified the configuration values of the temperature reports in the Lua file: C: \ … SampleDrivers \ st-multipurpose-sensor \ src \ test \ test_smartthings_sensor.lua.
-
I modified line 100 from:
test.socket.zigbee: __ expect_send ({mock_device.id, TemperatureMeasurement.attributes.MeasuredValue: configure_reporting (mock_device, 30, 300, 0x10)})
TO:
test.socket.zigbee: __ expect_send ({mock_device.id, TemperatureMeasurement.attributes.MeasuredValue: configure_reporting (mock_device, 30, 3600, 200)}).
- Once the driver is installed in the multi sensor, it is seen in the log that the configuration values sent to the sensor are still the original ones, not the ones I modified. And those are with the intervals with which the sensor sends the reports.
See screenshots:
The minimum value is 30 (1E)
The maximum value, although it puts minimum in logs, is 300 (12C)
The reportable change is 0x10 (16)
What am I doing wrong?
Don’t you have to change it in that .lua file?
Thanks
Ooh, I see. Ok, the file of test_smartthings_sensor.lua is used to test the Driver before installing the device, this means that those are “fake” values sent to your Driver to test the response and they run on your computer only. See the related documentation.
The Driver uses the default handler for the TemperatureMeasurement capability which has those values for min/max interval.
Let me check some details about this change and I’ll let you know the feedback.
1 Like
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?
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)
1 Like
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%)
UPDATED:
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.
1 Like
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.
1 Like
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.
1 Like
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.
1 Like
@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
Settings button
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.
2 Likes
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
doConfigurelifecycle.
- 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
