Categories
Uncategorized

Logging the temperature and humidity (code)

Temperature and Humidity

I’m always annoyed with myself when I don’t publish my code, so this is a follow-up to my Logging the temperature and humidity post.

This whole thing is definitely a work in progress. The hardware has exposed wires, and the software is all just cobbled together pieces. Making something that works is much different than making something that will continue to work, and work properly, and efficiently. Making something that works is a first step. It’s an important step, but it’s only the first step. So let’s begin!

I started with the example from Adafruit over on GitHub and about the only changes I made was to the format output of the data.

// Example testing sketch for various DHT humidity/temperature sensors
// Written by ladyada, public domain

#include "DHT.h"
#define DHTPIN 2     // what pin we're connected to
#define DHTTYPE DHT22   // DHT 22  (AM2302)

DHT dht(DHTPIN, DHTTYPE);

void setup() {
  Serial.begin(9600); 
  dht.begin();
  delay(1000);
}

void loop() {
  int h = dht.readHumidity();
  int t = dht.readTemperature();

  // check if returns are valid, if they are NaN (not a number) then something went wrong!
  if (isnan(t) || isnan(h)) {
    Serial.println("Failed to read from DHT");
  } else {
    Serial.print(h);
    Serial.print("\t");
    int temperatureF = (t * 9 / 5) + 32.5;
    Serial.print(temperatureF);
    Serial.print("\n");
  }
}

So this outputs the value for the humidity, then a tab, then the value for the temperature, and then a line return. Oh, I did change the code to output the temperature in Fahrenheit instead of Celcius. If we get a bad value, it’ll print “Failed to read from DHT” though I’ve yet to see that in the log files, I should probably take it out. Also, the Arduino just streams data at a fast rate, much faster than I need. I typically put the sleep functions (to limit the amount of data logged) in my reading code which runs on the computer. I think this is the right way to go, but if you have other ideas, please let me know.

Here’s a fairly simple Processing sketch that will read the data coming in from the Arduino. (Obviously you need the Arduino connected to the computer via USB.)

import processing.serial.*;

PrintWriter output;

Serial myPort;    // The serial port: 
PFont myFont;     // The display font: 
String inString;  // Input string from serial port: 
int lf = 10;      // ASCII linefeed 

void setup () {
  // set the window size:
  size(500,200);  
  println(Serial.list());
  myPort = new Serial(this, Serial.list()[0], 9600);
  // don't generate a serialEvent() unless you get a newline character:
  myPort.bufferUntil('\n');
  background(50);
  output = createWriter("output.txt");
}

void draw () {
  // everything happens in the serialEvent()
}

void serialEvent (Serial myPort) {
  // get the ASCII string:
  String inString = myPort.readStringUntil('\n');
  
    String[] words = split(inString, '\t');
    String humid = words[0];
    String tempe = words[1];
  
    background(50);
    textSize(40);
    text("   Humidity: " + humid, 40,90);
    text("Temperature: " + tempe, 40,160);

   output.printf("%d-%02d-%02d %02d:%02d:%02d\t%s", year(), month(), day(), hour(), minute(), second(), inString); // Write to the file
   output.flush(); // flush output
}

Besides displaying a small window with the humidity and temperature (seen at the top of this post) it will also log the data to a file named output.txt

Processing Output

2011-07-25 19:09:14     44      91
2011-07-25 19:09:14     44      91
2011-07-25 19:09:15     44      91
2011-07-25 19:09:15     44      91
2011-07-25 19:09:16     44      91
2011-07-25 19:09:17     44      91
2011-07-25 19:09:17     44      91
2011-07-25 19:09:18     44      91
2011-07-25 19:09:18     44      91

This is pretty terrible, as we’re getting way too much data. I should probably add some delay into the Processing sketch, as it’s creating a log file line much faster than the sensor can even output data! This will result in large log files and is just wasteful. If all I wanted was the window showing the current temperature and humidity, I’d probably just delete the logging part of the sketch. Add that to the TODO list. Anyway, it works, and as a proof of concept, it’s a start.

Here’s the Perl code I was using:

#!/usr/bin/perl

use Device::SerialPort;
use IO::Handle; FILE->autoflush(1);
my $port = Device::SerialPort->new("/dev/tty.usbmodemfd411");

$port->baudrate(9600);
$port->databits(8);
$port->parity("none");
$port->stopbits(1);

my $fileout = './templight.log';
my $filerec = './templight-recent.log';

open (FILE, ">>$fileout") or die ("Ooops! Could not open $fileout: $!");

while () {
    # Poll to see if any data is coming in
    my $char = $port->lookfor();

    # If we get data, then print it
    if ($char) {
	$time = localtime(time);
	if (length($char) > 1) {

		my $str = ($time . "\t" . $char . "\n");
		print FILE $str;

		open (FREC, ">$filerec") or die ("Ooops! Could not open $filerec: $!");
		print FREC $str;
		close (FREC);
	}
    }
    # Uncomment the following lines, for slower reading, 
    # but lower CPU usage, and to avoid 
    # buffer overflow due to sleep function. 

    $port->lookclear; 
    sleep (10);
}
close (FILE);

The logging here is a little better than the Processing sketch, at least we add some delay with that sleep at the bottom so our log files won’t be quite as large. We’re saving to two files, templight.log and templight-recent.log. The second one just saves the current data, this just enables us to grab the data from that file and do something else with it, like… send it to Twitter or something.

Perl Output

Tue Jul 26 04:30:39 2011        46      89
Tue Jul 26 04:30:49 2011        46      89
Tue Jul 26 04:30:59 2011        46      89
Tue Jul 26 04:31:09 2011        46      89
Tue Jul 26 04:31:19 2011        46      89
Tue Jul 26 04:31:29 2011        46      89
Tue Jul 26 04:31:39 2011        46      89
Tue Jul 26 04:31:49 2011        46      89
Tue Jul 26 04:31:59 2011        46      89

So our output from Perl looks similar, though we have much less data (but still plenty of data) and the date format is a little different. (Chalk that up to laziness.) Oh, the Perl code also has the serial port hardcoded to /dev/tty.usbmodemfd411, which is lame, and I do have code somewhere to grab the serial port dynamically, but I didn’t implement it yet.

Whew! It feels so liberating to publish all that terrible code… (I mean my own code, not Adafruit’s!) Now I feel the need to start re-writing it and making it less terrible.

Categories
Uncategorized

Logging the temperature and humidity

Adafruit DHT22 temperature-humidity sensor

Last November one of the Arduino-based projects I started working on was a temperature logger for the office. With winter coming up I wanted to see just how cold it got. (The office is in a converted attic, and the heating and cooling leaves much to be desired.)

I picked up a TMP36 – Analog Temperature sensor and got it wired up and wrote some hacky perl code to read the data and log it. I never really got it out of the experimentation stage, and ended up pulling the Arduino out for another project. (Isn’t that often the case!?)

So last month when Adafruit came out with the DHT22 temperature-humidity sensor I figured I should grab one, and maybe I’d get around to finishing the project.

My temperature (and humidity!) logger is still not done, but I did whip up something to run this week while Wisconsin is having a heat wave. The office has a window air conditioning unit, but it only runs when someone is in the office. When no one is there, it gets hot. How hot? Well, now we know….

Time Humidity Temperature
00:00 50% 89°F
00:30 50% 89°F
01:00 50% 89°F
01:30 49% 89°F
02:00 49% 89°F
02:30 49% 89°F
03:00 48% 89°F
03:30 48% 89°F
04:00 48% 89°F
04:30 48% 89°F
05:00 48% 89°F
05:30 48% 89°F
06:00 48% 89°F
06:30 49% 89°F
07:00 57% 89°F
07:30 58% 89°F
08:00 53% 91°F
08:30 52% 91°F
09:00 52% 91°F
09:30 52% 91°F
10:00 52% 91°F
10:30 52% 91°F
11:00 52% 91°F
11:30 52% 93°F
12:00 52% 93°F
12:30 52% 93°F
13:00 51% 93°F
13:30 51% 95°F
14:00 50% 95°F
14:30 50% 95°F
15:00 50% 95°F
15:30 50% 96°F
16:00 50% 96°F
16:30 50% 96°F
17:00 49% 96°F
17:30 50% 98°F
18:00 48% 96°F
18:30 43% 93°F
19:00 41% 91°F
19:30 40% 89°F
20:00 41% 87°F
20:30 39% 89°F
21:00 37% 89°F
21:30 42% 86°F
22:00 40% 86°F
22:30 39% 86°F
23:00 39% 84°F
23:30 37% 84°F

Chart

The hard part of the code is provided by Adafruit’s DHT-sensor-library and their DHTxx Sensor Tutorial was also useful. And just for fun we dug up another old bit of perl which was wired up to SuperTweet.Net so we could send the data out via the 2XL Networks Twitter account.

2XL Networks - Logging

I should really get around to finishing this project, since I have a spare Seeeduino that would be a good fit for it. I can always feed the data into Pachube or roll my own logging application.

I’m really just hoping the heat wave ends and it doesn’t get up to 98°F in the office again…

Update: See the post: Logging the temperature and humidity (code)

Categories
Uncategorized

gnuplot

gnuplot

I’ve started to use gnuplot, which is a “command-line driven graphing utility.” It’s not open source but it is freely available (under some other license) and it’s been around since 1986. I don’t think it’s going to “go commercial” any time soon…

It’s proving challenging to understand gnuplot and get it to do what I want it to do, but I’ve tried using OpenOffice and Numbers and neither one can seem to plot 24,000+ data points. I considered updating my Perl code to write SVG files (and I may revisit that) but gnuplot seems to be the tool to use in this case…

Hopefully by the time I’ve collected a few more weeks worth of data I’ve got a better idea how to use gnuplot… but if you’ve got any pointers, I’d love to hear them.

Categories
Uncategorized

Fitbit… getting closer!

Fitbit API

I originally thought the Fitbit looked awesome, but in digging into things, I found a few issues I didn’t like. (See Fitbit Improvements.) While it looks like they’ll never go the route of sending your own data to your own computer without first sending your data to the cloud, their official API is out (in beta) and should at least offer an improvement over the “unofficial” APIs people had been working on.

Over at dev.fitbit.com you can read up on the details, and get some example code (none in Perl yet though!) It’s good for the Fitbit ecosystem, as more applications may come out that make use of the data. If anything, I’d like to see something like what I created for Last.fm in Heard, an application that syncs your data back to your own server from the cloud.

I also noticed that Fitbit got a mention on the Arduino blog, which amuses me for a few reasons. First, if the Fitbit had been more open I probably would have looked more seriously into getting one last year. (Open source hardware would have been awesome, but I can live with closed, though it is interesting that they use the open source Arduino for rapid prototyping.) Second, I actually got into working with the Arduino partly to try to do some of the sleep monitoring functions that the Fitbit does. (Yes, that’s another project I got sidetracked on.)

Depending on how our research funds shake out this year, the Fitbit may still be on our list. As I’ve said before, I’m the type of person who needs to collect data, and analyze it, and chart it out, in order to find more value in it. Meanwhile, I’ll be in the lab working on my Arduino-based sleep monitor…

Categories
Uncategorized

Visitor Stats

For some reason (probably the whole “end of one year, beginning of another” thing, I felt like grabbing the visitor stats for this site.

I hadn’t realized that it was only about 6 months since the last time I did this. Even better, now we can compare! See the July 2010 stats if you want to review.

Visitor Stats

Compared to last time, Firefox is down, while Chrome is up. I guess that’s not surprising. Chrome is gaining in popularity. As for this site, I write about Firefox and Mozilla a lot more than I write about Chrome, so I’d still expect some good Firefox numbers.

Internet Explorer is down (thank goodness!) but so is Safari. I’d almost expect Safari to go up a bit due to the iOS… but I guess not.

Visitor Stats

Windows went up slightly, while the Mac stayed about the same. iPad went from less than 2% to over 11%. I really didn’t write much about the iPad until the end of December, of course, a lot more iPads are out there now.

Visitor Stats

The interesting number here is the second one, 768×1024, which I believe correlates to iPad in portrait mode. Very interesting! The other numbers are all pretty close. Do I really have that many visitors to this site using iPads?

I’ll have to remind myself to check the numbers again in 6 months…