Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dweet.io stops sending GET #3182

Closed
KyleHunter opened this issue May 1, 2017 · 9 comments
Closed

Dweet.io stops sending GET #3182

KyleHunter opened this issue May 1, 2017 · 9 comments

Comments

@KyleHunter
Copy link

Basic Infos

Hardware

Hardware: ESP-12
Core Version: Latest NodeMCU

Description

Problem description

Hey guys. I've been working on a new project with my generic ESP-12, posting to dweet.io. The method I use to post to dweet is below. I constantly loop it, sending it once every 1 second. I'm just sending dummy data currently.

It works well for maybe 12 hours or so, and then it just sends them very intermittently, and then it will completely stop.. I use a LED to notify me of the status of wifi connection, and it stays connected. It also flashes each time a successful request is sent. When it stops working, the LED just stays constantly on. I have a solid 2 amp power supply with a 100uF cap, and a 0.1uF.

Is there anything in my code that seems like it could cause an issue? If not, maybe I should check the rest of my code if there is a leak or anything sketchy. Thank you very much.

Sketch

  void send_to_server(float acceleration)
  {
    const char* host = "dweet.io";

     WiFiClient client;
     const int httpPort = 80;
     if (!client.connect(host, httpPort)) {
       client.stop();
       return;
     }
     client.print(String("GET /dweet/for/test?acc=") + String(acceleration) + " HTTP/1.1\r\n" +
      "Host: " + host + "\r\n" +
      "Connection: close\r\n\r\n");

    delay(10);
    int timer = millis();
    while (client.available() == 0) {
      delay(10);
      if (millis() - timer > 5000) {
        Serial.println("Timeout");
        client.stop();//Tried with and without
        return;
      }
    }

    digitalWrite(16, LOW);
    while(client.available())
      String line = client.readStringUntil('\r');
    digitalWrite(16, HIGH);


    client.stop();//Tried with and without
  }
@bebo-dot-dev
Copy link

Are you experiencing a real stop of requests being sent from your widget side or is it still sending but requests are being rejected by dweet.io? I've never used it myself..do they impose a limit on the number of allowed requests per day from a calling client? (1 a second will rack up to quite a lot of requests over 12 hours)

I read that you can expect to get a JSON response when you make a request to dweet - perhaps try logging this to serial to get a handle on what might be going on..

@KyleHunter
Copy link
Author

KyleHunter commented May 1, 2017

@jjssoftware
It definitely is on the nodemcu's end. It stops blinking when it is stops sending the requests, so it's hiting one of the two return blocks. I had it hooked up to my computer, and it would hit the block with the "timeout" a lot.

Just tried it again over night. It is updating still, but insanely slow, like once every 5 minutes. It's literaaly like it gets bogged down, and gradually slows to a stop. I modified my code to strip out everything else. This was my main loop:

void loop()
{
    broadcast_message();
    float data = sensor::get_acceleration();
    if (wifi::is_connected())
      digitalWrite(4, HIGH);
    else
      digitalWrite(4, LOW);

    if (wifi::is_connected() && millis() - server_time > 2000){
      server_time = millis();
      wifi::send_to_server(data);
  delay(10);
}
}

broadcast_message() is just a serial.println line. Could spamming serial too often bug it up?

EDIT: Now it's back posting fairly quickly.. It's just weird how intermittent this all is

@bebo-dot-dev
Copy link

I suppose serial could cause a problem if you were sending a lot of data down the wire at a low baud rate, but it doesn't look that's the case from these code snips. On that basis I'm going to say serial isn't the issue here but I can't tell from what's been said what exactly is slowing down / timing out.

It's at times like these that I strip stuff back to component parts to understand what's not working as it should..i.e.

  • Solely call sensor::get_acceleration() (whatever this does) and log the result to serial
  • Solely call dweet.io and log the result to serial

I think you're saying that your pin 16 is connected to an led to give an indicator of send / receive health. If so, I think dweet.io might still be in the frame as the cause of this problem so I think I'll ask again:

  1. does dweet.io impose a limit on the number of allowed requests per day from a calling client?
  2. does dweet.io impose some sort of call throttling mechanism to prevent abuse of their service?

@KyleHunter
Copy link
Author

KyleHunter commented May 1, 2017

@jjssoftware
OK. So, when I notice that the requests are lagging, I am able to manually send a request from my computer to dweet.io, and it instantly posts it. That was my initial thought, that the server was messing up.

For get_acceleration(), I'm just simulating sensor values at the current time:

float get_acceleration()
{
return random(0, 100) * random(0, 10) * 0.01;
}

It's tough to monitor via serial monitor, because it usually takes hours for it to start lagging..

EDIT: Throwing in some debbugging lines to print, will see what happens now

@bebo-dot-dev
Copy link

ok I'll chuck a few random things into the mix for you to try out if you've not already done so:

  • use a class level or global single instance of the WiFiClient class rather that using function level instantiation that you currently have. You'll still need to connect / stop in tthe function.
  • call int WiFiClient::connect(IPAddress ip, uint16_t port) rather than int WiFiClient::connect(const char* host, uint16_t port) to rule out any intermittent issues with hostname resolution in the WiFi.hostByName call. In other words call WiFi.hostByName one time only yourself and store the returned IP address in a class level or global variable.
  • I assume you're using the expressIf variant of lwip (the default). If so, give the prebuilt source and/or open source version of the lwip stack a try.

@KyleHunter
Copy link
Author

@jjssoftware
Makes sense, will try. But why would the global instance of the WiFi client affect anything?

@bebo-dot-dev
Copy link

I suppose this would be good practice if you're developing a class around your functionality; you'd typically introduce a member variable within the class of type WiFiClient and you'd expose one or methods on the class to enable WiFiClient functionality to be used but you'd only ever have one and only one WiFiClient instance within the class. You wouldn't be continually instantiating / destroying the object.

Why do this for a global instance in a non-class based simple sketch? Perhaps do it to save a few clock cycles for work that is done in the WiFiClient class constructor / destructor..

As an aside you might find these interesting - they could well be relevant to the issue you're experiencing:

@KyleHunter
Copy link
Author

@jjssoftware
Winner winner. Added a single instance creation of the WiFi client, and cached the IP of the site and it has been running for ~12 hours without a single slow down.

I'll look into which of the two possibilities actually caused it later on.

@KyleHunter
Copy link
Author

Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants