Skip to content
This repository has been archived by the owner on Sep 27, 2023. It is now read-only.

MH-Z19 sensor: disable auto-calibration and some odd fixes #592

Open
wants to merge 4 commits into
base: dev
Choose a base branch
from

Conversation

imammedo
Copy link

@imammedo imammedo commented May 5, 2019

Description:

  • Adds detection of MH-Z19B sensor
  • Ignore sensor reported values until it's booted.
  • Disable auto-calibration as it makes reported CO2 values not reflecting real situation in not sufficiently ventilated environment.
  • Fix/workaround non-recoverable "Invalid preamble from MHZ19!" case, when sensor is connected to hardware UART.

Checklist:

  • The code change is tested and works locally.
  • [ x] The code change follows the standards

If user exposed functionality or configuration variables are added/changed:

Igor Mammedov added 4 commits May 5, 2019 15:45
Reported CO2 might be not correct while sensor is booting and
while it boots it report value 15000 in response at offset
6-7. So skip reporting till this value is reported.

Signed-off-by: Igor Mammedov <[email protected]>
---
Idea is taken from ESPEasy implementation.
it will allow to report exact sensor type in dump config
and later will be used for turning off autocalibration.

Signed-off-by: Igor Mammedov <[email protected]>
MH-Z19B allows to enable/disable 'automatic baseline calibration'[*],
which is enabled by default (MH-Z19B v1.2 datasheet).
It operates on too short 24hr interval. So if the place
where sensor is located is not ventilated well Every day, ABC will
under-report CO2 since baseline (400ppm) is moved to lowest observed
value in 24hr.

With such short recalibrartion window, sensor often doesn't show
correct CO2 levels when ABS is left enabled. Disable it on boot
unconditionally.

Signed-off-by: Igor Mammedov <[email protected]>
When sensor is connected to hardware uart, sometimes on boot
uart's RX buffer contains several bytes of junk. Workaround it
by consuming all of it before sending command.
Also turn on cleanup logic only if problem is detected (i.e.
when reply from sensor doesn't look correct.

Signed-off-by: Igor Mammedov <[email protected]>
@imammedo imammedo marked this pull request as ready for review May 5, 2019 21:01
Copy link
Member

@OttoWinter OttoWinter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Automatic baseline correction should probably indeed be turned off.

Also See #591 (comment)

src/esphome/sensor/mhz19_component.cpp Show resolved Hide resolved
* TODO: implement an option to recalibrate sensor, to allow for occasional
* manual recalibration
*/
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole block sounds a bit more like it should go in the setup() function. We should probably move it there.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've tried it first but then node hangs for good (had to restart mcu several times before I was able to flash it again) on boot. With UART0 occupied by sensor without hardware to read log from UART1 output, I don't have means to debug it.

I'd still like to move it to setup, but don't know how to fix boot issue.

src/esphome/sensor/mhz19_component.cpp Show resolved Hide resolved

/*
* UART0 in NodeMCU v2, sometimes on boot has junk in RX buffer,
* check for it and drain all of it before sending commands to sensor
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uhm the flush command should flush the RX buffer (naming is bad, but copied from arduino core). If it does not do so that would be a bug.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's make on it as well,
but got arduino/esp only a couple days ago so I'm not sure where to look for respective code
and this workaround fixed non working sensor for me.

If it's within this git repo and you can point out to related code, I'll give it a try.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants