opendata-stuttgart
Support for CO2 sensor MH-Z19
How hard would it be to add support for MH-Z19 (CO2 sensor)? I've found a few seemingly related resources:
- https://github.com/popstas/nodemcu-co2-temp-hum-grafana
- https://diyprojects.io/publish-co2-concentration-mh-z19-sensor-domoticz-arduino-code-compatible-esp32-esp8266/
Unfortunately I have no experience with arduino / embedded at all, no idea where to start in order to extend the firmware in this repository.
According to the datasheet this is internal sensor. Its working temperature is 0 ~ 50 °C What will it show in a negative temperatures? Also there is a note "8.1 Do not use the sensor in the high dusty environment for long time."
Though the lifespan is quite long - over 5 years!
As to my mind some other sensor must be taken into consideration. https://www.winsen-sensor.com/sensor/carbon-dioxide-sensor.html
Hi @misev I'm also very interested in attatching gas sensors to the units! I was thinking more along the lines of something like this though as it only requires reading voltages. link
How hard would it be to add support for MH-Z19 (CO2 sensor)?
I already used this sensor in another project for indoor measurements.
Also there is a note "8.1 Do not use the sensor in the high dusty environment for long time."
The sensor is closed and uses optical measurement, so I would interpret that note as "the optical windows should be free of dirt". I don't think that this is a problem.
This is not my top priority issue, but I might start working on it.
I have added support for the MH-Z19 sensor in my mhz19sensor branch (based on the beta branch). The MH-Z19 is using the same serial port as the GPS sensor, so you can either use the GPS sensor or the MH-Z19 sensor, but not both at the same time. In the webserver UI the GPS has priority, that means if you enable both sensors, the MH-Z19 will be disabled when saving the configuration.
Unfortunately my soldering iron gave up yesterday, so I can't test it myself at the moment. Any volunteers for testing?
In the meanwhile I tested with an ESP32 and it works. You need only the following two commits of my branch, the other commits are to make the ESP32 work:
commit aa632149c673a9d257f7993e9fd3a1df5fa8c057 Author: Michael Dreher [email protected] Date: Sun Sep 8 11:54:05 2019 +0200
fixed serial port initialization of MHZ19
commit 9b2e3dbeadeed45efa0e5987b8418130ff11fbc9 Author: Michael Dreher [email protected] Date: Sat Sep 7 17:01:38 2019 +0200
added support for MHZ19 CO2 sensor
commit d95753083302bb044eb82f7fbf65517c6b722b09 Author: Michael Dreher [email protected] Date: Tue Sep 10 10:06:06 2019 +0200
using "conc_co2_ppm" for MHZ19 as key for APIs
commit 73158e9189ced54daa317fbfc9b67d2a369467ac Author: Michael Dreher [email protected] Date: Wed Sep 11 08:24:12 2019 +0200
added translation for MHZ19 sensor
for all languages
The servers api-rrd.madavi.de and api.sensor.community both give the following error messages when sending CO2 data:
{"software_version": "NRZ-2019-124-B6", "sensordatavalues":[{"value_type":"CO2","value":"3159"}]}
HTTP/1.1 400 Bad Request
Date: Mon, 09 Sep 2019 13:42:43 GMT
Server: Apache/2
Allow: POST, OPTIONS
Connection: close
Transfer-Encoding: chunked
Content-Type: application/json
48
{"sensordatavalues":[{"value_type":["\"CO2\" is not a valid choice."]}]}
Who needs to adapt the server code to accept also CO2 measurements?
Who needs to adapt the server code to accept also CO2 measurements?
Maybe this is one of the places: https://github.com/opendata-stuttgart/feinstaub-api/blob/master/feinstaub/sensors/models.py
Sorry that I was on a short tour the last days and couldn't answer the question within minutes ;-) Even if some people think we are a company, this project is organized unsalaried. We all spend much of our leisure time to keep this running.
The value_type should be changed to something like conc_co2_ppm or conc_co2_mikrogram. Some sensors can give both and we won't be able to tell apart this.
Sorry that I was on a short tour the last days and couldn't answer the question within minutes
Oops, did I sound that demanding? That wasn't my intention. The nice thing in open source is that everybody can find the answer and he also can fix a problem himself.
We all spend much of our leisure time to keep this running
That's what I do, but my holidays are almost over.
There should have been a smiley behind my answer ... I will add CO2 and do the other changes needed if you can change the value_type.
see my new commit:
commit d95753083302bb044eb82f7fbf65517c6b722b09 Author: Michael Dreher [email protected] Date: Tue Sep 10 10:06:06 2019 +0200
using "conc_co2_ppm" for MHZ19 as key for APIs
So actually there are 3 commits, I edited the list in my comment above
The calibration of the sensor for outdoor usage is a problem. Normally It does auto calibration once every 24 hours (or 48 hours?) when opening the window and the value is falling and staying at a lower value for a while. This value is used as calibration value of ~400 ppm.
There is a command to turn off auto calibration, but this seems not really to work reliably. Detailed information (a long horror story in German) can be found here: https://www.mikrocontroller.net/topic/470382
A real outdoor sensor, e.g. from Senseair could be an option, but most sensors are in a much higher price range.
It is not much sense to use this sensor outdoor. But for indoor environments it might be usefull.
Yes, an adequate use case is to know when you should open the window. That works fine with auto-calibration.
This project was started to measure outdoor air quality. And there are many other things we would like to measure for this. So we would like to have some space left for these extensions ;-)
Curently, there are plenty of space. So not a big problem to include this sensor for indoor use. Later a separate build can be made to support this sensor...
It was a hard piece of work to get this available space. And now we should use this for a feature that we need to test at every update and that may be removed in future releases? Sorry, who is crying if we need too long to release new versions with other really needed features? And we won't maintain more than the actual version. Additional builds are too time consuming.
Just wondering about the status of this. Will support for this sensor make it into the stable firmware build? I don't mind either way but if not then it may be a good idea to close this issue/PR to provide some clarity. Then people can just use other firmwares that do support it instead.
Doubt that this sensor will ever be included to stable build. The sensor itself is not the right one. Needs calibration which differs in different environments.
But there is a demand from home users who want to measure PM a CO2 values inside the building. For these users MH-Z19 is quite suitable. It would be nice to make an alternative build for these users but the question is - who will maintain it?!