This has been sitting in draft mode for about 6 months, figured I’d just publish it in its current state, and improve when I get a chance. I’m now playing with a couple other receivers, one a handheld, battery powered version.
Putting together a kit with all the pieces for making a SensorPack, but didn’t get an Adafruit-quality how-to done, so never put it up in the store. Should just sell the parts, since everything is labled, no more challenging than a paint-by-numbers assembly.
The final bits for my overall SensorPack project isn’t really the sending hardware, have had that working for years in a couple incarnations. Polishing the software enough for others to work with is always a challenge, and is what put this project on the back burner for me. I did a lot more work on my various one-off display stations than I did on the SensorPack itself. I’ve built a variety of display stations, so decided rather than picking one project, I’d just detail the various projects I’ve built to display the resulting data, since they could actually be used to display data from any Internet of Things type sensing device.
This post is intended to put all the resources in one place, while I build out my “how-to” projects pages. This is draft one, will continue to work on it as I further refine the code and “how I did it” writeups.
I currently have 5 different ways of gathering/displaying data.
1) Laptop receiver
The most general purpose, is a bit of processing code that you run on a computer, with just an XBee receiver attached. It parses the output from any sensor packs in range, and (optionally) rebroadcasts their data, so it can act as a bridge, which helps if you have multiple receiving stations in the house, but have your sensor pack outside.
It provides the following features:
- A primitive on-screen display of temp/pressure/humidty for any and all weatherstations in range
- Can assemble and send XML POST messages to send to a webservice (I’ll document the Rails webservice elsewhere).
- It will also update a WeatherUnderground weatherstation (you first have to set up an account with WeatherUnderground).
- At one point, I had this also updating twitter accounts. After Twitter went to OAuth, I never reworked it for the new authentication mechanism, so I’ve removed all that code.
- I also had it updating COSM, but they fairly regularly returned an error on update, which my processing code took as a reason to stop running, so the program would run for months unmonitored.
Download the Processing code here (TBD)
This is a really simple setup, it uses five easy to assemble components:
– An Arduino
– A Protoshield (optional)
– An Adafruit Touch Shield
– An XBee shield
– An XBee (you have many choices. Check Adafruit and Sparkfun)
Simply follow the instructions to put together the Touch Shield, then attach the XBee shield to pins 2 & 3 and power, and the install the code. This program will automatically receive messages from any in-range SensorPacks, and will then display information for the first 4 that check in. It also will display a clock, and can turn the display on and off depending on the time of day. For clock functionality, project #1 will send out time packets every minute automatically, or you can figure out a different method.
The code was really challenging to get working, since with the Touch Shield library, and serial library for talking to the XBee, you have VERY little space left for user programs and data, but this has been pretty stable for me. Do note that if you tweek the code, and it breaks, it’ll tell you in random ways. Usually by the display doing weird things, or the Arduino spontaneously rebooting. A real bear to debug.
This is probably the most adaptable designs, but probably the worst written code. It was my first try at a receiver, and I never did a cleanup, whcih would have been an re-write. As written, the software supports 4 LED displays, but you can use less than 4 with no issues. Building is also pretty simple, you can use any Arduino you want, 1-4 serial LED’s, an XBee shield and an XBee. An optional protoshield could make things a lot cleaner, I’m still running my first version I put on a tiny breadboard and tossed in a project box.
It also supports a clock in one display, and an on-board temperature sensor, and a light sensor to dim the LED’s based on ambient light. I have mine set up with one LED displaying time, one the internal temperature, and the other two rotating through temp/humidity/pressure for two different SensorPacks.
Components: (removed list of components, since the links were all dead/changed)
4) Big clock
This was a fun project to design and build. It uses these really big LED’s I got from Sparkfun. I liked the look so much, I designed a circuit board to hold the shift registers, and make wiring up the LED segments MUCH easier than on a breadboard, but the code obviously doesn’t care how you wire it all up, it just sends data to the shift registers.
The challenging part here will be wiring everything up in the right order so the LED’s display the right information. It’s going to need it’s own more detailed tutorial, but I include it here now for completeness. If you are comfortable with Arduino coding and wiring up shift registers to LED’s, you shouldn’t find it very difficult to get working. Again, removed all the component links, because they’re now obsolete.
This was mostly an exercise in learning how to write a non-trival Android app, but I actually use this more than any other method for checking on my sensors. I have it working well on my Droid Razr, and on my Nook Tablet, which I hacked with a Honeycomb OS port.
Unfortunately, ICS changed how XML parsing worked in an incompatible way for me, and my code stopped working. Requests went out, but the returned XML was no longer parsed. I spent several days trying to figure out how to rework it, and then got bored with it all. I left my Nook and Razr as Honeycomb devices, so I have two working displays. I’m not bothering to link to the code here, since it won’t work on a newer version of the OS.
I’d accomplished my real goal, writing a non-trivial Android app. I was disappointed in the vast differences in the evolving ADK though, so decided to wait a couple major revisions for Google to stop making incompatible changes from version to version. As a spare-time hobbiest, I just don’t have time to rework my code every major release.