Non-Cyan-Flash Offline Core

Firmware
21

The CC3000 can only maintain a limited number of sockets at a time (8, 4 with DNS requests I think). So if there is a bug scenario where it’s opening multiple connections inside a loop, it’s possible it’s exhausting that resource. I agree though, if you can stream on one connection like that, then that’s lower impact.

Don’t you need to send special headers to keep the client request socket alive?

22

It seems to be okay because I’m specifying HTTP 1/1 in the GET line: I’ve tested via telnet to the HTTP server and the same commands I’m sending from the core work just fine repeatedly. I did try doing available/flush/stop and then connect again next time, but that didn’t stop the core from going awol.

23

Hmm… Any chance you could monitor the tcp / http interactions from your core to dweet? I wonder if we had a packet capture if we might not see the issue? Something like them eventually closing the connection, and then trying to write to that socket might be causing a problem?

24

So as not to change too many variables at once I incorporated the ‘sketch’ into a local build (replacing application.cpp etc) and ran. It lasted just over 1 minute before going awol.

25

I haven’t run wireshark in a while but I can try, sure. I won’t necessarily see the packets though, since they’re going to the router via WiFi and I don’t have a good spot upstream of that to monitor from.

Maybe I need to check out Charles Proxy: it’s used for this sort of thing by iOS devs.

26

Is it possible to configure an HTTP proxy in the Core’s WiFi setup?

27

Hmm. I think that would be a matter of making your firmware make the http request through a proxy server directly. I don’t think we have any friendly wrappers for http requests yet, so that might be difficult. If you can listen promiscuously on your wifi network you would probably be able to see the session I would think.

28

We’d want to monitor the cloud connection too though, since the core stops responding to cloud variable get requests too.

29

I don’t see the core’s traffic from my laptop in normal promiscuous mode. I can turn on monitor mode to see the 802.11 packets flying around, but not sure how to get back to HTTP packets from that.

30

Updated via the Web IDE with the newly-released firmware. The core managed to run 20 minutes without giving up on doing the HTTP requests.

Once it stopped going the HTTP requests the cloud behavior was different: instead of just timing out as before, it returned:

{
  "ok": false,
  "error": "Variable not found”
}

instead.

31

To minimize the variables (pun intended) I took out all the Spark.variable stuff and made the sketch as bare as I could. I also made it point at a server I can just tail the log on rather than have to ask the core for a log in a variable:

const char *HTTP_ADDRESS = "finsprings.org";
const unsigned long GET_EVERY_MS = 10000;

TCPClient tcpClient;
unsigned long lastSendTime = 0;

void setup()
{
}

void loop()
{
    if (tcpClient.available()) {
        tcpClient.flush();
        tcpClient.stop();
    }
    
    const unsigned long now = millis();
    const unsigned long since = now - lastSendTime;
    const bool updateIsDue = since > GET_EVERY_MS;
        
    if (updateIsDue) {        
        if (!tcpClient.connected()) {
            tcpClient.connect(HTTP_ADDRESS, 80);
        }

        if (tcpClient.connected()) {
            lastSendTime = now;
            tcpClient.println("GET /ohai.html HTTP/1.1");
            tcpClient.println("Host: finsprings.org");
            tcpClient.println();
        }
    }
}

Will run this and see how long it keeps going.

32

That minimal sketch lasted 4 hours before it stopped making the HTTP requests.

33

Did you ever get your Dweet.io code working? I was looking to use Dweet with my spark core and didn’t want to re-invent the wheel if so.

34

I gave up since I couldn’t get the core to stay online while making those HTTP requests. I haven’t tried since the new firmware came out.