Voltcraft CO-20 USB-Luftqualitätssensor

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

Vorheriges Thema - Nächstes Thema

willybauss

Grade fällt mir auf, dass ich  Wohnzimmer_co20:voc_avg ... geschrieben hatte. Das geht natürlich nur, wenn Du über userReadings überhaupt Mittelwerte gebildet hattest (Details in meinem verlinkten Beitrag). Für erste Versuche lass das rote einfach weg, also  Wohnzimmer_co20:voc
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

sasasch

Danke Willy. Ist mir schon aufgefallen :)

Bei mir wird das ganze (noch) nicht ganz so umfangreich. Uns stört nur dass manch ein Nachbar seinen Brenner mit nassem Holz und womöglich anderer übelriechender Sachen versorgt und der Geruch uns die ganze Budde verpestet. Dann soll die KWL einfach mal für ne Stunde ausgehen. Das ganze max. 2x am Tag.

Dazu will ich den Sensor möglichst in die Ansaugöffnung bringen. Muss noch schauen ob ich das irgendwo in der Anlage selbst unterbringen kann ( Vaillant Recovair 260/4 ). Ansonsten müsste ich im Ansaugrohr ein Loch bohren und den Stick durchschieben und wieder Luftdicht verschließen. Nur weiß ich nicht ob das so gut ist.
Ein wenig Bedenken hab ich noch falls das Ding mal den Geist aufgibt und abrennt. Im Luftstrom könnte das Blöd ausgehen. Oder ich platziere ihn gleich irgendwo draußen.

Später werde ich dann mal schauen wie ich den Ebus bedienen kann um die Lüfterstufen zu schalten. Wobei die Anlage selbst einem Auto Modus hat und bei zu hoher Luftfeuchtigkeit entsprechend reagiert.

Gruß


Gesendet von iPhone mit Tapatalk

willybauss

Ich habe auch einen Sensor in der Zuluft. Das Blöde ist halt, dass er nur Fahrkarten anzeigt, sobald die Lüftung mal aus ist. Er kann also nicht von sich aus entscheiden, wann man die Lüftung wieder einschalten darf.

Du solltest auch sicherheitshalber darauf achten, dass man den Sensor am USB-Kabel mal kurz außer Betrieb nehmen kann. Bei mir ist es schon ein paar mal vorgekommen, dass er sich bei den Messwerten "verlaufen" hat und extrem hohe Werte anzeigte. Kurz aus- und wieder einstecken hilft schnell und einfach. Ich wäre aber auch nicht böse, wenn mir dafür Jemand eine "richtige" Lösung nennen würde.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

sasasch

#603
Also ich habe jetzt irgendwie doch noch Probleme damit: hier mein code
define co20 CO20
attr co20 advanced 1
attr co20 disable 0
attr co20 event-on-update-reading voc
attr co20 interval 20
attr co20 retries 20
attr co20 timeout 10000
attr co20 userReadings voc { ReadingsVal("co20","voc",0) }
define check DOIF ( ([co20:voc] > 900 )( set FBDECT_16 off ) )
attr check selftrigger all


Der Sensor geht definitiv über 900, passieren tut aber nix, außerdem bekomme ich folgende Fehlermeldung bei den readings im define check, siehe Anhang

Was mache ich  falsch ? Komme hier nicht weiter....


willybauss

Ich würde erst mal vermuten, dass die 3. Zeile von unten (...userReading...) weg muss. Bei mir dient sie dazu, aus den voc-Werten die voc_avg Werte zu bilden, die dann später gemittelt werden. Du versuchst, wenn ich das richtig interpretiere, den voc-Wert einer Variablen zuzuweisen, die ebenfalls voc heißt. Das schießt sich doch irgendwie ins Knie. Ich hoffe, ich täusche mich da nicht. Ist schon eine Weile her.

Vermutlich ist das der Grund, weshalb dein Screen Dump irgendwas von ReadingsValDoIf stammelt.

Was Du mit dem Attribut "selftrigger all" machst habe ich jetzt weder verstanden noch untersucht. Wird schon seine Richtigkeit haben.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

sasasch

Hat leider nix gebracht.
Zum Grundverständnis nochmal eine Frage:
Wie ist die Programmablauffolge bei  FHem? Wird hier quasi config file zyklisch abgearbeitet ( ähnlich wie bei einer SPS)?
Bzw. wenn hier eine Bedingung mittels DOIF erstellt ist , wird hier die Bedingung voc Wert ständig abgehorcht ohne weiteres Zutun oder wird hierfür ein Event benötigt?


Gesendet von iPhone mit Tapatalk

willybauss

Ist meines Wissens event-gesteuert. Aber für solche Details würde ich Dir Wiki&Co empfehlen.

Ist denn die Fehlermeldung nach wie vor da? Ggf. auch mal neu starten: shutdown-restart im UI eingeben.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

sasasch

Ich hab die Bedingung jetzt in Perl Code geschrieben, jetzt funktioniert es.
define test at +*00:00:20 { if (ReadingsVal("co20","voc", 99) > 800 { fhem (......

Danke und Gruß


Gesendet von iPhone mit Tapatalk

sasasch

Ok jetzt gehts auch mit DOIF. Der Fehler lag an der zusätzlichen Einklammerung außen

danillo

Ich würde ja mit dem Teil gerne die Luft im Wohnzimmer oder Schlafzimmer überwachen. Aber der Raspi mit Fhem steht im Keller. Aber eine freie Netzwerkdose hätte ich zum Beispiel im Schlafzimmer. Könnte das mit so einem teil https://www.amazon.de/LogiLink-Verl%C3%A4ngerungskabel-%C3%BCber-CAT5-Meter/dp/B001TOG6MM funktionieren?

willybauss

Mit sowas ähnlichem (oder demselben?) habe ich das auch gemacht - funktioniert perfekt. Müsste in diesem Thread ein paar Seiten weiter vorne stehen, oder evtl. im MyTHZ-Thread.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

Wolfpunk

Hat jemand eine Idee, warum ich bei FHEM-Start immer diese Meldung im Log habe? Wenn ich den CO20 rausnehme, ist die Meldung weg.

PERL WARNING: Use of uninitialized value in concatenation (.) or string at /usr/lib/arm-linux-gnueabihf/perl5/5.20/Device/USB.pm line 21, <$fh> line 964.

Das ist meine Definition (Linux ist Armbian auf Cubietruck):
define WZ_Sensor_CO20_01 CO20
attr WZ_Sensor_CO20_01 interval 60


Der CO20 ist scheinbar korrekt eingerichtet und funktioniert trotz der Meldung einwandfrei, trotzdem hätte ich die gerne weg.

wthiess

Hallo!

Hab genau dieselbe Meldung. Kommt aber nur einmal beim Start. Aber alles OK.
Ich hab hier im Forum gelesen das manche Meldungen beim Start daher kommen da eventuelle Abhängigkeiten noch nicht gestartet sind. Deshalb ignoriere ich manche Meldungen die nach dem Start stehen.

lg
Wolfgang
Raspberry Pi 3; 8xRelais; Aptodec Nano V3.0 Pro; FS1000a; RF-5V; Hama TS33C; 3x Brennerstuhl FunkSteckdosen; 9x Dooya funk Rollo; KWL Systemair VR400; Thermokon Modbusthermostat; diverse China Modbus Thermostate; 1-wire Bus; Telegram; QuickFhem; FhemNative; Firmata; Alexa ......

testkandidat

Ich habe zwei Sensoren auf Empfehlung hier im Forum bei mouser gekauft.

Zitat von: mtron am 18 Juli 2016, 13:14:54
und noch bei Mouser und Digikey.

http://www.mouser.de/ProductDetail/ams/IAM-USB-MODULE/?qs=sGAEpiMZZMtWSrBd5SaE4F3mqQC4rig8G2mAKiBkEvOUkzs241kPyQ%3d%3d
http://www.digikey.de/product-detail/de/ams/IAM-USB-MODULE/IAM-USB-MODULE-ND/5452366

Habe heute meinen bekommen.

Gruß
Rene

Sie werden von fhem nicht erkannt. Es wird immer disconnected angezeigt. Die udev-Regeln habe ich gesetzt. Danach mal mit airsensor probiert, mit dem Resultat "device not found". Ich habe dann im source code von airsensor die vendor id angepasst. Jetzt erkennt airsensor den stick, liefert aber nur komische Ergebnisse:

2017-02-15 21:05:19, ERROR: Invalid result code:  -2
2017-02-15 21:05:19, VOC: 21546, RESULT: Error value out of range

Hat jemand genau den Stick von Mouser ans Laufen bekommen?

joshi04

Zwar habe ich den Stick selbst nicht mehr, ich würde allerdings einmal probieren, was der Stick mit der Windows-Software an Werten ausgibt und ihn ggf. mit unbelasteter Luft kalibrieren.
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