MH-Z19B - MHZ19: Unknown response: 0 0 0 0 0 0 0 0 0

[dmq]

Hi Forum,

I installed the developer version of ESPeasy 2.0 dev 12 to get my MH-Z19B to work. Unfortunately I can't get it to work Maybe someone can help me.

Platform is Wemos D1 mini.

I tried many PIN setups - I double-checked.

I alway get the following output:

Code: Select all

54264 : MHZ19: Unknown response: 0 0 0 0 0 0 0 0 0
64403 : MHZ19: Error, timeout while trying to read
64404 : MHZ19: Unknown response: 0 0 0 0 0 0 0 0 0

First I thought the sensor must be defect. But then I connected an arduino nano with the Serial-Pins rx,tx and I got valid data.

I can't figure out what leads to the situation.

I saw that there are two different versions of the sensor available. Please the picture ((c) Wolfram55: tweakers.net):



I've got the sensor at the bottom.

Here is another picture:



Has someone an idea?

Thanks,
dmq

[frenesik]

RX -> D6
Tx -> D7

And Esp Easy

1st GPIO -> D7
2nd GPIO -> D6

[TD-er]

What pins did you use?
And how do you power the sensor (what voltage)?

[dmq]

RX -> D6
Tx -> D7

And Esp Easy

1st GPIO -> D7
2nd GPIO -> D6

Thanks. Already tried this combination.

What pins did you use?
And how do you power the sensor (what voltage)?

I think I already tried all combination I could find in this forum / etc.
I use 5VDC. At first from the Wemos and after that with a dedicated power supply.

Thank you both,
dmq

[dmq]

Just to get sure with your recommendiation - I checked again:

RX -> D6
Tx -> D7

And Esp Easy

1st GPIO -> D7
2nd GPIO -> D6

Here I get:

Code: Select all

376866 : MHZ19: Read error : CRC = 113 / 0 bytes read => 0/192/0/240/0/224/0/255/0/
376866 : MHZ19: Shifted 2 bytes to attempt to fix buffer alignment
387109 : MHZ19: Read error : CRC = 68 / 0 bytes read => 0/254/0/224/0/224/0/254/0/
395267 : WD : Uptime 7 ConnectFailures 0 FreeMem 19360
397119 : MHZ19: Read error : CRC = 68 / 252 bytes read => 255/0/224/0/224/0/252/0/252/
397120 : MHZ19: Shifted 2 bytes to attempt to fix buffer alignment
407129 : MHZ19: Read error : CRC = 58 / 248 bytes read => 248/0/232/0/224/0/254/0/248/
407130 : MHZ19: Shifted 4 bytes to attempt to fix buffer alignment
417140 : MHZ19: Read error : CRC = 17 / 0 bytes read => 0/252/0/255/0/252/0/248/0/
417140 : MHZ19: Shifted 3 bytes to attempt to fix buffer alignment
417140 : MHZ19: Shifted 3 bytes to attempt to fix buffer alignment
425268 : WD : Uptime 7 ConnectFailures 0 FreeMem 19360
427265 : MHZ19: Read error : CRC = 12 / 248 bytes read => 240/0/248/0/254/0/254/0/248/
427265 : MHZ19: Shifted 4 bytes to attempt to fix buffer alignment
437686 : MHZ19: Read error : CRC = 25 / 252 bytes read => 255/0/240/0/248/0/255/0/252/
447695 : MHZ19: Read error : CRC = 15 / 0 bytes read => 0/255/0/252/0/254/0/248/0/
447696 : MHZ19: Shifted 7 bytes to attempt to fix buffer alignment
455269 : WD : Uptime 8 ConnectFailures 0 FreeMem 19360
457821 : MHZ19: Read error : CRC = 12 / 255 bytes read => 254/0/254/0/248/0/254/0/255/
457822 : MHZ19: Shifted 6 bytes to attempt to fix buffer alignment

Do you also get CRC errors or is eveything clean on your side?

[dmq]

Has someone any idea - maybe someone has the same sensor?

Can I provide you with more data / information?

[TD-er]

I have both sensors here (MHZ19 and -B version).
In one system I use these pins:
D5 GPIO14
D6 GPIO12

And in the other system:
D3 GPIO0
D4 GPIO2 (BUILTIN_LED on Wemos D1 mini)

I think you could try D5 and D6.
Are there other plugins active? Perhaps try to disable them, just for debugging.

[dmq]

I think you could try D5 and D6.

I will try it. At the moment I have no access to the sensor. I'll give you feedback soon. Thank you so far.

Are there other plugins active? Perhaps try to disable them, just for debugging.

No other plugins.

[timbiker]

I have the B sensor version with the specific white plug.

I did have CRC read error during few minutes. I guess the time to the sensor to heat up (I though it was written somewhere that 3 minutes are needed)

But waiting a few moment and the Wemos is able to read it

[dmq]

So, now I tried these combinations with no luck. Still CRC errors. I also tried a nodemcu now. Without luck. Sad.

Which software versions are you running? Does someone has a working MH-Z19 without the white plug / part on the backside?

Thank you.

[TD-er]

Does the red light inside the sensor light up every so many seconds?
I never used the version with the external white connector.
Have you also tried to switch Rx and Tx?

[dmq]

Yes, the red light is there. Under Arduino I get valid data. I switched rx and tx.

[TD-er]

What voltage do to use as Vin?
I have only used the older (pre B) version on 3.3V, but maybe the newer versions are a bit more specific on the input voltage.

[dmq]

I use 5V - do you think I shall try 3.3V DC?

[TD-er]

Nope, the datasheet mentions 3.6 - 5.5V, which starts at >3.3V
So I guess its results will be less accurate for 3.3V

[timbiker]

I have both sensors here (MHZ19 and -B version).
In one system I use these pins:
D5 GPIO14
D6 GPIO12

And in the other system:
D3 GPIO0
D4 GPIO2 (BUILTIN_LED on Wemos D1 mini)

I think you could try D5 and D6.
Are there other plugins active? Perhaps try to disable them, just for debugging.

Right, Mine is on D5 for the Tx and D6 for the Rx. 5v powered and it is working also

[dmq]

Strange. And you are both on "ESPeasy 2.0 dev 12"?

I use the precompiled image "ESPEasy_v2.0.0-dev12_dev_4096".

[timbiker]

Well, I compiled myself the core of version 2.0 dev 12 with the plugin of the branch "2.0" because my sensor is the B version and it's only supported by this plugin. I compiled a 1024 bin but this is not that important.

But I though about that today, I recently wasted my time in having a lot of issue on a project. I just solved them in changing my power supply : as this sensor is quite hungry during peak, check with a good power supply and a good cable

[dgcracker]

Hello all !
I am new on this forum so at the beginning I am sorry form simple questions. I am user of Nodemcu V3 and MH-Z19B. I have loaded ESPEasy_v2.0.0-dev12_dev_4096.bin into Nodemcu. I have connected D6-Tx, D7-Rx power supply is from nodemcu(5VIN,GND) and configured MH-Z19B sensor as:

CO2 MH-Z19 [TESTING]
1st GPIO GPIO-12(D6)
2nd GPIO GPIO-13(D7)
ABC Disabled
Delay 60[sec]

And in logs I see messages: “MHZ19: Unstable reading, ignoring! PPM value: 1470 Temp/S/U values: 28/0/0.00”. Values are only visible in logs, I can’t read them
Sensor seems to work fine? From time to time blinking read but I can’t display values on LCD connected to nodemcu. I gues that problem is in incorrect software loaded into nodemcu. And here is my question – which software version for nodemcu v3 is correctly working with MH-Z19B and where can I download compiled (*.bin) version? I am a newbie not familiar with Arduino IDE, compiling modules etc. Maybe somebody have already compiled and working version with MH-Z19B.

Thank you for help!

[grovkillen]

... I have loaded ESPEasy_v2.0.0-dev12_dev_4096.bin ...

The MH-Z19 plugin is active in the "test" bin file so you can flash that instead just to try. As of next release the plugin is part of the "normal" build. Just for information.

[dgcracker]

Thx for reply. I have loaded test file into nodemcu v3 and there is no change. Still can't read sensor values. Only in logs I see messages “MHZ19: Unstable reading, ignoring! PPM value: 776 ...." PPM and Temp in logs are changing but each read of sensor values report "Unstable reading....". Sensor red leds are blinking from time to time so it looks like sensor is OK. Any ideas?
Thank you for help!

[timbiker]

Thx for reply. I have loaded test file into nodemcu v3 and there is no change. Still can't read sensor values. Only in logs I see messages “MHZ19: Unstable reading, ignoring! PPM value: 776 ...." PPM and Temp in logs are changing but each read of sensor values report "Unstable reading....". Sensor red leds are blinking from time to time so it looks like sensor is OK. Any ideas?
Thank you for help!

I already had this issue and T-Der answered me. That's because you have the B version of the sensor. Like me

You have to get the MH-Z19 plugin from the "2.0" branch of the Espeasy github

[TD-er]

You seem to have the "B" version of the sensor, which gives a "0" as S-value.
Starting version dev-13, this will be supported, but you can also compile a version for yourself if you need it faster.
I don't think the new dev-13 release will take long, since the last 2 days, a lot of pull requests were merged and I think it is only testing for a (short) while with these new versions before the new release will be created.

[dgcracker]

Thx for reply and help. Exactly I have "B" version. So I have to wait for dev-13 or in the meantime compile it myself

[dmq]

But I though about that today, I recently wasted my time in having a lot of issue on a project. I just solved them in changing my power supply : as this sensor is quite hungry during peak, check with a good power supply and a good cable

Ah, timbiker. Cool. I just changed the power supply and now I have the same state as dgcracker, because I own the same B version. But it works.

Thanks TD-er and timbiker!

[dmq]

Just for information. The old power supply was rated at 5VDC/2A and the measurement was stable. The new one has the exact same values but works.

[dmq]

You seem to have the "B" version of the sensor, which gives a "0" as S-value.
Starting version dev-13, this will be supported, but you can also compile a version for yourself if you need it faster.
I don't think the new dev-13 release will take long, since the last 2 days, a lot of pull requests were merged and I think it is only testing for a (short) while with these new versions before the new release will be created.

Did already tested someone the dev-13 release and the "B" version? At the moment I have no access.

Thanks.

[TD-er]

You seem to have the "B" version of the sensor, which gives a "0" as S-value.
Starting version dev-13, this will be supported, but you can also compile a version for yourself if you need it faster.
I don't think the new dev-13 release will take long, since the last 2 days, a lot of pull requests were merged and I think it is only testing for a (short) while with these new versions before the new release will be created.

Did already tested someone the dev-13 release and the "B" version? At the moment I have no access.

Thanks.

Ehh I don't understand your post (maybe lack of coffee, or sleep, or both )
Is your question about whether someone tested the latest builds? (both v2.0 and Mega have nightly builds now)
Or did you test it and it still doesn't work?

[dmq]

Ehh I don't understand your post (maybe lack of coffee, or sleep, or both )

Nope, you were perfectly ok. I think I had too much coffee

Is your question about whether someone tested the latest builds? (both v2.0 and Mega have nightly builds now)

Yes, exactly. You wrote in another post:

You seem to have the "B" version of the sensor, which gives a "0" as S-value.
Starting version dev-13, this will be supported, but you can also compile a version for yourself if you need it faster.

Question is, if someone with this version of the sensor now can see the correct values in the interface and not only in the logs.

Thanks.

[TD-er]

With the latest builds, the B version of the sensor is fully supported.
I run one here for a while now.

[dmq]

Very good. Thanks.