I'm writing a driver that uses UDP to check a device's status. If the UDP packet doesn't receive a response, the Hubitat log shows the warning "Error occured with UDP message: SocketTimeoutException: Receive timed out" attributed to that device.
Is there a way to catch that warning/timeout somewhere in the driver code? (so that I can set the device as 'off')
My specified callback function on the HubAction isn't called at all, and neither is the default parse() function
I have tried wrapping the sendHubCommand(hubAction) in a try-catch, but the catch doesn't get triggered.
Can't see any relevant options in the HubAction docs either.
As far as I know there's currently no way to catch that warning - I could do with it too for my LIFX drivers.
Any thoughts on this @chuck.schwer? I remember you were considering sending a type of LAN_TYPE_UDPCLIENT_ERROR with the error details to the parse method. Is that still possible?
Be careful with this... Itβs not reliable. If there is any chance that more than one HubAction could be called while another is still executing the next call to runIn overwrites the previous one and the error is never caught.
Correct; with the condition "from the same device" for a device driver. Not necessarily good for a Smart App providing communications services for multiple devices.
It is the only option available to catch UDP error or no response from the device. So I am stuck with it. In one of my multi-plugs, a command to a specific plug is ignored if the system is busy responding to another command. I use 5 seconds, but a shorter time is acceptable.
Yeah I was thinking of doing something similar to that if there's no better option (with a state variable to prevent a second execution if the first is still running).
There's a telnetStatus function that is called when a telnet connection has an error - I was hoping there was something similar for UDP.
That wouldn't work anyway since sendHubCommand returns once the HubAction has been sent.
The UDP timeout will occur many seconds later; you really wouldn't want sendHubCommand to wait around that long.
It would have to be dealt with in the callback method - parse() probably wouldn't be sufficient for this.
It waits for a response for every other request. I would have assumed it would wait around for this request as well. Otherwise, how would you catch any exceptions?
I don't believe it waits for requests, my use of sendHubCommand is that it's asynchronous. What I think they really need here is the way JavaScript handles things like this, have one callback for success (already exists) and a different callback that gets fired when an exception occurs. At least that'd be one way to design it... @chuck.schwer
No, it doesn't wait. That's the whole point of the parse() method or the callback parameter. The only exception would be from a badly formed HubAction.
Yes, it will be available in 2.2.0 as an option to enable it and then we will have to decide if we make it the default in some future version and add an option to disable it.
parseWarning - (true/false) Used as part of UDP messages, instructs the system to send any error message back to the parse method of the device. (Since 2.2.0)
Is there a way to correlate the warning/error passed back by parseWarning to the original request sent via HubAction? Conceptually would like to use this capability to catch the timeout and retry the same UDP request again.
fair enough - I don't have a choice in the device protocol - what benefit do I gain from using parseWarning=true, then? Simply the ability to hide these "errors" from the logs?
One example would be to keep a counter of consecutive failures. If failureCount > X, send a push notification "the connection to device XYZ appears to be down" Something like that maybe? Perhaps the people on this thread who asked for it will weigh in on what they're using it for!