Why does the MH-Z19 code never actually send a reset?

[DavyLandman]

Sorry to ignore the template, but I have a question about porting the MH-Z19 code to a different (yes GPL3 licensed) project I'm working on.

I found that most MH-Z19 implementation are quite limited, but the one in ESPEasy is thorough and has obvisouly been tested with real sensors over long. While porting it, I do have 2 questions that I hope @TD-er can shed some light on.

There are multiple places in the code that deal with the sensor getting stuck. I too have seen this behavior, that is what lead me to this implementation in the first place. However:

• the needsReset variable seems to be ignored except for a log message
• the preformInit call after too many broken messages doesn't reset the sensor, it only reset counters and recreates the SoftSerial interface

I cannot seem to find a single call to the send_mhzCmd(mhzCmdReset);, except when the user request it.

Is this intentional? Do you mind share the reasoning? Or is the reset more like a factory reset (and it will forget all the callibration for example?).

Thanks for your time (both in the existing module and in answering this question)

[TD-er]

Well as you may have seen, the code has been through quite some iterations, based on new insights. So there may be left-over parts of the code which were once implemented but later found to be quite destructive or only meant to be used with deep knowledge of the sensor.

First the reset() function. The reset() function you see is not really a reset of the sensor, but more something I am used to to clear struct settings/variables. Maybe not the best name for a function, I realize now. (maybe clear is better?)

There are ways to reset the MH-Z19 sensor, but some may lead to getting the sensor in some kind of limbo state and some also clear calibration settings. So right now the only thing that's being done is trying to get in sync again with the sensor data stream and trying to disable the ABC if needed.

To give a bit more historic view on this sensor. 3 - 4 years agom when the MH-Z19 was quite new, there wasn't a lot of information on the sensor. So some Russian guy (or at least writing blogposts with Cyrilic characters) was digging deep into the sensor to see to what commands it would reply. This along with some reactions from the manufacturer led to some understanding of the possiblities of the sensor. Almost all of them were once implemented in this plugin code in ESPEasy. Later the new revision (MH-Z19B) came to the market followed a bit later by its datasheets (and some revisions of those)

The main differences between those two is the way how it filters data. I implemented this filter also to be used for the older A version.. or at least as far as I could understand what it was doing based on the output values.

There are still some subtle differences between both regarding to the way they respond right after boot, but the ESPEasy code uses the strategy that would work fine on both.

About some commands being commented out in the code. There are commands to perform 400 ppm calibration and even 0 ppm level calibration. The 0 ppm calibration is something that should never been done by an end user. The 400 ppm calibration could be done is you know what you're doing. Sadly lots and lots of users started doing those calibration steps on brand new sensors in ways that would never result in a proper 400 ppm base line calibration. So that's why I made it harder to perform.

Problem is you can't be sure your CO2 concentration is 400 ppm, unless you have a very well controlled setup. Even outside air can be around 700 ppm or more. Especially during the night with lots of vegetation around. Plants exhail CO2 at night. Also living in a city may have elevated CO2 levels.

Is this information enough for you to continue?

[DavyLandman]

Thanks for the quick reply and the background. I've also read about the mess that is proper calibration. And also the flattening out if the sensor after a few years.

So a reset/clear is only to try and get back in sync with the sensor, if this is enough for all your users, it should be fine for my (future) users.

So the filtering tries to smooth out the jump right? It keeps track of the previous value, and calculates the delta, and if it jumps to hard, you only increment it slightly, and see if the next value also increases / decreases? It's a bit like a rolling mean I guess?

[TD-er]

Yep that's exactly what it does. The A version of the sensor gives somewhat of an uncertainty value ( 4 ... 64, all powers of 2) and I use it as a bitshift in the IIR filtering. It looked to me (based on the observations of the sensor output) that the B version does it internally. The B version also doesn't output this value or at least it is constant (0 or 1?)

The "Use unstable" filtering has no effect on the B version, but it enables/disables the filtering on the A version. Without it, you would hardly get any usable sensor update as it will react quite fast to CO2 concentration changes.

[DavyLandman]

Thanks for all the information! I'll close the issue for now. I'll post a link to the library if I end up with a working version that can be shared.