Edge Driver HTTP Close when Call HTTP Request

Developer Programs Writing Edge Drivers
1

Hello there.

I’m making an HTTP request by changing the example of esp8266.

The following is a common function.

------------------------
-- Send LAN HTTP Request
function command_handler.send_lan_command(url, method, path)
  local dest_url = url..'/'..path
  local res_body = {}

  log.trace('request to ' ..dest_url..' method ' ..method)

  -- HTTP Request
  local _, code = http.request({
    method=method,
    url=dest_url,
    sink=ltn12.sink.table(res_body),
    headers={
    }})

  log.trace('response code ' ..code)

  -- Handle response
  if code == 200 then
    return true, res_body
  end
  return false, nil
end

The function request is performed as follows.

  local success, data = command_handler.send_lan_command(
    device.device_network_id,
    'GET',
    'data')

The device_network_id is entered as follows.
ex) http://192.168.0.12:80

therefor log msg in log.trace(‘request to ’ …dest_url…’ method ’ …method) shown like

request to http://192.168.1.12:80/data method GET

In this state, the following errors are continuously displayed.

response code [string “socket”]:1406: closed

I’d like to get advice on this matter.

Regards.

2

Welcome to the SmartThings Community, @ktj1312!

Are you sending this request to an external device or is it a request within the driver?
If it’s for an external device, do you get that error before receiving the request on the device?
If it’s a request within the driver, please check my post here, there are some changes we need to apply to send internal requests.

3

Hi there.
I don’t understand what is external device mean exactly.
Here is my network configuration.
Router IP 192.168.1.1
ST Hub 192.168.1.71
Target Device 192.168.1.82

I don’t understand

mean.

for detail I use the function like this.

------------------------
-- Update Device Status
function command_handler.update_device_status(device)
  -- Refresh Device Status
  log.trace('Refreshing Device Status')

  local success, data = command_handler.send_lan_command(
    device.device_network_id,
    'GET',
    'data')

    log.trace(data)

  -- Check success
  if success then
    log.trace(data)
    local resp = json.decode(table.concat(data)..'}')
    return true
  else
    log.error('failed to poll device state')
    return false
  end
end

and blow error

show at this line.

4

I meant it was a command sent from the Hub to another device like the ESP8266 because other developers have given the sample other purposes.

As I understand per your description, you send the command to the device (192.168.1.82) and it is received there but when it returns a response, the driver shows the message response code [string “socket”]:1406: closed

Have you checked how long does it take for that error to appear? This is to check if it wasn’t caused by a timeout in the response.

5

I am also seeing the same error when sending a http request to one of my house devices.
The strange thing is that it works fine when sending the same http request from Postman to the device.

6

Can you use a browser to issue your request successfully?

You may be missing required headers (HOST, ACCEPT, etc)

1 Like
7

Timeout is immediately output in the log.
If I put the keep-alive attribute in the header, the timeout will be displayed after a certain period of time.

8

same issue with me.

9

The response is checked normally in the browser.
Postman also checks the response normally.

Is there any other way to check how the ST Hub sends requests except to run a separate server?

10

I highly suspect missing headers in your HTTP request. Use postman or google chrome developer tools to display the headers that are being sent with your request and you’ll see there are many for those tools that are working OK… Host and Accept are the common ones expected by most servers.

You can take the relevant parts of your Lua code and run it on any machine that has Lua 5.3 installed. Just change the cosock requires to regular socket.

11

image
image984×752 50.8 KB

I opened another web server to see how the request came in from the hub.
The request to the web server is performed normally. (HTTP 200)

The device that I’m trying to connect is responds normally in my browser. But it doesn’t work on Edge driver. Now, I think we need to check why the existing device is not responding.

Please give me advice on which part to check.

12

Are you sure the device ok with http and not https?

I would add an Accept header with the data type you are expecting back from the device.

And maybe try removing the connection and te headers.

13

HTTP request is correct.
I added an accept header.

Close and te headers are supposed to be automatically added to the 40x library.

image
image624×680 26.9 KB

Is there a way to delete the header value?

14

I didn’t realize they were being added by the library, so I guess you should leave them alone. I don’t know what else to suggest!

What type of device are you sending these requests to?

15

@ktj1312 @Tim99

Were either of you able to ever resolve the HTTP error you were getting? It turns out now I have a similar problem as well. Although my error is slightly different:

[string “socket”]:1410: closed

There is a preceding HTTP request before this occurs that always completes with no error. (same device, different message) But when it tries this next message, I get the error. I have numerous retries in my code and they only occasionally return with no error. The strange thing is, the device itself shows that it, in fact, DID get the message because its settings got changed as a result of the message. So somehow the problem is with the response message.

I am wondering if the device isn’t closing the connection so quickly after it sends its response, that the hub’s socket layer code isn’t fast enough to process the message before the connection is closed? It’s very frustrating! I think I am going to try and put a TCP trace on to see better what is happening…

16

@nayelyz Possibly related to this topic: Are you or the engineering team aware of any problems with the socket.http module? The reason I ask is that I’ve been trying to use it to send a message to a device, but have found that this particular device will respond only sporadically. I ran TCPdump utility running the same Lua code off-hub and found that the HTTP startline was sent OK, but then the headers were being sent multiple times before the socket was closed or timed out.

I can send the exact same HTTP message with the same headers (no body) from a web browser or postman to this same device with no problem.

What I think I’m seeing in TCPdump is that the browser or postman sends the HTTP startline and headers in one TCP message. Whereas this Lua socket.http code seems to first send the startline, and then send the headers in a separate TCP message. And this is what the device seems to be balking at.

I was wondering if perhaps this is a known issue with this Lua module? (A Lua issue, not an Edge issue) As further proof, I tried using a plain TCP socket in Lua (off-hub) to send my HTTP message (startline and headers in one socket send call), and the device responded fine. But whenever I try to use the Lua socket.http library, it fails.

It could be that for whatever reason, some devices’ HTTP servers don’t like getting the startline and headers separately. And this could be one of the reasons for issues like the one this topic was initially created about.

17

Hi, Todd.
The team mentioned this hasn’t been reported before. Please, could you provide your driver’s source code so the team can make a further analysis?
You can send a .zip file to build@smartthings.com or share a link to a Github repository.

18

I’m in the middle of a major re-write. I don’t know that your team could reproduce the problem unless they had one of these (Shelly) devices.

19

Following up with you, @ktj1312.

Does this mean that you’re able to send the HTTP request from the driver now but you had to add accept, close, and te headers to make it work?
The 41x firmware version was released a few days ago, did you notice any changes?

20

What I will do is to send the tcpdump files because I think they are more useful to see this particular problem. I have a Lua script I am running off-hub to test this issue. It’s really not an Edge issue but rather a Lua issue, or so it seems…