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:
Another integration here: dusty-bridge.php.zip (1.5 KB)
It’s been designed for LuftDaten.info 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!
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?
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!!
@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.
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.
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.
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?
Bargain.
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.
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.
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.
