Firmware reconnect after twitter post

Firmware
1

I’m getting spark disconnect/reconnect (cyan flash -> green flash -> breath cyan) after my firmware code posts to twitter. It reconnects no problem but I’m just learning so I want to understand if I’m doing it wrong. Any help would be appreciated. woop. @Dave

 void loop() {
    if (digitalRead(button) == LOW) {
        sendTweet(msg);
    }
    else if(digitalRead(button) == HIGH) {
        digitalWrite(led, LOW);
    }
}

void sendTweet(char* message) {
    delay(1000); 
    digitalWrite(led, HIGH);
    client.connect(LIB_DOMAIN, 80); 
    client.println("POST /update HTTP/1.0"); 
    client.println("Host: " LIB_DOMAIN); 
    client.print("Content-Length: "); 
    client.println(strlen(message)+strlen(TOKEN)+14); 
    client.println(); 
    client.print("token="); 
    client.print(TOKEN); 
    client.print("&status="); 
    client.println(message); 
    client.flush();
}
1 Like
2

I was able to fix it by adding a delay then stop:

delay(1000);
client.stop();

Without the delay the post never gets sent. Is there a better way?

3

I was going to suggest a stop as well, to make sure you’re cleaning up the socket. It’s also important to make sure you’re not tweeting too often. Twitter is (understandably) very defensive with their APIs, and you don’t want to get yourself / your account banned. So try not to tweet more than once every few seconds at the most. :slight_smile:

You can use a much much smaller delay before the stop. I think there is a TCPClient bug right now where a short (5-100ms) delay before a stop can be helpful to make sure everything goes across the wire before it’s closed. I opened an issue for this here:

Thanks,
David

4

Sounds good. Thanks! It’s tweet on button push, any good techniques for rate limiting on the client? Is the preceding sleep good enough or do people set ‘wait until’ timers?

5

Hi @dwashin,

Good question! You could totally use the delay to block the core as long as you want. If you want to save power / sleep the entire core until something interesting happens (say a pin goes high or low), you can use the currently in development interrupt sleep wrappers:

I hope that helps! :slight_smile:

Thanks,
David

1 Like