Evaluating Weather APIs

Many Internet-of-Things applications require knowledge of various environmental factors such as temperature, humidity, and light levels. While various sensors exist that fill this need locally–such as the ubiquitous DHT11/22 temperature and humidity sensor–sometimes an application requires broader weather data or just a sense of whether or not it is raining outside. Other applications might benefit from weather forecasts.

Thankfully the Internet provides us hobbyists and makers with a ton of APIs that provide weather data. Honestly the sheer volume of the APIs can be overwhelming. For a project that I’ve been playing around with–an indoor environmental monitoring system–I wanted some external data for comparison and worked with quite a few different APIs before I found the mix that worked for me. In the next few posts I’ll share my experiences and some sample code for working with each one.

But first here is a look at the contenders I will be evaluating

As a preview I’ve found that each has their pluses and minuses. Some provide lots of information, but have quirks in their API that make them annoying to use. Others lack data that seems essential. Ultimately–as I have cycles and bandwidth to spare–I combined all four in my final solution.

Advertisements

How “Functional” Should Arduino Be?

As mentioned in my last post, using Timer.h in my DHT11/ESP8266 project required me to transform much my sketch into functions. My initial experience with programming was in BASH and since then I’ve done some Python, so I am comfortable with using functions. But in Arduino I kind of liked being able to accomplish things without them. Take a look at this snippet that does basically everything I need the board to do:

void loop() {
  for (c = 0; c < 60; c++) {
    h = dht.readHumidity();
    f = dht.readTemperature(true);
    fS = (alpha * fS) + ((1 - alpha) * f);
    hS = (alpha * hS) + ((1 - alpha) * h);
    Serial.print("c="); Serial.print(c); Serial.print(" f="); Serial.print(f); Serial.print(" fS="); Serial.print(fS); Serial.print(" h="); Serial.print(h); Serial.print(" hS="); Serial.println(hS);
    delay(1000);
  }
  Serial.println("Sending to Thingspeak");
  ThingSpeak.setField(1, fS);
  ThingSpeak.setField(2, hS);
  ThingSpeak.writeFields(myChannelNumber, myWriteAPIKey);
  blink(BLUE, 1);
}

That is code I can easily understand without referring to multiple functions. The new approach breaks that up into basically two functions. The first polls the sensor and records a new value:

void sensorUpdate() {
  f = dht.readTemperature(true);
  h = dht.readHumidity();
  fS = (alpha * fS) + ((1 - alpha) * f);
  hS = (alpha * hS) + ((1 - alpha) * h);
  if (isnan(fS) || isnan(hS)) {
    fS = dht.readTemperature(true);
    hS = dht.readHumidity();
    fSo = fS;
  }
}

 

The second sends to thingSpeak

void thingspeakUpdate() {
  if (fSo > fS) {
    analogWrite(RED, 0); analogWrite(GREEN, 0); analogWrite(BLUE, 50);
  }
  else if (fSo == fS) {
    analogWrite(RED, 0); analogWrite(GREEN, 50); analogWrite(BLUE, 0);
  }
  else if (fSo < fS) {
    analogWrite(RED, 50); analogWrite(GREEN, 0); analogWrite(BLUE, 0);
  }
  printVars();
  fSo = fS;
  Serial.println("Sending to Thingspeak");
  ThingSpeak.setField(1, fS);
  ThingSpeak.setField(2, hS);
  ThingSpeak.writeFields(myChannelNumber, myWriteAPIKey);
}

It also does some fancy stuff with the LED on the development board I am using. (Well not that fancy, it just changes the color based on if the temperature is going up or down.)

Though it made sense to do it this way because Timer.h assumes that you have everything broken out into functions, I feel like I almost aesthetically drawn to the simplicity of the non-function version.

What do you think? Is that just a silly opinion?