MH-Z19: Invalid preamble from MHZ19 (after hard power cycle)

[enriquefernandez]

Operating environment/Installation (Hass.io/Docker/pip/etc.):

pip
ESP (ESP32/ESP8266, Board/Sonoff):

esp32

Affected component:

MH-Z19

Description of problem:
After esphome myconfig.yaml run, firmware is uploaded successfully and MH-Z19b seems to report values fine indefinitely. However, if I disconnect power and connect it again, sensor does not seem to report any values. Log messages show periodic warning:

[W][mhz19:029]: Invalid preamble from MHZ19!

It does seem like I get one first valid reading for CO2 and temperature upon restart. However, I do not get any other values after that and, instead, I get the message above when it's time to update the sensor.

If I run esphome myconfig.yaml run to reupload the same firmware wirelessly while the ESP is on, the sensor works perfectly fine after OTA completes.

Additionally, restarting the ESP via the Restart switch using HomeAssistant seems to have the same effect (e.g. the sensor works perfectly fine and reports values as expected after soft reboot is complete).

Problem-relevant YAML-configuration entries:

uart:
  - rx_pin: 32
    tx_pin: 25
    baud_rate: 9600  
    id: uart_co2 
  - platform: mhz19
    co2:
      name: "ESP32multi CO2"
      id: mhz19_co2
    temperature:
      name: "ESP32multi MH-Z19 Temperature"
      id: mhz19_temp
    update_interval: 30s 
    uart_id: uart_co2

Note: I've also tried with hardware UART (e.g. pins 16 & 17) but I get the same error.

Logs (if applicable):

Relevant lines are in the form of

[W][mhz19:029]: Invalid preamble from MHZ19!

which are only shown when the sensor is not reporting values (i.e. after hard power cycle).

Additional information and things you've tried:
Already described above.

[OttoWinter]

Please also enable very_verbose mode and post those logs - they contain what exactly the ESP is reading back from the sensor and help debug the issue.

[rickkdotnet]

I just wanted to chime in that I see the same behavior with 1.13.6 on a MH-Z19B connected to D0/D1 on a D1. If I reset the board with the reset button, or do an OTA update of the firmware the sensor reports values again.

Here's the very_verbose output (I grepped to filter out all the other messages from the display etc, let me know if you need more): https://pastebin.com/raw/pW7sN72C

(Note that this could be some kind of a power supply issue. I just received these sensors today and they report very high values and the leds on the d1 dim when the sensor is measuring. I'll try a different power supply and post if this fixes the issue)

[rickkdotnet]

If I power the MH-Z19 from another power supply:

• I get the same issue when I powercycle the MH-Z19 but not the D1
• I don't have the issue when I powercycle/reset only the D1

[anisart]

I have this issue on Heltec WiFi kit 8 on every powercycle

uart:
  - id: uart_1
    tx_pin: GPIO15
    rx_pin: GPIO13
    baud_rate: 9600
  - id: uart_2
    rx_pin: GPIO12
    baud_rate: 9600

sensor:
  - platform: pmsx003
    type: PMSX003
    pm_1_0:
      name: "PM <1.0µm Concentration"
      filters:
        - throttle: 5s
    pm_2_5:
      name: "PM <2.5µm Concentration"
      id: pm_2_5um_concentration
      filters:
        - throttle: 5s
      on_value:
        then:
          - logger.log:
              format: "pm2.5: %.0f"
              args: ['id(pm_2_5um_concentration).state']
              level: WARN
    pm_10_0:
      name: "PM <10.0µm Concentration"
      filters:
        - throttle: 5s
    uart_id: uart_2
  - platform: mhz19
    co2:
      name: "MH-Z19 CO2 Value"
      id: mhz19_co2
      on_value:
        then:
          - logger.log:
              format: "co2: %.0f"
              args: ['id(mhz19_co2).state']
              level: WARN
    temperature:
      name: "MH-Z19 Temperature"
      id: mhz19_temp
    update_interval: 60s
    uart_id: uart_1

I tried 3.3v and 5v for Vin.

[borpin]

I just wanted to chime in that I see the same behavior with 1.13.6 on a MH-Z19B connected to D0/D1 on a D1. If I reset the board with the reset button, or do an OTA update of the firmware the sensor reports values again.

@rickkdotnet - I cannot get my Wmos D1 Mini to communicate at all (neither HW UART nor SW) - care to share your config please?

[kekec14]

Hello! Has this issue been fixed? Have same problem as @enriquefernandez. I am using esp32 and after each power cycle i got message invalid preamble from mhz19 sensor. After reset/restart everything is ok.
Those are problematic lines from yaml file:

  - platform: mhz19
    co2:
      name: "MH-Z19_CO2"
      id: co2_sensor
    temperature:
      name: "MH-Z19 Temperature"
      internal: True
    update_interval: 60s
    uart_id: uart2_1
uart:
  rx_pin: 16
  tx_pin: 17
  baud_rate: 9600
  id: uart2_1

Thank you!
Regards

[borpin]

Are you using a B sensor? The commands have changed a little for the Rev B - DataSheet. I've raised an issue #709 and this may be part of the problem. I cannot get a 0-10,000 ppm sensor to respond at all.

[kekec14]

Yes, I am using B version. I used this sensor in combitnation with wemos d1 mini with software serial on pin D3 and D4, without this issue. So it could be the problem in hardware serial or in differebt type of the chip. I can try with software serial on esp32.

[borpin]

Yes, I am using B version.

What is the detection range of your device? Just trying to gather evidence for a theory.

[kekec14]

0-5000ppm

[vandecook]

I had the same same problem with MH-Z19B Sensor

The error was
[W][mhz19:029]: Invalid preamble from MHZ19!

For me I found a solution when I disabled UART logging

# Enable logging
logger:
# Disable UART Logging
  baud_rate: 0

[Electronlibre2012]

I had the same same problem with MH-Z19B Sensor

The error was
[W][mhz19:029]: Invalid preamble from MHZ19!

For me I found a solution when I disabled UART logging

# Enable logging
logger:
# Disable UART Logging
  baud_rate: 0

YES! thanks @vandecook , works great with SenseAir S8 too!

[OttoWinter]

Ok, since this appears to have been that the user attached MHZ-19 to the pins where logger also operates, this is expected.

Newer versions include a warning that warns the user if a uart component uses the same HW-UART as logger. So that notifies the user that they have an invalid config.