That’s awesome! I’ll be pending on the final result.
I’ll share this comment right away, good catch!
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.
The “doConfigure” handler is part of the defaults and is also executed in the driver without modifying, by default with driver: run ()
DeviceLifecycleDispatcher: smartthingsMultipurposeSensor
default_handlers:
infoChanged:
removed:
driverSwitched:
init:
added:
doConfigure:
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.
DeviceLifecycleDispatcher: default_handlers:
init:
added:
doConfigure:
driverSwitched:
infoChanged:
removed: (In the documentation it calls it “deleted”)
It is quite well defined that each one does in the driver documentation:
https://developer-preview.smartthings.com/edge-device-drivers/driver.html#lifecycle-event-handlers
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):
EDGE: infoChanged
DTH: updated
Finally there are the lifecycle_message_handler and ZigbeeMessageDispatcher: default_handlers
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 build@smartthings.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:
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:
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:
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:
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:
device:configure()
instruction which configures the other capabilities with the defaults (thank you for that)temperatureMeasurement
from the supported capabilities list as this is sent to register the defaults.temperatureMeasurement
cluster (measuredValue
attribute) and call the parsing method in the defaultsThese are my results:
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.
Great!!
I’ll try it tomorrow, now I’m a bit busy and tell you something.
Thank you so much!!
@nayelyz,
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.
Thanks
Hi @nayelyz,
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º):
Custom configuration (30 sec, 3600 sec, 1°):
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.
Thanks
Thank you for your feedback. I already reported the concerns about the default values, the engineering team will analyze the next steps regarding this matter.
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.
I have not been updated either, but I have noticed since today that when you change the driver with the app tool, all the drivers that are in the hub no longer appear:
It doesn’t seem like a mistake to me.
It seems like an improvement to me, but it is unclear.
A text could come out saying: there are these compatible drivers for this device.
Now it shows the device label, matching in the Hub drivers.
In this case, exist other driver compatible for “Lidl Bulb’”.
By clicking on the label app choose the compatible driver to install.
In this example Two drivers compatibles found for “Lidl Bulb”
It should show the names of the compatible drivers instead of the device label
If you click on the magnifying glass, it shows you all the ones in the hub, as before.
Hi @Mariano_Colmenarejo , @nayelyz
Could you share how to execute integration tests? I’ve searched everywhere but docs (Driver Tests — SmartThings Edge Device Drivers documentation) only describe the codding itself.
Best regards!
I have always tested with real devices
I can’t help you in this
Saludos
Do you mean to what is described in this document?
https://developer.smartthings.com/edge-device-drivers/integration_tests.html
I suggest you check the /test
directory of the drivers released by SmartThings. Eg: