Voltcraft CO-20 USB-Luftqualitätssensor

[Spiff]

aber da momentan wieder die Luft gut ist

...einfach mal kräftig reinpupsen!

Dieser qualifizierte Beitrag wurde präsentiert von: Spiff.

[maddin]

Mh, ich dachte es geht, aber ich bekomme mit der neuesten 38_CO20.pm Version nur folgendes:

2013.11.21 20:20:20 3: co20: CO20 device found
2013.11.21 20:20:20 3: co20: filed to open CO20 device
2013.11.21 20:20:20 3: co20: disconnected

Nachdem ich mal den Code etwas durchgeschaut habe bin ich zwar nicht wesentlich schlauer warum es nicht läuft (Geraten: USB-ID nicht richtig erkannt???), hab dafür aber gesehen das der Coder bei jeder Fehlermeldung den (lustigen) Schreibfehler drin hat....er soll doch immer 'failed' heißen, nicht 'filed', oder? Obwohl...

Hat jemand ne Ahnung was da fehlschlägt?

Grüße

[justme1968]

hat noch jemand anders das device offen ?

gruss
  andre

[My-FHEM]

Hallo,

es scheint noch etwas mit der Initialisierung nicht ganz hinzuhauen.

wenn ich fhem starte erhalte ich im co20 device nur :

STATE: waiting
und INTERVAL fehlt.

wenn ich zunächst airsensor -d starte erhalte ich
folgenden output:

Code Auswählen Erweitern


airsensor/airsensor -d
2013-11-22 21:06:35, DEBUG: Active
2013-11-22 21:06:35, DEBUG: Init USB
2013-11-22 21:06:46, DEBUG: USB device found
2013-11-22 21:06:46, DEBUG: Read any remaining data from USB
2013-11-22 21:06:47, DEBUG: Return code from USB read:  -110
2013-11-22 21:06:47, DEBUG: Write data to device
2013-11-22 21:06:47, DEBUG: Return code from USB write:  16
2013-11-22 21:06:47, DEBUG: Read USB
2013-11-22 21:06:47, DEBUG: Return code from USB read:  16
2013-11-22 21:06:48, DEBUG: Read USB [flush]
2013-11-22 21:06:48, DEBUG: Return code from USB read:
2013-11-22 21:06:47, VOC: 450, RESULT: OK
2013-11-22 21:06:58, DEBUG: Write data to device
2013-11-22 21:06:58, DEBUG: Return code from USB write:  16
2013-11-22 21:06:58, DEBUG: Read USB
2013-11-22 21:06:58, DEBUG: Return code from USB read:  16
2013-11-22 21:06:59, DEBUG: Read USB [flush]
2013-11-22 21:06:59, DEBUG: Return code from USB read:
2013-11-22 21:06:58, VOC: 450, RESULT: OK



Danach FHEM gestartet und co20 funktioniert

INTERVAL 300
STATE open

readings voc 450

Hilft dies?

Gruß

[volschin]

Hi zusammen,
irgendwie habe ich die Hoffnung noch nicht aufgegeben, den CO-20 auch an einer nicht gefreezten Fritzbox zum laufen zu bekommen.

Ich habe an einem geöffneten Stick gesehen, dass dieser einen ATMEL atmega32u4 zur Steuerung verwendet. das ist jetzt nicht irgendein Chip, sondern der Steuerchip des CUL.

Irgendwie bekommt es Rudolf doch hin, mit diesem ohne zusätzliche Packages, die Inline::C und Compliler benötigen zu kommunizieren.

Er nutzt dafür anscheinend die Routinen in der DevIo.pm. Aber ob die jetzt ganz speziell auf die CUL-FW abgestimmt sind oder man damit auch einen anderen atmega32u4 ansteuern könnte, das ist mir momentan doch zu hoch.

Vielleicht hat ja jemand mit der Info über den Chip eine Idee.

Gruß,
Veit

[justme1968]

das problem ist nicht die 'cpu' sondern wie diese an den usb bus angebunden ist. bei cul, jeelink, panstamp und co. geht das per usb seriell wandler (z.b. einem ftdi chip) der eine bestimmtes high level protokoll implementiert für das es keine speziellen triber braucht diese für diese geräte klasse entweder dabei sind oder ganz generisch für alle devices mit einem solchen chip funktionieren. im prinzip wird klartext ascii verwendet um mit dem device zu reden.

der co20 hängt aber per low level usb am bus und wird auf einer sehr viel tieferen ebene angesprochen. es wird keine generische device/triber klasse verwendet sondern (zumindest bei den verfügbaren beispielen) eine low level device spezifische schnittstelle.

gruss
  andre

[volschin]

Hallo Andre,
das kann der atmega32u4 aber von Haus aus (siehe hier).

Ich kann auch auf meinem CUL (mit transparentem Gehäuse) keinen FTDI-Chip finden. Ich denke das macht dort auch der ATMEL. Aber vielleicht ist das eine Frage der Firmware, die bei beiden Sticks anders implementiert sein könnte.

Gruß,
Veit

[Spiff]

Hallo Andre,

ich habe wieder folgenden Fehler:

Code Auswählen Erweitern

Use of uninitialized value in addition (+) at ./FHEM/38_CO20.pm line 170.

Hast du eine Idee, woher der kommt? Wenn er kommt, dann heftig: nicht nur eine Zeile, sondern Dauerstress.
Im Log habe ich gesehen, dass ich wohl ein Save Config ausgeführt habe und sich der co20 dann getrennt hat:

Code Auswählen Erweitern

2013.11.24 20:09:56 5: Cmd: >rereadcfg<
2013.11.24 20:09:56 3: co20: disconnected

Hat das etwas damit zu tun, dass eine Neuverbindung (noch) nicht implementiert ist?
Ich habe keine Ahnung, warum er sich überhaupt getrennt hat.

Viele Grüße
Spiff.

[justme1968]

bitte schau mal ob die angehängte version besser ist.

damit sollte die fehlermeldung weg sein und auch das reconnect besser funktionieren.

gruss
  andre

[Spiff]

Reconnect funktioniert ohne Probleme.
Bis jetzt keine Fehler zu entdecken.
Melde mich, wenn es etwas Auffälliges gibt.

Vielen Dank!
Spiff.

[Spiff]

Hallo Andre,

kann es sein, dass das Atribut "interval" keinen Einfluss mehr hat?
Er liest bei mir immer alle 300 Sekunden aus, egal, was ich einstelle.

Gruß
Spiff.

[justme1968]

das attribut wurde bisher nur beim connect ausgewertet.

in der angehängten version sollte es sofort auswirkung haben.

gruss
  andre

[Spiff]

Hallo Andre,

mit der Version funktioniert's leider gar nicht mehr.

Code Auswählen Erweitern

Subroutine CO20_Initialize redefined at ./FHEM/38_CO20.pm line 15, <$fh> line 32.
Subroutine CO20_Define redefined at ./FHEM/38_CO20.pm line 33, <$fh> line 32.
Subroutine CO20_Notify redefined at ./FHEM/38_CO20.pm line 59, <$fh> line 32.
Subroutine CO20_Connect redefined at ./FHEM/38_CO20.pm line 74, <$fh> line 32.
Subroutine CO20_Disconnect redefined at ./FHEM/38_CO20.pm line 127, <$fh> line 32.
Subroutine CO20_Undefine redefined at ./FHEM/38_CO20.pm line 146, <$fh> line 32.
Subroutine CO20_Set redefined at ./FHEM/38_CO20.pm line 156, <$fh> line 32.
Subroutine CO20_poll redefined at ./FHEM/38_CO20.pm line 165, <$fh> line 32.
Subroutine CO20_Get redefined at ./FHEM/38_CO20.pm line 199, <$fh> line 32.

Gruß
Spiff.

[justme1968]

sorry. das war totaler müll. an dem system an dem ich gerade entwickle geht der stick leider nicht drum war es ungetestet.

die version sollte gehen...

gruss
  andre

[Spiff]

Hi Andre,

das manuelle Setzen des Intervals funktioniert jetzt. Allerdings ist der Wert beim Neustart wieder weg, obwohl ich ihn in die fhem.cfg eingetragen habe.

Auch scheint der erste Auslesewert Startschwierigkeiten zu haben: er fängt erst nach dem ersten Interval an, anstatt sich gleich einen Wert zu holen. Aber das soll vielleicht so? Man startet fhem normalerweise ja auch nicht so oft neu. 

Danke & Gruß,
Spiff.