search

opendata-stuttgart / sensors-software

sourcecode for reading sensor data
576 stars 313 forks source link

Support for CO2 sensor MH-Z19 #375

Open misev opened 5 years ago

misev commented 5 years ago

How hard would it be to add support for MH-Z19 (CO2 sensor)? I've found a few seemingly related resources:

Unfortunately I have no experience with arduino / embedded at all, no idea where to start in order to extend the firmware in this repository.

DeeKey commented 5 years ago

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

jordanc365 commented 5 years ago

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

nospam2000 commented 5 years ago

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.

nospam2000 commented 5 years ago

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 Michael.Dreher42@gmail.com Date: Sun Sep 8 11:54:05 2019 +0200

fixed serial port initialization of MHZ19

commit 9b2e3dbeadeed45efa0e5987b8418130ff11fbc9 Author: Michael Dreher Michael.Dreher42@gmail.com Date: Sat Sep 7 17:01:38 2019 +0200

added support for MHZ19 CO2 sensor

commit d95753083302bb044eb82f7fbf65517c6b722b09 Author: Michael Dreher Michael.Dreher42@gmail.com Date: Tue Sep 10 10:06:06 2019 +0200

 using "conc_co2_ppm" for MHZ19 as key for APIs

commit 73158e9189ced54daa317fbfc9b67d2a369467ac Author: Michael Dreher Michael.Dreher42@gmail.com Date: Wed Sep 11 08:24:12 2019 +0200

added translation for MHZ19 sensor
for all languages
nospam2000 commented 5 years ago

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?

nospam2000 commented 5 years ago

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

ricki-z commented 5 years ago

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.

ricki-z commented 5 years ago

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.

nospam2000 commented 5 years ago

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.

ricki-z commented 5 years ago

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.

nospam2000 commented 5 years ago

see my new commit:

commit d95753083302bb044eb82f7fbf65517c6b722b09 Author: Michael Dreher Michael.Dreher42@gmail.com 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

DeeKey commented 4 years ago

Why is this still open? Something is not solved yet?

nospam2000 commented 4 years ago

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.

DeeKey commented 4 years ago

It is not much sense to use this sensor outdoor. But for indoor environments it might be usefull.

nospam2000 commented 4 years ago

Yes, an adequate use case is to know when you should open the window. That works fine with auto-calibration.

ricki-z commented 4 years ago

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 ;-)

DeeKey commented 4 years ago

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...

ricki-z commented 4 years ago

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.

jpsingleton commented 4 years ago

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.

DeeKey commented 4 years ago

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?!