Voltcraft CO-20 USB-Luftqualitätssensor

[immi]

I find it strange, CO20 is cheap, easy to use  (thanks to justme1968)
and still I see only 30 installations.

I can only recomand it, if you desire to get a feeling on your air quality, without spending real money.
I went a little further and correlated it to my ventilation system activity.

immi

[Spiff]

Hi immi,

a bit off-topic - but how can you see 30 users using the module?
Is fhem sending some statistics to the developers?!

Regards,
Spiff

[frank]

here you can see http://forum.fhem.de/index.php/board,11.0.html.

gruss frank

[scholty]

Hi,

[...]- und natürlich auch die Auto-Rekalibrierung ausgeschaltet.  [...]

Wie kann man die denn ausschalten? Ich beobachte nämlich auch, dass die Luft schlechter angezeigt wird, als es eigentlich sein dürfte.

Grüße scholty

[peterk_de]

scholty, über das WindowsTool von AppliedSensors und da über ein verstecktes Menü:

http://blog.moneybag.de/luftqualitaets-sensor-voltcraft-co-20-ein-erfahrungsbericht/#more-9919

[scholty]

Wow, danke.
Und ich hatte gedacht, ich hätte alles gelesen.

Grüße

scholty

[KölnSolar]

Nun muss ich dann auch mal ran. Erst mal vielen Dank an die guten Forumsbeiträge, die es mir ermöglicht haben eine Haussteuerung für diverse Aktoren(Intertechno,FS20), Sensoren(1-Wire,Oregon Scientific)  und sonstigen Geräten(FB, SamsungTV, Fronius, Hager eHz) aufzubauen.

An dem Luftgütesensor scheitere ich aber.

Ich habe das Ding an einem Windows-Rechner "einbrennen" lassen, bei guter Luft  kalibriert und das KNOB_ui16StartupBits = 1 gesetzt. Dann habe ich den Sensor an einen RPi mit passivem USB-Hub und dem Modul 38_CO2.pm in FHEM betrieben. Leider bekam auch ich die hier schon beschriebenen dauerhaften Abbrüche("disconnect").Dauerhaft immer dann, wenn im Log ein "failed to open CO20 device" erscheint. Dadurch konnte ich auch keine konkreten Erkenntnisse über das Verhalten des Sensors gewinnen. Dazu muss ich erwähnen, dass ich Raucher bin und einen Heizkamin betreibe. Ich hatte aber den Eindruck, dass sich während des Betriebs "irgendwie" die Kalibrierung selbständig ändert. Ich loggte daher zusätzlich r_s, welcher der veränderliche Widerstand des Sensors ist und sich scheinbar ungefähr umgekehrt proportional zu der Ausgabe voc verhält. Durch ein get "air_data" hatte ich gelernt den Sensor manuell wieder zurück ins Leben zu rufen.

Ich legte mir einen aktiven USB-Hub von Belkin zu, mit dem ich erhoffte die Abbrüche zu unterbinden. Leider Fehlanzeige. Damit ich nun endlich mal halbwegs permanente Daten bekomme, habe ich mir einen watchdog angelegt, der nun bei einem dauerhaften Abbruch ein get "air_data" macht. Endlich, ich habe permanente Daten . So lässt sich der Sensor prinzipiell sinnvoll betreiben.

Aber jetzt konnte ich auch das Fehlverhalten feststellen. Der beigefügten Grafik könnt Ihr entnehmen, dass beim Lüften(rote Kringel) der Sensor eine Art Neukalibrierung durchführt. Sprich bei steigendem r_s(pink) sinkt der voc ab ca. 500 nicht weiter ab. Ist der Peak von r_s erreicht und fällt dann wieder ab, steigt sofort der voc an, was zu dem Ergebnis "schlechte Luft" nach dem Lüften führt. Steckt man den Sensor ab und wieder neu an(blauer Kringel), hat man "plötzlich" wieder gute Luft. Irgendetwas stimmt mit dem Teil also nicht.

Kennt jemand ein ähnliches Verhalten ?

Was man sicherlich noch testen könnte: reset/recalibrate. Nur leider sind die Informationen dazu arg dürftig, teilweise sogar widersprüchlich. Hat jemand evtl. weitere Infos zu den Flags, Knobs etc. ? Tante Gockel hab ich auch schon endlos gequält, mit wenig befriedigendem Ergebnis.

Grüße
Markus

[det.]

Hallo andre,
hab da nach FHEM restart immer einmal folgende Kleinigkeit im LOG:

Code Auswählen Erweitern

PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/38_CO20.pm line 84.

[justme1968]

die warnung sollte ab morgen weg sien.

gruss
  andre

[det.]

Perfekt, danke!

[volschin]

An einem von meinen 4 CO20-Sensoren habe ich leider in unregelmäßigen Abständen (zwischen 1 und 3 Wochen) Aussetzer. Der Stick liefert dann keine Daten mehr und ich muss ihn abstecken und wieder anstecken und danach ein update manuell anstoßen.

Ich habe mir dafür mal einen Watchdog geschrieben.

Code Auswählen Erweitern

define w_CO20.Wohnen watchdog CO20.Wohnen 00:10:00 SAME {myProwl("CO2-Sensor ausgefallen","CO20.Wohnen manuell überprüfen!",1)};; trigger w_CO20.Wohnen .


Nach meinem Kernel-Update auf 3.12.35 ist das Problem noch nicht wieder aufgetreten. Alternative zum manuellen Abstecken wäre vermutlich auch ein Reboot des RasPi. Ein Restart von FHEM hatte das letzte Mal keinen Erfolg.

[justme1968]

steckt der stick direkt am rasberry oder an einem aktiven hub?

ich meine es gab schon ähnliche fälle bei denen ein aktiver hub geholfen hat. 

gruß
  andre

[volschin]

Direkt im RPi. Beim B+ gibt es das USB Stromversorgungsproblem so nicht mehr und das Netzteil ist mit 2,5 A absolut OK.
Ich werde es mal weiter beobachten.

[Markus M.]

Klappt das mit dem RasPi mittlerweile ohne Aussetzer?

Andre, spricht eigentlich irgendwas dagegen mal meine Änderungen ins SVN aufzunehmen, die die kompletten Daten des Sticks ausgeben und auch das Setzen der Einstellungen ermöglichen?!

Gruss, Markus

[volschin]

Also bei mir sind es jetzt 2 von 4, die hin und wieder hängen. Abstecken und wieder anstecken hilft.
Hatte noch nicht die Zeit es näher zu untersuchen, aber auch ein restart von FHEM hilft nicht.