Earlier this year I forked the software used to control the AirPi, a small board which monitors air quality measures including Carbon Monoxide, Nitrogen Dioxide and VOCs. Having made quite a lot of changes I’ve just tagged a v1.0 release on GitHub, so thought it might be prudent to take a look at what’s been added and/or amended.

AirPi – a tentative v1.0 release

Written by Haydn Williams

Earlier this year I forked the software used to control the AirPi, a small board which fits a Raspberry Pi to monitor environmental phenomena such as temperature, humidity and air pressure along with air quality measures including Carbon Monoxide, Nitrogen Dioxide and VOCs. Having made quite a lot of changes, I’ve just tagged a v1.0 release on GitHub, so thought it might be prudent to take a look at what’s been added and/or amended.

The pride of the fleet - Model B+, and the AirPi has the GPS chip. #bling.
The pride of the fleet – Model B+, and the AirPi has the GPS chip. #bling.

The original software was released by one of the projects instigators, Tom Hartley. This was forked by Fred Sonnenwald as part of the pi.gate.ac.uk project – he added a number of useful features, not least of which was the web server to display figures and pretty charts. I forked from his work because I needed to make a couple of tweaks, but they turned into a fairly major update.

AirPi software - original release (left) vs. my v1.0 release (right).
AirPi software – original release (left) vs. my v1.0 release (right).

The original release of the software would read from sensors and either print the results to screen or send to a Xively feed. At the end of 2013 the code was updated so that sensors and outputs became modular. Fred Sonnenwald’s update added support for a number of new sensors (including the TGS2600 air quality sensor), output to CSV files, the aforementioned HTTP output, and the ability to dial in calibration functions for individual sensors. The latter is particularly important, as the cheap nature of the sensors used by the AirPi mean there is great variability between individual instances of the same model even from the same production run. Fred did a great post giving an initial look at interpreting readings from the AirPi.

I stood on Tom and Fred’s shoulders, and added a number of other features, including:

  • A host of ‘UI’ improvements, either clarifying existing output or adding more information for users.
  • Output plugins for Thingspeak, dweet, JSON, RRD and ASCII graphs.
  • A ‘notification’ system to send SMS, email or Tweet if an error occurs.
  • Ability to start sampling automatically with no user interaction when the system boots.
  • Record metadata with results.
  • Control script to standardise different ways of running the software (and stopping it).
  • Averaging, i.e. take readings every 10 seconds then average each set of six readings for a minute average.
  • Full documentation and code templates.

Full details of all the changes can be found in the README.md file in the root of the repository, and there are now full usage instructions in the `docs` folder – see the file `usage.md` to get started.

Convenient!
Convenient!

This commit was tagged as v1.0 because it’s now got in all of the features I need to support some ongoing work I’m doing with the Atmospheric Chemistry group at the University of Leicester. There are also some additional features which came about as a result of a thread on the AirPi forum – thanks to participants there for ideas and bug reports. I won’t be adding any more new features at this point, but will be doing bug fixes and a bit of tidying, and probably updating the code to Python3 at some point too.

The next major piece of work is calibrating each of the three AirPis we have under standard conditions, so that we can create the custom calibration functions needed to convert the resistance readings into standard units such as ppm. It’s absolutely my intention to keep updating the software and this blog with the results of that work, particularly as it reveals more about the responses of the individual sensors. For now, any questions or queries can be raised in the AirPi forum, or by questions and bug reports on GitHub too.

7 thoughts on “AirPi – a tentative v1.0 release

  1. Alan McCullagh says:

    Thanks Haydn.

    Gonna try to load this up now as I had at last assembled my AirPi this evening. With the Xively policy changes (waiting list etc) I was looking for a rapid solution to start using. Will let you know how it goes for me.

  2. Tom says:

    Haydn:

    I sent an earlier message regarding AirPi problems. The MICS2710 sensor on channel 2 is now ok.
    I noticed that my earlier (Ver-1) board has a UV sensor diode and not a microphone, I assume that’s why I am getting an error message. I also noticed that my circuit has a UV diode,a resistor and a capacitor, then a later version of the circuit has a UV diode with and OP amplifier (more sensitive) than the original circuit. I would rather have a UV sensor rather than a microphone, but your software is designed for the microphone and I am not sure how I can adapt for UV diode use.
    Tom

    • If you edit cfgs/sensors.cfg then you can set which sensors are – and are not – enabled for your particular setup. This means you can disable the microphone and enable the UV sensor. I haven’t got a board with a UV sensor, but the values for that were set in the original AirPi.es software by Tom Hartley, so hopefully they should be correct already.

  3. Marco says:

    Hi Haydn.
    I want to generate csv file, so i enable it in outputs.cfg but now I have this error:
    Loading: OUTPUTS
    Success: Loaded output plugin Print
    Exception AttributeError: “‘CSVOutput’ object has no attribute ‘file'” in <bound method CSVOutput.__del__ of > ignored
    ERROR: Did not import output plugin CSVOutput: __init__() takes exactly 2 arguments (3 given)
    Traceback (most recent call last):
    File “airpi.py”, line 1264, in
    PLUGINSOUTPUTS = set_up_outputs()
    File “airpi.py”, line 540, in set_up_outputs
    raise excep
    TypeError: __init__() takes exactly 2 arguments (3 given)

    Must the file csvoutput exist ?
    If yes, what is its contents ?

    Thanks !!!!

  4. Marco says:

    from log:
    2015-04-03 20:02:52,138 – __main__ – DEBUG – Final combined params to be used to create CSVOutput instance are:
    2015-04-03 20:02:52,140 – __main__ – DEBUG – {‘async’: False, ‘outputFile’: ‘-.csv’, ‘outputDir’: ‘/home/pi/AirPi’, ‘metadatareqd’: False, ‘calibration’: ‘off’}

  5. Dave Kemplen says:

    Hi Hayden
    Many thanks for the software update, my output from the airpi, after a lot of head scratching now looks like yours. I am not very good with Linux so learning as I go. Construction is not a problem and I made a uvi ad on to fit the j3 pins which works well.
    Whilst I have a gps fitted for some reason that I have not managed to find the cause all I get at start up is :-

    Could not import sensor module serial_gps —— in the sensors directory I have gps controller.py
    Did not import sensor plugin GPS No module named gps and I am not sure wether it should be in the same directory.

    Any pointers would be much appreciated.
    DaveK

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.