Voltcraft CO-20 USB-Luftqualitätssensor

[justme1968]

ich würde in diesem fall den master immer definieren.

ich glaube das das umstecken häufiger ist als einen zusätzlichen neuen stick anzuschließen. wobei beides vermutlich eher selten ist.

dieser master könnte auch auf das einstecken eines stick reagieren. ich weiß nur nicht ob sich der aufwand zu implementieren wirklich lohnt. wie viele haben überhaupt mehr als einen stick an einem rechner. und wie oft kommt bei denen dann noch einer dazu. das kurz von hand anzustoßen ist glaube ich nicht so schlimm.

ich habe aber auch nur einen und würde die anderen jeweils an einem abgesetzten rapberry pi betreiben weil ich so auch andere ios verteile und noch ibeacons für indoor navigation machen möchte.

der anwenungsfall für zwei sticks an einem rechner ist glaube ich eigentlich nur die lüftersteuerung über den vergleich außen/innen. das wären zwei sticks bei denen es dann auch bleibt.

die idee den einen stick per led zu identifizieren finde ich sehr gut. ich würde ein identify kommando im device vorschlagen.

gruss
  andre

[Spiff]

Du hast wahrscheinlich Recht. Ich dachte zu sehr an meine persönliche Konfiguration, alles über einen einzelnen Server zu regeln - in einer Wohnung ist das auch noch gut handhabbar ohne zusätzliche RPis - wobei die sich mit dem Stick doch auch zickig verhalten sollen oder hat sich das mittlerweile gelegt? Vielleicht sollte ich das auch einfach mal ausprobieren, alleine um den Wirkradius etwas zu vergrößern und nicht so viele Kabel rumfliegen zu haben...

Gruß
Spiff

[justme1968]

per usb kabel geht bei 2 oder 3 stickwerken nicht mehr wirklich. mit keller wo der server inzwischen steht warten es sogar 4. netzwerk habe ich in jedem zimmer.

rapberry pi mit aktivem hub sollte inzwischen eigentlich gehen.

gruss
  andre

ps: je nach usb kabel gibt es ab ein paar metern ganz unabhängig von den spezifikationen bezüglich der datenleitungen alleine schon wegen der spannungsversorgung probleme. ein sr04 ultraschall sensor misst z.b. an einem arduino nanno bei mir nur noch mist wenn ich nach 5m kabel nicht die 5v per aktiven hub wieder auffrische. dann kann ich auch gleich noch einen raspberry spendieren oder das ganze per panstamp und funk machen.

[volschin]

So ist es, bei mir hat auch jeder Stick seinen eigenen RasPi, die per FHEM2FHEM über WLAN angekoppelt sind. Kein Kabelsalat.

[Markus M.]

So ist es, bei mir hat auch jeder Stick seinen eigenen RasPi, die per FHEM2FHEM über WLAN angekoppelt sind. Kein Kabelsalat.

Mit welchem Image und welchem RasPi hast du das langfristig lauffähig hinbekommen?

[volschin]

Gemischt B, B+ und der Master ein Pi 2. Raspbian Jessie und Kernel 4.1.4, lief aber vorher mit 3.18 auch schon stabil.

[vbs]

Hat das Vorteile mit FHEM2FHEM? Ich hab auch zwei Raspberries mit dem Sensor dran, aber ich hab da einfach Script laufen, welches einmal pro Minute den VOC-Wert vom Sensor ausliest und dann per Telnet "setreading" bei FHEM abliefert (WLAN). Das läuft unter TinyCore-Linux bei mir.

[volschin]

Seit meinem FHEM-Update heute Morgen hat sich ein Sensor schon das zweite Mal verabschiedet. Ich muss wohl die eingespielten Codeänderungen des Moduls mal näher unter die Lupe nehmen. Das mir seit Monaten nicht passiert.

[Markus M.]

Seit meinem FHEM-Update heute Morgen hat sich ein Sensor schon das zweite Mal verabschiedet. Ich muss wohl die eingespielten Codeänderungen des Moduls mal näher unter die Lupe nehmen. Das mir seit Monaten nicht passiert.

Die Änderungen sind Timeout und Retries.
Wenn du die Attribute nicht gesetzt hast sind es jetzt 10 und 3, vorher waren die Werte nicht initialisiert, was aber zumindest bei Linux scheinbar nicht weiter ...

Und exakt während ich diese Zeilen schreibe denk ich mir so ... fuck! Millisekunden! 
Wenn du den Timeout setzt sollte das Problem bis zum nächen Update behoben sein.

@Andre
Sorry, noch ne Runde
Kannst du bitte in Zeile 194 aus den 10 mal noch 1000 machen?!

Code Auswählen Erweitern

      $hash->{timeout} = AttrVal($name,"timeout",1000);

[volschin]

Ich will ja jetzt nicht oberpenibel sein, aber 10 sec = 10000 msec. Ich würde es eigentlich für sinnvoll halten, wenn das modulintern umgerechnet wird und man im Attribut und den INTERNALS die Sekunden angezeigt bekommt.

[Markus M.]

Ich will ja jetzt nicht oberpenibel sein, aber 10 sec = 10000 msec. Ich würde es eigentlich für sinnvoll halten, wenn das modulintern umgerechnet wird und man im Attribut und den INTERNALS die Sekunden angezeigt bekommt.

Das macht bei Werten in Millisekunden nicht unbedingt Sinn, bei denen dann in den meisten Fällen eine Zahl < 1 drin stehen würde.
1000ms sind für USB ordentlich. Ich hatte allerdings auch vergessen, das mit in die Doku zu schreiben.

Im Anhang ist eine Version in der nun alles passen sollten.
@Andre: Jetzt dann aber wirklich zum letzten Mal.

Sorry! Markus
(http://i.imgur.com/HTisMpC.jpg)

[Spiff]

Hi Markus!

Mein Stick hatte sich in der Nacht auch wieder verabschiedet. Seitdem ich die Attribute gesetzt hatte, scheint Ruhe zu sein.
Als ich 10 einstellen wollte, hatte er automatisch auf 1000 hochgestellt. Ich habe jetzt erstmal 10000 genommen, weil ich mir das mit den msec auch schon gedacht hatte.

Gruß
Spiff.

[PEPITO82]

Bis Sonntag lief mein VOC-Sensor stabil. Mit dem Update vom Sonntag ging dann erstmal nichts mehr.
Abhilfe brachte das Update aus Beitrag  #326. Jedoch bekomme ich seitdem regelmäßig Einträge ins Logfile (ca. alle 10 - 15 Minuten):

Code Auswählen Erweitern

2015.08.18 06:43:21 3: co20: disconnected
2015.08.18 06:43:21 3: co20: CO20 device found
2015.08.18 06:43:21 3: co20: CO20 device opened
2015.08.18 06:52:42 3: co20: disconnected
2015.08.18 06:52:42 3: co20: CO20 device found
2015.08.18 06:52:42 3: co20: CO20 device opened

Als Timeout sind 10000 gesetzt.

Hat jemand ähnliche Probleme. Was kann ich tun?

[Markus M.]

Bis Sonntag lief mein VOC-Sensor stabil. Mit dem Update vom Sonntag ging dann erstmal nichts mehr.
Abhilfe brachte das Update aus Beitrag  #326. Jedoch bekomme ich seitdem regelmäßig Einträge ins Logfile (ca. alle 10 - 15 Minuten)
Als Timeout sind 10000 gesetzt.
Hat jemand ähnliche Probleme. Was kann ich tun?

Du hast keine Probleme, nur Reconnects Welche Hardware?
Setz den Wert doch mal auf 1000 und schau ob es das besser macht.
Höhere Werte waren eigentlich nur bei den alten RasPis sinnvoll, die sonst gar keine Verbindung gehalten haben.

[PEPITO82]

Setz den Wert doch mal auf 1000 und schau ob es das besser macht.

Leider nein:

Code Auswählen Erweitern

2015.08.18 12:07:23 3: co20: disconnected
2015.08.18 12:07:23 3: co20: CO20 device found
2015.08.18 12:07:23 3: co20: CO20 device opened
2015.08.18 12:16:44 3: co20: disconnected
2015.08.18 12:16:44 3: co20: CO20 device found
2015.08.18 12:16:44 3: co20: CO20 device opened

Der Velux-VOC-Sensor hängt an einem RPi 2 über einen aktiven Hub.
Am Hub ist der Sensor über einen USB/LAN-Extender angeschlossen, da der Sensor im Schlafzimmer positioniert ist und der RPi 2 in der Hausverteilung hängt.
Läuft aber alles über die CAT7 Hausverkabelung.

Die Reconnects lt. Logfile sind neu.