Modul für CO2 Sensor MH-Z19

Begonnen von Adimarantis, 07 April 2022, 21:37:53

Vorheriges Thema - Nächstes Thema

Adimarantis

Hallo,

Nachdem ich schon ein wenig mit CO2 Sensoren rumprobiert habe, wollte ich den MH-Z19 möglichst einfach direkt an FHEM betreiben.
Meistens wird dieser ja über einen Arduino oder ESP32/ESP8266 (ESPEasy unterstützt ihn auch) angebunden, aber das ist nicht jedermanns Sache.
Man kann den Sensor auch direkt an die serielle Schnittstelle eines Raspberry anschliessen (GND,3.3V,Tx,Rx) bzw. mit einem UART Adapter auch via USB an beliebige andere Systeme.
Dazu braucht man erstmal den eigentlichen Sensor. Ich habe hier den MH-Z19D verwendet (vermutlich ein China Nachbau des Originals, etwas billiger, scheint aber ganz gut zu funktionieren)
https://www.aliexpress.com/item/1005003484848335.html
und diesen dann über einen USB to UART Controller, der praktischerweise gleich entsprechende Stecker hat und im USB Stecker eingegossen ist
https://www.aliexpress.com/item/32735988635.html
direkt angeschlossen.

Somit fehlte nur noch das FHEM Modul, welches diesen über die serielle Schnittstelle ansteuert. Mein erster Wurf dazu im Anhang.
Sollte eigenlich bereits alles wichtige können:
- Periodisch CO2 und Temperaturwerte abfragen
- Generelle Sensorinfos (Firmware, Range, Selbstkalbirierung) abfragen
- Selbstkalibrierung ein- und ausschalten
- Kalibrierungsmodus starten (mit Absicherung gegen versehentlichen Start, da der Sensor dazu für 20 min "an der frischen Luft" sein sollte)

Mehr Infos zum Sensor gibt es zuhauf, z.B. hier:
https://wolles-elektronikkiste.de/mh-z14-und-mh-z19-co2-sensoren

Das Modul braucht sicherlich noch etwas Feinschliff und vorallem Doku  :)

Würde mich freuen zu hören, ob jemand Interesse hat (mir ist klar das nicht jeder die Teile rumliegen hat und es insbesondere bei Bestellung aus China etwas dauern kann, bis jemand es ausprobiert).

Update 8.4.22: Code etwas aufgeräumt. Verzögertes Lesen via Timer um FHEM nicht zu blockieren. Etwas Dokumentation hinzugefügt
Update 21.4.22: Besseres Fehlerhandling, insbesondere reconnect wenn serielle Verbindung blockiert
Update 27.4.22: n/a statt Fehler wenn deviceInfo vom Sensor nicht unterstützt wird

Gruß
Jörg


Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Prof. Dr. Peter Henning

Ich habe Interesse, weil ich den Sensor in verschiedenen Sensorboxen verwende. Werde das auch gerne mit einem MH-Z14 testen, den habe ich noch herumliegen.

LG

pah

Adimarantis

Freut mich. Bin gespannt auf Feedback.

Ich habe gleich noch ein Update im ersten Post eingespielt, welches jetzt etwas Inline Dokumentation auf Englisch enthält.
Außerdem ist mir aufgefallen, dass der Sensor gut 1 Sekunde braucht um zu antworten und FHEM solange blockiert. Daher habe ich das Auslesen jetzt verzögert per Timer abgetrennt.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Prof. Dr. Peter Henning

Dauert aber, habe derzeit viel um die Ohren.

LG

pah

Adimarantis

Ich hatte jetzt schon Fälle, dass sich der USB/UART irgendwie aufgehängt hat, daher habe ich jetzt einmalig ein reconnect/retry für solche Fälle eingebaut.

Um zu zeigen wie einfach es ist den Sensor anzuschliessen anbei auch ein paar Bilder.
1. Der eigentliche Co2 Sensor und wo die Kabel vom USB Adapter (die im Stecker eingeschweisste Version) eingesteckt werden
2. Die USB Port Seite - dort habe ich aktuell noch einen zweiten USB Adapter erfolgreich parallel im Betrieb um die Sensoren zu vergleichen (Hab ich hier: https://www.aliexpress.com/item/32529737466.html gekauft)

Zwischen zwei dieser MH-Z19D Sensoren habe ich aktuell etwa 50ppm Abweichung. Mir reicht das für eine einfache CO2 Ampel - wer es genauer braucht, sollte evtl. auf die Original Sensoren (z.B. MH-Z19B) zurückgreifen.

Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Nighthawk

Hallo Jörg,

ich habe ebenfalls den einen oder anderen MHZ bei mir im Einsatz, werde das Modul bei Gelgenheit mal antesten.

Beim durchstöbern des Moduls ist mir in Zeile 110 ein möglicher copy/paste Fehler aufgefallen
return "Signalbot_Get: Unknown argument $cmd, choose one of " . join(" ", @cList);

sollte sicher CO2_MH_Z19_Get heissen, oder?

Gruß
Alex

Adimarantis

Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Nighthawk

Hallo Jörg,

habe heute mal einen MHZ19B an mein System angeschlossen und das Device in FHEM angelegt, leider schmiert mein FHEM dadurch dauernd ab und ich bekomme keine Wertw.

Hier ein Logauszug:

2022.04.23 21:29:12 3: CO2 Error reading from device
Undefined subroutine &main::CO2_MHT_Z19_Reopen called at ./FHEM/41_CO2_MH_Z19.pm line 223.
2022.04.23 21:30:43 1: PERL WARNING: Prototype mismatch: sub main::round ($$) vs none at /usr/lib/x86_64-linux-gnu/perl-base/Exporter.pm line 66.
2022.04.23 21:30:43 1: Including fhem.cfg

Adimarantis

Da hat sich wohl ein Tippfehler eingeschlichen. Ist korrigiert.
Mich wundert allerdings warum du überhaupt in diesen Teil des Codes "landest", da dies eine Fehlerbehandlung ist.
Wahrscheinlich stimmt was mit der serial device oder wie du den Sensor angeschlossen hast nicht.
Jetzt sollte es aber wenigstens keinen FHEM restart mehr dabei geben.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Nighthawk

Die neustarts sind nun weg, aber ich lande immer im "error" wenn das Modul die Daten lesen will.
Die Sensoren (ja, ich habe mehrere getestet) sind definitiv ok, habe ich mit Tasmota auf einem Wemos D1 und der Leitung geprüft.
Ich habe diverse USB zu Serial  getestet, FTDI, CP2104, CH341, mit keinem bekomme ich die Kommunikation hin.

Gruß
Alex

Prof. Dr. Peter Henning

Bin noch nicht zum Testen gekommen, kann also nichts dazu sagen.

LG

pah

Adimarantis

Zitat von: Nighthawk am 24 April 2022, 17:29:50
Die neustarts sind nun weg, aber ich lande immer im "error" wenn das Modul die Daten lesen will.
Hat dein FHEM user Zugriff auf den serial port (group dialout)? Vielleicht erstmal von der Kommandozeile prüfen.
Ich habe das mit CH340 und pl2303 getestet, das klappt beides.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Nighthawk

Der User hat Zugriff da ich auch einen Signalduino und ein Arduino Nano mit der Firmata Firmware mit dran habe, die ohne Probleme funktionieren.
Kann das evtl mit dem OS zusammenhängen?
Ich nutze Ubuntu x64.

Gruß
Alex

Adimarantis

Habs nur unter Raspberry 32bit probiert.
Glaube nicht, dass es am Ubuntu liegt, aber eventuell am 64bit, da ich ja letztendlich  Binärdaten schreibe/lese.
Muss ich mal mit meinem NUC probieren.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Adimarantis

#14
Auf meinem Intel NUC, arch=x86_64 mit "Ubuntu 20.04.4 LTS" funktioniert es ebenfalls auf Anhieb.
Habe leider keine Idee mehr, warum es bei dir nicht geht.

Jörg

Internals:
   CFGFN     
   DEF        /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0
   DeviceName /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0@9600
   FD         11
   FUUID      6266ea70-f33f-157a-55bb-100cf23dfbe904e2
   NAME       co2
   NR         54
   PARTIAL   
   STATE      409
   TYPE       CO2_MH_Z19
   READINGS:
     2022-04-25 20:37:43   Firmware        0520
     2022-04-25 20:37:43   Range           5000
     2022-04-25 20:37:43   SelfCalibration off
     2022-04-25 20:37:49   co2             409
     2022-04-25 20:37:49   state           409
     2022-04-25 20:37:49   temperature     18
   helper:
     retry      5
Attributes:
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Nighthawk

hmm, Geduld scheint die Mutter der Prozellankiste zu sein :-)

Ich habe bisher immer nur die 5 min abgewartet und am Anfang wirft das Modul hier einen Error, damit war für mich der Test gelaufen.
Jetzt habe ich den MHZ mal einfach drangelassen und siehe da, es kommen Daten :-)

Allerdings sehe ich bei mir nur den CO2 Wert und die Temperatur, alle anderen Readings fehlen bei mir.
Auch liefert das Modul die Medlung "Error reading from device" wenn ich get CO2 deviceinfo ausführe.

Internals:
   DEF        /dev/serial/by-id/usb-Silicon_Labs_My_CO2_USB_0001-if00-port0
   DeviceName /dev/serial/by-id/usb-Silicon_Labs_My_CO2_USB_0001-if00-port0@9600
   FD         32
   FUUID      626789aa-f33f-357a-d9e7-4c11f6883ba32319
   FVERSION   41_CO2_MH_Z19.pm:?/2022-04-24
   NAME       CO2
   NR         624
   PARTIAL   
   STATE      471 ppm
   TYPE       CO2_MH_Z19
   Helper:
     DBLOG:
       co2:
         logdb:
           TIME       1650984598.23501
           VALUE      471
       state:
         logdb:
           TIME       1650984823.06507
           VALUE      selfCalibration on
       temperature:
         logdb:
           TIME       1650971719.55265
           VALUE      21
   READINGS:
     2022-04-26 16:49:58   co2             471
     2022-04-26 16:54:59   state           Error
     2022-04-26 16:49:58   temperature     21
   helper:
     retry      4
   hmccu:
Attributes:
   event-on-change-reading co2
   stateFormat co2 ppm


Gruß
Alex

Adimarantis

Welche Sensortypen hast du? Vielleicht unterstützen die die Abfrage von DeviceInfo Daten nicht.
Ich meine irgendwo sowas gelesen zu haben.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Nighthawk

Es ist ein MHZ-19B den ich in China gekauft habe, wahrscheinlich ein Fake-Sensor.

Adimarantis

Hi Alex,

probier mal das Update im ersten Post.
Ich schreibe jetzt n/a in die readings der DeviceInfo wenn keine brauchbare Antwort vom Sensor kommt anstatt einen Fehler zu melden.
Wenn nur die Firmware Version nicht unterstützt wird, dann bekommst du trotzdem noch self calibration und range.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Nighthawk

Hallo Jörg,

es kommen jetzt alle Readings bis auf co2 und Temp, mit einem n/a

Internals:
   DEF        /dev/serial/by-id/usb-Silicon_Labs_My_CO2_USB_0001-if00-port0
   DeviceName /dev/serial/by-id/usb-Silicon_Labs_My_CO2_USB_0001-if00-port0@9600
   FD         28
   FUUID      626789aa-f33f-357a-d9e7-4c11f6883ba32319
   FVERSION   41_CO2_MH_Z19.pm:?/2022-04-24
   NAME       CO2
   NR         624
   PARTIAL   
   STATE      714 ppm
   TYPE       CO2_MH_Z19
   Helper:
     DBLOG:
       co2:
         logdb:
           TIME       1651148357.79799
           VALUE      714
       state:
         logdb:
           TIME       1651066780.01643
           VALUE      CONNECTED
       temperature:
         logdb:
           TIME       1650971719.55265
           VALUE      21
   READINGS:
     2022-04-28 14:23:06   Firmware        n/a
     2022-04-28 14:23:06   Range           n/a
     2022-04-28 14:23:06   SelfCalibration n/a
     2022-04-28 14:19:17   co2             714
     2022-04-28 14:24:18   state           Error
     2022-04-28 14:19:17   temperature     21
   helper:
     retry      4
   hmccu:
Attributes:
   event-on-change-reading co2
   stateFormat co2 ppm

Adimarantis

Hi Alex,

Kann es sein das die Kommunikation mit deinem Sensor auch ein wenig unzuverlässig ist? Ich sehe einen "Error" und den Retry counter auf 4 (statt 5).
Laut Datasheet vom Winsen Original Sensor, wird die Abfrage der "deviceinfo" Parameter nicht aufgeführt (also wohl gar nicht unterstützt). Ist also nicht zwangsläufig ein Hinweis auf ein Fake.
Somit auch gut, dass es jetzt optional ist. Danke fürs Testen.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)