Voltcraft CO-20 USB-Luftqualitätssensor

Begonnen von C64Emulator, 04 Juni 2013, 10:50:06

Vorheriges Thema - Nächstes Thema

vbs

Ok, danke, nützliche Infos! Werde damit mal etwas rumspielen.

Ich hab mittlerweile 4 von diesen Sticks hier liegen und das Register Reg_Set unterscheidet sich bei allen, die anderen Register sind gleich. Ich gehe davon aus, dass Reg_Set vom Werk aus kalibriert wird und gerätespezifisch ist um Fertigungstoleranzen auszugleichen. Eine Änderung daran ändert auf jeden Fall auch deutlich den Messwert.
Die Sensoren sollen ja aber einige Stunden/Tage "einbrennen", um ihre optimalen Werte zu liefern. Ich könnte mir vorstellen, dass die daher ab Werk nur grob "vorkalibriert" sind (ohne Einbrennen) und dass man daher als Benutzer noch etwas optimieren kann, wenn man dann nochmal händisch etwas anpasst. Leider hab ich kein Referenzgerät, so dass ich die Sticks nur zueinander kalibrieren kann.

Ich verstehe an diesem PID-Reglern nicht, wie das zu dem Sensor passt, da es doch Begriffe aus der Regeltechnik sind. Ich bin da totaler Laie, aber da geht es doch immer um Soll- und Ist-Werte, oder? Wie trifft das auf einen einfach Sensor zu, der ja nix regelt, sondern einfach immer nur stupide einen Wert liefert?

Markus M.

Ich habe absolut Null Ahnung von Regelungstechnik, bin mir nur ziemlich sicher dass die Register sowas bedeuten  :)

Schritt 1: nimm deine 4 Sensoren, schreib dir alle Werte auf, leg sie nebeneinander und mach nen kompletten Reset samt den paar Stunden Burn-In in einem leeren Raum mit geschlossenen Fenstern.
Dann vergleich nochmal Werte und Kurven.

Welches Kommando das ist steht im Readme, meine Modulversion kann es setzen.
Aktuell weder Smarthome noch FHEM vorhanden

vbs

Hat eigentlich jemand eine Ahnung, was "Recalibrate Heater" macht bzw. unter welchen Bedingungen man das ausführen sollte/dürfte? Ich hab mich noch nicht getraut, das zu drücken :/

Markus M.

Das sollte das komplette "Einbrennen" über mehrere Stunden am Anfang durchführen, d.h. erst nachdem der Stick eine längere Zeit in Betrieb war, werden die Referenzwerte gesetzt und Daten gewonnen.
Macht wahrscheinlich nur dann einen Unterschied, wenn der Stick tatsächlich längere Zeit nicht in Betrieb war.
Ist aber gefahrlos.
Aktuell weder Smarthome noch FHEM vorhanden

vbs

Ok danke, gut zu wissen.

Aber ich habe gerade ein anderes seltsames Verhalten festgestellt:
Ich hab hier 3 Sticks laufen und bei allen die Bits gesetzt, so dass sie sich nicht beim Starten neu auf einen Basiswert "kalibrieren". Ich habe sie an der frischen Luft kalibriert und sie liefen jetzt auch ca. 4 Wochen hier mit gewünschten Werten zwischen 450 und 2000.
Nun habe ich alle Sticks einmal abgezogen und USB-Verlängerungen angebracht, um sie besser positionieren zu können. Seitdem diesem Neustart liefern alle drei auf einmal Werte größer 2000, auch in gut belüfteter Umgebung. :(

Ich kann mir das Verhalten nicht erklären, da sich die Sticks ja wegen den gesetzten Bits nicht neu kalibrieren sollten beim Booten. Und selbst wenn sie es tun würden, dann müsste ich ja bei allen drei Sticks nach dem Neustart Werte um 450 sehen (und nicht 2000).

Ich wollte eigentlich meine einmal gemachte Kalibration beibehalten. Kann sich jemand erklären, wieso die Sticks nach dem Booten jetzt auf einmal so hohe Werte zeigen?

volschin

Also ich bin mir nicht sicher, ob durch dein Recalibrate Heater nicht etwas schief gelaufen ist. Die normale Funktion ist ui16StartupBits=0. Vom Einbrennen sollte man meines Wissens besser die Finger lassen.
Intel NUC+Ubuntu 24.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7690, Echo Dots+Show8, HomeBridge

Markus M.

Sollte eigentlich nur dann notwendig sein und einen Unterschied machen, wenn der Sensor längere Zeit nicht in Betrieb war.
Ich hatte das vorgestern mal gemacht da ich nach dem Wechsel auf einen anderen Rechner das Gefühl hatte, dass der Sensor etwas zu enthusiastisch reagiert und auch zu hohe Werte anzeigt. Das hat sich aber leider dadurch nicht gebessert.
Ich muss bei Gelegenheit mal nachsehen ob andere Einstellungen weiterhelfen.
Aktuell weder Smarthome noch FHEM vorhanden

PEPITO82

Hat den Raumluftfühler schon jemand in die Abluft eines Paul Novus 300 Lüftungsgerätes gehängt?
Das Gerät wirkt sehr dicht - komplett aus Styropor.
Daher würde mich der einfachste Weg ins Gerät interessieren.

FunkOdyssey

Vielleicht habt ihr eine Idee.
Ich habe den Stick direkt an RasPi B+ (USB 1.1) angeschlossen.
Direkt danach erhalte ich noch einmalig ein plausiblen Wert. Doch dann kommt nur noch "Out of range" & Co.

airsensor -d
2015-06-26 23:13:29, DEBUG: Active
2015-06-26 23:13:29, DEBUG: Init USB
2015-06-26 23:13:40, DEBUG: USB device found
2015-06-26 23:13:40, DEBUG: Read any remaining data from USB
2015-06-26 23:13:41, DEBUG: Return code from USB read:  -110
2015-06-26 23:13:41, DEBUG: Write data to device
2015-06-26 23:13:41, DEBUG: Return code from USB write:  16
2015-06-26 23:13:41, DEBUG: Read USB
2015-06-26 23:13:42, DEBUG: Return code from USB read:  16
2015-06-26 23:13:43, DEBUG: Read USB [flush]
2015-06-26 23:13:43, DEBUG: Return code from USB read:
2015-06-26 23:13:41, VOC: 450, RESULT: OK
2015-06-26 23:13:53, DEBUG: Write data to device
2015-06-26 23:13:53, DEBUG: Return code from USB write:  -16
2015-06-26 23:13:53, DEBUG: Read USB
2015-06-26 23:13:53, DEBUG: Return code from USB read:  -16
2015-06-26 23:13:53, ERROR: Invalid result code:  -16
2015-06-26 23:13:54, DEBUG: Read USB [flush]
2015-06-26 23:13:54, DEBUG: Return code from USB read:  -16
2015-06-26 23:13:53, VOC: 21546, RESULT: Error value out of range
2015-06-26 23:14:04, DEBUG: Write data to device
2015-06-26 23:14:05, DEBUG: Return code from USB write:  -110
2015-06-26 23:14:05, DEBUG: Read USB
2015-06-26 23:14:06, DEBUG: Return code from USB read:  -110
2015-06-26 23:14:06, ERROR: Invalid result code:  -110
2015-06-26 23:14:07, DEBUG: Read USB [flush]
2015-06-26 23:14:07, DEBUG: Return code from USB read:  16
2015-06-26 23:14:04, VOC: 21546, RESULT: Error value out of range
2015-06-26 23:14:17, DEBUG: Write data to device
2015-06-26 23:14:18, DEBUG: Return code from USB write:  -110
2015-06-26 23:14:18, DEBUG: Read USB
2015-06-26 23:14:19, DEBUG: Return code from USB read:  -110
2015-06-26 23:14:19, ERROR: Invalid result code:  -110
2015-06-26 23:14:20, DEBUG: Read USB [flush]
2015-06-26 23:14:21, DEBUG: Return code from USB read:  -110
2015-06-26 23:14:17, VOC: 21546, RESULT: Error value out of range


In Fhem kommt eigentlich gar nichts an. Vorhin stand kurz der Manufacture in den Internals. Aber ich habe noch keine VOC-Readings erhalten.

Fhem-Log
2015.06.26 23:13:39 3: CO20: CO20 device found
2015.06.26 23:13:39 3: CO20: CO20 device opened
2015.06.26 23:13:49 3: CO20: read failed
2015.06.26 23:13:49 3: CO20: disconnected
2015.06.26 23:13:49 3: CO20: CO20 device found
2015.06.26 23:13:49 3: CO20: CO20 device opened
2015.06.26 23:14:00 3: CO20: read failed
2015.06.26 23:14:00 3: CO20: disconnected
2015.06.26 23:14:00 3: CO20: CO20 device found
2015.06.26 23:14:02 3: CO20: failed to open CO20 device
2015.06.26 23:14:02 3: CO20: disconnected
2015.06.26 23:14:13 3: CO20: CO20 device found
2015.06.26 23:14:15 3: CO20: failed to open CO20 device
2015.06.26 23:14:15 3: CO20: disconnected


lsusb

Bus 001 Device 007: ID 03eb:2013 Atmel Corp.


dmesg
[ 7869.762721] usb 1-1.5: new full-speed USB device number 7 using dwc_otg
[ 7869.867003] usb 1-1.5: New USB device found, idVendor=03eb, idProduct=2013
[ 7869.867045] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 7869.867066] usb 1-1.5: Product: iAQ Stick
[ 7869.867085] usb 1-1.5: Manufacturer: AppliedSensor


/etc/udev/rules.d/99-usb.rules
# iAQ
SUBSYSTEM=="usb", ATTR{idVendor}=="03eb", ATTR{idProduct}=="2013", MODE="0666"


Was mich ein wenig wundert. Woher weiß das Fhem-Modul eigentlich, wo Airsensor installiert ist.
Oder wird direkt die USB-Schnittstelle abgefragt?

joshi04

Erster Verdacht, hat sich die USB-Stromversorgung des B+ gegenüber den alten Rpi eigentlich verbessert? Falls nicht und um das als Fehlerquelle auszuschließen, würde ich einen aktiven (unbedingt kompatiblen!) Hub dazwischen schalten. Die unzureichende Stromversorgung war am alten Rpi ein echtes Ärgernis. Ich weiß nicht, ob das beim B+ besser geworden ist.

Wenn Du erwähnst "direkt" gehe ich davon aus, dass da kein Kabel mehr zwischen ist, was, wenn es zu lang ist, auch gerne zu Kommunikationsschwierigkeiten führen kann.

Um den Fehler weiter einzugrenzen vermute ich, hast Du den Stick an einer anderen "Maschine" mal getestet und die einwandfreie Funktion bestätigen konntest.

Sorry, ich habe mich mit dem B+ noch nicht beschäftigt, daher sind das alles nur Verdachtsmomente mit dem Versuch, mögliche Fehlerquellen auszuschließen.

Auf der Suche nach der Antwort zu Deiner letzten Frage, schau doch mal ins Modul hinein.

Schöne Grüße und viel Erfolg,
John

PS: Leider gibt es noch keinen Wikiartikel. Ich hätte da zwar auch Lust drauf, muss aber erstmal ein paar andere Projekte abschließen, bevor neue gestartet werden sollten. Die Chance, sich zu verewigen... :)
NUC: 2xJeeLink, PCA301/TX35DTH; HueBridge, LivingColors; vair-monitor (CO2); HMLan, Winmatic, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-ES-TX-WM, HM-WDS10-TH-O, HM-ES-PMSw1-Pl, HM-SEC-SC-2, HM-SEC-SCo; AVM DECT 200; panStamp; smartVISU

Markus M.

Ein Raspberry ist mit USB Geräten nicht sinnvoll zu verwenden, weil sich auch beim RPi2 nichts daran geändert hat dass der ganze Aufbau der Schnittstelle kompletter Mist ist.
Entweder es funktioniert so wie es soll, oder es funktioniert nicht - dann ist allerdings jede Sekunde die ihr darin investiert nur verschwendete Zeit.
Wirf das Ding in die Ecke und vergiss einfach, dass der RasPi einen USB Anschluss hat!
Aktuell weder Smarthome noch FHEM vorhanden

FunkOdyssey

Ich habe den Stick ohne Hub angeschlossen. Einen Hub würde ich unteren nutzen, denn ich will die "Installation" optisch schlank und stromsparend halten. Ich hatte halt noch einen Stick rumfliegen und dachte das wäre einfach hinzubekommen. Ich habe sowieso überall echte CO-Sensoren von Kidde (Stand-Alone). Über Fhem wäre es "Schmuck am Nachthemd" gewesen. Ich traue den Sticks sowieso nicht. Unter Windows waren der PPM-Werte damals recht merkwürdig monoton. Meine Lüftungsanlage hatte immer feinere Werte ermittelt.

Danke dennoch. Vielleicht also ein anderes mal. :-)

volschin

Hat Markus jetzt aber sehr überspitzt formuliert.  ;)
Bei mir laufen 4 CO2-Sensoren an 4 RasPis (alles über B, B+ und 2). Das hatte zwar auch ein paar Herausforderungen, wie man weiter vorn im Thread lesen kann, funktioniert aber jetzt sehr gut.
Intel NUC+Ubuntu 24.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7690, Echo Dots+Show8, HomeBridge

FunkOdyssey

Den Thread hatte ich vorher gelesen. Den einzigen Unterschied, den ich bei mir habe, ist der nicht vorhandene USB Hub. Sonst sollte alles okay bei mir sein.

Hast du einen Hub?

volschin

Nein, ich habe keine Hubs dran, aber entsprechend starke Netzteile.
Intel NUC+Ubuntu 24.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7690, Echo Dots+Show8, HomeBridge