Voltcraft CO-20 USB-Luftqualitätssensor

[Markus M.]

Poste doch mal Definition und Log mit Level 5


Sent from my iPhone using Tapatalk

[drdownload]

Ganz banal: mit rehau.sensoren.wohnzimmer co20 definiert.

mit dem air-sensors-linux cli bekomme ich gerade 2016-05-23 20:47:11, VOC: 3277, RESULT: Error value out of range

im log:

Code Auswählen Erweitern

2016.05.23 20:51:59 3: rehau.Sensoren.wohnzimmer: CO20 device found
2016.05.23 20:51:59 3: rehau.Sensoren.wohnzimmer: failed to open CO20 device
2016.05.23 20:51:59 5: datalen 1
2016.05.23 20:51:59 3: rehau.Sensoren.wohnzimmer: disconnected

[drdownload]

Ah ja, ich habe auch eine wh3080 die über pywwv per libusb angesprochen wird.

[willybauss]

Poste doch mal Definition und Log mit Level 5

Ganz banal: mit rehau.sensoren.wohnzimmer co20 definiert.

[drdownload]

ha, die reihenfolge des ganzen zeugs am usb hub verändert und auf einmal geht alles (auch über 2 reboots). sehr strange, aber hauptsache es geht

[belu]

Hallo,

ich habe mir nun auch 3 Rehau Sensoren zugelegt, habe sie nun mehrere Tage im Betrieb und eingestellt. Habe sie an einer Raspberry laufen. Benutze sie an einer Lüftungsanlage. Ich habe Abluftschläuche, darin habe ich sie eingelassen. Das klappt wunderbar, ich kann die Lüftung entsprechend der Luftgüte erhöhen oder reduzieren.
Problem ist aber das ich die eindeutige Zuweisung nach einem Reboot verliere. Bad OG / Bad EG / Küche
aktuelles Device 001:006 / 001:007 / 001:008. Nach einem Neustart sieht es anders aus.

Hat jemand eine Idee?

Jeder Sensor hat ne Eindeutige ID: SERIALNUMBER 48313631373015020112 wie kann ich die Eindeutige Zuweisung damit bestimmen?

LG Belu

[willybauss]

Die Probleme mit der Zuweisung habe ich auch. Wenn ich den Raspi mitsamt USB-Hubs beim Reboot stromlos mache, dann klappt's.

Eine Lösung mit Erkennung der Seriennummer wäre mir auch wesentlich lieber.

@belu: Hast Du nicht eine THZ/LWZ? Ich habe grade vor ein paar Tagen dort im Thread meinen Code zur automatischen Einstellung der Lüfterdrehzahlen veröffentlicht. Wäre schick, (dort) zu erfahren, wie Du es gelöst hast. Evtl. kann ich ja noch was lernen/verbessern.

Das mit dem Sensor im Abluftschlauch hatte ich am Anfang auch, aber im zentralen Schlauch direkt am Eingang der Anlage. Damit wurde ich nicht glücklich. Wenn in einem Raum die Luft schlecht, in allen anderen Räumen gut ist, dann sehe ich im Abluftschlauch nur einen geringen Bruchteil davon. Die Regelung war deshalb unzuverlässig. Aber wenn Di die Sensoren in jedem einzelnen Abluftschlauch hast wird's wohl besser funktionieren.

[joshi04]

Nur ein Hinweis, für die eindeutige Zuordnung würde ich mal schauen, ob man dafür eine udev rule einrichten kann, wenn man die unterschiedlichen Sticks über die SN identifiziert bekommt.

[willybauss]

Wenn ich mich richtig erinnere hatten wir das Thema gier schonmal. Ich glaube es war so, dass der Stick beim booten seine Seriennummer nicht raus gibt. Aber Versuch macht klug - hab nur leider grade keine Zeit dafür.

[joshi04]

Du hast Recht:
https://forum.fhem.de/index.php/topic,13166.msg322854.html#msg322854
und folgende.

Wenn sie sich "per USB" nicht unterscheiden, kann man udev vergessen.

[willybauss]

Ja, dann wäre es nur über eine Änderung im Modul möglich, z.B. die Seriennummer per Attribut definieren, so dass sich das Modul beim booten die Sensoren selbst suchen kann.

[Markus M.]

Über die Seriennummer wird das eher nichts, dazu muss der Stick ja erst mal verbunden sein.
Wenn du zwei Sensoren über einen 7-Port USB HUB anschliesst, sollte es über den Bus und UDEV aber wieder klappen, immer den richtigen zu finden.

[willybauss]

das Modul müsste beim booten

• über lsusb die Deviceadressen erfragen
• die erste Adresse verbinden
• Seriennummer auslesen
• in fhem das Seriennummer-Attribute des Co20-Devices damit vergleichen
• ggf. Verbindung trennen, wenn die SN nicht passt
• nächste Deviceadresse

Klar, das ist kein Einzeiler. Aber gehen würde es.

Wenn du zwei Sensoren über einen 7-Port USB HUB anschliesst, sollte es über den Bus und UDEV aber wieder klappen, immer den richtigen zu finden.

drdownload, joshi, belu, willybauss - das sind in den letzten paar Beiträgen schon 4 User, bei denen es halt nicht klappt. Auch bei anderen Devices habe ich mit UDEV-Regeln ein unzuverlässiges Verhalten festgestellt und bin deshalb zu einer hart codierten Lösung übergegangen, z.B.

Code Auswählen Erweitern

define Mythz THZ /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0@115200

Aber das geht halt nur, wenn das Device in /dev/serial/by-id/ auftaucht und einen eindeutigen Namen hat.

[belu]

Moin,

@ Willy hab dein Programm übernommen, bilde aber nur aus meinen 3 Werten einen Mittelwert und arbeite mit diesem, das aber aktuell kein Zustand so. Habe mir nun noch einen bestellt.
@Markus hab einen 7 Port USB Hub. Es wird nach durcheinander gewürfelt.
Also Willy hat schon recht, wir sollten da vielleicht nochmal das Konzept überarbeiten.

Man bekommt beim Boot nur raus das ein Sensor auf dem Port hängt, nicht welcher Sensor. Selbst bei vollendeten Boot per lsusb -v ist keine unterscheiden möglich.
Also alle uDev Regeln können da nicht greifen.
Kann dein CO20 Modul nicht einfach alle Sensoren per Automount aktiveren. Diese dann per SN Identifizieren?

Aktuell sprechen wir ja mit :

define device co20 bus:ID

Es geht ja auch ohne Zuweisung bei 3 Sensoren klappt dann nix, ich glaube die pollen dann alle auf den ersten.

Es wäre schön nach erfolgter Adressierung die Identifizierung über die Seriennummer zu machen.

define device co20 48313631373015020110

Dadurch wäre der Port egal, Hauptsache die ID stimmt zur Log.

LG

LG

[Markus M.]

Ich schau mir das diese Woche mal an. Testversion gibt's dann hier.
Bitte den Anhang ausprobieren, definieren über die SERIALNUMBER.
Bei mir klappt es mit 2 Sticks.
Das Problem ist aber wie immer der Raspi. Das ganze ist blockierend und wenn dann was schief geht...