staying connected to wi-fi & xively vs. multiple connects & disconnects

Dumb HTTP question no doubt:

In the following example, every iteration of loop() connects to the wi-fi access point (AP), connects to Xively, sends data, disconnects from Xively, and then disconnects from the AP. Repeat forever.

Why not just connect to the AP and Xively in setup(), and never disconnect? (And maybe test for "accidental" disconnects and re-connect if needed?)

/***************************************************
This is a sketch to use the CC3000 WiFi chip & Xively
Written by Marco Schwartz for Open Home Automation
****************************************************/

// Libraries
#includes.......
// Define CC3000 chip pins
#defines....

// Create CC3000 instances
Adafruit_CC3000 cc3000 = Adafruit_CC3000(ADAFRUIT_CC3000_CS, ADAFRUIT_CC3000_IRQ, ADAFRUIT_CC3000_VBAT,
                                         SPI_CLOCK_DIV2); // you can change this clock speed
                                         
// DHT instance
DHT dht(DHTPIN, DHTTYPE);

// WLAN parameters
#defines....

// Xively parameters
#defines...

uint32_t ip;

void setup(void)
{
  // Initialize
  Serial.begin(115200);
  
  Serial.println(F("\nInitializing..."));
  if (!cc3000.begin())
  {
    Serial.println(F("Couldn't begin()! Check your wiring?"));
    while(1);
  }
 
}

void loop(void)
{
  // Connect to WiFi network
 cc3000.connectToAP(WLAN_SSID, WLAN_PASS, WLAN_SECURITY);
  
  
  /* Wait for DHCP to complete */
  while (!cc3000.checkDHCP())
  {
    delay(100);
  }

  // Set the website IP
  uint32_t ip = cc3000.IP2U32(216,52,233,120);
  cc3000.printIPdotsRev(ip);
  
  // Get data & transform to integers
  float h = dht.readHumidity();
  float t = dht.readTemperature();
  
  int temperature = (int) t;
  int humidity = (int) h;
  
  // Prepare JSON for Xively & get length
  int length = 0;

  String data = "";
  data = data + "\n" + "{\"version\":\"1.0.0\",\"datastreams\" : [ {\"id\" : \"Temperature\",\"current_value\" : \"" + String(temperature) + "\"},"
  + "{\"id\" : \"Humidity\",\"current_value\" : \"" + String(humidity) + "\"}]}";
  
  length = data.length();
  
  // connect to Xively and Send request
 Adafruit_CC3000_Client client = cc3000.connectTCP(ip, 80);
  if (client.connected()) {
    Serial.println("Connected!");
    client.println("PUT /v2/feeds/" + String(feedID) + ".json HTTP/1.0");
    client.println("Host: api.xively.com");
    client.println("X-ApiKey: " + String(API_key));
    client.println("Content-Length: " + String(length));
    client.print("Connection: close");
    client.println();
    client.print(data);
    client.println();
  } else {
    Serial.println(F("Connection failed"));
    return;
  }
  
  Serial.println(F("-------------------------------------"));
  while (client.connected()) {
    while (client.available()) {
      char c = client.read();
      Serial.print(c);
    }
  }
 
client.close();
 
cc3000.disconnect();
  
  // Wait 10 seconds until next update
  delay(10000);
  
}

Source: arduino-cc3000-xively/CC3000_xively.ino at master · openhomeautomation/arduino-cc3000-xively · GitHub

Also here: Arduino sketch | Adafruit CC3000 WiFi and Xively | Adafruit Learning System

And here: http://www.openhomeautomation.net/internet-of-things-arduino-wifi/

Why not just connect to the AP and Xively in setup(), and never disconnect? (And maybe test for "accidental" disconnects and re-connect if needed?)

That is probably up to Xively. They may or may not not want persistent connections with their servers. The HTTP 1.1 specification provides for persistent connections.

Ok - thanks for the reply.

DaveEvans:
Why not just connect to the AP and Xively in setup(), and never disconnect? (And maybe test for “accidental” disconnects and re-connect if needed?)

I haven’t used Xively for a few weeks and do so with the usual cosm code, but I thought that was the standard procedure. You establish the connection in setup and feed in the loop. What could be more clear than that? The problem is that there is no provision for retry in the event of a disconnect. I can run for weeks with no problem and then have a mysterious fail. Your test for disconnect and auto-reconnect sounds a really good idea. The best I can get is a “200” signal confirming a successful feed.

It could be that, while a disconnect/reconnect in the loop sounds tedious and dumb, it is actually advantageous, as it at least puts you in control and you do get the reconnect.

Well, "sort of" in control. Actually, the code I posted doesn't have any timeouts or limits on the number of retries for the various actions, so it often hangs up in the infinite loops when it can't checkDHCP, or send the data, or get the reply. (I'm amazed you can run for weeks without hiccups.)

That brings up another question:

What would happen if I put a limit on the number of retries and, when the limit is exceeded, "return" to the start of loop()? (Or I could set up a timeout to accomplish the same thing.)

For example, let's say I add code to "return" to the top of loop() after ten attempts to cc3000.checkDHCP(). Doing so would bypass the client.close() and cc3000.disconnect() actions at the bottom of the loop. Would that cause any problems, or should I attempt to client.close() and cc3000.disconnect() before the return statement?

DaveEvans:
For example, let’s say I add code to “return” to the top of loop() after ten attempts to cc3000.checkDHCP(). Doing so would bypass the client.close() and cc3000.disconnect() actions at the bottom of the loop. Would that cause any problems, or should I attempt to client.close() and cc3000.disconnect() before the return statement?

I really can’t comment much as the code is quite alien to me. Further, I stay away from WiFi, and your problems might be in that arena. I simply plug the Ethernet shield into a WiFi repeater.

What I have establishes the connection in setup and feed in the loop. This means that, if there is an involuntary disconnect, I’m stuffed until there is a manual reset which, by virtue of being on the interenet in the first place, could take weeks.

What I understand you have is an intentional disconnect and a re-try every trip round the loop. Ergo, in the event of an involuntary disconnect, you reconnect as soon as possible, even if it takes hours. I don’t actually see much point in time-out procedures. In the event of a problem with connection, there is only one objective - reconnect, no matter how long it takes. This particularly in mind as the disconnect might not be your fault, indeed probably not. So you just go round the loop, which you need to do for local recording anyway.

I am going to try and incorporate your procedure with my programme., even though I am looking at defecting to Grovestreams.