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.
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
for detail I use the function like this.
-- Update Device Status
-- Refresh Device Status
log.trace('Refreshing Device Status')
local success, data = command_handler.send_lan_command(
-- Check success
if success then
local resp = json.decode(table.concat(data)..'}')
log.error('failed to poll device state')
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.
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.
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…
@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.
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 firstname.lastname@example.org or share a link to a Github repository.
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?
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…