Looks to be related to the change in serial I made recently.

What gpio pins do you use?

It might be, lets see, I guess you have found a point Gijs :-)

esp01 = Gpio0 Gpio2 (no problems seen yet)
esp02 = Gpio14 Gpio12
esp08 = Gpio14 Gpio12
esp18 = Gpio14 Gpio12

Peter

I have two nodes here I can also test later this afternoon

Ok,
Fault is not immediate, they stop sending after a while, and are quite persisting in that then, reboot or sw downgrade is not enough to get them sending data again. They need a powercycle and some time between off and on.

How long is "after a while" ?
I have just setup a node using one of these sensors and also a BMP280 is connected.
It is using GPIO-14 & -12 for the CO2 sensor.

a couple of hours, yesterday everything was working, this morning i had 3 out of 4 with same status.

And they all booted around the same time, before they all stopped working?

yes, all were restarted/updated within an hour i think, was updating them yesterday evening. and during the night they stopped working

I was just about to update my nodes but luckily noticed this. @TD-er which would be the latest release before the changes to Serial you're guessing might be the culprit? Or would it be more useful if I flashed the newest version to see if I'll experience the same issue?

If any missing updates are not a big deal, I would suggest the latest version.
To keep on the version before the serial port wrapper, you could use 20181231. (I think I committed the changes this year)

i did downgrade the 3 "problem" esp's to 20181231 yesterday, can confirm they are still sending data with no hardware changes, now for 24h so those three esp's still using gpio12 and gpio14 in my case

Any luck with recreating it Gijs ?

Nope, my node is still sending values and it is running the build from January 16th. (core 2.5.0)

i used the ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin on those nodes, that has the 2.4.1 core i believe ?

@pwassink That's correct.
You can also see the core build in the sysinfo page.

I did install that version ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin back to the esp02 here, lets see if it happens again

Hmm,
Maybe the day of the week or the position of the moon has a certain influence,
I did not see the fault reoccurring here within the past days.

It seems to be working fine here too.
It was just about full moon when you reported it, so I guess that should have been it ;)

Update,

i left esp02 running with the ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin version that is still running as it should.

Yesterday i did update the rest of my nodes to ESP_Easy_mega-20190121_normal_core_241_ESP8266_4096.bin

And esp-18 went bozo again at 06:55 local time, all is functioning as it should, except the MHZ19 Co2 sensor, in the devices tab it is displaying the "last-known-good value" from approx 07:00 and again with the same entries in the Logfile :
MHZ19: Error, timeout while trying to read
MHZ19: Unknown response: 0 0 0 0 0 0 0 0 0

Esp-18 is using Gpio 14 / 12
it is a Nodemcu with Ch340 version 2 of 3 from ali
Remote reboot via web console did not solve the issue
again it is displaying those entries mentioned above several times
After powercycle
78640: MHZ19: Error, timeout while trying to read
78641: MHZ19: Read error: checksum = 202 / 0 bytes read => 255/168/12/161/226/255/0/0/0/
78643: MHZ19: Shifted 1 bytes to attempt to fix buffer alignment
After some more time :
255652: MHZ19: PPM value: 1584 Temp/S/U values: 25/0/0.00
255656: EVENT: Rik-CO2#PPM=1584.00
255656: EVENT: Rik-CO2#PPM=1584.00 Processing time:1 milliSeconds
255659: EVENT: Rik-CO2#Temperature=25.00
255659: EVENT: Rik-CO2#Temperature=25.00 Processing time:1 milliSeconds
255662: EVENT: Rik-CO2#U=0.00
255662: EVENT: Rik-CO2#U=0.00 Processing time:1 milliSeconds

It seems working again now, but needed the powercycle about 2 minutes no power

Does it need to do something at that moment? Can be something which could lead to a hickup of the wifi on the ESP?

Nothing at all,

There are no scheduled resets, reboots, backups, wfi resets, dhcp cleanups or any external reason at that time

And the wifi keeps working fine it is just the readout of the mhz19 that stops, all other (i2c based) sensors on same esp still work

This morning at 03:00 it happened again with Esp-18 running the 0121 Mega version, Same errors in esp-logfile as before, other sensors work fine

And at 19:05 the esp02 running with the ESP_Easy_mega20190116_normal_core_241_ESP8266_4096.bin also crashed, same situation as above, no data anymore and same entries in logging.

Again 2 hickups today, esp02 and esp18 both went wrong again same faults in the log
Software 2 versions involved, 0116 and 0121 both 2.4.1 core and 4 Mb version
hardware of esp02 is a nodemcu-d1-mini / esp18 is a nodemcu-v2 both use gpio12/gpio14

Can you try this build on one of your nodes?

ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

It is running on one of my nodes with a MH-Z19 and has now an uptime of 54 days 23 hours 21 minutes
That's since a power outage...
This one is running fine with regular updates of the CO2 value.

i will,

but have i already mentioned before that up till version mega 20181231 core 2.4.1 normal 4Mb none of the reported stability issues have been seen, so why this specific version ?

i will download that specific version en install it to eesp02 and esp18 co2-measuring nodes, but the problems appeared in the mega-2019* range not earlier in my humble opinion Gijs ..

OK, then it is of no use indeed.

That specific version is running on a version I have which appears to be (sadly unusual) stable.
And you're right, if it was running fine until 20181231, then it is not really worth to try the older ones.

Nevertheless,
Esp02 and esp18 are running on ESP_Easy_mega-20181109_normal_ESP8266_4096.bin now
Esp01 and Esp08 are running on ESp-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin

And we will see

Remark, my eye just catched that the 1109 version has build number 20102 so that is way back and different ?

Gijs,

I might have found another clue on this issue.

a couple of minutes ago my Esp08 A nodemcu ch340V2 4Mb running ESp-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin stopped sending co2data aslo.

Log snippet
370508579: UDP : 60:01:94:0F:AF:9D,192.168.3.46,17
370508785: UDP : 24:0A:C4:82:F2:B8,192.168.3.51,21
370509501: UDP : 60:01:94:0C:2E:FD,192.168.3.48,19
370514624: UDP : 5C:CF:7F:82:FD:47,192.168.3.31,2
370515674: MHZ19: Read error: checksum = 120 / 248 bytes read => 255/134/5/183/71/128/15/112/248/
370515677: MHZ19: Shifted 1 bytes to attempt to fix buffer alignment
370517702: EVENT: Clock#Time=Wed,12:19
370517755: EVENT: Clock#Time=Wed,12:19 Processing time:53 milliSeconds
370520257: UDP : 60:01:94:0B:94:5C,192.168.3.30,1
370520460: UDP : 60:01:94:02:0E:E8,192.168.3.36,7
370523940: UDP : 18:FE:34:E2:18:84,192.168.3.35,6
370529880: UDP : BC:DD:C2:EA:3D:BC,192.168.3.54,24

This is the first time i've seen this fault, maybe ..

A checksum error should be handled more gracefully.
Maybe we should add some threshold on when to start shifting to search for a new good start.
Or a better algorithm to get in sync again.
As far as I know, there has been no change in the code for this in over a year. There has been only a change in the way the serial port connection is being created, so I really don't know why it leads to these issues.

I have the idea that the mhz19 sensor itself enters a "blocked" state after a couple of hours miscommunication or as the result of not beeing able to get data out. ?
Motivation: a reboot or even a full sw-update does not solve that status, the mhz19 has to be powerless for a minute or so to regain life, i found this behaviour when it is stuck in the status that looks like:
MHZ19: Error, timeout while trying to read
MHZ19: Unknown response: 0 0 0 0 0 0 0 0 0

The fault esp08 was this morning was still solvable with a remote reboot option from the web console so it was not the same as the complete lockup after several hours i've found and reported a couple of times.

But found this afterwards:
at approx 1800 local time it went in to the blocked status, reset, reboot through console powercycle nothing worked this time, Device needed a re-flash with mega 20181231 4mb version then it came to life again. Esp08 is using Gpio12/14 combination and is a nodemcu v2 ch340 model too

It sounds quite strange, since the plugin does send a command to gather new sensor data to the MH-Z19
So I don't get it why even a soft-reboot is not working.
I will add also some stats to see how often a checksum error occurs (receiving end)
If that happens a lot, it may also happen when sending data to the sensor and maybe the sensor is then put into some unknown command mode.
Maybe some pull-up resistor configuration has changed when I changed the way how serial pins are configured???

It might,

will look into it a bit further tomorrow or during the oncoming weekend perhaps i will be able to find something, is that sensor not that widely used that no-one suffers identical behaviour ?

Or not used by people running the latest builds

I have 2 MH-Z19b, both running on 20190116 test build without issues

Ok, just curious exactly which core-version of the test build and which Gpio's are you using ?

I see 1 is running ESP_Easy_mega-20190116_test_core_250_beta_ESP8266_4096.bin, the other ESP_Easy_mega-20190121_test_core_250_beta_ESP8266_4096.bin. On both sensor connected to GPIO 13 & 12

So that's another core and one other GPIO you are usin 13/12 instead of GPIO 14/12 i use here

Today i updated 4 out of 4 to the ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin version

lets see

Now that I think of it, there may be another change in the used SWserial library since start of this year.
We used to have our own version of the SWserial library, which I patched to use less iRAM memory.
But now we are using the version included in the core library and for the core 2.5.0 this may be a newer version than before.
Also there may be some change in the use of interrupts on low-speed connections. (9600 baud and lower)
I must look into that too.

It still doesn't explain why the sensor apparently can get so messed-up it needs a power-down to act normal again.

Within 3 hours after updating to ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin my esp18 was locked up again, webconsole reboot did not work, powerdown was required again.
the other one is still working, will add inhere if it freezes the MHZ19 also

Yes, the other one esp18 stopped sending reasonable CO2 Data at 19:05 this evening, so fault is persistent in yesterdays mega 202 core 2.4.1 at least .
That one is back and donwgraded to the 20181231 version now too.

Around midnight the third esp, esp02 froze up with the Co2 readings, also downgraded to 20181231 now

The only one still running on the ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin is the one that is using Gpio-0/Gpio-2, the other three who did freeze up are using Gpio14/gpio12.
i don't think this is a coincidence anymore,

i will change esp02's wiring tot Gpio-0/Gpio-2 and upgrade it to the 0202 version core 2.4.1 again and we might see if that stays alive after this gpio-change.
Done

I just added a commit to do some improvement on the reading.
See https://github.com/TD-er/ESPEasy/commit/3d507bdbb9dc6dd4aee2ce0c7ce6c809ea7dfb7c

Can you build a test version for it, or do you want me to build one?

If you could provide me with a bin i will be happy to put it on both still on gpio12/14 running esp's
and then it is certain the file is the same, no local influences etc ..

OK, took some time, but here is the test build

Got it,

Esp08 and esp18 are running on this testversion with the 2.4.1 core now, they both use gpio12/14

Lets see !

You should also see some indicator showing the number of lines processed and the nr of CRC failures

Yes , i have them in the console too now!

will leave those 2 and see at certain interval if those counters increase.
Keep you posted ..

Both sensors in use at the test nodes are B versions so that detection worked too

Checksum (pass/fail): | 11/0
-- 08 --
Detected: | MH-Z19B

Checksum (pass/fail): | 8/0
-- 18 --
Detected: | MH-Z19B

Do you also have a mix of MH-Z19 A/B or only the newer B versions?
It should not matter, just curious.

Do you also have a mix of MH-Z19 A/B or only the newer B versions?
It should not matter, just curious.

B versions, just added that info , detection worked too :-)

small update, all are still running fine, the ones with your special version esp8 and 18 show increasing counters but still no faults or checksum errors, current values are:

Esp08: Checksum (pass/fail): | 1795/0
Esp18: Checksum (pass/fail): | 724/0

and the other one that failed quite consistent esp02 is also still running now with the changed Gpio's
and thus di-mini has now the mhz19 on Gpio-0/Gpio-2 and mega 20190202 version core 2.4.1

Bummer accidentally deleted the post here , try to recreate out of my memory :

Yesterday evening three of my esp's 02, 08 and 18 went red on Domoticz, no Co2 sensor data.
two of them have the special version core 2.4.1 , and gpio 12/14. A web console reboot did not solve it, and only produced: MHZ19: Unknown response: 0 0 0 0 0 0 0 0 0 but esp18 co2 measurements gained life back after approx one hour, at 0:56 it started sending proper values again .

Esp08 has received a reboot too, and esp02 also (that one has gpio0/2 now same as esp01) both did not recover, and this morning both got a 2 minute power-down , after that both came back to life ok.

I now changed the software-version on esp02 to ESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4 so we can test that core-version too, the gpio chnage did not make a difference running the old (current 2.4.1) version became clear
esp02 did show a single checksum failure today: Checksum (pass/fail): | 79/1

I also activated syslog for esp08 only in the beginning, with settings als below, if you want a specific setting please ask.

Maybe you can also itemize your configs in the post (can also be next post, no need to edit this one) showing the following:

• Your internal unit nr (for your own reference like "02, 08, 18)
• Build running
• nr of success/fail (if available)
• kind of failure/issue

Itemized information is (for me) easier to follow compared to descriptive text.
I also reply from my phone sometimes.

esp08/18 ESP_Easy_mega-20190202-58-PR_2235_normal_ESP8266_4096 core 2.4.1 gpio12/14
esp01/02 ESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4096 gpio 0/2

-- frozen means woriking fine except for co2 readings

22:57 esp08 frozen again, counters Checksum (pass/fail): | 1077/2 put syslog aside when found.
05:05 esp18 frozen again, counters Checksum (pass/fail): | 1076/2
06:25 esp08 frozen again, no counters, esp was crashed completely this time, got syslog
12:57 esp18 frozen again. counters Checksum (pass/fail): | 116/2
20:43 esp18 frozen again, counters Checksum (pass/fail): | 316/2 tried the mhzreset command
No changes what so ever, sensor is sending the mhz19 unknown response 0 0 0 0 0 0 0 0
message over and over again, tried several attempts no solution, power cycled the node .

Gijs,

I did some analysis on the last syslog of esp08, during the hours that it is running i saw 78 occurances of:
2019-02-08T05:27:07.581181+01:00 hub08 EspEasy - - - EspEasy: MHZ19: Unknown response: ff 0 0 0 0 0 0 0 0

Automated search using #cat messages-crash-esp08-0625 |grep MHZ19 | grep response | grep 'ff 0 0 0 0 0 0 0 0' | wc -l

and after changing that cmdline to the second unknown-response variant linux counted 408 times this line :
2019-02-08T10:44:06.855432+01:00 hub08 EspEasy - - - EspEasy: MHZ19: Unknown response: 0 0 0 0 0 0 0 0 0

The checksum error counters in your custom-debug-version did not get any higher than 2 as far as i saw during the last couple of days.
the first error message (MHZ19: Unknown response: ff 0 0 0 0 0 0 0 0) came a couple of times six or so directly after each other before it froze up this morning.

It looks like the sensor itself is crashing, but I can't think of a reason why it is doing it now.
In our source there is a command for calling reset of the MH-Z19 sensor, but that's not documented in the datasheet.
So I don't know its status.
Could you try to call that command on a node which is stuck like this?

Edit: that command is mhzreset

There has to be some change made after the mega 20181231 2.4.1. 4Mb version which has this results on the MHZ19 as far as i found yet. that one is running for weeks without problem even on gpio 12/14.

will try it next time something stops working, at 23:20 found that esp18 was frozen, mhzreset did not change that, see above log.

the mhzreset command does not open a command window in the webconsole, does not report Ok back or so, after several attempts i found in the syslog :
<5>1 2019-02-08T23:25:34.164674+01:00 hub18 EspEasy - - - EspEasy: MHZ19: Sent sensor reset!
<5>1 2019-02-08T23:25:36.313828+01:00 hub18 EspEasy - - - EspEasy: MHZ19: Sent sensor reset!
so easy says it has been sent, but it seems not in a flavour the mhz19 understands or likes :-)

That command does seem to do something for the MH-Z19 A version.

127136: MHZ19: Sent sensor reset!
137272: MHZ19: Unknown response: ff ff ff ff ff ff ff ff ff
152275: MHZ19: Unknown response: ff 31 f5 4b 42 32 30 30 d
167277: MHZ19: Bootup detected! PPM value: 5000 Temp/S/U values: 23/1/15000.00
197279: MHZ19: Bootup detected! PPM value: 400 Temp/S/U values: 23/1/15000.00
<repeat a few times>
257279: MHZ19: PPM value: 906 Temp/S/U values: 24/64/11554.00

So it looks like it cannot be used on the B-version.

I could assume something like that command is also used someway in the startup / init of the plugin ?
which might explain why a reboot / reset without power cycle does not solve the problem.

Did not see failures until this afternoon:
15:43 esp08 frozen again, counters Checksum (pass/fail): | 2316/2 put the systlog aside.

And just to be sure, these nodes were running fine on older firmware versions?

Yes up till the ESP_Easy_mega-20181231_normal_ESP8266_4096 is was and is still ok,
They would run for weeks without problems

I looked into the recent changes in the SWserial library, since that's the one we're now using.
One of the changes made in there was to no longer use interrupts on TX transfers for 9600 baud.
Can you try this test build ?

N.B. I also removed the core 2.5.0 builds, since they act strange when serving web pages.

Esp08 and Esp18 running ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin
those two also do send their data in to a syslog server so the log data will be recorded

The other two will follow tomorrow, one of them might be a Mhz19A, And it is.

Hw config is now:
Esp01 has the MHZ19A at gpio0/gpio2
Esp02 has the MHZ19B at gpio0/gpio2
Esp08 has the MHZ19B at gpio12/gpio14
Esp18 has the MHZ19B at gpio12/gpio14

All of them on the same testversion of esp-easy now, running on :
ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin

update

06:01 esp08 frozen again, counters lost(user caused ) put the syslog aside.

05:21 Esp18 frozen, Checksum (pass/fail): | 1460/0, have put syslog aside
12:53 Esp08 frozen , Checksum (pass/fail): | 1351/28, have put syslog aside

The core 2.4.1 build was not included in that test build, so I just made one only containing that core version. core 2.4.1 build of same code as in ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin
That one uses an older version of the SoftwareSerial library.
If that's working, then I will change the used SW serial library.

Starting upgrade to the special-version: firmware.bin for all 4 nodes now, finished at 12:30

First thing i noticed, Esp08 was frozen, this firmware update restarted the MHZ19B , it came back allive, an the init i mean: sensor is giving me a reasonable C02 Value this seemed much faster too

I am running the old SWserial library on a test node too and indeed it is working much better
For example the Eastron energy monitoring was having about 20 - 30% of the received lines corrupted, but this is now running perfectly. (no failed checksums yet)

I just made a new test build in which I changed a lot regarding the HW/SW serial wrapper.
It now works with the Eastron plugin for both SWserial and HW serial and SWserial is now using the old library we used until 20180131.

So this is actually the same as the 0202 version but with the same serial lib as the 20181231 version, i will upgrade them directly .. just a moment

Installed ESP_Easy_mega-20190212-73-PR_2235_normal_ESP8266_4096.bin
on Esp0/02/08/18 now
 
lets see ..

Yep and it has the HWserial/SWserial wrapper, so it should be easy to switch to HWserial as soon as you're using the correct pins for those.

I still need to add GPIO2 as extra option for HWserial0 and there is still some cleaning-up to do in the code.

As the first hours passed by they are still working, after the last update i cant see any unknown
response ff 7 x 0 or 8 times 0 messages in the syslog from esp08 or esp18 anymore.

Took some time to look into the syslog-data of 2 nodes:
Esp08 still has a unknown response with varying code's once in a while,
Esp18 did not produce any faults yet

Good to hear.
I think we had some issues where the data sent to the sensors got corrupted.
Then the sensor itself may crash, I guess.

With the Eastron plugin (sending a lot more data) the number of checksum errors was significantly reduced.
From about 20 - 30% CRC errors in the messages to near 0. (1 error in 10'000 messages) using SWserial.

Still running fine, all four of them

Looked at the fixed-list of release 20190215, is that version now the same as the version i am running on the 4 Co2 measuring nodes here ?

Almost the same.
At least the code for serial port and your plugin is the same.

Then i leave it as it is and continue testing with the "special"

Was not clear to me what was included in the release and what not ,some of the numbers did match.

Yep the big PR I merged yesterday was the source of all the test builds I made last weeks.

Esp08 frozen at 14:17, counters Checksum (pass/fail): | 3292/70, syslog put aside for further analysis

And did a simple reboot (or save settings) of the node restart the sensor (not power down) ?

Will try that next time, just powercycled it after checking the counters.

Esp08 frozen again, counters Checksum (pass/fail): | 2660/55

save of the co2-device parameters did resolve the freeze !

Esp08 18:18 frozen again, counters Checksum (pass/fail): | 2660/55

save of the co2-device parameters did resolve the freeze !

OK, so it is possible to perform a reset.
I will add a check for N unknown responses and then perform an init again.

That might solve this problem completely.

For now the whole serial issue we had occurring on all of them seems gone now on the modelA and with two of the three Mhz19B model sensors.
Esp08, which is a model B, is the only one i've seen with a variable "unknown response (every time a changing) Hex value " still in the logfiles, if this sensor could be reset out of the plugin when behaving bad, it might be the solution.

Upgrading all to Mega 201902026 4Mb now.

First thing i noticed, Co2 sensor type mhz19B is giving correct values almost instantly after flash new image, much much faster then before too .

This sounds really promising! I've been watching this thread, waiting for a moment I could finally upgrage. :grin: I have a node which has both a MH-Z19 and PMS7003 attached. MH-Z19 has been working >90% of the time but occasionally I've had to reset the ESP for that.

The PMS7003 seems to be failing a lot more though. Most of the times even reset does not help but disconnecting power for a few seconds might fix it. I've been suspecting its connector might be the culprit but haven't had gotten into debugging it. This thread got me curious if it could still be firmware related... I'm going to give it a shot when I can be sure enough it won't cause issues with the MH-Z19 as it's data is more important.

And yes, I noticed #2349 only touched MH-Z19 code but the build I'm running is "20100 - Mega (core 2_4_0)" which I assume is quite old.

I want to say it's rare to see such persistence from both both sides of an issue. I reckon many would have given up after a few days. Hats off to you from this bystander @TD-er and @pwassink!

You may want to wait 1 more day before upgrading.
I am now working on some patches for network connectivity.

Thanks for the info! I was planning to wait @pwassink reports for a moment anyway though (lazy me).

Just know that a lot has changed since your current build, and sadly not all positive.
One of the issues we're still trying to tackle is the hardware watchdog reboots. So you may want to keep a backup of the current settings you have and write down the current version you're using. Just to be sure.
I hope to improve a bit on these reboots by the fixes of today, but since these reboots have several different causes, I don't think today's fixes will handle them all.

Note taken. I can only imagine the difficulty to avoid regression in a system like ESPEasy. I'll be reporting any regressions after I'll do the upgrade (as separate issues of course).

I'm planning to upgrade two ESP's I have here. Based on those only I can observe if there's regression on MH-Z19, PMSx003, BMx280, TSL2561, DHT22 sensor or OLED SSD1306 display handling. TSL2561 on the other ESP tends to stop returning data randomly also (quite rare though). It is running build "20102 - Mega".

That's not the build, but the internal file format (confusing I know) You may find the build name/date in the sysinfo page.

It's on the "build" field at least. Binary filename is "ThisIsTheDummyPlaceHolderForTheBinaryFilename64ByteLongFilenames". I probably flashed it straight from PlatformIO. I might have some difficulty flashing the same version then as it was almost a year ago. I didn't really make any notes not to mention a tag. :joy: Well I guess I can just do a backup of the firmware if I don't feel adventurous enough.

No build timestamp in the sysinfo page?

There's a timestamp but it won't help much as I don't remember if I had pulled in the latest code before doing that. But of course it gives some ballpark.

This is not the ESP that hosts the MH-Z19 and PMS7003 though.

But I guess this is going way off topic. Sorry for temporarily hijacking the thread and thanks for replying to my comments anyhow!

what version was this fixed in?

after a few hours i get MHZ19: Unknown response: 0 0 0 0 0 0 0 0 0
reboot won't fix it have to unplug it and plug it back in

i am using a wemos 1d mini pro, does this version have the fix in it?

Build:⋄ | 20104 - Mega
-- | --
System Libraries:⋄ | ESP82xx Core 2_5_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.1.2 PUYA support
Git Build:⋄ | mega-20191003
Plugins:⋄ | 46 [Normal]
Build Md5: | 3180a4d3e118166b3414444513a6169
Md5 check: | passed.
Build Time:⋄ | Oct 3 2019 02:15:29
Binary Filename:⋄ | ESP_Easy_mega-20191003_normal_ESP8266_4M1M.bin

thanks

Yep and previous versions also.
I would suggest trying with the 20190928 build, since the October one had some other issues (which I'm fixing for the last week or so)

You may also want to have a look at the number of read errors shown on the plugin page, after it has been running for a few hours.

For example one of my own units (3 days uptime)

N.B. the filter (set to "Use Unstable" in the screenshot) does not have a meaning on the MH-Z19B sensor, it is only applicable for the -A version.

And another one:

As you can see, the number of failed reads is minimal.
If you have some errors there, you may have another problem at hand.

those 11 resets where me trying to get it to boot up again without plugin it back in and out, i don't remeber seeing any errors though but i can give it another shot, should i be using Software Serial?

Hardware Serial is the better one, but then you must also disable the serial port in the Tools->Advanced->Serial Port. (as is stated in your screenshot :) )

I'm not sure if any present USB to serial adapter on the board may have an effect on the communication.
When in doubt you could change to software serial.

Build: ESP_Easy_mega_20201130_normal_ESP8266_4M1M
reporting to FHEM.
I had a similar problem: The MH-Z190B sensor freezes every few hours and keeps dropping to 400 when I use hardware serial.
After switching to software serial it seems to work normally and doesn't freeze anymore.
2 screenshots attached.

The BME280 attached with I2C works fine and keeps reporting all the time

Hmm that's strange.
To what HW serial port was it connected?
What else is connected to the board? (e.g. USB to serial chip)
Is "Use Serial" unchecked on the Tools->Advanced page?

It's connected to GPIO-13 (D7) <- TX and GPIO-15 (D8) -> RX (first in HW now in SW) as I wanted to use the TXD0 and RXD0 to read the messages via the USB-port (CH340) of the Wemos D1 mini.
Does "Use Serial" mean "Serial Settings - Enable Serial port:" checked? I left this checked to be able to read the messages by USB.

HW serial on an ESP8266 uses Serial0.
If you send also logs to the same serial port, the sensor may crash as it doesn't understand the "commands" it receives when the logs are sent via that port.

If you connect something to the HW Serial port, you should no longer send other data. Thus you should disable "Use Serial" on the tools->Advanced page.

Yesterday, I got a second Sensor MH-Z19C. This one seems to work fine with HW-Serial on Serial2. As the sensors all were connected to Pins D7 (GPIO 13) and D8 (GPIO 13) (RXD2 and TXD2) there should not be any conflict with Serial0 (Pins RXD0 (GPIO3) and TXD0 (GPIO1)) as far as I'm understanding the Pinout. I think the first sensor (MH-Z19B from another supplier) was just a fake not working properly at all, ...
So be careful when buying those sensors. The second one, I got yesterday was in a much better packaging with the Winsen Logo and a test certificate joined. The supplier seems to be more serious than the one that sold me the first one.