Is there a tracking command for DTH?

Hi, All:
I want to track how my DTH file is run through Z-Wave Zniffer. But some functions do not seem to be called. I try to send commands to track, but the sent commands seem to interfere with the process. I hope that there is a method similar to log.trace or log.debug, which can observe the value of certain variables in Z-Wave Zniffer or know where the program is running, but this command cannot affect the normal process. Excuse me, does such auxiliary debugging command exist?

Hi, @chenjun.
So, you want to see the logs of the commands sent from the handler to the physical device?
Have you already tried the log.trace and log.debug in your DTH parse methods but you need more info?

Hi,@nayelyz
In the IDE simulator, I can see the information I want through log.trace and log.debug. The problem I have now is that I find that preferences do not work, but I cannot track the cause in the simulator.

ooh, so you receive the value of the preference correctly but when you send the zwave.configuration to the device, it doesn’t take effect, is this correct?

Please, share your preferences config and the commands you use to send them to the device.

Hi, @nayelyz:
My DTH file is implemented by referring to aeotec-trisensor.groovy, and the virtual device using aeotec-trisensor.groovy also has the same problem. But another file eva-logik-in-wall-smart-switch.groovy, the virtual machine created will not have such a problem.

Ok, I reviewed your situation with the engineering team and the feedback is:

  • The configuration Get command helps you verify if the device is saving the values you sent
  • Check if the values you send for the device attributes are correct ( that depends on the physical device config).
  • They suggest using the scaledConfigurationValue parameter in the configuration set instead of calling your own parsing method to avoid having issues with it - configurationValue: intToHexBytes(param.value, param.size).
    Here:

Let me know if you have any questions.

Hi,@nayelyz:
Thank you for your reply, I noticed this difference, because in my comparative test, the DTH file eva-logik-in-wall-smart-switch.groovy was implemented using the method you mentioned, and I also synchronized this to my file. I tracked the running track of the device loaded with eva-logik-in-wall-smart-switch.groovy, and found that after the preferences were changed, the “updated()” method was first called in eva-logik-in-wall-smart-switch.groovy, the method “executeConfigureCmds” involved in the statement "runIn(5, executeConfigureCmds, [overwrite: true]) "in “updated()” will be called quickly. But in my file, even if I use the same method to call, “executeConfigureCmds” will not be called immediately. I have observed that it is called after a long time, but it is random. If I don’t use the “runIn” method and call “executeConfigureCmds” directly, a large number of “Routed Errors” will be observed in Z-Wave Zniffer.

I don’t understand the function of the “runIn” method. Where can I find the instructions for using this method? The current observation is that there are differences in the implementation of this method.

The runIn() method is used to schedule the execution of the method after the defined seconds have elapsed.
The [overwrite: true] parameter avoids having duplicated events as it overwrites any pending schedule.
Here’s the documentation about scheduling events:
https://docs.smartthings.com/en/latest/smartapp-developers-guide/scheduling.html#schedule-from-now-runin
What is the maximum time the call has been delayed?
Also, it’s important for us to know:

  • Why in the updated() method, initialize() is called again?
  • Does your device have a sleep timer? This means that if it doesn’t receive activity for a while it gets into a sleep mode. If it does, ST won’t be able to send the configuration commands successfully whenever it isn’t awake.

Hi,@nayelyz
Sorry, regarding the setting of checkInterval (in initialize()), I actually only implemented it by referring to the file eva-logik-in-wall-smart-switch.groovy, and did not fully understand its purpose. I reviewed the code related to the public warehouse and found that there is no unified process for the setting of checkInterval.

Hi,@nayelyz:
Although initialize() is called repeatedly, it is conditionally judged before sending the command. I am not sure if my device has a sleep timer, if so, how to set it? If not, how to set it up? Sorry, I found that this part of the code in the public repository seems a bit confusing.

Hi, @nayelyz:
I found two ways to check whether checkInterval should be updated:
One is:

  The other is:

Which one do you recommend?

checkInterval belongs to the HealthCheck capability, the difference I see between the two options is that the event data is mapped first in one but the configuration is very similar.
Would you update it constantly?
Here are some details about this event:

It depends on the manufacturer and is better not to have one because the healthCheck capability would evaluate this device as offline constantly.

Many of my connected devices are offline, which may be the reason. I asked our electronics engineer that we only have one product that supports sleep timer, which means that most of the HealthCheck function in DTH files can be removed, right?

No, HealthCheck is key.
I suggest you evaluate each device and verify its behavior/configuration:

  • From the Device status, you can see the checkInterval and if they’re tracked or not.
  • Check if the ping() function is called correctly (every checkInverval)
  • Verify in the /health endpoint, the current device’s status (online/offline)
  • When you recently install the device, try setting the attributes and check if they’re saved.