Voltcraft CO-20 USB-Luftqualitätssensor

[willybauss]

Du musst wenn der Stick disconnected ist im Idealfall einfach nur ein update machen.
Wenn es dann nicht funktioniert, liegt es wahrscheinlich am RasPi USB.
Mehr als jetzt kann ich da nicht tun.

Dann würde ich vorschlagen, dass Du die Testsoftware lt. Deinem Beitrag vom 13. Juni 10:38 eincheckst, denn die war am zuverlässigsten. Da konnte ich mich auf "opened" und "disconnected" verlassen, was bei den nachfolgenden Versionen nicht mehr der Fall war.

[Joker2002]

Hallo miteinander,

nachdem ich auf diesen Threat gestoßen bin, hatte ich mir auch den VELUX Raumluftfühler besorgt um meine Raumluft zu überprüfen. Habe den Threat durchgelesen und bin folgende Schritte durchgegangen:

sudo apt-get install libdevice-usb-perl
define co20 CO20
attr co20 interval 1800
define FileLog_co20 FileLog ./log/co20-%Y.log co20:voc:.*

In FHEM erhalte ich jedoch immer die Meldung, dass der Stick ,,disconnected" ist.
Im Forum hatte ich gelesen, dass es wohl daran läge, dass oftmals der Befehl ,,sudo apt-get install libdevice-usb-perl" vergessen wurde auszuführen. Diesen Befehl habe ich jedoch durchgeführt.

Habt ihr einen Tipp für mich, warum der Stick in FHEM immer als disconnected angezeigt wird ?

Anbei mal ein List des Gerätes:

Code Auswählen Erweitern

Internals:
   DEV
   INTERVAL   1800
   NAME       co20
   NOTIFYDEV  global
   NR         292
   NTFY_ORDER 50-co20
   STATE      disconnected
   TYPE       CO20
   fail       0
   seq2       103
   seq4       1
   tag
Attributes:
   alias      Velux Raumluftsensor
   interval   1800
   room       Lüften


[wthiess]

Usb-hub ?

[willybauss]

Passen die Zugriffsrechte? In der Commandref gibts dazu Hinweise und einen weiter führenden Link. Und wie bereits genannt: erst mal direkt anschließen ohne USB-Hub. Nach Fehlversuchen hatte ich auch immer Probleme; habe dann erst mal alles für 30 Sekunden stromlos gemacht. Dann hat's immer geklappt.

Sobald Du Zugriff hast kannst Du im advanced Mode die Seriennummer auslesen und die Testversion des co20-Moduls vom 13. Juni installieren. Die schafft anhand der Seriennummernangabe in der Definition auch den Reconnect.

[Joker2002]

Hallo, danke für die schnellen Antworten. Ich werde es nächste Wiche testen

[volschin]

Dein Intervall mit 1800 = 3h ist so wirklich richtig?

Was setzt Du an Hardware ein, einen RasPi? Wenn ja, welchen?
Ist das Netzteil ausreichend dimensioniert?

[Joker2002]

Ich nutze eine raspberry Pi 3. als Netzteil habe ich das eine Amazon Fire tv Sticks genommen

[volschin]

Soweit mir bekannt ist, hat dieses Netzteil nur 1800 mA. Das ist bei einem RasPi 3 schon mal arg wenig, empfohlen sind >2500 mA. Ich könnte mir vorstellen, dass Deine Probleme mit der Stromversorgung zusammenhängen.

[willybauss]

Die Stromstärke des Netzteils allein sagt nicht alles über die Raspi-Tauglichkeit. Es muss impulsfest sein, also kurzzeitig schnelle Stromschwankungen verdauen, ohne dass es dabei zu Spannungsschwankungen kommt. Die Netzteile, die bei Bundleangeboten dabei sind, sind sicher meist die beste Wahl.

[Markus M.]

Dann würde ich vorschlagen, dass Du die Testsoftware lt. Deinem Beitrag vom 13. Juni 10:38 eincheckst, denn die war am zuverlässigsten. Da konnte ich mich auf "opened" und "disconnected" verlassen, was bei den nachfolgenden Versionen nicht mehr der Fall war.

Na dann probier doch mal die hier.

[willybauss]

Na dann probier doch mal die hier.

- Testsoftware vom 20.6.16 ins .../FHEM Verzeichnis kopiert
- shutdown restart
- 2 von 3 Sensoren: opened; der dritte: disconnected
- mehrfach "reconnect" erfolglos versucht => bleibt disconnected
- 15 Minuten gewartet => bleibt disconnected
- nochmal reconnect => opened
- allerdings sind jetzt die anderen beiden im Status "error"
- einen davon per reconnect in Status "opened" gebracht ==> die anderen beiden sind jetzt "error"
- das kann ich endlos fortsetzen: sobald einer auf "opened" geht sind die anderen beiden auf "error"
- 1 - 2 Minuten warten => alle 3 sind auf error
==> Versuch abgebrochen, da total instabil

Ich bleibe dabei: die Version vom 13.6. war die stabilste. Seither wurde es mit jeder Version instabiler. Wobei ich einschränken muss, dass auch diese Version (13.6.) grade nach dem abgebrochenen Test 3 - 4 Anläufe brauchte, um einen Sensor ans laufen zu bringen. Die anderen gingen auf Anhieb fehlerlos.

Bei der heutigen Version hast Du die ehemaligen drei verschiedenen "reconnect..." Arten (id, serial, singleDevice) zu einem einzigen reconnect zusammengefasst, der offenbar selbst erkennen soll, welcher Typ grade gebraucht wird. Wäre es nicht besser, vor solchen Erweiterungen die grundlegende Funktion (zuverlässiger reconnect, stabiler Betrieb bei mehreren Sensoren, ...) zu verbessern? Ein Modul mit schicken Gimmicks, das aber nicht die grundsätzliche Funktion beherrscht, nützt nichts.

Evtl. sollte ich erwähnen, dass 2 von 3 Sensoren bei mit an USB-RJ45-Adaptern hängen, um die USB-Leitung auf 10 - 15 m zu verlängern. In den Attributen habe ich

Code Auswählen Erweitern

retries  5
timeout  2000

eingetragen. Evtl. hakt es ja an internen Timeouts im Modul, die dazu nicht passen?

Falls ich weiterhin testen soll möchte ich zu weiteren Testversionen jeweils eine Liste der Änderungen, damit ich auch weiß, was zu testen ist und wo evtl. "der Hund begraben liegen" könnte.

[Markus M.]

die Version vom 13.6. war die stabilste. Seither wurde es mit jeder Version instabiler.

Funktionell ist das von heute die Version vom 13.6.
Der State "error" ist neu und wird bei jedem Timeout gesetzt.

Bei der heutigen Version hast Du die ehemaligen drei verschiedenen "reconnect..." Arten (id, serial, singleDevice) zu einem einzigen reconnect zusammengefasst, der offenbar selbst erkennen soll, welcher Typ grade gebraucht wird.

War nur zum Testen. Es wird jetzt immer so neu verbunden wie der Stick definiert ist, entweder ID, Serial oder eine einfache Suche.

Evtl. sollte ich erwähnen, dass 2 von 3 Sensoren bei mit an USB-RJ45-Adaptern hängen, um die USB-Leitung auf 10 - 15 m zu verlängern. In den Attributen habe ich retries  5 timeout  2000 eingetragen. Evtl. hakt es ja an internen Timeouts im Modul, die dazu nicht passen?

Es hakt leider an deinem System. Es ist schwierig genug, einen der Sticks direkt stabil an einem Raspberry zu betreiben, drei mit langen Leitungen funktionieren leider einfach nicht. Das siehst du ja auch an den error States - die USB Kommunikation schlägt öfter fehl als dass sie funktioniert.
Und die Sticks haben dummerweise zusätzlich die Eigenart, dass sie dann irgendwann bis zum Abstecken gar nicht mehr funktionieren.

Was passiert denn, wenn du das System neu bootest? Werden wenigstens alle erkannt?
Es geht mir bei der Erweiterung nur darum, dass sie nach Serial sauber zugeordnet werden. Gegen die Kommunikationsprobleme kann ich nichts tun.

[willybauss]

Es hakt leider an deinem System. Es ist schwierig genug, einen der Sticks direkt stabil an einem Raspberry zu betreiben, drei mit langen Leitungen funktionieren leider einfach nicht. Das siehst du ja auch an den error States - die USB Kommunikation schlägt öfter fehl als dass sie funktioniert.

Ich habe seit Monaten mit dieser Konfiguration fehlerfrei vollständige Daten bekommen, da fehlt nichts. "die USB Kommunikation schlägt öfter fehl als dass sie funktioniert" kann ich daher in keinster Weise bestätigen.

Der State "error" ist neu und wird bei jedem Timeout gesetzt.

Wird dabei der per Attribut verlängerte Timeout berücksichtigt? Wie gesagt: dann müsste ich seit Monaten Probleme haben, der Log ist aber gähnend leer.

Was passiert denn, wenn du das System neu bootest? Werden wenigstens alle erkannt?

eingecheckte Version:
Beim booten werden nicht unbedingt alle erkannt. Aber wenn man das System komplett herunter fährt und kurz stromlos macht (auch die Sticks), dann werden alle drei fehlerfrei erkannt.

Testversion vom 13.6. (möglicherweise auch die späteren):
stromlos ist nicht erforderlich; wenn ein Stick nicht erkannt wird hilft ein reconnect, evtl. aber erst nach mehreren Versuchen.

[willybauss]

Es wäre sicher hilfreich, wenn sich auch Jemand mit einer einfacheren Konfiguration an den Tests beteiligen würde. Wenn man überlegt, wie viele Leute wie oft eine Erkennung anhand der Seriennummer gewünscht hatten, dann ist die Beteiligung doch recht traurig ... 

[Markus M.]

Ich habe seit Monaten mit dieser Konfiguration fehlerfrei vollständige Daten bekommen, da fehlt nichts. "die USB Kommunikation schlägt öfter fehl als dass sie funktioniert" kann ich daher in keinster Weise bestätigen.
Wird dabei der per Attribut verlängerte Timeout berücksichtigt? Wie gesagt: dann müsste ich seit Monaten Probleme haben, der Log ist aber gähnend leer.

Der Timeout wird berücksichtigt, so wie vorher auch.
Natürlich ist das Log leer. Alles was du davon bisher gesehen hast, war der unscheinbare fail Counter in den Internals.
Mit dem State error ist das jetzt nur sichtbarer.
Wie hattest du die drei Sticks vorher definiert? Mit der ID?

eingecheckte Version:
Beim booten werden nicht unbedingt alle erkannt. Aber wenn man das System komplett herunter fährt und kurz stromlos macht (auch die Sticks), dann werden alle drei fehlerfrei erkannt.
Testversion vom 13.6. (möglicherweise auch die späteren):
stromlos ist nicht erforderlich; wenn ein Stick nicht erkannt wird hilft ein reconnect, evtl. aber erst nach mehreren Versuchen.

Hast du mal mit dmesg nachgesehen was beim Einstecken oder Booten passiert?
Erkennt der Rechner den Stick überhaupt immer?