>>> Join Us in the Fight Against Air Pollution

AirGradient Forum

I-9PSL displays dash/hyphen for PM2.5 intermittently when air quality is good

Hi there, I recently purchased a pre-assembled I-9PSL and I’ve noticed an unusual behavior. It seems like, when I have all my windows shut and my air purifier on, the PM2.5 reading on the display switches intermittently between 0 and –.

Digging into this a little further, the condition seems to be triggered when all the PM readings are zero. For example, when accessing the device via the local server API, this will trigger the issue:

{"wifi":-43,"serialno":"xxxxxx","rco2":560,"pm01":0,"pm02":0,"pm10":0,"pm003Count”:0,"atmp":23.11,"atmpCompensated":23.11,"rhum":52,"rhumCompensated":52,"tvocIndex":125,"tvocRaw":30601,"noxIndex":1,"noxRaw":16683,"boot":782,"bootCount":782,"ledMode":"co2","firmware":"3.1.4","model":"I-9PSL"}

It’s almost as if seeing all zeros makes the device think “hmm, something’s wrong with the PM sensor, I have to reset myself.” When this happens, the display shows “–“ and all the pm values disappear completely from the JSON.

Stuff that I’ve checked:

  1. This does not seem to happen at all when the PM readings are non-zero. I shut off my air purifier earlier today for testing and right now my numbers are holding at around pm01":0,“pm02”:0,“pm10”:0,"pm003Count”:73. The display itself hasn’t gone to “–“ once in the several hours that I’ve been watching it.

  2. The all-zero PM readings do not seem to be the result of a bad sensor reading. I have tested turning my air purifier on/off, opening the windows, lighting a candle, etc. and the PM values seem to rise/fall as expected.

Anyway, I’m wondering if this is normal/expected behavior or if it could indicate some sort of software/hardware issue.

Thank you,
Eugene

This is very helpful information. Could you please open a GitHub issues at: Issues · airgradienthq/arduino · GitHub

This is where our developers look at bugs and fix them and this is also where they then comment on. Thank you!

In general this has been an issue we have been fighting with for quite some time. Normally we show a “-” when we get an error from the PM sensor. It seems that at very very low concentrations the sensor module itself sends that error message instead of the correct (very low) reading.

I think what we have already implemented is a 3x retry in these cases that seem to help a lot but might not catch all cases.

Thank you. For your reference, and others who may see this post, it’s issue #202 (I am not allowed to post links to Github here, apparently, but it should be pretty easy to look up by the number). The bug report also includes a video of the issue plus a log file, in case you’re interested.

It seems a like temporary workaround would be to make my air dirtier, but I don’t like that idea very much. :grinning:

@Achim_AirGradient

Follow-up on this: it seems like my unit was auto-updated to 3.1.8 last night. Now, when PM concentrations are low, the unit seems to reboot itself every few minutes.

I noticed this because my device is in my bedroom with the display off and the LEDs at very low brightness. On reboot, the display comes on and it’s quite bright until it’s initialized. As you can imagine, this is not great when people are sleeping.

With the previous firmware I was running (3.1.4) it just reported a “–“ when PM values were close to zero without lighting up. So, I will try to roll back to that version in the morning.

Thanks for reporting this. We will look into this.

Could you please run a log file and then send to us at support@airgradient.com

Online Debug

Sure thing, I will do this later today before downgrading.

Speaking of this, I am wondering if there’s a way to downgrade the firmware and prevent auto-updates? It seems that I can disable network connectivity entirely, but I would still like to have my data reported to the dashboard.

(I’m hoping that the solution won’t be putting a piece of black tape over the display while we are trying to sleep.)

Once you did the log file, please email us also the serial number.

We can then lock you to 3.1.4 for that particular monitor so it wont update automatically.

It looks like my device was rolled back to 3.1.4. I will still upload a log file later showing the original issue (GitHub issue #202) which has not yet been resolved.

Looking through some of the changes since 3.1.4, I see that issue #217 is “Reset board on repeated read errors from PMS sensor.” This sounds like it could be the cause of the new issue? I mean, if low PM values result in read errors from the PMS sensor, and read errors trigger a board reset, then it would make sense why my device was resetting itself constantly when it was running 3.1.8.

(One of the developers in issue #202 suggested the possibility that the sensor could be defective, but I don’t think that’s the case since I can basically make the issue go away by opening my windows and letting in some fresh air. Apparently, the air purifier in my room is highly effective, so much that it causes errors from the sensor).

Thanks!

Yes we decided to roll back to 3.1.4 all monitors to have time to address these issues.

Yes here are some weird edge cases from some of the Plantower batches that we investigate.

Ah, so if it’s an issue with some batches, then replacing the sensor could resolve it? I would be happy to pick one up off Amazon for $20 and try that if you feel that it would be useful.

The only possible complication is that I got a pre-assembled version for the warranty, so I don’t want to do anything to void it. However, if I got permission from the founder/CEO … :slight_smile:

No problem with the warranty but maybe you wait a bit before buying the sensor as we don’t have the root cause fully identified yet.

1 Like