HttpClient - connection failed (ubidots)

Hi @twfinmv

Just one quick thing–you are not using capital-D Delay() are you? You should use lowercase-d delay() instead. The capital-D version is an internal function that can break the cloud.

Hi @bko,

Thanks for the correction. I was actually using Delay in one of my test files (I’ve fixed it now). I hope I haven’t caused grief in the cloud!

My other test file is literally a cut and paste from from the above code from @aguspg and it correctly uses a little d delay.

1 Like

I should have said “break the cloud connection on your core.” You can’t easily hurt the cloud!

Is the problem there only when you try to post to Ubidots or is it a more general problem?

I have run all the examples in the EXAMPLES section of the the Spark documentation without problem. No issues with the POST or GET as written in the examples. My core has run with these simple examples for long periods without any obvious problems, dropouts or SOS. I guess there could have been problems when I wasn’t watching but none that I’ve seen.

Hi @twfinmv,

I think I was able to replicate your error; I took a Spark that I know has had DNS problems, then ran the DNS test tool by @mtnscott, then it didn’t pass the test, then I typed the “Fix DNS” option and I was able to ping the data.sparkfun.com address.

So far so good, but then I ran the example I had written above and the HTTP request didn’t come through (“HTTP failed”). So instead of dealing with the CC3000 DNS issue, I used this other code which had been discussed here before.

It uses some kind of internal DNS server inside the Spark, which can be seen in this line:

IPAddress dnsServerIP(8,8,8,8);

Here’s the code that is sending data as I write:

// These #include statements were automatically added by the Spark IDE.
#include "dnsclient/dnsclient.h"
#include "HttpClient/HttpClient.h"

/**
* Declaring the variables.
*/
HttpClient http;

#define VARIABLE_ID "54eb85fb76254xxx756158d4"
#define TOKEN "6ZImUxxxGhPWecutlSnMd8ayOpjRps"

float voltage = 0.0;
char resultstr[64];

// Headers currently need to be set at init, useful for API keys etc.
http_header_t headers[] = {
      { "Host", "things.ubidots.com" },           // Declare the host here as well when your Spark has problems with DNS resolution
      { "Content-Type", "application/json" },
      { "X-Auth-Token" , TOKEN },
    { NULL, NULL } // NOTE: Always terminate headers will NULL
};

http_request_t request;
http_response_t response;

//This are additional declarations in case your Spark is not supporting DNS resolution
IPAddress dnsServerIP(8,8,8,8);
IPAddress remote_addr;
DNSClient dns;
char serverName[] = "things.ubidots.com";

void setup() {
    pinMode(A0, INPUT);
    request.port = 80;
    dns.begin(dnsServerIP);
    dns.getHostByName(serverName, remote_addr);
    request.ip = remote_addr;
    request.path = "/api/v1.6/variables/"VARIABLE_ID"/values";
    Serial.begin(9600);
}

void loop() {

    // Get variable

    voltage = analogRead(A0);

    // Send to Ubidots

    sprintf(resultstr, "{\"value\":%.4f}",voltage);
    request.body = resultstr;
    http.post(request, response, headers);

    Serial.println(response.status);
    Serial.println(response.body);

    delay(1000);
}

Hope this helps!

1 Like

Thanks @aguspg. I will try it tonight.

Quick question though, When you re-created the failure did the symptoms include the SOS panic code to breathing cyan cycle? That is what I experienced.

Thanks for the advice.

Mmm - actually not. It only returned the “HTTP Failed” message, but no panic code.

@aguspg, when I run the code you just posted (with my own variable id and token) I get interesting results

With the delay set to 1000 ms I get the following serial output. The first time I ran it it locked out my core and I had to do a factory reset. The data on Ubidots was timestamped mostly at 2 and 3 second intervals but I did notice one timestamp that was 27 seconds later. The core was mostly breathing cyan but occasionally flashing cyan. No SOS however. The second time I ran it (after factory reset) it stuck to mostly 2-3 second update cycle, seemed more stable, and remained connected to the cloud.

HttpClient>.Connecting to IP: 50.23.124.68:80
HttpClient>.Start of HTTP Request.
POST /api/v1.6/variables/54f11aa276254256995acac3/values HTTP/1.0
Connection: close
Content-Length: 19
Host: things.ubidots.com
Content-Type: application/json
X-Auth-Token: p7D0xQvnjMfIfTdH2VrIumk7RhE7xQ1sSmOwjEm6q4calNCB76QQVYof5VC8
{"value":2127.0000}
HttpClient>.End of HTTP Request.

HttpClient>.Receiving TCP transaction of 128 bytes.
HTTP/1.1 201 CREATED
Server: nginx
Date: Sat, 28 Feb 2015 02:17:32 GMT
Content-Type: application/json
Connection: close
Vary: Accept
Location: http://things.ubidots.com/api/v1.6/values/54f1253c762542677675f71e
Allow: GET, POST, HEAD, OPTIONS

{"url": "http://things.ubidots.com/api/v1.6/values/54f1253c762542677675f71e", "value": 2127.0, "timestamp": 1425089852624, "context": {}, "created_at": "2015-02-28T02:17:32.624"}
HttpClient>.End of TCP transaction.
HttpClient>.End of HTTP Response (734ms).
HttpClient>.Status Code: 201
201
{"url": "http://things.ubidots.com/api/v1.6/values/54f1253c762542677675f71e", "value": 2127.0, "timestamp": 1425089852624, "context": {}, "created_at": "2015-02-28T02:17:32.624"}

With the delay set to 60000 ms and no other change to the code I get the following output. The first time I tried this I got regular timestamps around 62-63 seconds apart and the core remain connected for the few minutes I let it run. The second time I tried it the core was locked out almost immediately but later (2-3 minutes) resumed connection to the cloud.

HttpClient>.Connection failed.
-1

HttpClient>.Connecting to IP: 50.23.124.68:80
HttpClient>.Start of HTTP Request.
POST /api/v1.6/variables/54f11aa276254256995acac3/values HTTP/1.0
Connection: close
Content-Length: 19
Host: things.ubidots.com
Content-Type: application/json
X-Auth-Token: p7D0xQvnjMfIfTdH2VrIumk7RhE7xQ1sSmOwjEm6q4calNCB76QQVYof5VC8
{"value":2106.0000}
HttpClient>.End of HTTP Request.

HttpClient>.Error: Timeout while reading response.

HttpClient>.End of HTTP Response (5056ms).
HttpClient>.Status Code: 
HttpClient>.Error: Can't find HTTP response body.
-1

Still seems pretty unstable to me but definitely better.

Hey guys, just wanted to quickly drop a note that i played around with the testing of CC3000 patch and it improved the connections by a lot.

But it need some help here since there’s limited time for me to sit down and do serious testing.

1.) Create a gist of code that will be able to upload/post without any delays etc (treat it like the core has no issues)

2.) Provides steps on how i can create an account + view that data is being uploaded.

If you can do me a little favour, i will be able to test out whether things get better with the patch :wink:

@twfinmv I left it running without a delay and saw that it also resets every 2-3 minutes. I don’t know why it becomes unstable, it might be related to heap fragmentation, the good news is that it automatically starts working again after reset.

To me it looks like the body part is coming in after the connection is closed which will cause the hard fault. Try increasing the timeout and maybe have a look at the thread “faster http client” for an updated version I wrote a few weeks ago. I found that the print method in the old version caused some delays that really slowed down the servers response for some reason… and sometimes there was no response… Now with the much faster write method I have much more stable connections

Thanks @Hootie81. I will try the updated HttpClient.

Hi ubidots states this variable is empty initial don’t have this issue.

I am using this library and stated my problem on it’s thread as well as another thread. We have traced it back to this library for sure but get certain amount of intermittency.

I also have the client failing and timing out. It starts JUST failing then after ? cycles it does function but times out.
In my example it is talking to a web service which is constantly online. The failing stops between 1-5 cycles no link found for cycle number. Once it begins timing out the web service is working perfectly and the response is seen by the client it just seems to hold the connection open for no reason.

I have not tested my idea yet but I am wondering if it is line 190 in the library.
Instead of available may need to be connected?
Thats my plan anyway.

Hi have you tried your plan.

Yes that is not the problem. The issue continues even with combinations of them.
I have created a new web service to accept time out scenarios and publish swathes of data instead of just little bits. This is obviously not desirable because the library should work but has hiccups (its a new library so thats expected).

Have a look at this post, the library has been updated to disconnect after processing the correct number of bytes based on the content length header. Haven’t tested it myself yet…

@itayd100, @twfinmv, Do you have an update on using the faster HTTP client mentioned in the above response by @Hootie81?

Sorry but I don’t have an update. My project has been sidelined by other non-particle work.

@TheVelozGroup,

I saw you asked today and I tried to install the lib on the Core and the Photon.
The Core worked well with the old lib, but with the new lib I have a problem. It can’t work with large answer:
HttpClient>.Error: Response body larger than buffer..
After a large answer the Core is stuck with this message in a loop.

I wanted to try it with the Photon, but right now I have a bigger problem. The Photon stuck after it enters into the loop. The program that worked on the Core doesn’t work on the Photon.

I think I’ll stay with the old and slow, but working one.
Good luck