[ST Edge] Driver Deep Sleep?

I have been noticing a consistent behavior in each of the LAN drivers I am developing. If no http requests are made for an extended period of time (e.g. overnight) then the first request takes a very long time to be made (3-8 seconds). If I trigger additional events, they are all sub second and stay that way while hitting the driver.

I am guessing that the underlying socket layer is reusing tcp connections to keep it fast during quick calls, but the initial delay is confusing.

@nayelyz / @robert.masen Do you know if drivers/hub go into some sort of deep sleep? Is there anything we can do to encourage connection reuse for http requests? Does something like keep-alive apply to edge drivers?


All my lan driver does that since a few days


Is that coming from actions within the ST app that trigger http request?

Scheduled HTTP request seems to be fine.

1 Like

Yes, from actions and from button presses within the ST app. It’s very reproducible for me. Maybe the delay is coming from the cloud calling back to the edge driver. Not sure where it comes from, just that it goes away while the driver is actively used.


We do not put drivers into any kind of a deep sleep at this time. I would imagine it is being caused by the length of timeout being set on a socket and the lack of tcp keep-alive. One option you could try would be to reduce the socket timeout by calling settimeout on your cosock socket with a small number like 0.5 or 1. If you receive multiple timeouts in a row, treat that as a closed error and re-connnect the socket. We are hoping to add tcp keep-alive soon however we don’t have an official timeline.


I have been trying things out to try and eliminate this delay. Do you think your luncheon library would do the trick since we can provide it the socket we want to use? Can we just create a shared request socket and use it for all of the luncheon requests so it doesn’t get closed? Not sure what the implications would be with multiple devices pushing that socket.

Do you think your luncheon library would do the trick since we can provide it the socket we want to use

Luncheon is primarily concerned with serializing and deserializing http messages, so if you are using http then it could work. The one note is that we still don’t have support for chunk encoding in Luncheon so if your response bodies are chunk encoded, you will need to provide your own source which would handing that encoding.

Not sure what the implications would be with multiple devices pushing that socket.

So long as the server is capable of handling that kind of behavior then you should be fine. This would require coordinating an http keep-alive with server but you should be able to make Luncheon send multiple Requests on the same socket

@robert.masen I am now seeing ~30 second delays for the first REST call after a long downtime. I see this on all LAN drivers that use REST. After this call is made, further quick calls are executed as expected. This time noticeably increased with the latest firmware update.

Hey Blue,

a long downtime

Can you provide a general duration you see this happen at starting with, for example after 5 minutes the request time jumps, or after 1 hour?

Also can you classify

LAN drivers that use REST

Is this with socket.http or is it with Luncheon? Are you creating a new tcp socket for each request (default for socket.http) or are you re-using the same socket across multiple requests? Does an error come occur between the long request and the subsequent short requests?

Sorry for the delayed response. I haven’t nailed down a firm time, but It seems like a hour or so of downtime results in a long delay on the next call.

I am seeing these delays for drivers that are using http = cosock.asyncify 'socket.http'. I have experimented with Luncheon but have not tried it for a real driver yet. As of right now, I am letting socket.http create and manage the socket.

There are no errors that come across. There is simply a delay. I can see the event come into the driver, then there is a long delay, then the http request goes to the device.