SDS011 PM2.5 / PM10 Air Quality Particulate Sensor with Emoncms / emonPi

Tags: #<Tag:0x00007f8df0359500>

Building upon the work of @danbates

We’ve been testing a couple of low cost Nova SDS011 PM2.5 / PM10 air quality sensors logging to Emoncms

It’s quite an impressive sensor (for the cost). It’s very responsive to small changes like doing some soldering or cooking. It’s interesting to see how these actions affect air quality.

If you’re interested in giving it a go we’ve got a docker container / script to make it easy to post the data to Emoncms (HTTP) or MQTT. The docker container has been tested running on emonPi (emonSD-17Oct19), Ubuntu and Synology DMS:

To get started

git clone
cd usefulscripts/SDS011

Copy the environment file:

cp default.env env

Edit your environment file to set your mqtt / emoncms http and ttyUSB settings, use dmesg to find your serial port assigned to the sensor:

nano env

Build and run the docker container

docker build -t dust .
docker run --privileged --env-file=env dust

Run in the background on boot and always restart

docker run -d --privileged --restart=always --env-file=env dust


On the Home Assistant theme, there is also an HA component for this device

1 Like

Another integration here: (1.5 KB)
It’s been designed for project firmware, and can be places at emoncms device homepage root, along-side index.php. The luftdaten firmware I can recommend because it easily integrates with two widely accessible PM data world maps.
At the luftdaten ESP-based firmware web-interface thing, are the fields to enter the custom API credentials.

The PHP script attached has clues on what to enter in the fields.
The essential info is: the ‘username’ field at the ESP web-interface is the emonCMS API write key.

@glyn.hudson we could create a graphic of the interface/API options, I think we have three methods now!

How often are you reading the air quality?

The datasheet says these have a 8000hr service life, which is just 333 days if running full-time, although a 1Hz reading is a bit OTT so are you just spinning it up once every minute or so? I read somewhere that it needs to spin up 30secs for a good reading, so once a minute might only double the service life to less than 2years if I’m not mistaken? If so those “cheap” sensors might become quite an expensive habit, cash wise and environmentally if the sensor cannot be saved, no?

Some interesting reading about the SDS011 (and a few other PM sensors) and calibration.

1 Like

up to 8000 hours, so maybe less. That’d be a bummer if it turned out to be significantly less. :frowning_face:
Further driving up the cost, as you mentioned above.

1 Like

To add to the sites that have code for connecting these, here’s one where the guy used an ESP32 ->

Given I’ve already got code for an ESP8266 for reading DS18B20 temperatures and sending them to my emoncms server and MQTT, I’ll replace the DS18B20 code with some to read from the sensor and hopefully ‘hey presto!’.

Will probably never re-light the wood burning open hearth afterwards mind you!!


1 Like

@Bill.Thomson that’s a good bit of research, I’ve seen it before and had forgotten about the humidity factor.
I think the most important aspect of accuracy of these devices is to do with humidity.
Humidity should ideally be read in parallel with PM count, and the count should be adjusted in software according to humidity.
I don’t know if luftdaten firmware does this. Their typical setup does include a temperature/humidity sensor.

Interesting that’s pretty low! I wasn’t aware of that. We’re currently taking a reading every 10’s but the sensor fan is running continuously. I’ll look at adapting the code to power down / spin down the sensor in between readings and maybe reduce to once per 60s? Or even slower

How often does it change - is there much jitter? If you looked at the trend, it would help you assess how often to sample. Perhaps the average of a burst of 3-5 samples every 10 min would work.

1 Like

A good indicator (for indoors) would be Building Regulations - how many air changes per hour for a given room and usage does that call for?

Yes, there’s quite a bit of jitter

However, when there is an event which significantly changes the air quality it’s nice if the sensor responds quickly allowing easy attribution to that event e.g

The paper that @Bill.Thomson linked (I’ve only skimmed it) suggests any short term readings are not reliable and that readings should be averaged over 15mins or so to remove spikes. Depending on the purpose of the reporting, perhaps a reading every 10mins and averaged over an hour would suffice to establish the general air quality, obviously this won’t work for any form of warning system etc but I don’t think this sensor could be relied upon for any crucial warning/monitoring etc.

1 Like

I haven’t looked into it in depth so I don’t know exactly what “the service life” refers to precisely. If it is the laser or sensor (not the fan?) maybe reducing the sample rate alone might do? I have no idea if the laser or sensor are permanently on or just “for a reading”. 8000hrs does seem awfully short, but would actually be pretty long if it’s only a few millisecs each minute.

Big spike. What causes that?

I think it was in the article I quoted but certainly somewhere in what I’ve read there is mention of dust building up in the laser (they must mean in the enclosure, not actually in the laser!). So maybe the service life is due to that buildup - in which case it would be worse in a more polluted environment.


I believe luftdaten’s default post rate is every 2 minutes, the fan is span up 30 seconds before a reading.
Is that up to 3.6 years of service life for £25?

EDIT: Basically a mute point that anyway. A few days worth of data is worth that price if a community wants to get some ball park figures on PM levels.

1 Like

That doesn’t look like jitter to me. That’s the pattern of air circulation present in the room. We have two sensors side by side at the lab.
If we really want to look at jitter, we should compare them side by side.

1 Like


1 Like

Building Regs change a bit over time, and are somewhat complicated. They used to require a purge rate of 0.44 ACH. Modern regs aren’t specified in terms of ACH. They’re in l/s/m², which if you convert to m³/hr is m³/hr/m² or m/hr which looks like an unusual unit of speed. If you said somewhere between 0.2 ACH and 0.4 ACH you’d probably catch most opinions.