Sending output to a remote server

Squirrel Code
1

So, I’m using the electric imp to periodically report values from a temp/humidity sensor (HTU21D). Everything seems to be working except for one small quirk: sending the data to a remote web server only works every other time, unless I deploy a code change to the imp, then it seems to work twice before returning to the “every other” pattern, and very occasionally (over the course of about a week) it will work twice in a row, but occasionally it will only work every third time!

Sorry if that’s confusing… here’s some recent logs (you can see it failing every other time in general): http://pastebin.com/5hTqaB4u

Relevant device code:
`
// Send info every 5 minutes
function SendInfo() {
server.log(“Sending info…”);
agent.send(“infoPush”, {
“temp”: ReadTemp(),
“humidity”: ReadHumidity(),
“battery”: hardware.voltage(),
“registry”: ReadRegistryInfo()
});

// Tell the server to expect imp to sleep for an hour
server.expectonlinein(3600);

// Sleep!
server.log(“Deep sleeping…”);
imp.onidle(function() { imp.deepsleepfor(3600); });
}

imp.onidle(SendInfo);
Relevant agent code:
device.on(“infoPush”, function(data) {
local request = http.post(“myserver.net/report”,
{ “Content-Type” : “application/json” }, http.jsonencode(data));
local response = request.sendsync();

if (response.statuscode == 200) {
server.log(“Sent metrics”);
} else {
server.log(“Failed to send metrics”);
}
});
`
Any ideas?

2

Without more information it’s difficult to tell… what status code and message are you getting back from the server?

Are you sending it to your own server or an API of some kind?

3

So the comment about sending every 5 minutes is not correct?

// Send info every 5 minutes
function SendInfo() {

In actuality, it sends one every hour?

I think this has something to do with sleeping and waking. It probably takes some time for the WiFi to connect … it’s not sending?

What happens if you use an input pin to trigger the SendInfo function and turn-off all of the sleep stuff. Just for testing. Every minute, make pin 1 high and do the SendInfo. See if it sends each time, every time.

That will verify the POST works, and your website gets the data OK. Even try pushing your button every 10 seconds … it should work each time.

Then you’ll know it has something to do with the deep sleep, or idle modes.

4

The first wifi call will cause the imp to block until wifi comes up. No issues with sending immediately, the message will arrive.

Logging the response code for every http request is definitely worth doing in the agent to see what’s happening to the outbound request.

5

Thanks for the replies… sorry this took so long to get back to.

I’m sending the info to my own server. I get no message back from the server as it appears to be hitting a hard 10 minute timeout and then returning from the sendsync(). response.statuscode is giving ‘28’ and I don’t know what that means.

(I also updated the comment ;))

edit: Ah… just read the API. Seems likely it’s CURLE_OPERATION_TIMEDOUT (28). That sort of confirms what I already knew, but doesn’t really tell me WHY it would timeout. The consistent succeed then fail pattern seems to indicate it’s not actually my server, but I suppose it could be. I’m not sure what else to dig into to debug this.

6

Sounds like your server is, well, not sending a return code to the imp server, hence the imp server it just sitting there waiting… ie the problem would appear to be at your end, not ours.

Try hitting your server with an equivalent curl command line maybe?

What does your server log indicate?

7

50% packet loss would be surprising, but I suppose not impossible since I’m using a wireless dongle temporarily until I get a switch.

Since the request never actually hits my server I don’t think there’s a log. The network metrics show no dropped incoming packets, but it could be happening somewhere before the metrics are actually calculated in linux.

I’ll report back when I start using the switch to see if that resolves the issue.

8

Try tcpdump on your server to show everything happening on that port? If you’re calling sendsync() then the request is almost certainly happening - it’s happening many, many times a day at our end :slight_smile:

If you can PM me the device ID I can see if there’s anything in our logs that might help.

9

There’s only 1 incoming address on port 80 during the times when it fails, and it’s an address I use to query my IP address every so often to update DNS.

I’ll PM you the device ID to see if you can find anything useful, otherwise I’ll just wait until the switch for my server comes and we’ll pick it up from there.

10

Forgot to update this.

This issue seemed to be that my server wasn’t properly closing the connection each time (I haven’t figured out the exact reason why) which was causing the agent to try to re-use the same socket when sending another request, which was then failing because my web server didn’t think the socket was still open. The temporary solution was disable keepalive on the webserver.