I’ve been developed a custom raw socket driver and I’m running into an issue/quirk I could use some guidance on.
Whenever no data is received on the socket for ~30 seconds, Hubitat generates a socketReceiveError in the logs. This happens even though the connection itself is still valid and the remote device is simply idle.
Is there a way to disable or extend this idle timeout so that socketReceiveError isn’t generated when the connection is otherwise fine?
If the timeout/error is fixed behavior, is there any way for a driver to catch or suppress the socketReceiveError so that it doesn’t show up in the logs?
As a workaround, I could implement a periodic heartbeat/keep-alive, but ideally I’d prefer to control how the platform itself handles idle sockets.
Has anyone dealt with this before, or found a best practice for keeping a socket open without generating repeated error messages when no data is flowing? Any pointers would be appreciated.
Feel free to review the driver as well it works very well, this is one quirk I have not been able to circumvent.
Have you tried adding a timeout parameter/key? It looks like that should work and that the default is 30 seconds, which appears to match up with what you're seeing.
Thanks for the response and you are correct, however only applies if you are not using EOL.
readDelay - Optional. The amount of time in milliseconds between reads from the socket, defaults to 150. (Cannot be used with eol)
Since the protocol data is sent with "eol" it makes it a little simpler not need to parse the bytes then dispatch as you could get a partial read or more data. I suppose I can read into a buffer and parse and dispatch.
I might play with this concept with a test driver first and see how the behavior changes.
Also 150ms is .15 seconds so not a direct correlation to the message. I am hoping the Hubitat dev team can address why those messages occur and possibly improve the behavior, it's consider "Alpha" but the ability to use raw sockets is fantastic. They mentioned to report any issues to the "Community".
Again not saying it will help, but that's not what I was talking about. These are two different parameters, and I am referring to timeout in particular.
I am appreciative of anyone who has ideas and thanks for reaching out about it. We'll see when I get time to test it; unfortunately the behaviors are not documented so who knows what it does internally. Is any of the code for Hubitat open sourced just so we can gain visibility into what happens behind the scenes?
No, though some driver and app code that is identical or similar to that built in to the hub has been shared.
I can tell you that all of the socket interfaces share a base class that uses the same options map (maps are how named parameters work in Groovy -- where your keys like timeout are), though I suppose the underlying networking library may use them differently (or not at all) based on the actual type of connection.
and thanks for reaching out about it. We'll see when I get time to test it; unfortunately the behaviors are not documented so who knows what it does internally. Is any of the code for Hubitat open sourced just so we can gain visibility into what happens behind the scenes?
