Singapore is facing a severe haze crisis. Besides the subjective " this is bad", I got curious how the official air quality gets reported. Singapore's National Environment Agency uses the US devised Pollution Standard Index, but reports that onlt only as 24h, but also 3 h average for different places in the republic. Besides that they report the 2.5µ particle (PM2.5) count that isn't part of the PSI ( PM stands for particulate matter).
So far it feels like the information is genuine. Nevertheless knowing how an abstract number is formed is the first step to independent verification. With a little digging NEA provides the detailed instructions how the value is computed. The substances measured are: Sulphur dioxide (µg/m³). Particles with 10µ or more size (µg/m³), Carbon Monoxide (mg/m³), Ozone (µg/m³) and Nitrogene dioxide (µg/m³) which NEA publishes separately including a haze map:

Source: NEA
A quick check on Google reveals, that air quality measurement is quite a popular application both with Arduino as well as the Raspberry PI (there are more). It seems the Arduino has an edge when it comes to coupling the sensors, while the Raspberry PI shines in aggregation and web accessibility. Probably a combination of both would be a winner. Something like the Pinoccio meshed with a Raspberry Pi powered CouchDB for aggregation.
The real challenge however are the sensors (and their calibration later on). The PSI measurements are in weight per volume, while most of the data sheets for the sensors I found state sensitivity in particles per million (PPM) or particles per billion (PPB). Luckily LennTech provides an online calculator to transcribe the values for us:

Substance	range (weight/volume)	Parts per million	Parts per billion
Sulphur dioxide	80-2620 µg/m³	0.0284 - 0.9289	28.4 - 928.9
Carbon monoxide	5-57.5 mg/m³	4.05 -46.6	4050 - 46600
Ozone	118-1180 µg/m³	0.0558 - 0.558	55.8 - 558
Nitrogen dioxide	1130 - 3750 µg/m³	0.558 - 1.85	558 - 1850

The PM concentration can't be converted from weight/volume into ppm using a static formula, since particles can be anything with different weight. It needs to be measured.
So the hunt for suitable sensors starts. SO2 seems to be the biggest item on the list. I've looked so far at the following providers:

• Futurlec (no luck with SO2 here)
• Alphasense
• Aliexpress (most of the stuff is made in China anyway) - with an impressive 75 different gas sensors rom just one company
• Sparkfun (of course) - no luck on SO2,
• Parallax
• The Sensor Portal

I would be grateful for more hints of suppliers. Once the sensors have been settled, further planning will commence. stay tuned!

I like my Java to be well managed, properly prepared and of top quality.
Unless you are living under an XRock, you know that managed beans are (one of) the talk of the town in the XPages community.
While managed beans are simple beans that have been given a name and a scope, they need some thought when you want to test your applications.
Refering from one bean to another or to a session and the current database is made easy using com.ibm.xsp.extlib.util.ExtLibUtil. However I like to test my code outside the XPages environment, where such a call (or any call to a JSF resolver) will fail. So I came up with a helper class to make the beans testable. Let's start with a typical managed bean setup: To access those beans from plain Java as well as the session and current database I use a helper class. It doesn't matter if you use thee helper from the command line or in an XPages, the results will be the same. What is important: you can't store the oobjects when you use them in the XPage since they are either not thread save (session, database) or would loose their scope association (the rest). If you want to make the setBeans (see below) method more robust, you could call javax.faces.context.FacesContext.getCurrentInstance(). If anything else but null is coming back, you are in the XPages thread and should not set the objects to anything but null (or add that to your getter?)
The enum.INSTANCE is a Singleton and asures that I always get the same object back. This allows me to write a test class (or actually use JUnit tests) like this: The test class is easily run from Eclipse or the debug perspecitve in Domino Designer and you can step through with the debugger. Other than the local http preview the code runs with the current userid's permissions, so you don't need to mess with the ACL. The whole class is about a hundred lines and pretty easy to understand: