Many readings of zero, leading to few messages

[brev-dev]

Great work on this mod, thanks @Hypfer!

I've now tried it with two sensors. One works flawlessly, reporting regularly over MQTT. The other is quiet for long periods of time, only occasionally reporting a reading. Over serial, I see that many of the measurements are zero (and the code won't publish unless the average reading is greater than zero).

At first I thought it was either a dead sensor, or a hardware issue with my mod. But if I hold a match next to the sensor, the light changes to yellow and red, and the reported numbers increase. MQTT messages are then sent until the smoke dissipates, the sensor returns to green, and the numbers reduce to zero again.

So what's going wrong? Bad sensor? Acceptable calibration differences between sensors, which need to be handled differently in the code? With a sample size of 2, I don't have enough to go on.

For now, I'm going to remove the "don't publish if zero" line in the code, set the two devices next to each other, and set-up logging of the MQTT messages to see if this sheds any light on the behavior.

[Hypfer]

Interesting report. Honestly, I have no idea whether or not 0ug/m³ is a plausible reading or not, however that check was only there because I didn't know that there was a checksum in there to ensure that we only store valid readings.

As that has been added with https://github.com/Hypfer/esp8266-vindriktning-particle-sensor/commit/04701b28db4d816c9ff1e639ea4a1adae00e755d, all those > 0 checks are obsolete and can be removed I think

[brev-dev]

Thanks again - I'll give it a try!

[brev-dev]

OK, here are some side-by-side tests. For the "problematic" Device1 (red curve), I removed two of the zero checks in the code (one in the check loop, and one in the average calculation in SerialCom.h). The "behaving" Device2 (green curve) uses your code unchanged.

The first image shows an ambient overnight test. Device1 produced nothing but zeros all night.

For the second image I placed both devices under a plastic cover (maintaining the Ikea theme), and added a bit of smoke. Both devices color-cycled from green to red and back, with Device1 transitions consistently trailing Device2 as the air quality worsened, and leading Device2 as the quality improved (as an aside, it looks as though the transitions are at about 30 and 100ug/m³).

Conclusions... I suspect both devices are "working", at least for the intended purpose of a rough traffic-light air quality display. And they'll be fine for me, too. The absolute values they report are quite different, though. I haven't looked into data sheets, but maybe there's a way to calibrate the sensor if it matters to your use case.

In terms of the mod, yes, I suggest you remove the zero-checks, as long as it doesn't break anything else!

[Hypfer]

I wonder if one could implement an auto calibration algorithm similar to what is used in some CO2 sensors:

https://www.monnit.com/support/knowledgebase/sensors/co2-auto-calibration-feature/

TL;DR: It takes the lowest reading during a long interval (multiple days) and assumes that that must be a specific value (400ppm).

[pejotigrek]

I know this issue is closed, but I just wanted to give you measurements for transitions, just in case they're needed somewhere - according to the user guide attached to my Vindriktning sensor here they are:

• green: 0-35 (good+low)
• orange: 36-85 (OK+medicore)
• red: 86-... (bad+high)