Hallo,
würde gerne den Mieffaktor mit dem CO-20 (//www.conrad.de/ce/de/product/101316/VOLTCRAFT-CO-20-USB-Luftqualitaetssensor-Raumluftmessgeraet-USB-Stick-zur-Anzeige-der-Luftqualitaet-Auswerte-Software) messen...
Vor fast genau einem Jahr gab es in der alten Mailingliste einen Thread
Link (http://forum.fhem.de/index.php?topic=6875.msg38868#msg38868)
zum CO-20. Würde mich interessieren, was daraus geworden ist...
Da der RasPi ein paar USB-Ports hat, wäre eine Einbindung in FHEM vielleicht gar nicht mal so kompliziert.
Freue mich über Info.
Danke!
Helmut
Hallo,
ich antworte mir jetzt mal selbst...
Im weiteren nenne ich den Sensor iAM (indoor-Air-Monitor).
Um die Eigenheiten des iAM besser zu verstehen, zunächst etwas zum Messprinzip:
Der Sensor ist ein chemischer Gassensor, auch MOS-Sensor (MetalOxidSensor) oder MEMS (Micro-Electromechanical System) genannt, der auf einem ultradünnen, beheizten (ca. 300°C) SiO2 Substrat zwei interdigitale Strukturen besitzt, auf denen eine Zinndioxidpaste aufgetragen ist.
Durch Beaufschlagung mit den oben genannten Gasen kommt es zur Sauerstoffreduktion auf der Oxidoberfläche und in Folge zu Elektroneneinlagerungen, welche den Widerstand reduzieren bzw. den Leitwert erhöhen, was wir als Sensorantwort bekommen.
Der im iAM eingebaute Sensor ist sehr breitbandig und misst im Gegensatz zu reinen CO2-Sensoren grob gesagt alles, das nicht zu guter Luft gehört. Es sind dies im Wesentlichen:
* Kohlenmonoxid,
* VOCs (Volatile Organische Compounds) auch Mischgase genannt. Dazu gehören ca. 6000-10000 verschiedene Verbindungen.
Hier ein Auszug:
* Allgemein Kohlenwasserstoffe
* Aromate
* Aliphate
* Alkohole
* Ketone
* Amine
Dinge die er physikalisch nicht oder nur sehr wenig misst sind z.B. (Auszug):
* Edelgase
* Stickstoff
* Sauerstoff
* CO2
Anmerkung: CO2 misst der Sensor prinzipbedingt nicht direkt (physikalisch), sondern bestimmt dies über den eingebauten Algorithmus, basierend auf der Konzentration der VOCs.
Info gibt es auch auf der Webseite des Herstellers: https://www.appliedsensor.com/products/indoor-air-monitor-iam/ (//www.appliedsensor.com/products/indoor-air-monitor-iam/) und hier: http://www.mikrocontroller.net/articles/IAQ-2000 (//www.mikrocontroller.net/articles/IAQ-2000)
Den iAM gibt es bei verschiedenen Elektronik-Shops für ca. 25 EUR.
Zum Umgang mit dem Sensor:
- Der iAM sollte bei der Erstinbetriebnahme einem 'Burn-In' (!) von mehreren Stunden unterworfen werden. Erst dann sind sinnvolle Werte zu erwarten
- Der iAM benötigt nach dem Einstecken ca. 15min. bis er den ersten Wert liefern kann.
- Die Messung dauert sehr lange. Das kleine C-Programm muss ca. 15sec. warten, bis der iAM Werte zurückliefert. Im ersten Moment dachte ich, dass das Programm ins Nirvana abgetaucht ist, bis der Wert dann angezeigt wurde.
Fazit: Der iAM braucht etwas GEDULD!!!
So, nun zur Umsetzung am RasPi-USB:
Der iAM wird erkannt, wenn es nach dem Einstecken folgende Meldung gibt (dmesg):
Jun 7 16:29:36 RPi-FHEM kernel: [71352.247324] usb 1-1.3: new full-speed USB device number 4 using dwc_otg
Jun 7 16:29:36 RPi-FHEM kernel: [71352.357708] usb 1-1.3: New USB device found, idVendor=03eb, idProduct=2013
Jun 7 16:29:36 RPi-FHEM kernel: [71352.357739] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jun 7 16:29:36 RPi-FHEM kernel: [71352.357756] usb 1-1.3: Product: iAQ Stick
Jun 7 16:29:36 RPi-FHEM kernel: [71352.357769] usb 1-1.3: Manufacturer: AppliedSensor
Jun 7 16:29:37 RPi-FHEM kernel: [71352.370562] hid-generic 0003:03EB:2013.0001: hiddev0,hidraw0: USB HID v1.11 Device [AppliedSensor iAQ Stick] on usb-bcm2708_usb-1.3/input0
Info zur Vorbereitung des Systems (Berechtigungen) und den Sourcecode für das kleine Ausleseprogramm gibt es hier:
http://code.google.com/p/usb-sensors-linux/wiki/Install_AirSensor_Linux (//code.google.com/p/usb-sensors-linux/wiki/Install_AirSensor_Linux)
Das Progi hat eine kleine Hilfe:./airsensor -h
AirSensor [options]
Options:
-d = debug printout
-v = Print VOC value only, nothing returns if value out of range (450-2000)
-o = One value and then exit
-h = Help, this printout
Nach dem Start des Progis (erst mal warten...):
pi@RPi-FHEM /opt/fhem $ time ./airsensor -o
2013-06-12 19:57:33, VOC: 581, RESULT: OK
real 0m13.792s
user 0m0.030s
sys 0m0.090s
pi@RPi-FHEM /opt/fhem $
Wie gesagt: ca. 15sec....
Wg. dieser langen Wartezeit habe ich mich entschieden, das Progi nicht aus FHEM zu starten, sondern bin einen anderen Weg gegangen (wird ähnlich auf der obigen Progi-Quelle so gezeigt):
Cronjob liest regelmäßig die iAM-Werte und übergibt die Werte (siehe Anhang) mit /opt/fhem/fhem.pl localhost:7072 "set $VARNAME $VARVALUE"
In fhem.cfg steht folgendes:
# airquality sensor VOLTCRAFT CO-20
define airquality.livingroom dummy
attr airquality.livingroom loglevel 1
attr airquality.livingroom room Wohnzimmer
define FileLog_airquality.livingroom FileLog ./log/airquality.livingroom-%Y.log airquality.livingroom
attr FileLog_airquality.livingroom logtype airquality:airquality,text
define weblink_airquality.livingroom weblink fileplot FileLog_airquality.livingroom:airquality:CURRENT
attr weblink_airquality.livingroom label "airquality.livingroom Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr weblink_airquality.livingroom room Plots
Mit einem simplen gplot-File gibt es dann schon Werte (siehe Anhang).
Interessant, wie schlecht die Luft wird, wenn die Tochter wieder mal das Popcorn für die GNTM-Session hat anbrennen lassen, weil sie ganz dringend ihren Beziehungsstatus in Facebook aktualisieren musste, oder der "süße" Hund völlig unsüße Blähungen hat. Aber das wusste ich eigentlich auch so...Das ist auch der Grund, warum ich einen reinen CO2-Sensor nicht für sinnvoll halte: der kann solche Sachen nicht messen. Jetzt könnte ich zukünftig automatisch die Lüftungsanlage in den Partymodus schalten. Aber das ist ein anderes Projekt...Apropos: hat schon jemand mit FHEM den LONBUS angesteuert?
Viel Spaß beim Nachmachen!
Helmut.
Edit: Preis ergänzt, diverse Hervorhebungen zum besseren Querlesen.
Hallo Moderator,
wäre vielleicht sinnvoll, den Thread in "Codeschnipsel" zu verschieben?
Gruß
Helmut.
ich habe seit gestern auch einen co20 in betrieb.
mir hat aber die version mit cron job und externem programm nicht so gut gefallen also habe ich mal versucht ein 'echtes' fhem modul draus zu machen. zuerst dachte ich das man das ganze mit blockigCall angehen muss...
nach genauem hinschauen ist mir dann aufgefallen das die hauptsächliche wartezeit in dem externen programm durch ein unnötiges sleep verursacht wird. die zweite bremse war bei jedem starten das usb device neu zu suchen und zu öffnen. genau das lässt sich aber mit einem fhem modul vermeiden. und siehe da... das auslesen der werte ist praktisch 'sofort' möglich.
nach dem anlegen mit
define co20 CO20wird das device alle 5 minuten ausgelesen. das intervall lässt sich mit dem attribut Intervall ändern.
sonstige hinweise:
- das modul ist noch fast ungetestet :)
- abziehen und wieder anstecken geht noch nicht
- es ist Device::USB (z.b. per cpan install) zu installieren. das ist ein wrapper um die libusb. das ganze geht also nur auf systemen die libusb unterstützen. primär ist das linux und unix. auf einem mac geht es leider nicht. das ist ein bekanntes problem. theoretisch müsste es sogar unter windows gehen.
- die 15 minuten warm laufen nach power on werden im modul (noch?) nicht berücksichtigt
- robin (fh168) hat schon eine plotdefinition die die werte in drei farben plottet. ich vermute mal er hängt sie bald hier an :)
gruss
andre
Klingt interessant. Ich liebäugle schon länger mit dem Teil. Hab ich mir jetzt gleich bestellt.
Hallo Andre,
postest Du bitte auch mal Deine Plot-Datei. das mit den eingefärbten Zonen sieht schick aus. Mein CO-20 wird hoffentlich zum nächsten Wochenende da sein, da werde ich dann testen.
Was mich wundert ist, dass bei Deinem Plot bei 1000 anscheinend abgeriegelt wird. Sieht sehr ungewöhnlich aus. Vielleicht gibt es da noch einen Bug?
Gruß
Veit
Hallo,
ich habe den unteren Wert auf 450 und den oberen Wert auf 2000 gesetzt, steht alles in meinem Blog-Beitrag über den Voltcraft CO-20 Sensor.
http://blog.moneybag.de/luftqualitaets-sensor-voltcraft-co-20-ein-erfahrungsbericht/#more-9919
Den Plot reiche ich nach, da soll André noch mal drüberschauen, der ist ziemlich gefrickelt (aber funktioniert).
/robin
Der Voltcraft ist da. Ich habe ihn erstmal an meinem PC warmlaufen lassen.
Jetzt habe ich versucht ihn in FHEM auf der Fritzbox einzurichten. Leider ein Fehlschlag:
Can't locate Device/USB.pm in @INC (@INC contains: /var/InternerSpeicher/fhem/lib/perl5/site_perl/5.12.2/mips-linux /var/InternerSpeicher/fhem/lib/perl5/site_perl/5.12.2/mips-linux /var/InternerSpeicher/fhem/lib/perl5/site_perl/5.12.2 /var/InternerSpeicher/fhem/lib/perl5/5.12.2/mips-linux /var/InternerSpeicher/fhem/lib/perl5/5.12.2/mips-linux /var/InternerSpeicher/fhem/lib/perl5/5.12.2 /opt/lib/perl5/site_perl/5.12.2/mips-linux /opt/lib/perl5/site_perl/5.12.2 /opt/lib/perl5/5.12.2/mips-linux /opt/lib/perl5/5.12.2 . ./FHEM) at ./FHEM/38_CO20.pm line 11.
BEGIN failed--compilation aborted at ./FHEM/38_CO20.pm line 11.
Da fehlen leider der Fritzbox die notwendigen Voraussetzungen.
Gruß,
Veit
Moin Veit,
siehe Wiki
http://www.fhemwiki.de/wiki/Cpan_auf_Fritzbox
Gruß Joachim
in dem fall ist es mit cpan alleine vermutlich nicht getan. das perl modul nutz per native interface die libusb. ohne libusb ist der sensor leider nicht nutzbar weil er sehr low level angesprochen wird.
gruss
andre
Hallo Andre,
danke für den Hinweis mit der libusb. Dann werde ich mal die Hoffnung noch nicht aufgeben, da ich hier eine fertige Fritzbox libusb aus einem anderen Thread (http://forum.fhem.de/index.php/topic,13071.0.html) liegen habe.
Mal schauen, ob ich das doch noch ans Laufen bekomme.
Gruß,
Veit
Moin Veit,
zumindest in meinem Lieblingsimage von Zebradem ist die libusb drinnen.
Gruß Joachim
Zitat von: Joachim am 02 November 2013, 10:31:57
siehe Wiki
http://www.fhemwiki.de/wiki/Cpan_auf_Fritzbox
Hallo Joachim,
danke, aber das meine Fritzbox kein Freetz hat und auch keins bekommen soll, kommt der weg nicht in Frage.
Gruß,
Veit
Dann kann ich Dir nicht weiterhelfen.
Gruß Joachim
Zitat von: justme1968 am 02 November 2013, 10:43:11
in dem fall ist es mit cpan alleine vermutlich nicht getan. das perl modul nutz per native interface die libusb. ohne libusb ist der sensor leider nicht nutzbar weil er sehr low level angesprochen wird.
Ich habe die libusb am laufen. Leider scheitert es daran, dass Device/USB.pm Inline.pm braucht. Und Inline.pm steuert einen transparenten Compile von C-Code. Dazu müsste natürlich ein C-Compiler auf der Box vorhanden sein. :(
War also nichts.
Gruß, Veit
Ich versuche das an meinem Raspberry Pi zum laufen zu kriegen.
Leider wird mir immer gesagt: Cannot load module CO20 .
Kann mir da einer bitte helfen.
MfG Breil
du musst Device::USB perl modul installieren. entweder per 'sudo apt-get install libdevice-usb-perl' oder mit 'cpan install Device::USB.
gruss
andre
Vielen Dank, jetzt steht kein Fehler mehr da.
Aber mir wird als
STATE angezeigt
disconnected angezeigt und Daten sammelt das Ding auch nicht.
Bin erst seit einer Woche begeisterter FHEM Nutzer, habe also noch nicht so richtig nen Plan.
- Ich habe die 38_CO20.pm erstellt
- airquality.gplot erstellt
- define co20 CO20 in fhem.cfg eingefügt
- attr co20 event-min-interval 1 eingetragen um erstmal zum testen schneller veränderungen festzustellen
Meine Eintrag in der fhem.cfg
#######################################################################
#
# CO2 Messung
#
define co20 CO20
attr co20 alias Luftqualität 450 bis 1000 ist gut, 1001 bis 1500 mittelmäßig, darüber schlecht
attr co20 event-min-interval 1
attr co20 room Plots
define FileLog_co20 FileLog ./log/airquality.livingroom-%Y.log airquality.livingroom
attr FileLog_co20 logtype airquality:airquality,text
define weblink_co20 SVG FileLog_co20:airquality:CURRENT
#Muss ich noch was machen oder habe ich einen Denk und/oder Copy&Paste Fehler?
Vielen Dank für eure Mühe.
Gruss Breil
die event-min-interval zeile ist falsch. damit hast du alle events abgeschaltet weil dir syntax nicht stimmt und außerdem kannst du damit das device nicht dazu bringen schneller events zu liefern als es will.
gruss
andre
Hallo!
Ich habe den Stick auch gerade bei Conrad besorgt. Leider habe ich auch den Fehler:
Zitat von: mrbreil am 04 November 2013, 18:35:41
Cannot load module CO20
Da ich fhem aber auf einem Windows-Rechner laufen lasse, kann ich mit
Zitat von: justme1968 am 04 November 2013, 18:40:50
du musst Device::USB perl modul installieren. entweder per 'sudo apt-get install libdevice-usb-perl' oder mit 'cpan install Device::USB.
nichts anfangen.
Hat jemand eine Idee, was für Windows hier fehlt?
Ich benutze ActivePerl 5.16.3 32 bit.
Danke & Gruß
Spiff
da ich (gott sei dank) kein windows verwende kann ich dir hier leider nicht weiter helfen.
aber schau mal hier http://search.cpan.org/~gwadej/Device-USB-0.36/lib/Device/USB.pm#LIMITATIONS (http://search.cpan.org/~gwadej/Device-USB-0.36/lib/Device/USB.pm#LIMITATIONS). da gibt es einen kurzen verweis wie es eventuell unter windows gehen könnte.
gruss
andre
Hi Andre,
danke für den Tipp! Ich habe es nach einer schlaflosen Nacht hinbekommen. Es gab ein paar Hürden, über die ich gestolpert bin, deswegen versuche ich mal, das hier zusammenzufassen. Es kann sein, dass ein paar Schritte überflüssig sind, das kann ich allerdings nicht mehr nachvollziehen, weil ich sehr viel herumprobiert habe.
- libusb-win32 Version 1.2.4.0 herunterladen und entpacken.
http://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.4.0/libusb-win32-bin-1.2.4.0.zip/download
Wichtig: alle neueren Versionen gehen nicht ohne Weiteres, weil die Library von usb.h auf lusb0_usb.h umbenannt wurde und diese dann später von Device::USB nicht gefunden wird. Einfaches Umbenennen geht nicht. - Stick einstecken
- über libusb-win32-bin-1.2.4.0\bin\inf-wizard.exe eine Treiber inf erstellen und gleich installieren ("install now")
Edit: Wenn bei "install now" ein Fehler wegen fehlender administrativen Rechte kommt, funktioniert folgender Weg:
Über den Gerätemanager unter Eingabegeräte (HID) das richtige USB-Eingabegerät identifizieren (z.B. über Eventghost, bei dem ein Event ausgelöst wird, wenn man den Stick aus- und einsteckt, dort ist die VID und PID zu sehen, die man dann im Gerätemanager unter Details -> Eigenschaften -> Hardware-ID herausfinden kann)
Für dieses Gerät den generierten libusb-Treiber überbügeln.
- Gerät "iAQ-Stick" auswählen
- im Gerätemanager gibt es jetzt eine Kategorie "libusb-win32 devices", in der sich der "iAQ-Stick" befindet.
Man kann jetzt schonmal testen, ob alles bis hierher geklappt hat:
libusb-win32-bin-1.2.4.0\bin\x86\testlibusb-win.exe sollte folgendes ausgeben:
DLL version: 1.2.4.0
Driver version: 1.2.4.0
bus/device idVendor/idProduct
bus-0/\\.\libusb0-0001--0x03eb-0x2013 03EB/2013
- Manufacturer : AppliedSensor
- Product : iAQ Stick
bLength: 18
bDescriptorType: 01h
bcdUSB: 0200h
bDeviceClass: 00h
bDeviceSubClass: 00h
bDeviceProtocol: 00h
bMaxPacketSize0: 20h
idVendor: 03EBh
idProduct: 2013h
bcdDevice: 1000h
iManufacturer: 1
iProduct: 2
iSerialNumber: 0
bNumConfigurations: 1
wTotalLength: 41
bNumInterfaces: 1
bConfigurationValue: 1
iConfiguration: 0
bmAttributes: 80h
MaxPower: 50
bInterfaceNumber: 0
bAlternateSetting: 0
bNumEndpoints: 2
bInterfaceClass: 3
bInterfaceSubClass: 0
bInterfaceProtocol: 0
iInterface: 0
bEndpointAddress: 81h
bmAttributes: 03h
wMaxPacketSize: 16
bInterval: 10
bRefresh: 0
bSynchAddress: 0
bEndpointAddress: 02h
bmAttributes: 03h
wMaxPacketSize: 16
bInterval: 10
bRefresh: 0
bSynchAddress: 0Damit sind die Vorbereitungen getroffen und es kann die Perl-Installation angepasst werden:
- MinGW installieren
über cmd: "ppm install MinGW"
C:\>ppm install MinGW
Downloading ActiveState Package Repository packlist...done
Updating ActiveState Package Repository database...done
Syncing site PPM database with .packlists...done
Downloading MinGW-5.1.4.1...done
Downloading dmake-4.11.20080107...done
Unpacking MinGW-5.1.4.1...done
Unpacking dmake-4.11.20080107...done
Generating HTML for MinGW-5.1.4.1...done
Generating HTML for dmake-4.11.20080107...done
Updating files in site area...done
1070 files installed
- Ich habe jetzt inline::makemaker installiert, kann aber sein, dass man das nicht benötigt
- Inline::C installieren
über cmd: "cpan Inline::C"
- Device::USB installieren
Zunächst die Pfade zu libusb angeben (Pfad anpassen!):
über cmd:
"set LIBUSB_INCDIR=\libusb-win32-bin-1.2.4.0\include"
"set LIBUSB_LIBDIR=\libusb-win32-bin-1.2.4.0\lib\gcc"
"cpan Device::USB"
C:\tmp>cpan Device::USB
Set up gcc environment - 3.4.5 (mingw-vista special r3)
CPAN: Term::ANSIColor loaded ok (v4.02)
CPAN: Storable loaded ok (v2.34)
Reading 'C:\Perl\cpan\Metadata'
Database was generated on Tue, 05 Nov 2013 20:53:02 GMT
Running install for module 'Device::USB'
Running make for G/GW/GWADEJ/Device-USB-0.36.tar.gz
CPAN: Digest::SHA loaded ok (v5.84)
CPAN: Compress::Zlib loaded ok (v2.06)
Checksum for C:\Perl\cpan\sources\authors\id\G\GW\GWADEJ\Device-USB-0.36.tar.gz
ok
CPAN: Archive::Tar loaded ok (v1.90)
Device-USB-0.36/
Device-USB-0.36/t/
Device-USB-0.36/t/TestTools.pm
Device-USB-0.36/t/11-usb-device-methods.t
Device-USB-0.36/t/16-usb_dev_interface.t
Device-USB-0.36/t/06-list_devices.t
Device-USB-0.36/t/03-list_busses.t
Device-USB-0.36/t/04-find_device.t
Device-USB-0.36/t/05-find_device_if.t
Device-USB-0.36/t/07-list_devices_if.t
Device-USB-0.36/t/12-constants.t
Device-USB-0.36/t/00-load.t
Device-USB-0.36/t/18-usb_device-configurations.t
Device-USB-0.36/t/15-usb_dev_configuration.t
Device-USB-0.36/t/13-bus_find_device_if.t
Device-USB-0.36/t/17-usb_dev_endpoint.t
Device-USB-0.36/t/01-create-usb.t
Device-USB-0.36/t/02-find_busses_devices.t
Device-USB-0.36/t/14-bus_list_devices_if.t
Device-USB-0.36/t/08-get_busses.t
Device-USB-0.36/t/10-usb-device-accessors.t
Device-USB-0.36/t/09-usb-bus.t
Device-USB-0.36/lib/
Device-USB-0.36/lib/Device/
Device-USB-0.36/lib/Device/USB.pm
Device-USB-0.36/lib/Device/USB/
Device-USB-0.36/lib/Device/USB/DevInterface.pm
Device-USB-0.36/lib/Device/USB/Bus.pm
Device-USB-0.36/lib/Device/USB/DevEndpoint.pm
Device-USB-0.36/lib/Device/USB/FAQ.pod
Device-USB-0.36/lib/Device/USB/Device.pm
Device-USB-0.36/lib/Device/USB/DevConfig.pm
Device-USB-0.36/USB.pm
Device-USB-0.36/README
Device-USB-0.36/META.json
Device-USB-0.36/dump_usb.pl
Device-USB-0.36/Changes
Device-USB-0.36/Makefile.PL
Device-USB-0.36/META.yml
Device-USB-0.36/MANIFEST
Device-USB-0.36/xt/
Device-USB-0.36/xt/boilerplate.t
Device-USB-0.36/xt/pod.t
Device-USB-0.36/xt/pod-coverage.t
Device-USB-0.36/MANIFEST.SKIP
CPAN: File::Temp loaded ok (v0.22)
CPAN: Parse::CPAN::Meta loaded ok (v1.4404)
CPAN: CPAN::Meta loaded ok (v2.120921)
CPAN: Module::CoreList loaded ok (v2.80)
CPAN.pm: Building G/GW/GWADEJ/Device-USB-0.36.tar.gz
Set up gcc environment - 3.4.5 (mingw-vista special r3)
Checking if your kit is complete...
Looks good
Writing Makefile for Device::USB
Writing MYMETA.yml and MYMETA.json
cp USB.pm blib\lib\Device\USB.pm
cp lib/Device/USB/DevEndpoint.pm blib\lib\Device\USB\DevEndpoint.pm
cp lib/Device/USB/Device.pm blib\lib\Device\USB\Device.pm
Skip blib\lib\Device\USB.pm (unchanged)
cp lib/Device/USB/Bus.pm blib\lib\Device\USB\Bus.pm
cp lib/Device/USB/FAQ.pod blib\lib\Device\USB\FAQ.pod
cp lib/Device/USB/DevInterface.pm blib\lib\Device\USB\DevInterface.pm
cp lib/Device/USB/DevConfig.pm blib\lib\Device\USB\DevConfig.pm
cp dump_usb.pl blib\lib\Device\dump_usb.pl
C:\Perl\bin\perl.exe -Mblib -MInline=NOISY,_INSTALL_ -MDevice::USB -e1 0.36 blib
\arch
validate Stage
Starting Build Preprocess Stage
get_maps Stage
Finished Build Preprocess Stage
Starting Build Parse Stage
Finished Build Parse Stage
Starting Build Glue 1 Stage
Finished Build Glue 1 Stage
Starting Build Glue 2 Stage
Finished Build Glue 2 Stage
Starting Build Glue 3 Stage
Finished Build Glue 3 Stage
Starting Build Compile Stage
Starting "perl Makefile.PL" Stage
Set up gcc environment - 3.4.5 (mingw-vista special r3)
Writing Makefile for Device::USB
Writing MYMETA.yml and MYMETA.json
Finished "perl Makefile.PL" Stage
Starting "make" Stage
Set up gcc environment - 3.4.5 (mingw-vista special r3)
C:\Perl\bin\perl.exe C:\Perl\lib\ExtUtils\xsubpp -typemap "C:\Perl\lib\ExtUtils
\typemap" USB.xs > USB.xsc && C:\Perl\bin\perl.exe -MExtUtils::Command -e mv --
USB.xsc USB.c
C:\Perl\site\bin\gcc.exe -c -I"C:/Perl/cpan/build/Device-USB-0.36-UOfRGu" -I"\t
mp\include" -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DPERL_TEXTMODE_SCRIPTS
-DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D_
USE_32BIT_TIME_T -DHASATTRIBUTE -fno-strict-aliasing -mms-bitfields -O2
-DVERSION=\"0.36\" -DXS_VERSION=\"0.36\" "-IC:\Perl\lib\CORE" USB.c
Running Mkbootstrap for Device::USB ()
C:\Perl\bin\perl.exe -MExtUtils::Command -e chmod -- 644 USB.bs
C:\Perl\bin\perl.exe -MExtUtils::Mksymlists \
-e "Mksymlists('NAME'=>\"Device::USB\", 'DLBASE' => 'USB', 'DL_FUNCS' => {
}, 'FUNCLIST' => [], 'IMPORTS' => { }, 'DL_VARS' => []);"
Set up gcc environment - 3.4.5 (mingw-vista special r3)
C:\Perl\site\bin\dlltool.exe --def USB.def --output-exp dll.exp
C:\Perl\site\bin\g++.exe -o blib\arch\auto\Device\USB\USB.dll -Wl,--base-file -W
l,dll.base -mdll -L"C:\Perl\lib\CORE" USB.o C:\Perl\lib\CORE\perl516.lib \tmp\
lib\gcc\libusb.a C:\Perl\site\lib\auto\MinGW\lib\libmsvcrt.a C:\Perl\site\lib\au
to\MinGW\lib\libkernel32.a C:\Perl\site\lib\auto\MinGW\lib\libuser32.a C:\Perl\s
ite\lib\auto\MinGW\lib\libgdi32.a C:\Perl\site\lib\auto\MinGW\lib\libwinspool.a
C:\Perl\site\lib\auto\MinGW\lib\libcomdlg32.a C:\Perl\site\lib\auto\MinGW\lib\li
badvapi32.a C:\Perl\site\lib\auto\MinGW\lib\libshell32.a C:\Perl\site\lib\auto\M
inGW\lib\libole32.a C:\Perl\site\lib\auto\MinGW\lib\liboleaut32.a C:\Perl\site\l
ib\auto\MinGW\lib\libnetapi32.a C:\Perl\site\lib\auto\MinGW\lib\libuuid.a C:\Per
l\site\lib\auto\MinGW\lib\libws2_32.a C:\Perl\site\lib\auto\MinGW\lib\libmpr.a C
:\Perl\site\lib\auto\MinGW\lib\libwinmm.a C:\Perl\site\lib\auto\MinGW\lib\libver
sion.a C:\Perl\site\lib\auto\MinGW\lib\libodbc32.a C:\Perl\site\lib\auto\MinGW\l
ib\libodbccp32.a C:\Perl\site\lib\auto\MinGW\lib\libcomctl32.a C:\Perl\site\lib\
auto\MinGW\lib\libmsvcrt.a dll.exp
C:\Perl\site\bin\dlltool.exe --def USB.def --base-file dll.base --output-exp dll
.exp
C:\Perl\site\bin\g++.exe -o blib\arch\auto\Device\USB\USB.dll -mdll -L"C:\Perl\l
ib\CORE" USB.o C:\Perl\lib\CORE\perl516.lib \tmp\lib\gcc\libusb.a C:\Perl\site
\lib\auto\MinGW\lib\libmsvcrt.a C:\Perl\site\lib\auto\MinGW\lib\libkernel32.a C:
\Perl\site\lib\auto\MinGW\lib\libuser32.a C:\Perl\site\lib\auto\MinGW\lib\libgdi
32.a C:\Perl\site\lib\auto\MinGW\lib\libwinspool.a C:\Perl\site\lib\auto\MinGW\l
ib\libcomdlg32.a C:\Perl\site\lib\auto\MinGW\lib\libadvapi32.a C:\Perl\site\lib\
auto\MinGW\lib\libshell32.a C:\Perl\site\lib\auto\MinGW\lib\libole32.a C:\Perl\s
ite\lib\auto\MinGW\lib\liboleaut32.a C:\Perl\site\lib\auto\MinGW\lib\libnetapi32
.a C:\Perl\site\lib\auto\MinGW\lib\libuuid.a C:\Perl\site\lib\auto\MinGW\lib\lib
ws2_32.a C:\Perl\site\lib\auto\MinGW\lib\libmpr.a C:\Perl\site\lib\auto\MinGW\li
b\libwinmm.a C:\Perl\site\lib\auto\MinGW\lib\libversion.a C:\Perl\site\lib\auto\
MinGW\lib\libodbc32.a C:\Perl\site\lib\auto\MinGW\lib\libodbccp32.a C:\Perl\site
\lib\auto\MinGW\lib\libcomctl32.a C:\Perl\site\lib\auto\MinGW\lib\libmsvcrt.a dl
l.exp
C:\Perl\bin\perl.exe -MExtUtils::Command -e chmod -- 755 blib\arch\auto\Device\U
SB\USB.dll
C:\Perl\bin\perl.exe -MExtUtils::Command -e cp -- USB.bs blib\arch\auto\Device\U
SB\USB.bs
C:\Perl\bin\perl.exe -MExtUtils::Command -e chmod -- 644 blib\arch\auto\Device\U
SB\USB.bs
Finished "make" Stage
Starting "make install" Stage
Files found in blib\arch: installing files in blib\lib into architecture depende
nt library tree
Installing C:\Perl\cpan\build\Device-USB-0.36-UOfRGu\blib\arch\auto\Device\USB\U
SB.bs
Installing C:\Perl\cpan\build\Device-USB-0.36-UOfRGu\blib\arch\auto\Device\USB\U
SB.dll
Finished "make install" Stage
Starting Cleaning Up Stage
Finished Cleaning Up Stage
Finished Build Compile Stage
GWADEJ/Device-USB-0.36.tar.gz
C:\Perl\site\bin\dmake.exe -- OK
CPAN: YAML::XS loaded ok (v0.39)
Running make test
C:\Perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib\lib',
'blib\arch')" t/*.t
t/00-load.t ....................... 1/1 # Testing Device::USB 0.36, Perl 5.01600
3, C:\Perl\bin\perl.exe
t/00-load.t ....................... ok
t/01-create-usb.t ................. ok
t/02-find_busses_devices.t ........ ok
t/03-list_busses.t ................ ok
t/04-find_device.t ................ ok
t/05-find_device_if.t ............. ok
t/06-list_devices.t ............... ok
t/07-list_devices_if.t ............ ok
t/08-get_busses.t ................. ok
t/09-usb-bus.t .................... ok
t/10-usb-device-accessors.t ....... ok
t/11-usb-device-methods.t ......... ok
t/12-constants.t .................. ok
t/13-bus_find_device_if.t ......... ok
t/14-bus_list_devices_if.t ........ ok
t/15-usb_dev_configuration.t ...... skipped: No devices found.
t/16-usb_dev_interface.t .......... skipped: No devices found.
t/17-usb_dev_endpoint.t ........... skipped: No devices found.
t/18-usb_device-configurations.t .. ok
All tests successful.
Files=19, Tests=102, 4 wallclock secs ( 0.03 usr + 0.05 sys = 0.08 CPU)
Result: PASS
GWADEJ/Device-USB-0.36.tar.gz
C:\Perl\site\bin\dmake.exe test -- OK
Running make install
Prepending C:\Perl\cpan\build\Device-USB-0.36-UOfRGu/blib/arch C:\Perl\cpan\buil
d\Device-USB-0.36-UOfRGu/blib/lib to PERL5LIB for 'install'
Files found in blib\arch: installing files in blib\lib into architecture depende
nt library tree
Installing C:\Perl\site\lib\auto\Device\USB\USB.bs
Installing C:\Perl\site\lib\auto\Device\USB\USB.dll
Installing C:\Perl\html\site\lib\Device\dump_usb.html
Installing C:\Perl\html\site\lib\Device\USB.html
Installing C:\Perl\html\site\lib\Device\USB\Bus.html
Installing C:\Perl\html\site\lib\Device\USB\DevConfig.html
Installing C:\Perl\html\site\lib\Device\USB\DevEndpoint.html
Installing C:\Perl\html\site\lib\Device\USB\Device.html
Installing C:\Perl\html\site\lib\Device\USB\DevInterface.html
Installing C:\Perl\html\site\lib\Device\USB\FAQ.html
Installing C:\Perl\site\lib\Device\dump_usb.pl
Installing C:\Perl\site\lib\Device\USB.pm
Installing C:\Perl\site\lib\Device\USB\Bus.pm
Installing C:\Perl\site\lib\Device\USB\DevConfig.pm
Installing C:\Perl\site\lib\Device\USB\DevEndpoint.pm
Installing C:\Perl\site\lib\Device\USB\Device.pm
Installing C:\Perl\site\lib\Device\USB\DevInterface.pm
Installing C:\Perl\site\lib\Device\USB\FAQ.pod
Appending installation info to C:\Perl\lib/perllocal.pod
GWADEJ/Device-USB-0.36.tar.gz
C:\Perl\site\bin\dmake.exe install -- OKJetzt sollte der CO20 in fhem integrierbar sein.
Viele Grüße
Spiff
Quellen:
http://code.google.com/p/perl-device-usb/wiki/StrawberryPerlInstallation
http://www.activestate.com/blog/2009/01/ppm-install-mingw
http://search.cpan.org/~sisyphus/Inline-0.53/
http://search.cpan.org/~gwadej/Device-USB-0.36/
Jetzt, wo alles funktioniert, kommen trotzdem die ersten Probleme:
a) Hin und wieder kommt folgender Fehler und legt den Stick innerhalb fhem lahm (er liefert keine neuen Werte mehr) und fhem muss neu gestartet werden:
Use of uninitialized value in addition (+) at ./FHEM/38_CO20.pm line 169.
b) ich habe verstanden, dass die event-min-interval-Definition sozusagen dem eigentlichen Auslesen nachgeschaltet ist. Aber trotzdem: wie kann man denn den Auslese-Intervall verändern? Man kann ihn ja auch über "get co20 update" anstoßen, einen neuen Wert zu liefern. Lässt sich das vielleicht in das Modul als Einstellung einbringen?
Danke & Grüße
Spiff
du kannst das attribut intervall setzen. in sekunden.
oder disable setzen und per notify ein get update machen wenn du es komplizierter brauchst.
gruss
andre
Hi,
das funktioniert nicht.
define co20 CO20
attr co20 intervall 30
attr co20 room Arbeitszimmer
co20: unknown attribute intervall, choose one of verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings disable:1 event-on-change-reading event-on-update-reading event-min-interval stateFormat devStateIcon devStateStyle fp_Groundfloor icon onDevice sortby webCmd or use attr global userattr intervall
Ich benutze
# $Id: 32_CO20.pm 3931 2013-09-20 10:48:35Z justme1968 $
Gibt es eine neuere Version?
Gruß
Spiff
sehr komisch. in der version oben fehlt die eine zeile mit der attribut definition. der restliche code ist aber da.
aber egal. hier noch mal vollständig.
gruss
andre
Perfekt, danke!
Use of uninitialized value in addition (+) at ./FHEM/38_CO20.pm line 169.
kam bis jetzt auch nicht wieder vor. Vielleicht lag es daran. ::)
Ich habe gestern mal meinen Kamin angeworfen und da sind die Werte komplett durch die Decke gegangen (Maximum um 2800). Da die Werte stundenlang über 2000 lagen kam natürlich nix mehr im Log an (bei -v wirft er ja 0 aus und das wird vom send2fhem.sh ignoriert). Daher habe ich mir die airsensor.c noch mal runtergeladen und auf range <= 3001 gepatcht....ich weiß ist außerhalb des gültigen Messbereichs des Sensors, aber lieber ungenaue Werte als gar keine.
Lange Rede kurzer Sinn: Kann das in die 'offizielle' airsensor.c Version integriert werden? Meinetwegen auch bei -o -v als Ausgabe ' $Wert out of range!'?
Dann zeigt der Graph das richtig an, aber im Log und im dummy Device sieht man dann das es ungenaue Werte sind?
hast du mal das fhem modul oben zum vergleich probiert? da ist die limitierung auf 2000 nicht drin. und es geht eigentlich auch ressourcen schonender mit dem usb bus um weil nicht für jede abfrage das device gesucht und neu geöffnet wird.
gruss
andre
Hatte ich noch nicht eingerichtet, habe ich jetzt aber mal eben gemacht. Sieht danach aus, aber da momentan wieder die Luft gut ist kann ich es nicht zu 100% sagen...
Zitataber da momentan wieder die Luft gut ist
...einfach mal kräftig reinpupsen!
Dieser qualifizierte Beitrag wurde präsentiert von: Spiff.
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
hat noch jemand anders das device offen ?
gruss
andre
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:
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ß
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
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
Hallo Andre,
das kann der atmega32u4 aber von Haus aus (siehe hier (http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=124545&start=0)).
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
Hallo Andre,
ich habe wieder folgenden Fehler:
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:
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.
bitte schau mal ob die angehängte version besser ist.
damit sollte die fehlermeldung weg sein und auch das reconnect besser funktionieren.
gruss
andre
Reconnect funktioniert ohne Probleme.
Bis jetzt keine Fehler zu entdecken.
Melde mich, wenn es etwas Auffälliges gibt.
Vielen Dank!
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.
das attribut wurde bisher nur beim connect ausgewertet.
in der angehängten version sollte es sofort auswirkung haben.
gruss
andre
Hallo Andre,
mit der Version funktioniert's leider gar nicht mehr.
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.
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
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. :o
Danke & Gruß,
Spiff.
hast du mal den wert von hand gesetzt und in fhem ein mal save gesagt? ist der wert dann nach einem neustart auch weg?
das mit dem starten nach dem ersten intervall stimmt. ich hab es korrigiert.
gruss
andre
Hi Andre,
ja, habe gespeichert.
Trotzdem weicht der Wert für interval, der bei Internals steht (300) von dem unter Attributes (bei mir 30) ab, bis ich es wieder manuell setze.
Viele Grüße
Spiff.
fehler gefunden.
das kommt davon man man deutsch und englisch mischt.
gruss
andre
ach ja: zur zeit ist 60 die untergrenze. 30 sollte also eigentlich gar nicht gehen.
gruss
andre
Hi Andre,
funktioniert! Vielen Dank!
Spiff.
Guten Morgen,
eine Frage am Rande: Was macht ihr mit den Werten, bzw. was steuert ihr wann an?
Ist ja eine nette Spielerei, Frage mich nur was man damit sinnvoll machen kann. Habt ihr den Sensor über USB Kabel abgesetzt montiert? Meine FHEM Server Hardware steht zB im Flur, versteckt im Schrank. Da brauch ich nix messen :-)
Guten Start in den Tag, Tobias.
eine Idee ist mit einer winmatic zu lüften. ich hab aber noch keine bezahlbare gefunden.
ansonsten sind die möglichkeiten natürlich wieder endlos. von push nachricht das bewegung fällig ist über automatisch rechner ausschalten bis hin zu 'zeit zum windeln wechseln' nachricht :)
gruss
andre
wie justme1968 schon sagte, da gibt es viele Möglichkeiten.
Ich habe den Stick in einer USB-Dockingstation eingebaut, siehe meinen Blog-Beitrag (Foto):
http://blog.moneybag.de/luftqualitaets-sensor-voltcraft-co-20-ein-erfahrungsbericht/#more-9919
Derzeitig zeigt er bei mir die obligatorische Grafik mit den Abstufungen Luft: gut / mittelmäßig / schlecht. Natürlich kann bei schlechter Luft über notify ein PushOver-Event erzeugt werden, damit man sich mal vom Sofa erhebt und mal kurz durchlüftet. Angedacht ist bei mir auch ein öffnen des Fensters, das Modul ist mir aber auch zu teuer.
Robin
Dann lag ich ja gar nicht falsch mit meiner Vermutung :-)
Der Stick ist also in unmittelbarer Nähe zur Serverhardware, richtig?
Hmmm....
kleines Problem ...
heute ist mein CO-02-Sensor gekommen. Fhem soweit konfiguriert
#### Voltcraft CO-20-Sensor
# eingebunden am 2013-11-26
define co20 CO20
attr co20 interval 120
attr co20 room OG.ArbZ
define FileLog_co20 FileLog /opt/fhem/log/airquality_OG_ArbZ-%Y-%m.log airquality_OG_ArbZ
attr FileLog_co20 logtype airquality:airquality,text
define weblink_co20 SVG FileLog_co20:airquality:CURRENT
aber in der Web-GUI sehe ich nur
Zitat
CFGFN /opt/fhem/FHEM/Sonstiges.cfg
INTERVAL 120
NAME co20
NR 999
NTFY_ORDER 50-co20
STATE waiting
TYPE CO20
manufacturer AppliedSensor
product iAQ Stick
tag
Edit: Mein Problem ist also
STATE waiting. Ich erhalte in Fhem keine Werte.
Mir fehlt zwar noch die
airquality.plot, aber das dürfte/sollte ja nicht der Grund sein.
in der fhem.log steht (nach einem Fhem-Restart):
Zitat
2013.11.26 22:05:59 3: co20: CO20 device found
2013.11.26 22:05:59 3: co20: waiting for CO20 device
2013.11.26 22:05:59 1: usb create starting
2013.11.26 22:05:59 1: usb create end
Installiert ist die
38_CO20.pm vom 25 November 2013, 21:54:34 aus dem Beitrag http://forum.fhem.de/index.php/topic,13166.msg110095.html#msg110095 (http://forum.fhem.de/index.php/topic,13166.msg110095.html#msg110095)
Die Abfrage mittels
# ./airsensor -o
ergibt
Zitat
2013-11-26 22:14:45, VOC: 559, RESULT: OK
Sollte also passen, oder?
Das, was ich noch nicht gemacht habe, ist das für mein OS doch etwas unübliche
shutdown now -r
Irgendwelche Fehler bei mir?
Gruß
Thomas
mir ist nicht ganz klar wann der state 'waiting' kommt bzw. was er bedeutet. zur zeit gibt das modul einfach auf.
versuch bitte mal nach einer weile ein 'modify co20' oder disable und dann disable wieder löschen. dann versucht das modul neu zu verbinden.
du kannst auch mal versuchen in zeile 97 das return raus zu schmeissen und schauen was passiert.
gruss
andre
Hallo Andre,
Entwarnung ... sorry ...
Mein Fehler: Vorletzte Version geladen :(
Nun sehe ich auch die Readings in Fhem:
Zitat
Readings voc 628 2013-11-26 23:00:26
Und der Status ist (nach einem
modify co20):
Zitat
STATE opened
Danke.
Gruß
Thomas
Hallo,
ich habe die Version aus dem Post #47 (ist doch die aktuelle, oder?) und habe das Problem:
2013.11.27 08:44:33 3: co20: CO20 device found
2013.11.27 08:44:33 3: co20: failed to open CO20 device
2013.11.27 08:44:33 3: co20: disconnected
Ich bin mit gerade unsicher ob es überhaupt schon mal ging...das 'alte' Verfahren mit dem cron-job geht auf jeden Fall problemlos.
du hast aber nicht beides gleichzeitig laufen oder?
der sensor kann nur von einer anwendung gelesen werden. wenn airsensor läuft ist das
device belegt.
gruss
andrr
Hallo maddin,
Zitat von: maddin am 27 November 2013, 08:50:42... ich habe die Version aus dem Post #47 (ist doch die aktuelle, oder?)
Wenn du die Version aus Andres Post vom "25 November 2013, 23:40:15" meinst, ja.
Zitat
und habe das Problem:
2013.11.27 08:44:33 3: co20: CO20 device found
2013.11.27 08:44:33 3: co20: failed to open CO20 device
2013.11.27 08:44:33 3: co20: disconnected
Ich bin mit gerade unsicher ob es überhaupt schon mal ging...das 'alte' Verfahren mit dem cron-job geht auf jeden Fall problemlos.
Könnte auch ein Rechte-Problem sein. Der cron-Job lief als root? Fhem als ... ?
Die Vorgehensweise ist ja in dem folgenden Link beschrieben (unten):
http://code.google.com/p/usb-sensors-linux/wiki/Install_AirSensor_Linux (http://code.google.com/p/usb-sensors-linux/wiki/Install_AirSensor_Linux)
Hth
Thomas
Moin,
mist! Ich hätte wetten können das ich die udev Regel schon von Anfang an gesetzt habe. Nachgeholt und nun geht es sogar.
Sorry, wenn man es richtig macht funktioniert es!
Grüße
Hallo Andre,
mir ist aufgefallen, dass der Stick in unregelmäßigen Abständen (meist mehrere Stunden) seinen Dienst versagt.
Im Log steht dann:
2013.11.28 17:23:40 3: co20: disconnected
2013.11.28 17:23:40 1: Including fhem.cfg
2013.11.28 17:23:40 3: Opening CUL1 device com4
2013.11.28 17:23:40 3: Setting CUL1 baudrate to 9600
2013.11.28 17:23:40 3: CUL1 device opened
2013.11.28 17:23:40 3: CUL1: Possible commands: BCFiAZEGMRTVWXefmltux
2013.11.28 17:23:40 1: HMLAN_Parse: HMLAN1 new condition disconnected
2013.11.28 17:23:40 3: Opening HMLAN1 device 192.168.178.150:1000
2013.11.28 17:23:40 3: HMLAN1 device opened
2013.11.28 17:23:40 1: HMLAN_Parse: HMLAN1 new condition init
...
Also es sieht irgendwie so aus, als würde fhem die Config neu einlesen, oder? Abgestürzt ist es aber nicht. Ist das Teil deiner "Reconnect-Prozedur"?
Der Eintrag "co20: disconnected" ist der erste seit ein paar Minuten, es ist also der "Start" des Problems.
Er liefert danach auch automatisch keine Werte mehr. Erst, wenn ich manuell einen anfordere, kommen bis zum nächsten "co20: disconnected" minütlich neue Werte.
Ich habe den Eindruck, dass eine der älteren Versionen stabiler lief, kanne s bei Bedarf gerne nochmal testen.
Hast du eine Idee?
Viele Grüße
Spiff.
das schaut ja komisch aus.
das ist nicht von mir ausgelöst. jedenfalls nicht absichtlich. bist du sicher das da nicht irgendwoher ein rereadconfig dazwischen funkt?
gruss
andre
Oh äh hmm äh. JA. Kann gut sein, dass ich da gerade "intern" die fhem.cfg verändert habe. ::)
Aber wieso verbindet sich der Stick nicht neu?
das finde ich raus :)
Hallo ihr 2 ;)
habe ich gerade auch festgestellt ...
Gestern mal wieder am Produktions-Fhem-System "rum gespielt" (Testsystem habe ich nicht). Erforderte auch (mehrfach) "shutdown restart" von Fhem.
Erst kam (jetzt alles fhem.log):
2013.11.27 20:05:23 3: HKE - 2 Heizkörper von 12 melden Bedarf (> 16 Öffnung)
2013.11.27 20:07:43 3: co20: disconnected
2013.11.27 20:07:43 1: Including /opt/fhem/fhem.cfg
Danach kam erst mal gar nichts mehr bezüglich CO20 im fhem.log. Kurz danach hatte ich den Fhem-Server wegen Kernel-Update neu gestartet, so dass dann wieder Meldungen in fhem.log auftauchten.
2013.11.27 21:46:01 1: Including /opt/fhem/log/fhem.save
2013.11.27 21:46:02 3: co20: CO20 device found
2013.11.27 21:46:02 3: co20: waiting for CO20 device
2013.11.27 21:46:02 1: usb create starting
2013.11.27 21:46:02 1: usb create end
2013.11.27 21:46:02 2: SecurityCheck: WEBphone,WEBtablet ...
Heute Abend bemerkte ich dann den Ausfall des CO20 (Status "waiting"), ein "modify co20" brachte keine Änderung,
2013.11.28 17:59:37 3: co20: disconnected
2013.11.28 17:59:37 3: co20: CO20 device found
2013.11.28 17:59:37 3: co20: waiting for CO20 device
auch ein "shutdown restart" von Fhem nicht. Es erschien sogar im fhem.log die Meldung
2013.11.28 18:06:36 3: co20: filed to find CO20 device
(btw: kleiner Typo drin)
Erst als ich in der Konsole ein
# ./airsensor -o
anstieß, erschien nach einem erneuten "modify co20"
2013.11.28 18:20:08 3: co20: disconnected
2013.11.28 18:20:08 3: co20: CO20 device found
2013.11.28 18:20:08 3: co20: CO20 device opened
und das Logging funktionierte wieder mit Status "opened".
Hth
Thomas
das finde ich raus :)
Danke Andre, dass du da am Ball bist.
ich habe es gerade noch einmal reproduzieren können, da ich nach einem "update" von Fhem ein "shutdown restart" machen musste.
CO-20 danach im state "waiting".
"modify co20" brachte keine Änderung.
Nun ein
# ./airsensor -o
2013-11-28 21:37:49, VOC: 1008, RESULT: OK
Danach wieder ein "modify co20" in Fhem und Status ist opened und der VOC-Wert wird gelesen.
Anderes Thema in Zusammenhang mit dem CO-20:
Bei Conrad ist unter den Kundenbewertungen ( http://bewertungen.conrad.de/6781-de_de/101316/voltcraft-voltcraft-co-20-usb-luftqualitatssensor-raumluftmessgerat-usb-stick-zur-anzeige-der-luftqualitat-auswerte-software-reviews/reviews.htm (http://bewertungen.conrad.de/6781-de_de/101316/voltcraft-voltcraft-co-20-usb-luftqualitatssensor-raumluftmessgerat-usb-stick-zur-anzeige-der-luftqualitat-auswerte-software-reviews/reviews.htm) ) häufiger zu lesen, dass der CO-20 sich nach dem Anstöpseln auf den momentanen "Luftwert" als "guten" Wert kalibrieren würde.
Ist das jetzt nur die ständige Wiederholung eines irgendwo falsch aufgeschnappten "Fakts" oder ist da was dran? Ich erwarte natürlich von einem "Luftgütesensor" für den Preis keine belastbaren Werte, aber für eine grobe Einschätzung der ermittelten Werte wäre es doch hilfreich, die Bedeutung der Werte zumindest näherungsweise verstehen/beurteilen/einordnen zu können. Mein Englisch ist auch nicht so gut, als dass ich da etwas aus den Datenblättern zum Sensor lesen könnte.
Meine persönliche (subjektive) Einschätzung dazu ist zwar eine andere als die in den Bewertungen wieder gegebene, aber ich habe ja keinerlei Vergleich bzw. Langzeiterfahrungen dazu oder Testreihen gemacht.
Gruß
Thomas
Hallo Thomas,
es ist tatsächlich so: der Sensor kalibriert sich neu, wenn man ihn einsteckt.
Ich habe das mal am Log-Graphen gesehen, nachdem hier der Strom kurz weg war. Da ist dann ein richtiger Sprung zu sehen gewesen.
Robin (fh168) hat das in seinem Blog beschrieben - auch, wie man die Kalibrierung fixieren kann. Woher die Informationen dazu kommen, weiß ich allerdings auch nicht, ich vermute von dem Chip-Hersteller AppliedSensor selbst.
http://blog.moneybag.de/luftqualitaets-sensor-voltcraft-co-20-ein-erfahrungsbericht/#more-9919
Siehe "Kalibrierung des Sensors".
Ich hätte auch lieber einen "absoluten" Wert und kann mir auch nicht ganz erklären, wieso die Werte nicht einfach gleich bleiben und bei einer Kalibrierung (z.B. per Knopfdruck) nur ein Offset verwendet wird. Vielleicht ist er damit benutzerfreundlicher und die Sache mit der Ampel funktioniert im Stall genauso gut wie im Reinstraum.
Viele Grüße,
Spiff.
Hallo Spiff,
Zitat von: Spiff am 28 November 2013, 22:10:09... es ist tatsächlich so: ...
Deine Sprünge hatte ich auch schon.
Danke für den Hinweis auf den Blog-Beitrag. Den hatte ich bisher nicht in Gänze gelesen. Bei nächster Gelegenheit also "gute Luft" zum Umstellen auf "nicht immer neu kalibrieren" nutzen. Mal schauen.
Gruß
Thomas
Hi,
nachdem ich ja vor etlicher Zeit das Thema irgendwie angestossen habe, konnte ich mich in letzter Zeit sehr wenig mit fhem beschäftigen. Umso erfreuter bin ich, das es jetzt eine Lösung gibt. Nun habe ich aber eine Frage bezgl. der Verkabelung: Ich möchte in der Küche, Badezimmer, Wohn- und Schlafzimmer CO-20 - Sensoren platzieren. Im Bad sowie in der Küche soll entsprechend der Luftqualität die Abluftanlage gesteuert werden, im Wohn- und Schlafzimmer möchte ich jeweils eine Winmatic ansteuern.
Benötige ich nun je Sensor einen RPi, und wenn ja wie schalte ich die Teile in FHEM zusammen? Oder hat schon jemand eine andere Lösung probiert? Kabel durch mehrere Zimmer verlegen kommt leider nicht in Frage.
Danke!! justme1968
mein neue co20 ist seit Gestern im Einsatz.
einzige Schwierigkeit war zu installieren die fehlende Perl-Module in meine QNAP-FHEM (1 Stunde)
Device::USB
Inline::C
Parse::RecDescent
gruss
immi
Zitat von: Heiermann am 03 Dezember 2013, 17:05:41
Hi,
nachdem ich ja vor etlicher Zeit das Thema irgendwie angestossen habe, konnte ich mich in letzter Zeit sehr wenig mit fhem beschäftigen. Umso erfreuter bin ich, das es jetzt eine Lösung gibt. Nun habe ich aber eine Frage bezgl. der Verkabelung: Ich möchte in der Küche, Badezimmer, Wohn- und Schlafzimmer CO-20 - Sensoren platzieren. Im Bad sowie in der Küche soll entsprechend der Luftqualität die Abluftanlage gesteuert werden, im Wohn- und Schlafzimmer möchte ich jeweils eine Winmatic ansteuern.
Benötige ich nun je Sensor einen RPi, und wenn ja wie schalte ich die Teile in FHEM zusammen? Oder hat schon jemand eine andere Lösung probiert? Kabel durch mehrere Zimmer verlegen kommt leider nicht in Frage.
Wenn du nicht mit irgendwelchen USB over CAT5 Kabel (aber auch da brauchst du halt Kabel) wird leider nichts anderes übrig bleiben als nen RPi in jeden Raum zu hauen. Aber der braucht trotzdem mindestens Stromkabel....
Die kosten typischerweise so viel, dass man auch einen RPi nehmen kann. Außerdem sind sie oft auf Scan, Print und File beschränkt.
und es gibt keinen der wirklich unter linux funktioniert.
ein raspberry pi ist auf jeden fall die bessere wahl. wenn du keine ethernet kabel liegen hast und wlan verwendest kannst du sogar das kleinere modell a verwenden.
gruss
andre
Hi,
besten Dank für Eure Antworten. Das mit ein paar RPIs ist ja nicht wirklich mein Problem. Wie integriere ich die in fhem? Muss ich auf jedem RPI fhem installieren, und dann via fhem2fhem auf den Voltcraft-Sensor zugreifen?
Ich werde auf jeden Fall im Badezimmer und in der Küche WLAN einsetzen.
gruss
Heiko
Ich habe mir jetzt auch gerade einen RPi zugelegt um meinen Voltcraft, der momentan nur am USB-Netzteil läuft, dann mal richtig zu nutzen.
Es gibt ja zwei Möglichkeiten, die beide hier im Thread genannt wurden. Die ursprüngliche Variante war die airsensor als C-Programm laufen zu lassen und remote FHEM zu triggern, Variante 2 ist das Modul, für dass Du dann FHEM installieren musst.
Wenn man nur den Airsensor ranhängen will, ist Variante 1 vermutlich die sinnvollere. Falls Du ihn für weitere Sensoren nutzen willst, wirst Du um FHEM nicht herumkommen.
Gruß
Veit
Hallo Andre,
heue habe ich meinen neuen RasPi mit dem CO20 eingerichtet. Mit dem airsensor-Programm läuft alles stabil, aber das Modul bringt mich zur Verzweiflung. Grundsätzlich landet es nach einem shutdown restart im Status waiting und lässt sich auch durch modify da nicht rausbewegen. Erst nach Abruf eines Wertes mit airsensor kann ich dann mit modify das Device in den Status opened bringen und dann fragt es auch Werte ab.
Ich war ja nicht der Einzige, der dieses Problem zu haben schien. Gibt es da schon eine Lösung?
Ich setze die Version vom 25.11. 23:40 Uhr ein (http://forum.fhem.de/index.php/topic,13166.msg110114.html#msg110114)
RasPi habe ich heute auch auf die neuesten Updates inkl. Kernel 3.10.24+ aktualisiert.
Gruß,
Veit
ich bin noch nicht dazu gekommen. mein problem ist gerade das modul auf einem mac nicht läuft weil die libusb da ein problem hat wenn es schon andere ftdi devices gibt und auf dem system an dem ich ihn einsetzen will ein teil es gerade ein problem mit dem kernel und usb gibt ich aber nicht neu booten kann/will weil der rechner noch etwas tut.
ich schaue es mir aber auf jeden fall noch an.
gruss
andre
Oh, ich sehe gerade, dass der Stick (auf unbestimmte Zeit) ausverkauft ist...
Also der Ditributor-Liste des Herstellers (https://www.appliedsensor.com/pdfs/IAM_flyer.pdf) (untere rechte Ecke) zu beurteilen, dürfte dieser Stick hier (http://shop.sentinel-haus.eu/Wohngesundheit/Raumluftmessung/Der-RaumluftWaechter-inkl-Spezial-Software.html) baugleich mit dem CO-20 von Conrad sein.
Ich habe mal 2 davon bestellt, hab' den CO-20 nämlich auch verpasst.
Gruß, Viktor
Zitat von: justme1968 am 15 Dezember 2013, 18:30:55
ich bin noch nicht dazu gekommen. mein problem ist gerade das modul auf einem mac nicht läuft weil die libusb da ein problem hat wenn es schon andere ftdi devices gibt und auf dem system an dem ich ihn einsetzen will ein teil es gerade ein problem mit dem kernel und usb gibt ich aber nicht neu booten kann/will weil der rechner noch etwas tut.
ich schaue es mir aber auf jeden fall noch an.
gruss
andre
Hallo Andre,
bist du mit dem Lauffähig machen auf einem Mac schon einen schritt weiter gekommen?
auf dem mac bin ich leider nicht weiter gekommen. die libusb funktioniert da nicht richtig. das scannen geht aber das device öffnen nicht. das gleiche problem hindert mich auch die cronos watch zu flashen...
ich habe aber inzwischen noch einen neuen raspberry pi in betrieb genommen. an dem werde ich testen.
gruss
andre
anbei eine version mit der das device öffnen jetzt richtig funktionieren sollte. auch ohne vorher airsensor aufzurufen.
gruss
andre
Hallo Andre,
vielen Dank. Ich bin gerade erst zum Testen gekommen. Sieht alles sehr gut aus. Nach einem shutdown restart purzeln jetzt sofort die Werte rein. Was so 4 Zeilen Code ausmachen können. ;)
Dann werde ich mal als nächstes in Angriff nehmen auf Dblog umzustellen.
Viele Grüße und guten Rutsch ins neue Jahr,
Veit
Ich kann nun bestätigen, dass der "Der RaumluftWächter" von Sentinel Haus Institut baugleich mit dem CO-20 von Conrad ist
und mit dem 38_CO20.pm-Modul funktioniert. Vielen Dank dafür! :)
Hallo zusammen,
habe nun auch zwei Sticks von Sentinel Haus. Habe jedoch auch das Problem, dass zwar der/die Stick/s gefunden wird/werden, aber kein connect statt findet. Im Log steht folgendes:
2014.01.10 09:30:34 3: CO20: CO20 device found
2014.01.10 09:30:34 3: CO20: failed to open CO20 device
2014.01.10 09:30:34 3: CO20: disconnected
DMESG gibt folgendes aus:
[ 2.398684] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[ 2.507286] usb 1-1.2: New USB device found, idVendor=16c0, idProduct=0483
[ 2.509275] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.511144] usb 1-1.2: Product: USB Serial
[ 2.512963] usb 1-1.2: Manufacturer: Teensyduino
[ 2.514756] usb 1-1.2: SerialNumber: 14663
[ 2.598718] usb 1-1.3: new high-speed USB device number 5 using dwc_otg
[ 2.699373] usb 1-1.3: New USB device found, idVendor=1a40, idProduct=0101
[ 2.701258] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 2.703024] usb 1-1.3: Product: USB 2.0 Hub
[ 2.705626] hub 1-1.3:1.0: USB hub found
[ 2.707647] hub 1-1.3:1.0: 4 ports detected
[ 2.988932] usb 1-1.3.4: new high-speed USB device number 6 using dwc_otg
[ 3.089542] usb 1-1.3.4: New USB device found, idVendor=1a40, idProduct=0101
[ 3.091398] usb 1-1.3.4: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 3.093114] usb 1-1.3.4: Product: USB 2.0 Hub
[ 3.100945] hub 1-1.3.4:1.0: USB hub found
[ 3.104251] hub 1-1.3.4:1.0: 4 ports detected
[ 3.388862] usb 1-1.3.4.2: new full-speed USB device number 7 using dwc_otg
[ 3.498473] usb 1-1.3.4.2: New USB device found, idVendor=03eb, idProduct=2013
[ 3.500402] usb 1-1.3.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3.502096] usb 1-1.3.4.2: Product: iAQ Stick
[ 3.503680] usb 1-1.3.4.2: Manufacturer: AppliedSensor
[ 3.535912] hid-generic 0003:03EB:2013.0001: hiddev0,hidraw0: USB HID v1.11 Device [AppliedSensor iAQ Stick] on usb -bcm2708_usb-1.3.4.2/input0
[ 3.618890] usb 1-1.3.4.4: new full-speed USB device number 8 using dwc_otg
[ 3.728486] usb 1-1.3.4.4: New USB device found, idVendor=03eb, idProduct=2013
[ 3.730587] usb 1-1.3.4.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3.732360] usb 1-1.3.4.4: Product: iAQ Stick
[ 3.734027] usb 1-1.3.4.4: Manufacturer: AppliedSensor
[ 3.771518] hid-generic 0003:03EB:2013.0002: hiddev0,hidraw1: USB HID v1.11 Device [AppliedSensor iAQ Stick] on usb -bcm2708_usb-1.3.4.4/input0
[ 3.899596] udevd[154]: starting version 175
[ 4.773861] bcm2708_i2c bcm2708_i2c.0: BSC0 Controller at 0x20205000 (irq 79) (baudrate 100k)
[ 4.866739] bcm2708_i2c bcm2708_i2c.1: BSC1 Controller at 0x20804000 (irq 79) (baudrate 100k)
[ 6.149485] cdc_acm 1-1.2:1.0: This device cannot do calls on its own. It is not a modem.
[ 6.199700] Registered led device: led0
[ 6.396258] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
[ 6.478749] usbcore: registered new interface driver cdc_acm
[ 6.480942] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 11.683799] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 12.158063] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 13.061218] i2c /dev entries driver
[ 13.201394] Driver for 1-wire Dallas network protocol.
[ 21.907637] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
[ 25.081802] CIFS: no cache= option specified, using "cache=loose". This default will change to "cache=strict" in 3. 7.
[ 25.174106] CIFS VFS: default security mechanism requested. The default security mechanism will be upgraded from n tlm to ntlmv2 in kernel release 3.3
[ 41.076812] Adding 102396k swap on /var/swap. Priority:-1 extents:2 across:1886336k SS
[ 49.708672] fuse init (API version 7.20)
[ 183.716845] usb 1-1.3.4.4: USB disconnect, device number 8
Jetzt hab ich in dem Thread hier was von udev-Rechten gelesen. Muss ich da noch irgendwas freigeben oder so? Wenn ja, wie?
Als zweites würde ich gern wissen, ob das Modul beide Sensoren ausliest und wie man die Daten von den beiden Sensoren unterscheidet. Im Device-Eintrag gibt man ja keine Adresse an.
Gruß,
Dennis
EDIT: udev habe ich mittlerweile angepasst und folgende Zeile hinzugefügt:
SUBSYSTEM=="usb", ATTR{idVendor}=="03eb", ATTR{idProduct}=="2013", MODE="0666"
EDIT2:
TOLL! Irgendwie habe ich immer das Talent es ans laufen zu bekommen, nachdem ich gepostet habe. Es läuft jetzt. Ein Neustart des RPi hats dann gebracht. ::)
Bleibt noch die Frage mit dem zweiten Sensor.
das modul sucht den ersten sensor mit der passenden id den es findet. d.h. zur zeit nur ein sensor pro rechner.
wenn du mir mal ein lsusb schickst kann ich mal schauen ob man das einschränken kann.
aber sind zwei sensoren am gleichen rechner nicht eh so dicht beieinander das sie immer das gleiche anzeigen ?
gruss
andre
Hi Andre,
das wäre super, wenn man beide ansprechen könnte. Ich habe die Sensoren nicht am RPi eingesteckt sondern habe mir eine USB-Verlängerung bis zu meiner Lüftungsanlage gelegt. Von dort möchte ich über einen USB-Hub beide Sensoren anschließen. Einer kommt in den Bereich wo frische Außenluft angesaugt wird und der andere kommt in den Abluftbereich, also wo die Luft vom Haus nach draußen geblasen wird.
Bei einer schlechten Raumluftqualität kann ich dann die Anlage hochfahren lassen und wenn draußen einer grillt und der Wind ungünstig steht kann ich die Anlage dann abschalten lassen, bevor es im ganzen Haus nach Grill riecht ;).
Habe das schon mal versucht über einen Teensy zu realisieren, da ich darüber direkt die Anlage ansprechen könnte, aber scheitere da beim Modbus und der Schnittstelle FHEM <-> Teensy, da mir dafür die nötigen Programmierkenntnisse fehlen.
Hier mal der lsusb Auszug:
root@raspberrypi:~# lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 007: ID 03eb:2013 Atmel Corp.
Bus 001 Device 008: ID 03eb:2013 Atmel Corp.
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 16c0:0483 VOTI Teensyduino Serial
Bus 001 Device 005: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 001 Device 006: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Gruß,
Dennis
ich schaue mal wie weit ich das mit dem einen sensor den ich habe nachstellen kann.
bitte mal mal ein 'lsusb -v' am besten in ein file umleiten und das file hier ran hängen.
gruss
andre
ähhhhh, wie leite ich das in ein file um???? ???
EDIT: Google hilft! Hier die Datei.
lsusb -v -d 03eb:2013 >co20-usb.txt
wenn das mit dem umleiten nicht klappt reicht auch lsusb -v -d 03eb:2013das listet nur die co20 devices. das sollte kürzer sein.
gruss
andre
... so, nun nur mit den CO-20 Devices ;)
ok. danke.
leider gibt es ein problem. die dinger haben keine eindeutige serien nummer.
d.h. es bleibt nur sie nach laufender bus und device numemr zu finden. das ist leider nicht unbedingt. sehr zuverlässig.
ich versuch mal was zusammen zu bauen das du probieren kannst. aber ich fürchte eine lösung mit einem extra reaspberri pi oder änlichem wird deutlich sicherer.
gruss
andre
anei eine version bei der du im define bus:device angeben kannst. also bei dir 001:007 und 001:008. ich habe aber keine ahnung wie stabil das funktioniert. auf meinem rasperry pi hat der stick bei jedem aus und ein stecken eine neue device id bekommen.
ich fürchte also das du nicht glücklich wirst wenn du beide sensoren am gleichen rechner laufen lässt.
gruss
andre
SUPER Andre! Klappt auf Anhieb!!!! ;D
nicht zu früh freuen. probier erst mal ein paar fhem neu starts, rechner neu starts und vielleicht auch das abziehen und wieder an stecken.
wenn das auch halbwegs stabil funktioniert würde ich diese version dann einchecken.
gruss
andre
Also FHEM-Neustart hat schon mal funktioniert. Probiere dann noch gerade nen RPi-Neustart und das abziehen und anstecken der Sensoren.
Ok, also:
Restart FHEM : OK
Restart Raspberry : Ok
Abziehen und wieder einstecken eines Sensors : nOk
Beim wiedereinstecken des Sensors wird diesem eine neue ID zugewiesen. Also vorher war er z.B. 001:008 und nun ist er 001:009. Unabhängig davon, ob man den selben USB-Port oder einen anderen verwendet (am USB-Hub).
Korrigiert man man in FHEM im Device die Adresse und klickt auf "modify", verbindet sich das Modul automatisch und ruft wieder Werte ab.
Gruß,
Dennis
EDIT: Für mich reicht das aber. Abgezogen werden die Sensoren eigentlich nicht, da sie ja dann in der Lüftungsanlage verbaut sind. Nach einem Restart vom RPi behält er ja die Adressen. Hmmmmm, da fällt mir ein: Habe ja nur nen "shutdown restart" gemacht. Sollte den RPi auch mal vom Netz trennen und schauen ob er dann neu adressiert. Wenn ja, kann ich trotzdem mit leben. So oft wird der nicht vom Netz getrennt (hängt an nem Hutschienennetzteil) und wenn doch, dann kann ich die Adressen über libusb ja schnell auslesen und das im Device korrigieren. 8)
ja. bitte probier auf jeden fall ein mal das komplette abschalten.
und noch was: der sensor kalibriert sich normalerweise bei jedem einschalten neu auf die luftqualität die gerade da ist.
robin hat oben im thread einen link auf sein blog wo er beschreibt wie man das abstellen kann. das ist vielleicht wichtig wenn du etwas damit steuern willst.
gruss
andre
ich hab das modul eben eingecheckt.
gruss
andre
Habe die Re-Kalibrierung ausgeschaltet. Aber noch ne Bitte an Dich, Andre:
Wie sieht Dein gplot-File aus? Bekomme es einfach nicht hin, dass die drei Farben darzustellen.
Mein FileLog hat folgende Daten:
2014-01-10_21:06:01 CO20_1 voc: 549
2014-01-10_21:06:08 CO20_2 voc: 453
2014-01-10_21:07:01 CO20_1 voc: 548
2014-01-10_21:07:19 CO20_2 voc: 451
2014-01-10_21:08:01 CO20_1 voc: 547
2014-01-10_21:08:19 CO20_2 voc: 454
2014-01-10_21:09:01 CO20_1 voc: 548
2014-01-10_21:09:19 CO20_2 voc: 453
2014-01-10_21:10:01 CO20_1 voc: 545
2014-01-10_21:10:19 CO20_2 voc: 451
2014-01-10_21:11:01 CO20_1 voc: 547
Und noch ne Frage Off-Topic hinterher:
Mittlerweile habe ich mit jeder Menge Hilfe aus dem KNX-User-Forum mein Teensy ans laufen bekommen, welcher meine Lüftungsanlage steuern soll. Ich kann mit Telnet vom Laptop aus auf den Teensy zugreifen (über ser2net auf /dev/ACM0) und dort bitlash-Befehle absetzen. Gibt es ne Möglichkeit von FHEM (bzw. Perl) aus diese Telnet Verbindung herstellen und befehle absetzen und auf Ausgaben am Terminal lauschen kann?
Gruß,
Dennis
ich such das plot file noch mal raus. das war von robin. vielleicht kann er es einfach noch mal posten.
schau dir mal das ECMD device an. das könnte für dich passen. ansonsten gibt es glaube ich noch ein paar andere lösungen. schau mal im wiki.
gruss
andre
Das mit dem ECMD-Device ist ein guter Ansatz! Scheint auch "fast" zu funktionieren. Habe ich parallel eine Telnet-Sitzung offen kann ich sehen, dass der Befehl ankommt und auch eine Antwort in der Telnet-Sitzung erscheint. Aber im Device in FHEM kommt steht unter Readings nur der der von mir abgesetzte Befehl. Hmmm. Aber schon mal nah dran ;-).
Naja, gehört ja eigentlich auch nicht in den Thread hier. Ich werde morgen noch mal was experimentieren und das Wiki durchstöbern. Wenn ich nicht weiterkomme mache ich nen separaten Thread auf.
Einen gute Nacht noch :)
Also mit dem gplot-File bekomme ich das irgendwie nicht hin. hab das jetzt folgendermaßen übernommen:
# Created by FHEM/98_SVG.pm, 2014-01-11 14:32:27
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Luftqualität (außen)'
set ytics
set y2tics
set grid y2tics
set ylabel ""
set y2label "VOC"
set y2range [0:2000]
#FileLog 4:CO20_1.*::$fld[2]>1500?1000:$fld[2]
#FileLog 4:CO20_1.*::$fld[2]>1000?1500:$fld[2]
#FileLog 4:CO20_1.*::
#FileLog 4:CO20_1.*::
#FileLog 4:CO20_1.*::
plot "<IN>" using 1:2 axes x1y2 title '.' ls l1fill lw 0.2 with lines,\
"<IN>" using 1:2 axes x1y2 title '.' ls l4fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title '.' ls l0fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title '.' ls l4fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Luftqualität' ls l1fill lw 1 with lines
Trotzdem bekomme ich keine Farbunterschiede :-[
Hallo Dennis,
du hast Werte um die 500, das Plotfile stellt Werte um 1.000 / 1.500 andersfarbig dar. Sorg mal für richtig schlechte Luft um deinen CO-20, dann wird der schon Farbe bekennen ;)
Oder du spielst etwas (sinngemäß) mit den Werten 1.000 und 1.500 im Plot-File.
Gruß
Thomas
Hi Thomas,
wo habe ich denn Werte von 500? Da sind sogar Spitzen über 2000 und über 5000. Nur für kurze Zeit waren die Werte unter 500! Das ist ja das was mich wundert.
Gruß,
Dennis
Hi,
sry für die Verwirrung. Ich sollte nicht nur deinen Log-File-Auszug lesen, sondern auch Bilder gucken.
Dann muss jemand anders ran.
Gruß
Thomas
Kein Ding! ;)
Habs mittlerweile allein hinbekommen.
Musste die Werte im "Function"-Feld des Plots an die "Column" anpassen:
Original Eintrag von Robin:
#FileLog 3:airquality.livingroom.*::$fld[2]>1000?1000:$fld[2]
So hatte ich es zunächst am laufen (wo das mit den Farben nicht funktionierte:
#FileLog 4:CO20_1.*::$fld[2]>1500?1000:$fld[2]
Und so funktioniert es nun:
#FileLog 4:CO20_1.*::$fld[3]>1500?1000:$fld[3]
Kleine Ursache, große Wirkung ::)
So, ich hab jetzt auch einen :)
Ich habe den Stick heute kalibriert, getestet, nochmal kalibriert und noch ein wenig mehr getestet.
Nach der ersten Kalibrierung (auf dem Balkon) habe ich drinnen zwischen 1000 in einem frisch gelüfteten Raum und 2500 bei Normalluft.
Nach der zweiten Kalibration liege ich jetzt bei 4500 im Normalzustand.
Um auch was von den bunten LEDs zu haben muss ich wohl morgen nochmal einen Versuch wagen.
Wie sehen eigentlich eure Werte in den Settings aus?
Ich vermute, dass die Empfindlichkeit über Reg_Set gesteuert wird - hab aber nicht aufgepasst.
Was mir noch aufgefallen ist ist, dass es in der Software bei 65k einen astreinen Integer Overflow gibt :)
Hat mal jemand probiert was bei FHEM bei solchen Extremwerten rauskommt?
Viele Grüsse, Markus
@Markus:
Das hatte ich auch, wenn ich draußen kalibriere und die "automatische Kalibrierung", welche nach dem einstecken des Sticks erfolgt, ausschalte. Dann gingen die Werte auch sehr hoch. Vermutlich spielen Lufttemperatur und -feuchte eine Rolle bei den Messwerten.
@Andre:
Ein Problem habe ich derzeit noch. Und zwar bekomme ich bei einem der Sensoren nach einigen Stunden einen disconnect, während der andere Sensor weiter ausgelesen wird. Kann das am Modul liegen?
ich will mir das auf jeden fall noch mal anschauen wenn meiner endlich in betrieb geht.
geht die verbindung wieder wenn du ein modify machst ?
gruss
andre
ne, habe es einmal nur mit modify probiert. dann habe ich mal die adresse geändert, modify geklickt und wieder zurück geändert. auch kein erfolg. als letztes habe ich einen shutdown-restart gemacht. trotzdem bleibt es auf disconntected. lsusb gibt immer noch die gleichen adressen aus. gebe ich die adresse meines ersten sensors an, dann geht er auf "open".
ich vermute schon fast, dass sich der eine stick aufhängt oder abschaltet. hmmm :-\
versuch mal ob airsensor noch werte bekommt.
ansonsten schau mal ob dmesg etwas sagt oder ob in /var/log/messages etwas steht.
gruss
andre
hier mal das ergebnis von dmesg. airsensor muss ich erst mal installieren.
Bei mir sieht das leider auch so aus:
2014.01.13 11:34:30 3: co20: read failed
2014.01.13 11:34:30 3: co20: disconnected
2014.01.13 11:34:30 3: co20: CO20 device found
2014.01.13 11:34:30 3: co20: CO20 device opened
2014.01.13 11:34:41 3: co20: read failed
Das passiert meistens schon nach wenigen Readings.
Das Logfile sagt:
Jan 13 15:23:18 fhem kernel: [13934.119676] usb 1-1.2.4: usbfs: USBDEVFS_CONTROL failed cmd perl rqt 128 rq 6 len 255 ret -110
Jan 13 15:23:19 fhem kernel: [13935.119683] usb 1-1.2.4: usbfs: USBDEVFS_CONTROL failed cmd perl rqt 128 rq 6 len 255 ret -110
:-/ Markus
Dann sind wir schon zwei ;)
Die Meldung im Logfile ist bei mir identisch. Heute Nacht ist übrigens der zweite Sensor ausgefallen und steht auf disconnected.
ich vermute es ist ein timing problem und man muss das lesen ein klein wenig verzögern.
ich installiere mal fhem auf einem raspberry pi und probiere es da.
gruss
andre
Die Wahrscheinlichkeit für einen Ausfall scheint höher zu sein, wenn der RasPi unter Last ist, also z.B. FHEM mit longpoll im Browser geöffnet ist. Auch bei mir scheint mit lsusb alles ok zu sein, obwohl FHEM nicht mehr verbindet.
Eventuell hilft eine Art USB Reset?
http://raspberrypi.stackexchange.com/questions/9289/how-can-i-reset-a-usb-device-using-command-line-utilities (http://raspberrypi.stackexchange.com/questions/9289/how-can-i-reset-a-usb-device-using-command-line-utilities)
Mit Reg-Set kann man übrigens bequem manuell "kalibrieren".
Kleinere Werte machen den Stick empfindlicher - ich bin gerade auf 152, damit bekomme ich bei gekipptem Fenster um die 2000, standardmässig knapp unter 4000.
Das mit dem Integer Overflow passiert übrigens im Stick, also kommt nicht auf die Idee damit gefährliches Zeug zu messen ;)
Markus
Nur so als Info und für mich mit Antwortbenachrichtigung.
Dieses Thema interessiert mich auch. Deshalb ist mein nächstes Projekt eine 1wire-Platine zu entwickeln die die Funktiones des Air-Pi´s (http://airpi.es/) ins 1wire Netz bringt.
Hab noch nicht verstanden, was das mit diesem Thread zu tun hat.
@Markus & Dennis: Seid ihr beide noch auf Kernel 3.6.11+? Bei mir läuft es auf dem aktuellen Kernel 3.10.24+ bombenstabil und das jetzt seit Wochen.
Gruß,
Veit
Hallo Veit,
das stimmt. Bei mir ist noch der 3.6.11+ drauf. Wie aktualisiere ich den? mit sudo apt-get update+upgrade?
Gruß
Dennis
EDIT:
Habe jetzt mal auf 3.10.24+ upgedated und nen "shutdown restart" gemacht. Laut "lsusb" wurden die Sensoren nicht gefunden. Trennen der USB-Verbindung und wieder verbinden brachte die Sensoren dann wieder in die lsusb-Ausgabe zurück. Danach fließen auch wieder Daten in FHEM ein (nach anpassen der Adresse). Mal schauen wie lang es hält.
Zitat von: volschin am 15 Januar 2014, 13:50:14
@Markus & Dennis: Seid ihr beide noch auf Kernel 3.6.11+?
3.10.25+
Auch usbreset brachte beim nicht reagierenden Stick am Hub keinen Erfolg mehr.
Jetzt hängt er direkt am Pi, mal sehen was passiert.
Update:
Es ist leider immer noch so dass sich der Stick nach einigen Stunden verabschiedet.
Die einzige mir bekannte Möglichkeit den Stick dann wieder zum Funktionieren zu bringen ist, ihn physisch vom Strom zu trennen.
Nicht gerade ideal für FHEM...
Gruss, Markus
Wie hast Du FHEM installiert? Mit dem 5.5 deb-Paket?
Ja, nutze jetzt allerdings die aktuelle SVN Version.
Der Stick hat sich in FHEM heute Mittag wieder verabschiedet, ist aber mit airsensor noch auslesbar.
Ich habe übrigens die Conrad Version
Update:
airsensor hat für 1 Reading funktioniert, nach FHEM Restart tut sich auch da nichts mehr.
Haus Du einen oder zwei Sensoren? Hast Du den/die Sensor/en direkt am RPi-USB-Port angeschlossen? Ich habe zum Beispiel zwei Stück an einem passiven USB-Hub an meinem RPi angeschlossen. Da der Sensor ja eine Heizung hat, stelle ich mir mittlerweile die Fragen, ob meine Sensoren zusammen zuviel Strom ziehen und daher irgendwann nicht mehr ansprechbar sind.
Ein Sensor, an einem aktiven Hub.
Ich kriege sehr viele Timeouts bei der USB Verbindung...
Ich arbeite gerade an einer neuen Version des Moduls.
Die ersten 24h ohne Totalausfall hat es auf dem Pi bereits geschafft.
Wenn ich das Setzen der Knobs fertig habe, lade ich es hier hoch.
Wenn alles klappt, wird die Windows Software nicht mehr benötigt.
Hat eigentlich schon mal jemand das Offline-Logging an einem Netzteil ausprobiert?
Funktioniert das?
Zitat von: Markus M. am 25 Januar 2014, 18:23:00
Hat eigentlich schon mal jemand das Offline-Logging an einem Netzteil ausprobiert?
Funktioniert das?
Ja, das funktioniert. Ich habe es als mobile Messstation mit einem Ninetec Powertank testweise betrieben. Damit kann man locker 24h Betrieb herstellen.
Gruß
Veit
hast du denn rausgefunden woran das hängen bleiben liegt?
gruss
andre
Vermutlich daran dass sowohl die verwendete Perl-Implementation von USB als auch ganz besonders die USB-Hardware am Raspberry Pi absoluter Mist sind ;)
Wenn ich den Timeout auf 2 Sekunden hochsetze und nicht jedesmal einen Reconnect versuche wenn's nicht gleich klappt, bekomme ich bei 90 Sekunden Intervall die meisten Readings, ohne dass es zum Totalausfall kommt.
Hab mir eben noch einen 2. Stick bei eBay geschossen, die Implementation von mehrerern Geräten über die Seriennummer mache ich als wahrscheinlich auch irgendwann noch :)
2014.01.25 19:39:05 3: co20: CO20 device found
2014.01.25 19:39:05 3: co20: CO20 device opened
2014.01.25 19:39:05 4: @0001;iAQ Stick;C;1.12p5 $Revision: 346 $;;MCU=ATmega32U4;Air Quality Trend;S/N:48303230303415132119;bI=0A;;???
2014.01.25 19:39:05 4: @0002;CO2/VOC level_warn1;ppm;1;0;5000;0;?Ë?;CO2/VOC level_warn2;ppm;1;0;5000;0;?‹?;Reg_Set;;1;0;200;0;?ï?;Reg_P;;1;0;1000;0;???;Reg_I;;1;0;1000;0;??;Reg_D;;1;0;1000;0;???;LogInterval;s;1;0;65535;0;???;ui16StartupBits;;1;0;65535;0;???;;??
2014.01.25 19:39:06 4: @0003;??;0;CO2/VOC level;ppm;1;0;5000;0;0;??;1;Debug;i16;1;0;65535;0;0;??;2;PWM;ui16;1;0;255;0;0;??;3;Rh;ohm;0.01;0;200;0;0;??;4;Rs;ohm;1;0;200000;0;0;????????
2014.01.25 19:39:06 4: @0004;WARMUP;BURN-IN;RESET BASELINE;CALIBRATE HEATER;LOGGING;
wo hast du die Serien nummer gefunden? in der ausgabe von lsusb hatten wir keine entdeckt....
das es am timing liegt hab ich befürchtet. vielleicht hilft es schon wenn man zwischen kommandos schicken und antwort lesen einen tick wartet.
gruss
andre
Die Seriennummer musst du abfragen. Macht die Windows-Software beim Start.
Was das Timing angeht: Die Timeouts bekomme ich nicht mehr beim Lesen sondern beim Schreiben :(
Ich vermute mal dass davon nur der Raspberry Pi betroffenist, der sich schon mit meinem RFXTRX433 nicht sonderlich gut verträgt.
das klingt als hättest du dokumentation gefunden?
dann könnte man das kalibireren und vielleicht auch das auslesen von daten aus dem stand allone mode über fhem machen ?
gruss
andre
Zitat von: Markus M. am 25 Januar 2014, 19:50:34
Vermutlich daran dass sowohl die verwendete Perl-Implementation von USB als auch ganz besonders die USB-Hardware am Raspberry Pi absoluter Mist sind ;)
Wenn ich den Timeout auf 2 Sekunden hochsetze und nicht jedesmal einen Reconnect versuche wenn's nicht gleich klappt, bekomme ich bei 90 Sekunden Intervall die meisten Readings, ohne dass es zum Totalausfall kommt.
Das erklärt vielleicht auch, warum es bei mir stabil läuft. Mir reicht alle 5 min ein Reading und das ist so eingestellt.
Gruß
Veit
Hier mal die neue Version, entstanden nach ein wenig Spielen mit einem USB Analyzer.
Ich habe nahezu keine Ahnung von Linux, Perl oder USB Protokollen, bin aber recht gut darin das zu ignorieren und ausserdem recht hartnäckig ;)
Es gibt 3 neue Attribute:
timeout - USB timeout
retries - Versuche die fehlschlagen dürfen ehe ein Reconnect versucht wird (der meist nichts bringt)
advanced - Alle Settings aus der Windows App (stellt euch darauf ein den Stick neu einzustecken)
Was noch zu tun ist: Erkennung verschiedener Sticks über die S/N, Auslesen der Offline-Daten
Bitte um Rückmeldung was funktioniert, was nicht funktioniert und wann es das tut.
Das Log ist SEHR gesprächig.
Viel Spass!
Markus
Hallo,
falls jemand bei Conrad den Sensor nicht mehr bekommen hat:
Bei Velux gibt es auch einen Raumluftfühler von AppliedSensor für 19,50 Eur zu kaufen.
http://www.velux.de/Privatkunden/Produkte/Integra_System/Produkte/Produktempfehlung/Raumluftfuehler
Meine 3 Sensoren sind heute angekommen ;D
Ich werden mal ausprobieren, ob sie zu dem von Conrad kompatibel sind.
Viele Grüße
Marcus
Hallo,
nur ein kurzes Feedback: Der Stick von Velux ist kompatibel zu dem CO20 von Conrad.
Zumindest konnte ich ihn unter fhem auf einem RasPi einbinden.
Gruß
Marcus
Hi Marcus,
laufen die bei Dir stabil? Bei mir stehen die nach nem Tag auf "disconnected".
Gruß,
Dennis
Habt ihr mal meine Version ausprobiert?
Hat eigentlich irgendjemand auf dem Raspberry Pi keine Probleme oder auf einer anderen Hardwarebasis trotzdem Verbindungsprobleme mit dem Stick?
Ich befürchte langsam, dass es schlicht daran liegt.
Hallo Markus,
ich habe gerade Deine Version ausprobiert. Leider bekomme ich einige Fehler-Meldungen:
Unrecognized escape \8 passed through at ./FHEM/38_CO20.pm line 647, <DATA> line 1.
Useless use of a constant (9100) in void context at ./FHEM/38_CO20.pm line 616, <DATA> line 1.
Use of uninitialized value in pattern match (m//) at ./FHEM/38_CO20.pm line 156.
Hast Du eine Idee woran das liegen könnte?
Marcus
Also mit Deiner Version bleibt FHEM beim Start hängen.
Ja, fhem bleibt bei mir auch beim Start stehen und auf der Konsole gibt es die obigen Meldungen.
Marcus
Zitat von: marcus42 am 04 Februar 2014, 22:17:31
ich habe gerade Deine Version ausprobiert. Leider bekomme ich einige Fehler-Meldungen:
Unrecognized escape \8 passed through at ./FHEM/38_CO20.pm line 647, <DATA> line 1.
Useless use of a constant (9100) in void context at ./FHEM/38_CO20.pm line 616, <DATA> line 1.
Use of uninitialized value in pattern match (m//) at ./FHEM/38_CO20.pm line 156.
Hast Du eine Idee woran das liegen könnte?
Leider Nein, müsste sich mal jemand ansehen der Ahnung von Perl und RegEx hat.
Bei mir läuft sie trotzdem. Der Start dauert aber tatsächlich
sehr lange.
@Dennis:
Ich habe den Sensor erst einen Tag in Betrieb. Solange ich nicht daran rumgefummelt hatte, lief er auch wacker weiter.
Von einer Langzeitstudie kann man also nocht nicht reden. Ich beobachte weiter und melde mich wieder ...
was mir noch aufgefallen ist: Ein Editieren der fhem.cfg führt zu einem Hängen. Ich muss dann fhem neu starten. Wenn es einmal läuft ist aber alles prima.
Marcus
anbei die version von markus mit dem versuch die warnungen alle raus zu machen.
gruss
andre
@justme1968:
Mit Deiner Version startet fhem schon mal wieder und es werden Werte ausgelesen ... :D
Ich bekomme mit dieser Version und mit der vorherigen Version diese Warning:
Use of uninitialized value in pattern match (m//) at ./FHEM/38_CO20.pm line 84.
Marcus
PS: Die neuen 'Features' von Markus habe ich noch nicht ausprobiert. Ich melde mich ...
Zitat von: justme1968 am 04 Februar 2014, 22:40:15
anbei die version von markus mit dem versuch die warnungen alle raus zu machen.
Falsche Datei?
Das war irgendwie deine aktuelle SVN Version ohne meine Änderungen
Mh, ich sehe die neuen Attribute in der Version auch leider nicht ...
ich hatte die falsche version hoch geladen. hab es oben ausgetauscht. jetzt stimmt zumindest das.
das langsame starten kommt vermutlich von den sleep die eingebaut sind.
gruss
andre
Bei mir startet fhem leider auch nach 5min nicht mir dieser Version :-\
Hallo an alle,
ein Neustart von fhem ist mit dem CO20 Stick nicht mehr möglich.
Nach Abziehen des Sticks, Neustart von Fhem, Stick wieder einstecken,
läuft alles wieder.
Mit welcher Version?
Ich habe die Reihenfolge auf 58_CO20 geändert und es klappt.
ich finde nur eine 38_CO20
Hallo zusammen,
ich teste gerade noch die Version von Markus vom Post # 135 (1 Co-20 an einem Hub am Raspberry Pi).
Damit läuft es stabil, also ich kriege kontinuierlich Werte (mindestens seit 2 Tagen). Auch Neustarts von fhem funktionieren mit eingestecktem Stick (mit der älteren Version hatte ich Probleme mit dem fhem-Start bei eingestecktem Stick).
Reconnect nach Abziehen des Sticks war glaub noch problematisch, muss ich aber noch testen.
Ne, also bei mir funktioniert es nicht. Weder mir der Version aus Post #135, noch die aus Post #145. Habe auch die Änderung von 38_CO20.pm auf 58_CO20.pm versucht. Ebenfalls erfolglos. FHEM startet nur bis zum öffnen des ersten Sensors und bleibt dann stehen. Ein beenden oder neustarten von FHEM über Telnet (./fhem restart) ist nicht möglich. Auch über "sudo shutdown -r now" funktioniert nicht. Ein Neustart ist nur durch Trennung der Stromversorgung zu erreichen. ???
Zitat von: Dennis D. am 05 Februar 2014, 18:31:48
Ne, also bei mir funktioniert es nicht.
Hmm...
Ich hab das Ding auch an einem Hub.
Was sagt das Log (CO20) auf Level 5?
Starte FHEM mal ohne Stick und setz es hoch.
hier mal ein Auszug aus meinem Log (immer noch Version von Post #135), als offenbar ein disconnect passiert ist (Einstellung 3 retries):
2014.02.06 14:11:26 4: CO20: write error -110/-110 (1)
2014.02.06 14:11:59 4: CO20: write error -110/-110 (2)
2014.02.06 14:12:29 4: CO20: write error -110/-110 (3)
2014.02.06 14:12:29 3: CO20: release
2014.02.06 14:12:29 3: CO20: disconnected
2014.02.06 14:12:29 3: CO20: CO20 device found
2014.02.06 14:12:29 3: CO20: CO20 device opened
2014.02.06 14:13:29 4: CO20: write error -110/-110 (1)
2014.02.06 14:13:59 4: CO20: write error -110/-110 (2)
2014.02.06 14:14:29 4: CO20 got @g�w�9i/ / 32 / 64
Also write error passiert regelmäßig, der disconnect passiert alle paar Stunden, aber immer gleich wieder reconnect. Wie auch immer kommen kontinuierlich Daten....
@ Dennis: Mit Deiner udev rule ist alles OK bei Dir? Das war bei mir glaub mal die Ursache, warum fhem nicht startete
Hallo, hat jemand eine Ahnung wo es den Sensor noch gibt? Suche mich seit einer Stunde wund.
VG
Frank
Schau mal unter dem Link den ich schon weiter oben mal reingestellt hatte:
http://www.velux.de/Privatkunden/Produkte/Integra_System/Produkte/Produktempfehlung/Raumluftfuehler
Gruß
Marcus
Gesendet von meinem iPhone mit Tapatalk
Hallo Frank,
wund Suchen hilft nicht,aber das Forum Lesen. Im Post Antwort#7 : http://blog.moneybag.de/luftqualitaets-sensor-voltcraft-co-20-ein-erfahrungsbericht/#more-9919 von dort kommst Du auf: http://www.velux.de/Privatkunden/Produkte/Integra_System/Produkte/Produktempfehlung/Raumluftfuehler
Hab den heute gerade per Rechnung (nach sofortiger Lieferung) bezahlt mit Skonto 19.11 EUR
Hallo,
ich habe meinen Sensor heute von Velux bekommen. Ich habe den Sensor exakt nach dieser Anleitung installiert:
https://code.google.com/p/usb-sensors-linux/wiki/Install_AirSensor_Linux (https://code.google.com/p/usb-sensors-linux/wiki/Install_AirSensor_Linux)
Und bekomme auch entsprechende Werte ausgegeben:
pi@FHEM:/home/pi/airsensor# ./airsensor -o
2014-02-11 16:27:22, VOC: 793, RESULT: OK
Der Sensor wird auch im Fhem Log angezeigt und erkannt:
2014.02.11 16:19:31 3: co20: CO20 device found
2014.02.11 16:19:31 3: co20: CO20 device opened
Die Dateien "38_CO20.pm" und "airquality.gplot" habe ich in entsprechende Verzeichnisse eingefügt.
Leider kann ich den Sensor nicht in FHEM einbinden. Sobald ich diesen mit define co20 CO20 einbinden möchte, beginnt Fhem zu laden und bricht dann komplett zusammen. Nach einem Neustart ist dann wieder alles beim alten und der Sensor fehlt natürlich.
Mache ich irgendetwas falsch?
Zitat von: justme1968 am 04 November 2013, 18:40:50
du musst Device::USB perl modul installieren. entweder per 'sudo apt-get install libdevice-usb-perl' oder mit 'cpan install Device::USB.
gruss
andre
danach habe ich es bei mir gemacht, cpan hat ewig gedauert aber danach läuft es seither absolut prima
Wenn ich "cpan install Device::USB" ausführe erhalte ich diese Ausgabe:
pi@FHEM ~ $ cpan install Device::USB
Going to read '/home/pi/.cpan/Metadata'
Database was generated on Tue, 11 Feb 2014 03:29:02 GMT
Device::USB is up to date (0.36).
Das definieren des Sensors mit "define co20 CO20" endet wieder mit einem Abstürtz von Fhem. :(
Hallo,
ich möchte nur mal wieder ein Feedback geben, nachdem ich den Velux Stick schon einige Tage im Einsatz habe:
Mittlerweile habe ich den Stick, wie schon hier empfohlen wurde, an einen aktiven USB-Hub angeschlossen.
Seit dem läuft er endlich ohne Abstürze/Hänger. Allerdings verwende ich das C-Programm als externen Datenlieferanten am RasPi im Wohnzimmer und nicht das mitgelieferte FHEM Modul. Der RasPi sendet dann die Daten über Telnet an meine FritzBox mit FHEM.
Damit steuere ich nun seit ca. 10Tagen meine Lüftungsanlage. Diese lässt sich in 10 Stufen schalten, so dass ich nun eine prima bedarfsabhängige Steuerung habe. Bei unter 500ppm schaltet sich die Lüftung auf Minimalbetrieb. Darüber habe ich Intervalle in ppm definiert, die ich auf die einzelnen Lüftungsstufen abgebildet habe.
Ein Notify nimmt den Wert entgegen und setzt die neue Lüftungsstufe. Mit einem at +15min habe ich einen Wächter definiert, der die Automatik deaktiviert, falls länger als 15min keine neuen werte ankommen.
Als nächstes Projekt möchte ich einen weiteren Stick im Schlafzimmer unterbringen und ihn per Ethernet-USB-Extender an den Raspi anbinden. Damit der Raspi dann mit 2 unterschiedlichen Sticks am Gerät umgehen kann, habe ich das C-Programm mit einem dirty Hack so modifiziert, dass ich ihm eine lfd. Nummer für den Stick (z.B. -n1 -n2) mitgeben kann.
Gruß
Marcus
Und mal wieder ein Update:
Gestern kam der Logilink USB Extender an. Habe ich abends angebunden und die Verbindung klappt tatsächlich. Vom Wohnzimmer (Aufstellort RasPi) in den Anschlussraum und von dort ins Schlafzimmer gepatcht.
Sobald der Anwesenheit-Status auf 'schlafen' gesetzt wird, ist der Raumluftfühler im Schlafzimmer die führende Messgröße für den Volumenstrom der KWL.
Erste Erkenntnis: Der Grund-Volumenstrom der KWL im Schlafzimmer muss definitiv noch erhöht werden. 2 Erwachsene und im Verlauf der Nacht noch 2 dazukommende Kleinkinder ist zu viel für diesen Raum ;-)
Übrigens kostete der USB Extender nur 12,x Euro. Also definitiv günstiger als ein eigenständiger RasPi. Treiber waren nicht nötig. Nur Einstecken und klappt.
Trotzdem eine kleine Anmerkung/Einschränkung: ich verwende kurze CAT 6 Patchkabel zum Anschluss. Ein Versuch mit einem normal langen CAT 5 Kabel im Schlafzimmer brachte keine Verbindung.
Gruß
Marcus
Hi wenn ich versuche das Modul zu laden kommt nur: Cannot load module CO20
Ein Velux-Stick ist angesteckt
usb 1-1.3: new full speed USB device using orion-ehci and address 21
generic-usb 0003:03EB:2013.0002: hiddev0: USB HID v1.11 Device [AppliedSensor iAQ Stick] on usb-orion-ehci.0-1.3/input0
du musst das perl usb modul installieren. siehe weiter oben im thread.
was steht im log file?
gruss
andre
Danke. Ich suche mal. Kannst du bitte in der commandref noch einen Hinweis dazu rein setzen? Ich zb installiere nicht über cpaN sondern Debian pakete . Muss mal gucken wie das heißt.
Gruss
Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk
das steht doch schon im der commandref:
Note:
Device::USB hast to be installed on the FHEM host.
gruss
andre
Vieleicht könntest du ja auch noch das deb-Modul dort einstellen:
Zitatsudo apt-get install libdevice-usb-perl' oder mit 'cpan install Device::USB
Edit: für squeeze gibts das Paket leider nicht :(
Und Installtion per cpan will nicht :(
[...]
CPAN: File::Temp loaded ok (v0.22)
CPAN.pm: Going to build G/GW/GWADEJ/Device-USB-0.36.tar.gz
Can't locate Inline/MakeMaker.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at Makefile.PL line 3.
BEGIN failed--compilation aborted at Makefile.PL line 3.
Warning: No success on command[/usr/bin/perl Makefile.PL INSTALLDIRS=site]
Warning (usually harmless): 'YAML' not installed, will not store persistent state
GWADEJ/Device-USB-0.36.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- NOT OK
Running make test
Make had some problems, won't test
Running make install
Make had some problems, won't install
Could not read '/root/.cpan/build/Device-USB-0.36-WFV_Zc/META.yml'. Falling back to other methods to determine prerequisites
ich hab es in der doku ergänzt.
versuch mal zuerstcpan install Inline::MakeMaker
gruss
andre
Bin ein Stück weiter..... Konnte nun Device::USB installieren.
Aber:
Use of uninitialized value in pattern match (m//) at ./FHEM/38_CO20.pm line 84, <DATA> line 1.
2014.03.06 14:55:12 3: CO20: CO20 device found
2014.03.06 14:55:12 3: CO20: failed to open CO20 device
2014.03.06 14:55:12 3: CO20: disconnected
du musst die Rechte anpassen. schau mal weiter oben im thread.
gruss
andre
Ziemlich groß schon der Thread. Ein fall für die Commandref??
http://code.google.com/p/usb-sensors-linux/wiki/Install_AirSensor_Linux
Edit: jetzt läuft es. Muss jetzt noch referenzwerte rausbekommen . Aktuell habe ich 455. Ist die Einheit ppm??
hab die doku noch mal ergänzt.
die einheit sollte ppm sein. aber ich glaube nur dann wirklich wenn du den sensor kalibriert hast: http://blog.moneybag.de/luftqualitaets-sensor-voltcraft-co-20-ein-erfahrungsbericht/#more-9919 (http://blog.moneybag.de/luftqualitaets-sensor-voltcraft-co-20-ein-erfahrungsbericht/#more-9919) unter kalibireren des sensors.
gruss
andre
Zitat von: Tobias am 06 März 2014, 16:00:13
Muss jetzt noch referenzwerte rausbekommen . Aktuell habe ich 455. Ist die Einheit ppm??
ppm - allerdings musst du das Initialisierungsflag rausnehmen um auch nach einer Stromunterbrechung einigermassen konsistente Werte zu bekommen.
Ich habe den Velux-Sensor erhalten und er loggt brav Werte in die DB.
Dennoch erhalte ich folgende Fehlermeldungen..... hab ich was falsch gemacht? ;-)
EDIT: FEHLER von mir, habe auf die Ausgabe von "airsensor" geschaut, nicht auf das Log. War das falsche Putty-fenster ;-)
2014-03-12 18:42:33, VOC: 21546, RESULT: Error value out of range
2014-03-12 18:42:44, ERROR: Invalid result code: -16
2014-03-12 18:42:44, VOC: 21546, RESULT: Error value out of range
2014-03-12 18:42:55, ERROR: Invalid result code: -16
2014-03-12 18:42:55, VOC: 21546, RESULT: Error value out of range
2014-03-12 18:43:06, ERROR: Invalid result code: -16
2014-03-12 18:43:06, VOC: 21546, RESULT: Error value out of range
2014-03-12 18:43:17, ERROR: Invalid result code: -16
2014-03-12 18:43:17, VOC: 21546, RESULT: Error value out of range
2014-03-12 18:43:28, ERROR: Invalid result code: -16
2014-03-12 18:43:28, VOC: 21546, RESULT: Error value out of range
2014-03-12 18:43:39, ERROR: Invalid result code: -16
2014-03-12 18:43:39, VOC: 21546, RESULT: Error value out of range
2014-03-12 18:43:50, ERROR: Invalid result code: -16
2014-03-12 18:43:50, VOC: 21546, RESULT: Error value out of range
2014-03-12 18:44:01, ERROR: Invalid result code: -16
2014-03-12 18:44:01, VOC: 21546, RESULT: Error value out of range
2014-03-12 18:44:12, ERROR: Invalid result code: -16
2014-03-12 18:44:12, VOC: 21546, RESULT: Error value out of range
2014-03-12 18:44:23, ERROR: Invalid result code: -16
2014-03-12 18:44:23, VOC: 21546, RESULT: Error value out of range
2014-03-12 18:44:34, ERROR: Invalid result code: -16
2014-03-12 18:44:34, VOC: 21546, RESULT: Error value out of range
2014-03-12 18:44:45, ERROR: Invalid result code: -16
2014-03-12 18:44:45, VOC: 21546, RESULT: Error value out of range
Bei einem CO2 Wert von 20000 ppm würde meine Konzentration auch leiden. Verschaff Dir mal Frischluft! ;)
in fhem zeigt er schöne werte an und funktioniert, warum also das commandlinetool solch einen Fehler meldet, ist mir unklar...
Hallo zusammen,
ich bin ein Anfänger also steinigt mich bitte nicht gleich. Ich habe heute meinen Velux Sensor bekommen und gleich mal fleißig losgelegt.
Auf meinem Pi habe ich per apt-get die Perl-USB-Komponente installiert und dann gleich mal die "PM"-Datei unter /opt/fhem/FHEM abgelegt. Danach habe ich den Pi rebootet und in Fhem folgendes eingetragen (Achtung kopiert aus dem Thread ;) ):
define co20 CO20
attr co20 interval 120
attr co20 room Wohnzimmer
define FileLog_co20 FileLog /opt/fhem/log/airquality_Wohnzimmer-%Y-%m.log airquality_Wohnzimmer
attr FileLog_co20 room Wohnzimmer
attr FileLog_co20 logtype airquality:airquality,text
define weblink_co20 SVG FileLog_co20:airquality:CURRENT
attr weblink_co20 room Wohnzimmer
Soweit so gut. Mein Objekt co20 wurde angelegt, aber ich finde im Fhem Log folgende einträge:
2014.03.18 18:25:46 3: co20: CO20 device found
2014.03.18 18:25:46 1: co20: failed to open CO20 device
2014.03.18 18:25:46 3: co20: disconnected
2014.03.18 18:25:52 2: co20: no device
2014.03.18 18:25:52 3: co20: CO20 device found
2014.03.18 18:25:52 1: co20: failed to open CO20 device
2014.03.18 18:25:52 3: co20: disconnected
Komisch das er das ding nicht aufmachen kann, da der Stick korrekt "grün" anzeigt.
Was muss ich noch machen damit alles läuft? Auserdem, wie kann ich bei einem Schwellwert einen notify ausführen? (Ich würde gerne ne Mail verschicken sobald die CO-Sättigung einen kritischen Wert erreicht)
Danke & Schönen Gruß (ich werde mal weiter tüfteln)
du hast vermutlich das rechte problem. schau ein paar posts über deinem.
gruss
andre
mhm nachdem ich nun die Rechte anscheinend behoben habe, startet mein FHEM nicht mehr. Die letzten Zeilen im Log:
2014.03.18 19:34:01 3: WEB: port 8083 opened
2014.03.18 19:34:01 3: WEBphone: port 8084 opened
2014.03.18 19:34:01 3: WEBtablet: port 8085 opened
2014.03.18 19:34:05 1: Including ./log/fhem.save
2014.03.18 19:34:06 3: co20: CO20 device found
2014.03.18 19:34:06 3: co20: CO20 device opened
noch eine Idee?
OK MEA CULPA! Ich hätte einfach warten sollen. Aber ist das normal, dass das ding einige Sekunden benötigt?
Hallo anscheinend bin ich wieder mal "zu dumm". Ich habe folgendes in meiner config definiert:
define co20 CO20
attr co20 interval 120
attr co20 room Wohnzimmer
define FileLog_co20 FileLog ./log/airquality.Wohnzimmer-%Y-%m.log co2
attr FileLog_co20 logtype text
und irgendwie logt der co20 nicht in das logfile. Habe ich hier irgendwo einen denkfehler?
ist es das?
Zitat von: MichaelH am 19 März 2014, 18:39:01
Hallo anscheinend bin ich wieder mal "zu dumm". Ich habe folgendes in meiner config definiert:
define co20 CO20
attr co20 interval 120
attr co20 room Wohnzimmer
define FileLog_co20 FileLog ./log/airquality.Wohnzimmer-%Y-%m.log co20
attr FileLog_co20 logtype text
und irgendwie logt der co20 nicht in das logfile. Habe ich hier irgendwo einen denkfehler?
OH MY GODNESS!!!! Den Wald vor lauter Bäume nicht gesehen........
Sorry Sorry Sorry! Und danke an Markus, ich suche schon wirklich seit ein paar Stunden und hab DAS nicht gesehen :(
Hallo,
nochmal zurück zu den farbigen Plots. Ich habe dies mit DbLog probiert und es hat zunächst nicht geklappt. Falls es jemand auch mit DbLog machen möchte; die Lösung ist:
$val=($val>1500?1000:$val)
statt $fld[3]>1500?1000:$fld[3]
Viele Grüße
Niko
Zitat von: Niko am 20 März 2014, 14:30:30
nochmal zurück zu den farbigen Plots...
Danke!!!Damit hab ich's endlich hinbekommen.
Falls noch wer daran verzweifelt, hier ist eine "Vorlage"
Hallo,
ich bin mal wieder anscheinend zu doof. Hat mal jemand ein dreifarbiges gplot file? Also ohne DBLog?
[€dit]
Für alle die es interessiert und genauso ein Anfanger sind wie meine wenigkeit:
Bei allen drei Werten ist die Column 4 und der Label "." (damit es überhaupt akzeptiert wird)
$fld[3]>1000?1000:$fld[3] l1fill
$fld[3]>1500?1500:$fld[3] l4fill
l0fill
[/€dit]
Hi Markus,
Kannst du bitte zu deinem Screenshot das fertige gplotFile anhängen?
co20.gplot (DbLog)
# Created by FHEM/98_SVG.pm, 2014-03-20 15:12:35
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
set ytics "good" 750, "ok" 1250, "bad" 1750
set y2tics "" 1000,"" 1500
set grid y2tics
set ylabel ""
set y2label "Air quality (ppm)"
set yrange [450:2000]
set y2range [450:2000]
#DbLog co20:voc:::
#DbLog co20:voc:::$val=($val>1000?1000:$val)
#DbLog co20:voc:::$val=($val>1500?1500:$val)
#DbLog co20:voc:::$val=($val>2000?2000:$val)
#DbLog co20:voc:::
plot "<IN>" using 1:2 axes x1y2 title 'Air quality (ppm)' ls l5 lw 0.2 with lines,\
"<IN>" using 1:2 axes x1y2 title ' ' ls l1fill lw 0.2 with lines,\
"<IN>" using 1:2 axes x1y2 title ' ' ls l4fill lw 0.2 with lines,\
"<IN>" using 1:2 axes x1y2 title ' ' ls l0fill lw 0.2 with lines,\
"<IN>" using 1:2 axes x1y2 title ' ' ls l3fill lw 0.2 with lines
Hallo!
Bei mir kommt auch immer dieser Fehler:
Use of uninitialized value in pattern match (m//) at ./FHEM/38_CO20.pm line 84.
Der Stick funktionert trotzdem tadellos.
Was könnte das sein?
Gruß
Spiff
Hallo alle Miteinander.
Hat jemand den C02-Stick schon mal unter OpenWRT zum laufen gebracht ?
-> ATTITUDE ADJUSTMENT (12.09, r36088)
Weil hier hab ich weder das Perl-Usb Packet finden können,
noch scheint unter dem Ding das Perl-Cpan Modul vernünftig zu laufen.
-> perl -MCPAN -e shell
liefert
Untagged opnames: ne i_le sc ... <snip>
Can't locate object method "maybe_command" via package "MM" at /usr/lib/perl5/5.10/CPAN.pm line 1140.
Compilation failed in require.
BEGIN failed--compilation aborted.
Gruß
Marco
Hallo Zusammen,
kurze Rückmeldung von meinem Versuch ohne aktiven Hub am RasPi:
Die ausgelesenen Werte schwingen in sehr kurzen Abständen zwischen 450 und 7105 incl. LED-Farbwechsel am Stick.
Da die LED am Stick ja autark funktioniert, vermute ich, es liegt an der Stromversorgung. Aktiver Hub ist bestellt.
Ich poste nochmal, wenn es das war.
Einrichtung lief übrigens problemlos entsprechend commandref. Danke schon einmal. Super Sache!
Schöne Grüße,
John
Habe meinem Velux Stick heute bekommen.
Problem am Raspberry: Erst nach um schalten auf dwc_otg.speed=0 (USB 2.0) funktioniert der Stick tadellos.
Auf dwc_otg.speed=1 (USB 1.1) spackt er nur rum (disconnect, etc.).
Auf USB 2.0 bringt mein HM-USB-CFG allerdings regelmäßig Timing-Probleme.
Hat jemand ne Lösung?
Best regards
Daniel
Nachtrag:
Zitat von: joshi04 am 05 Mai 2014, 19:48:14
Die ausgelesenen Werte schwingen in sehr kurzen Abständen zwischen 450 und 7105 incl. LED-Farbwechsel am Stick.
Da die LED am Stick ja autark funktioniert, vermute ich, es liegt an der Stromversorgung. Aktiver Hub ist bestellt.
Ich poste nochmal, wenn es das war.
Mit dem aktiven Hub (D-Link DUB-H7 7-Port USB 2.0 Hub) läuft es problemlos bei mir. Auch die ständigen disconnects des Sticks haben sich damit erübrigt.
Schöne Grüße,
John
Hier nochmal meine aktuelle Version samt Bugfix und ohne grosse USB-Anpassungen, da beim RasPi da einfach nichts zu machen ist.
Drin sind immer noch die erweiterten Readings sowie die Set Funktionen für Flags etc., der Kommunikationsteil ist wesentlich lesbarer.
Mag diesen Teil mal jemand in die offizielle Version übernehmen?
Gruss, Markus
ZitatMag diesen Teil mal jemand in die offizielle Version übernehmen?
Sind die
sleep 1
im Programmcode nicht ungesund für fhem? Könnte zu Problemen für andere zeitkritische Vorgänge in FHEM führen.
die sleep sind auf jeden fall problematisch und versauen z.b. das homematic timing. das ist also nicht die endgültige lösung.
bei mir funktioniert es auch ohne die sleep seit monaten einwandfrei. wer hat noch probleme mit dem aktuellen timing?
alles andere schaue ich mir an sobald ich dazu komme.
gruss
andre
Zitat von: joshi04 am 10 Mai 2014, 11:13:49
Nachtrag:
Mit dem aktiven Hub (D-Link DUB-H7 7-Port USB 2.0 Hub) läuft es problemlos bei mir. Auch die ständigen disconnects des Sticks haben sich damit erübrigt.
Im Langzeitbetrieb haben sich die Disconnects leider doch nicht erledigt, wenn auch deutlich seltener. Allerdings habe ich auch noch die USB-Schnittstelle des RPi und das Kabel im Verdacht. Weil das sowieso geplant was, habe ich einen Cubietruck im Anschlag und hoffe, dass neben der Performance-Verbesserung auch die akzeptiere Kabellänge etwas besser wird.
Wenn der läuft (das kann noch etwas dauern), werde ich noch einmal etwas genauer Troubleshooting betreiben.
Schöne Grüße,
John
Kurzes Feedback, Sensor läuft einwandfrei ohne Disconnects seit 3 Tagen am CT mit aktuellem Modul über USB-Hub angeschlossen.
Vielen Dank! :D
Da noch nicht produktiv, kann ich bei Bedarf gerne noch mal testen.
Schöne Grüße,
John
Edit: Vielleicht sollte ich noch kurz ergänzen, dass im Log nach dem Starten noch folgendes steht:
2014.06.03 21:44:49 3: SZ_CO20: CO20 device found
2014.06.03 21:44:49 3: SZ_CO20: CO20 device opened
2014.06.03 21:44:50 3: NTFY return: -110
Es gibt aber keine Einschränkung. Ich bin leider, was die Information "NTFY return" angeht, über Zusammenhang und Bedeutung noch unwissend.
Die sleep hatte ich vergessen rauszunehmen, weil es bei mir auch so lief.
Es ist allerdings so, dass nichts was ich versucht hatte einen dauerhaften Betrieb auf dem Raspberry Pi ermöglicht hat.
Ob der komplette Verbindungsabbruch nun nach 2 Stunden oder 3 Tagen kommt ist weniger wichtig.
Die Plattform ist was USB angeht schlicht Mist - alles was dabei hilft ist ein Hardwarewechsel.
Hallo, habe heute von einem Kollegen einen Sensor von VELUX geschenkt bekommen. Da ich am Raspi schon so ein Teil seit einem halben Jahr problemlos laufen habe, stellt sich mir jetzt die Frage, den 2. Sensor am gleichen Raspi zu betreiben.
Ist das möglich? Wenn ja, was müsste geändert werden damit der 2. Sensor eingebunden werden kann?
VG
Frank
such mal weiter oben im thread. du kannst die busid beim define mit angeben. musst aber sicherstellen das die sich beim neustart nicht ändert.
die gepatchte version von oben kann das glaube ich noch etwas besser. die ist aber noch nicht mit eingecheckt.
gruss
andre
Danke andre, hat geklappt. bus:device
VG
Frank
Ich habe das Modul gestern auf meinem Cubietruck in Betrieb genommen (mit einem Stick von Velux, die haben den übrigens auf Rechnung und Versankostenfrei geliefert und man kriegt bis zu 2% Skonto ... sowas kennt man ja kaum noch) und wollte einfach einmal danke sagen - es funktioniert auf Anhieb, alle Probleme durch lesen dieses Threads lösbar - großes Kino!
So ein bisschen nachm Mond geht das Teil aber schon - oder? Ich hab einmal ein Diagramm angehängt:
- Beim Lüften geht der Messwert korrekt runter auf fast das Minimum
- Danach wird er dann wieder viel größer als vorher
- An der Temperatur (Zweites Plot) kann das ja auch nicht wirklich liegen, die bleibt annährend konstant ...
Meine Vermutung: Da scheint die beworbene "Driftkorrektur" zuzuschlagen ... kann man die testweise abschalten?
Kalibriert habe ich ihn 2 Tage vorher auf dem Balkon - und natürlich auch die Auto-Rekalibrierung ausgeschaltet. Beobachtet soetwas noch jemand?
OK nach ein paar Tagen "einbrennen lassen" und anschließender Neukalibrierung draußen an der frischen Luft hat sich das erübrigt, jetzt geht das Ding richtig gut! Klettert bei geschlossenem Fenster sehr langsam hoch; beim Lüften rutscht der Messwert auf gut 450 binnen weniger Minuten wieder runter - um danach wieder im gleichen Tempo wie vorher zu steigen. Ein zweiter direkt daneben gelegt verhält sich auf +/- 30 ppm genauso, absolut ausreichend um zu sagen, wann das Fenster wieder zu kann nachm Lüften. Bei Stufe gelb merkt man auch wenn man von draußen kommt, dass die Luft nicht mehr toll ist. Und bei Blähungen ist die Empfindlichkeit ja regelrecht bombastisch :-D
Tipp, wenn man mehrere (in verschiedenen Räumen) verwenden möchte, und die Messwerte vergleichen will: Unbedingt ein paar Tage laufen lassen und danach *gleichzeitig* draußen kalibrieren.
Anhand der Zackigkeit der Kurve, wenn jemand im Raum ist vs. der kompletten Glattheit bei Abwesenheit könnte man das Ding direkt zur Anwesenheitserkennung verwenden....
Mal gucken wie sich das mit dem Wandel des Wetters und dem älterwerden des Sticks entwickelt.
Ich habe das Gefühl, dass der Stick bei höherer Luftfeuchte unempfindlicher reagiert (Autokalibrierung aus)
Kann das jemand bestätigen?
Kann durchaus sein. Ich habe auch noch einen reinen CO2 Messer in der Nähe stehen und die Abweichungen könnten bei hoher Luftfeuchte höher sein. Das Problem ist, dass die CO2 Messungen und VOC nie komplett korrelieren, insofern ist eine Aussage schwierig.
I find it strange, CO20 is cheap, easy to use (thanks to justme1968)
and still I see only 30 installations.
I can only recomand it, if you desire to get a feeling on your air quality, without spending real money.
I went a little further and correlated it to my ventilation system activity.
immi
Hi immi,
a bit off-topic - but how can you see 30 users using the module?
Is fhem sending some statistics to the developers?!
Regards,
Spiff
here you can see http://forum.fhem.de/index.php/board,11.0.html (http://forum.fhem.de/index.php/board,11.0.html).
gruss frank
Hi,
Zitat von: peterk_de am 27 Juni 2014, 12:31:59
[...]- und natürlich auch die Auto-Rekalibrierung ausgeschaltet. [...]
Wie kann man die denn ausschalten? Ich beobachte nämlich auch, dass die Luft schlechter angezeigt wird, als es eigentlich sein dürfte.
Grüße scholty
scholty, über das WindowsTool von AppliedSensors und da über ein verstecktes Menü:
http://blog.moneybag.de/luftqualitaets-sensor-voltcraft-co-20-ein-erfahrungsbericht/#more-9919
Wow, danke.
Und ich hatte gedacht, ich hätte alles gelesen.
Grüße
scholty
Nun muss ich dann auch mal ran. Erst mal vielen Dank an die guten Forumsbeiträge, die es mir ermöglicht haben eine Haussteuerung für diverse Aktoren(Intertechno,FS20), Sensoren(1-Wire,Oregon Scientific) und sonstigen Geräten(FB, SamsungTV, Fronius, Hager eHz) aufzubauen.
An dem Luftgütesensor scheitere ich aber.
Ich habe das Ding an einem Windows-Rechner "einbrennen" lassen, bei guter Luft kalibriert und das KNOB_ui16StartupBits = 1 gesetzt. Dann habe ich den Sensor an einen RPi mit passivem USB-Hub und dem Modul 38_CO2.pm in FHEM betrieben. Leider bekam auch ich die hier schon beschriebenen dauerhaften Abbrüche("disconnect").Dauerhaft immer dann, wenn im Log ein "failed to open CO20 device" erscheint. Dadurch konnte ich auch keine konkreten Erkenntnisse über das Verhalten des Sensors gewinnen. Dazu muss ich erwähnen, dass ich Raucher bin und einen Heizkamin betreibe. Ich hatte aber den Eindruck, dass sich während des Betriebs "irgendwie" die Kalibrierung selbständig ändert. Ich loggte daher zusätzlich r_s, welcher der veränderliche Widerstand des Sensors ist und sich scheinbar ungefähr umgekehrt proportional zu der Ausgabe voc verhält. Durch ein get "air_data" hatte ich gelernt den Sensor manuell wieder zurück ins Leben zu rufen.
Ich legte mir einen aktiven USB-Hub von Belkin zu, mit dem ich erhoffte die Abbrüche zu unterbinden. Leider Fehlanzeige. Damit ich nun endlich mal halbwegs permanente Daten bekomme, habe ich mir einen watchdog angelegt, der nun bei einem dauerhaften Abbruch ein get "air_data" macht. Endlich, ich habe permanente Daten ;-). So lässt sich der Sensor prinzipiell sinnvoll betreiben.
Aber jetzt konnte ich auch das Fehlverhalten feststellen. Der beigefügten Grafik könnt Ihr entnehmen, dass beim Lüften(rote Kringel) der Sensor eine Art Neukalibrierung durchführt. Sprich bei steigendem r_s(pink) sinkt der voc ab ca. 500 nicht weiter ab. Ist der Peak von r_s erreicht und fällt dann wieder ab, steigt sofort der voc an, was zu dem Ergebnis "schlechte Luft" nach dem Lüften führt. Steckt man den Sensor ab und wieder neu an(blauer Kringel), hat man "plötzlich" wieder gute Luft. Irgendetwas stimmt mit dem Teil also nicht.
Kennt jemand ein ähnliches Verhalten ?
Was man sicherlich noch testen könnte: reset/recalibrate. Nur leider sind die Informationen dazu arg dürftig, teilweise sogar widersprüchlich. Hat jemand evtl. weitere Infos zu den Flags, Knobs etc. ? Tante Gockel hab ich auch schon endlos gequält, mit wenig befriedigendem Ergebnis.
Grüße
Markus
Hallo andre,
hab da nach FHEM restart immer einmal folgende Kleinigkeit im LOG:PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/38_CO20.pm line 84.
die warnung sollte ab morgen weg sien.
gruss
andre
Perfekt, danke!
An einem von meinen 4 CO20-Sensoren habe ich leider in unregelmäßigen Abständen (zwischen 1 und 3 Wochen) Aussetzer. Der Stick liefert dann keine Daten mehr und ich muss ihn abstecken und wieder anstecken und danach ein update manuell anstoßen.
Ich habe mir dafür mal einen Watchdog geschrieben.
define w_CO20.Wohnen watchdog CO20.Wohnen 00:10:00 SAME {myProwl("CO2-Sensor ausgefallen","CO20.Wohnen manuell überprüfen!",1)};; trigger w_CO20.Wohnen .
Nach meinem Kernel-Update auf 3.12.35 ist das Problem noch nicht wieder aufgetreten. Alternative zum manuellen Abstecken wäre vermutlich auch ein Reboot des RasPi. Ein Restart von FHEM hatte das letzte Mal keinen Erfolg.
steckt der stick direkt am rasberry oder an einem aktiven hub?
ich meine es gab schon ähnliche fälle bei denen ein aktiver hub geholfen hat.
gruß
andre
Direkt im RPi. Beim B+ gibt es das USB Stromversorgungsproblem so nicht mehr und das Netzteil ist mit 2,5 A absolut OK.
Ich werde es mal weiter beobachten.
Klappt das mit dem RasPi mittlerweile ohne Aussetzer?
Andre, spricht eigentlich irgendwas dagegen mal meine Änderungen ins SVN aufzunehmen, die die kompletten Daten des Sticks ausgeben und auch das Setzen der Einstellungen ermöglichen?!
Gruss, Markus
Also bei mir sind es jetzt 2 von 4, die hin und wieder hängen. Abstecken und wieder anstecken hilft.
Hatte noch nicht die Zeit es näher zu untersuchen, aber auch ein restart von FHEM hilft nicht.
Zitat von: volschin am 24 Januar 2015, 15:22:54
Also bei mir sind es jetzt 2 von 4, die hin und wieder hängen. Abstecken und wieder anstecken hilft.
Das liegt am USB des RasPi, ich habe leider keine Möglichkeit gefunden das zu beheben und letztendlich die Hardware gewechselt.
Du kannst mal meine Version ausprobieren und ein wenig mit
retries und
timeout rumspielen.
Das sollte die Aussetzer seltener auftreten lassen, ganz wegbekommen wirst du sie damit allerdings nicht.
Je kleiner das Intervall, desto höher die Wahrscheinlichkeit dass sich der Stick aufhängt.
Ich habe deine modifizierte Version mal auf einem RasPi eingespielt und werde da mal testen. Wenn das auch nichts bringt, könnte ich den Raspi bei einem Ausfall des Sensors rebooten. Bisher habe ich leider keine möglichkeit gefunden, den Prozess des Absteckens über Software zu simulieren.
Den gibt es leider auch nicht.
Ich bin mir nicht mal sicher ob ein Reboot irgendwas bringt.
Gib mal Bescheid, ich hab auch noch Sticks und RasPis rumliegen :)
Du konntest "Hard Core" mäßig probieren, die Linux USB-Treiber zu entladen (z.B. rmmod ohci) und wieder zu laden (modprobe ohci), es sei denn, die sind im Kernel einkompiliert ...
Alternativ (besser) versuchen passenden USB-Anschluß ab/anschalten
z.B.: cat /sys/bus/usb/devices/1-7/power/control
Habe ich mir ein paar Sachen angesehen, hat aber nicht funktioniert. Laut Aussagen im Netz ist das power Control bei USB optional und leider auf dem Raspi nicht vorhanden. Alle USB-Teiber zu entladen verursacht weitere Probleme mit anderen USB-Geräten, z.B. Bluetooth und WLAN. Deshalb ist die sicherste bisher gefundene Option außer Abstecken ein Reboot.
die Version von Markus ist äußerst hilfreich und sollte eingechecked werden !
Ich hab ja weiter oben schon über meine konfig und Probleme berichtet. Ich kann Markus nur zustimmen: eine Änderung des Abfrageintervalls von 60 auf 90 hat bei mir wahre Wunder bewirkt: keine oder nur ganz seltene Ausfälle ! Der aktive Hub hatte an meinem B+ gar nichts verbessert, aber: der r_h wert ist wesentlich stabiler mit aktivem Hub und dadurch die voc-kurve glatter/genauer
Meine bisher unbeantworteten Fragen kann ich mittlerweile selber beantworten: Bei verbesserter Luft gegenüber der gespeicherten Kalibrierung "rekalibriert" sich der co20 im laufenden Betrieb selbständig. Außerdem ist der Sensor für Raucher eher ungeeignet: eine Zigarette signalisiert sofort eine schlechte Luftqualität. Ja, ihr habt recht, ich sollte das Rauchen aufgeben :-[
Markus
Zitat von: KölnSolar am 29 Januar 2015, 21:39:17
Außerdem ist der Sensor für Raucher eher ungeeignet: eine Zigarette signalisiert sofort eine schlechte Luftqualität. Ja, ihr habt recht, ich sollte das Rauchen aufgeben :-[
Da hat der Sensor doch schon seinen Zweck erfüllt. ;)
Gefahr erkannt, Gefahr gebannt. ;D
Leider ist die Version von Markus in einem Punkt nicht kompatibel. Das Kommando "get device update" wurde in "get device air_data" umbenannt.
Damit muss man externe Aufrufe anpassen.
Zitat von: volschin am 31 Januar 2015, 08:53:50Kommando "get device update" wurde in "get device air_data" umbenannt.
Hatte ich nur gemacht weil ich das als erstes in der Liste haben wollte und vergessen rauszunehmen.
Du hast nen Texteditor? Go! ;)
Zusammen mit dem internen Timer macht ein manuelles Update aber wenig Sinn, beim Pi ist es unter Umständen tödlich.
Hej folks,
hab mir erlaubt, ein funktionierendes gplot-File (FileLog) für den co20-Sensor auf Sourceforge hochzuladen.
Ist somit ab morgen per Update verfügbar.
Have fun! ;-)
Zitat von: Markus M. am 02 Februar 2015, 10:58:18
Zusammen mit dem internen Timer macht ein manuelles Update aber wenig Sinn, beim Pi ist es unter Umständen tödlich.
Wenn der Timer läuft sicher nicht, aber der Watchdog schaut und gibt nochmal einen nach, wenn eine zeitlang nichts aktualisiert wurde. Das hilft in vielleicht der Hälfte der Fälle bei dem alten Modul tatsächlich.
Mit Deiner Datei hatte ich tatsächlich bisher noch kein Problem, obwohl ich mein 5 Minuten-Intervall nicht verlängert habe. Aber das kann ja noch kommen. Manchmal war so auch über eine Woche Ruhe. ;)
Hallo Gemeinde,
seit 1,5 Jahren läuft mein Voltcraft Luftqualitätssensor einwandfrei.
Am Wochenende bin ich auf dem Raspberry Pi 2 B umstiegen und habe Fhem neu installiert.
Läuft sowas alles glatt.
Problem ist der Luftquali-Sensor, welcher keine Daten mehr an Fhem sendet. Der Sensor selber funktioniert mit dem C-Programm einwandfrei.
Die Installation habe nach dieser Methode gemacht: http://forum.fhem.de/index.php/topic,13166.msg82135.html#msg82135
root@raspberrypi:~# /opt/fhem/send2fhem.sh
Can't connect to localhost:7072 <<<<< hier der Fehler nach 4 Minuten.
Einzeln:
root@raspberrypi:~# /opt/fhem/airsensor -o
2015-02-19 22:07:31, VOC: 514, RESULT: OK
root@raspberrypi:~#
root rechte auf fhem.pl habe ich gegeben (da kam sonst immer ein access denied).
ein netstat wirft das aus:
tcp 0 0 Fhem.fritz.box:7072 192.168.178.29:41070 VERBUNDEN
tcp 0 1 Fhem.fritz.box:37230 localhost:7072 SYN_SENT
Jemand eine Idee?
die 192.168.178.29 habe ich mal abgeklemmt, hat auch nicht funktioniert.
Robin
Passendes Perl-Modul wieder installiert? Was sagt das Log?
welches Perl modul meinst du?
Log (verbose 5) schweigt sich hier aus.
Würde mir auch gerne so einen Sensor bestellen. Aber ich habe leider im Wohnzimmer keinen PC/Rasp dauerhaft laufen, an den ich den Stick anschließen könnte. Hat jemand so einen Stick schonmal über einen USB-over-Ethernet-Adapter laufen lassen?
Im billigsten Fall sowas hier? http://www.amazon.com/SANOXY%C2%AE-over-Extension-Cable-Adapter/dp/B003BDMK3S/ref=sr_1_3?s=pc&ie=UTF8&qid=1424382243&sr=1-3&keywords=usb+over+ethernet
Und könnte man theoretisch mehrere von den Sensoren an _einen_ PC anschließen, um damit mehrere Räume zu messen?
EDIT:
Ok, das Ding aus dem Link ist etwas sehr billig und ist im Endeffekt nur ein Kabeladapter. Also da wird kein Protokoll umgesetzt ^^
Zitat von: fh168 am 19 Februar 2015, 22:39:11
welches Perl modul meinst du?
Log (verbose 5) schweigt sich hier aus.
Ich sehe grade, du nutzt garnicht das Modul. Bei deiner Lösung kann ich nichts zu sagen.
Nein, ich war einer der "Early Adopters", die die Luftqualitäts-Daten noch über einen Cron-Job und send2fhem.sh bekommen. Das lief bis zur Umstellung auf dem Pi 2 absolut perfekt. Andrés Modul war damals noch nicht programmiert. Ich probiere noch mal ein bischen rum, ansonsten packe ich sein Modul drauf.
Robin
Ich habe mir auch diesen Velux Luftsensor gekauft und erfolgreich mittels eines USB-to-Ethernet Extender ins Wohnzimmer gepatched. In der Windows Software habe ich die Kalibrierung des Sensors deaktiviert (ui16StartupBits=0 gesetzt). Die modifizierte Version von "38_CO20.pm" (Markus M.) habe ich auch im Einsatz.
Was mich nun etwas verwundert hat ist die Tatsache das die Luftqualität die letzten Tage nur noch zwischen etwa 500 und 750 ppm geschwankt hat. Das war - trotz Lüftungsanlage - anfangs nicht der Fall. Deshalb habe ich heute Mittag mal den Stick abgezogen und wieder eingesteckt. Seitdem leuchtet der Stick rot und gibt Werte um 2000ppm aus. Hat vielleicht jemand einen Tip für mich??? Anbei 2 Screenshots... vielleicht kann Jemand etwas mit den Werten wie seq2, seq4,debug, pwm, r_h, r_s aus dem 38_CO20 Modul anfangen.
Zitat von: Peter-FL am 20 Februar 2015, 13:16:18
Ich habe mir auch diesen Velux Luftsensor gekauft und erfolgreich mittels eines USB-to-Ethernet Extender ins Wohnzimmer gepatched. In der Windows Software habe ich die Kalibrierung des Sensors deaktiviert (ui16StartupBits=0 gesetzt). Die modifizierte Version von "38_CO20.pm" (Markus M.) habe ich auch im Einsatz.
Klasse, klingt super! Kannst du mir sagen, welchen U-to-E-Extender du verwendest? Danke!
Kurze Zwischenfrage:
Was sind das eigentlich alles für Werte, die das Modul so ausspuckt (außer dem voc natürlich).
Matthias war so nett und hat das Modul in andFHEM aufgenommen, jedoch konnte ich ihm nur sagen, was der voc ist und in welchen Einheiten er angegeben wird.
Wäre super, wenn noch jemand Licht in mein dunkel bringen würde, damit ich Matthias die Info weiterleiten kann.
Thx a lot! :-)
@vbs: Es handelt sich um einen USB Line Extender von LOGILINK Model: UA0021D. Diesen hab ich für 8€ ink. Versand bei ebay bekommen. In Verbindung mit meiner Cat.6 Hausverkabelung bisher keine Probleme...
Zitat von: volschin am 31 Januar 2015, 08:53:50
Leider ist die Version von Markus in einem Punkt nicht kompatibel. Das Kommando "get device update" wurde in "get device air_data" umbenannt.
Damit muss man externe Aufrufe anpassen.
Im Anhang kompatibel - wenn man nicht die "Advanced" Ansicht gewählt hat, heisst es auch im UI wieder
update.
Zitat von: Peter-FL am 20 Februar 2015, 13:16:18heute Mittag mal den Stick abgezogen und wieder eingesteckt. Seitdem leuchtet der Stick rot und gibt Werte um 2000ppm aus. Hat vielleicht jemand einen Tip für mich??
Keine Ahnung...
Falls der Stick relativ neu ist:
set co20stick recalibrate_heater und dann mal gucken ob das nochmal passiert.
Unter Umständen ist
set co20stick KNOB_ui16StartupBits 0 anschliessend wieder nötig.
Zitat von: Mr. P am 20 Februar 2015, 20:26:49Kurze Zwischenfrage:
Was sind das eigentlich alles für Werte, die das Modul so ausspuckt (außer dem voc natürlich).
Was
debug und
pwm genau tun ist mir entfallen, die beiden Widerstandswerte sind allerdings von der Heizung und vom Sensor. Irgendwo in den Daten des Chipherstellers sollte mehr dazu zu finden sein. Für's UI sind sie irrelevant.
Gruss, Markus
Ich habe gestern mal den Stick wieder an einen Windows Rechner angeschlossen und die Werte mit dem Airmonitor überprüft. Der Stick hat aber die gleichen hohen Werte ausgegeben wie in FHEM. Daraufhin habe ich mal einen "Reset AQL (Ser the current reading to represent a good air quality level)" durchgeführt (natürlich am Frischluftventil der Lüftungsanlage). Seit dem scheint sich der Stick wieder normal zu Verhalten.
@Markus: Ja der Stick ist jetzt vielleicht gerade mal 2 Wochen alt. Bewirkt dein Vorschlag "set co20stick recalibrate_heater" (ich gehe mal davon aus das es ein FHEM Befehl ist) das gleiche wie mein Reset AQL unter der Windows Software? Danke für Deine Unterstützung.
Hallo Markus,
seit der Installation Deiner angepassten Datei gab es keinen Abbruch mehr. Klasse und vielen Dank.
Gruß
Veit
Zitat von: Peter-FL am 22 Februar 2015, 15:54:52Bewirkt dein Vorschlag "set co20stick recalibrate_heater" (ich gehe mal davon aus das es ein FHEM Befehl ist) das gleiche wie mein Reset AQL unter der Windows Software?
Ne, das wäre glaub ich
reset_baseline gewesen ;)
recalibrate_heater führt noch mal eine längere Einbrennphase des Chips durch. Kannst du probieren wenn das jetzt nicht geholfen hat.
Bis auf das Auslesen von offline aufgezeichneten Werten (das im FHEM Umfeld eh niemand braucht) kann meine Version grundsätzlich alles was auch die Windows Software kann.
Ich weiss nur leider selbst nicht mehr was manche Funktionen eigentlich tun.
Wenn du also mal Doku schreiben möchtest... ;)
Hab schon einige Seiten vom Thread gelesen, aber eine blöde Frage trotzdem: Das Modul CO20 kann ja mit dem Sensor direkt per libusb reden, wenn er an die FHEM-Maschine gesteckt ist. Aber was ist der beste Weg, um die Daten per LAN/WLAN zu holen, wenn der CO20-Stick an einem zweiten Raspi in einem anderen Zimmer steckt? Selbst mit airsensor und dem send2fhem.pl geht man ja davon aus, dass das alles auf der gleichen Maschine passiert, oder?
das send2fhem.pl sendet die werte per telnet an fhem. das geht natürlich auch an ein remote fhem wenn du keine telnet password hast.
ansonsten per fhem2fhem.
gruss
andre
Hm ok, aber das Skript scheint nicht direkt eine Telnet-Verbindung zu machen, sondern FHEM aufzurufen:
# Send data
/opt/fhem/fhem.pl $SERVER "set $VARNAME $VARVALUE"
Das setzt ja scheinbar voraus, das FHEM lokal installiert ist? Das braucht man also tatsächlich? Da hängt da ja auch wieder Perl etc. dran.
Kannst es auch einfach mit einem:
echo "<FHEM-Befehl>" | nc -w10 <FHEM-IP> <FHEM-Port>
an FHEM senden. ;-)
$SERVER muss nicht localhost sein... und das /opt/fhem/fhem.pl das aufgerufen wird muss nur da sein aber es muss kein komplettes fhem laufen.
die nc variante sollte genau so funktionieren.
Ok, danke euch.
Ich hab das airsensor mal um einen Parameter "-c" erweitert, dem man selbst ein Kommando mitgeben kann. Das Kommando wird dann nach jedem Pollen aufgerufen. Es muss einmal %d enthalten, um den VOC-Wert aufnehmen zu können.
Außerdem einen Parameter -i um das Intervall konfigurieren zu können.
Beispiel:
./airsensor -d -i 120 -c "echo \"setreading fl_airSensor airQuality %d\" | nc -w10 localhost 7072"
Holt alle 2 Minuten einen Wert und setzt ihn per setreading.
Falls das auch jemand gebrauchen kann:
https://github.com/verybadsoldier/airsensor (https://github.com/verybadsoldier/airsensor)
EDIT:
...übrigens sind die Velux Raumlüftfühler jetzt wieder lieferbar:
http://www.velux.de/produkte/lueftungsloesungen-belueftung/raumluftfuehler (http://www.velux.de/produkte/lueftungsloesungen-belueftung/raumluftfuehler)
Lieferzeit 5 Tage.
Hi,
ich habe nun auch ein V...x Teil mit FHEM am laufen. Funktioniert soweit auch, jedoch erhalte ich im Log permanent
2015.04.12 22:31:01 3: co20: CO20 device found
2015.04.12 22:31:01 3: co20: CO20 device opened
2015.04.12 22:31:11 3: co20: disconnected
2015.04.12 22:31:11 3: co20: CO20 device found
2015.04.12 22:31:11 3: co20: CO20 device opened
2015.04.12 22:33:21 3: co20: disconnected
2015.04.12 22:33:21 3: co20: CO20 device found
2015.04.12 22:33:21 3: co20: CO20 device opened
2015.04.12 22:33:31 3: co20: disconnected
2015.04.12 22:33:31 3: co20: CO20 device found
2015.04.12 22:33:31 3: co20: CO20 device opened
2015.04.12 22:37:41 3: co20: disconnected
2015.04.12 22:37:41 3: co20: CO20 device found
2015.04.12 22:37:41 3: co20: CO20 device opened
2015.04.12 22:39:46 3: co20: disconnected
2015.04.12 22:39:46 3: co20: CO20 device found
2015.04.12 22:39:46 3: co20: CO20 device opened
2015.04.12 22:39:56 3: co20: disconnected
2015.04.12 22:39:56 3: co20: CO20 device found
2015.04.12 22:39:56 3: co20: CO20 device opened
2015.04.12 22:40:06 3: co20: disconnected
2015.04.12 22:40:06 3: co20: CO20 device found
2015.04.12 22:40:06 3: co20: CO20 device opened
Gibt es hierfür eine Lösung?
mfg
Thomas
Meine kaputte Glaskugel zuckt und ich deute, sie will mir sagen, du hast ihn an einem Raspberry angeschlossen...
Wenn dem so ist, stelle ihn einmal um auf USB1.1 und dann funktioniert das auch mit dem Nachbarn. ;-)
Meine Glaskugel hat sich auch gerade geregt, scheint aus der gleichen Charge zu kommen. Nach dem Rpi kam bei meiner, als sich der Schleier nach etwas Warten noch ein wenig weiter gelichtet hat, ein zu langes und ggf. minderwertiges oder großen Störeinflüssen ausgesetztes USB-Kabel zum Vorschein. Bitte prüfe einmal, ob davon etwas zutreffend ist.
Ergänzend zum Umschalten auf USB 1.1, ein aktiver kompatibler (!) Hub kann richtig Freude bereiten... ;) Ich habs aber auch schon ohne hinbekommen.
Da das mM bekannte Schwierigkeiten sind, mag sich jmd erbarmen, das dem Wiki hinzuzufügen, wenn nicht bereits geschehen? Mache ich gerne selbst, wenn ich die Panstamp -Baustelle im Griff habe (das dauert noch) und noch viel schlimmer mein Internet wieder geht...!
Gesendet von meinem iPhone mit Tapatalk
Edith sagt: Internet geht wieder, wenn denn die Panstamps sich auch von selbst einrichten würden...
Sorry ich vergaß,
ja Rasperry Pi B+ und Stick hängt direkt am Pi. Selbst mit aktivem USB 2.0 Hub war das Problem nicht behoben.
OK werde mal googlen wie man das Ding auf USB 1.1 umstellt, oder könnt ihr dies kurz posten.
mfg
Thomas
Trage im File: /boot/cmdline.txt
am Anfang der Zeile einfach: dwc_otg.speed=1
ein bzw. schau ob der Parameter mit 0 bereits existiert und ändere den Wert auf 1.
Also zB:
dwc_otg.speed=1 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
Vielen Dank,
dwc_otg.speed hat das Logfile beruhigt. Nun bleibt die Verbindung offen.
Gruß
Thomas
Hat schon jemand rausgefunden, wie es zu Werten von "21546" kommen kann?
2015-04-15 22:56:33, VOC: 21546, RESULT: Error value out of range
2015-04-15 22:56:44, ERROR: Invalid result code: -16
Ist mir bisher mit der Windows-Software nicht aufgefallen (evtl. wird das dort gefiltert). Jetzt am Raspberry bekomme ich das ca. 2 Mal pro Stunde mit "airsensor".
Diese Werte sind Fehlerwerte wenn bei der Sensorabfrage irgendwas schief geht und üblicherweise die Vorstufe zum Lock-Up, wenn du danach gleich wieder pollst. Solange es nur ab und zu vorkommt kannst du das ignorieren.
Ja, soweit versteh ich das. Würde es aber trotzdem gerne verstehen, warum das passiert und nach Möglichkeit auch gerne beheben. Einfach aus einem Spieltrieb heraus ;) Kann das etwas mit der Spannugsversorgung des RaspBi zu tun haben? Ich hab da im Moment nur ein 1A-Netzteil dran.
Kann sein, muss nicht.
Solange es generell läuft würde ich keinen Aufwand in USB Debugging stecken weil die einzige Lösung darauf hinausläuft, keinen RasPi zu verwenden.
Also ich hab jetzt mal probiert, den USB-Speed zu begrenzen, mal gucken. Scheint ja eine Wunderwaffe beim Raspi gegen USB-Probleme zu sein... dann probier ich nochmal ein 2A-Netzteil... und dann gebe ich auf...
Hat schonmal jemand rausgefunden, wofür die Register Reg_P, Reg_I und Reg_D sind? Ich habe hier mehrere von den Sticks und versuche gerade, mindestens zwei dazu zu bewegen, die gleichen Werte auszugeben. Habe beide unter identischen Bedingungen kalibriert, aber wenn die Werte steigen, laufen sie ca. 5% auseinander. Evtl. gibt es in den Registern einen kleinen Parameter, den man tunen kann zu dem Thema?
Keine Ahnung, ich kann dir aber mal meine Vergleichswerte geben:
KNOB_Reg_D 0
KNOB_Reg_I 10
KNOB_Reg_P 3
KNOB_Reg_Set 147
debug 716
pwm 336
r_h 146.87
r_s 192353
voc 516
Reg_Set ist der Vergleichswert zum Widerstand r_h aus der Kalibrierung - Versuch daran mal minimal zu drehen.
Der Rest: http://de.wikipedia.org/wiki/Regler#PID-Regler (http://de.wikipedia.org/wiki/Regler#PID-Regler)
Probier rum und berichte von deinen Erkenntnissen :)
Und übertreibs nicht mit den Werten, nicht dass dir das Ding noch durchbrennt.
Der Vollständigkeit halber hier noch das Readme zu Stick und Software:
AirMonitor engineering mode
===========================
To enter the (unsupported) engineering mode, do the following:
- Hold down left CTRL-key and double-click on the right top logo
Posting a bug report
--------------------
If the program crashes you will most probably see a requester on the form
"Fatal program error in Airmonitor: ...".
As the requester say, the error has been copied to your clipboard.
Please do a "paste" operation when sending the bug report to us (e.g in an email).
That way you do not need to send us a screen dump of the error.
Get sensor information
----------------------
To get technical information about the connected sensors,
open "Help"-"About" and click on "Sensor info...".
You can copy and paste the text e.g into an email.
Sensor Reading time
-------------------
The time required for reading all connected sensors is shown as a constant flag "tr=XX.XX"
in the upper left corner. This time must not exceed the sampling interval.
File menu
---------
Some extra functions are now available:
- Save current buffer data... ; ; : Saves what you see on the screen to a file.
- Erase flash & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp;: Erases any records stored in the stick
The stick can record data when not enumerated (= connected to a power source only).
This is enabled by setting the "knob" LogInterval to something else than 0.
If the knob "LogInterval" does not exist the stick does not support that functionality.
Support tools
-------------
This menu is only available in engineering mode.
- Edit knobs...
This menu will give access to the "knobs" (analogue settings) in each stick,
like warning levels, PID setting etc. "Flags" are also displayed.
A value can be changed by double-clicking on it. You can get back to the factory settings by
sending the "RST" command to the stick(s), see Airmonitor command line options in the help file.
Some knobs (stored in EEPROM):
CO2/VOC level_warn1: Lower warning level
CO2/VOC level_warn2: Upper warning level
Reg_Set: &nbs p; &nbs p; &nbs p; Regulator setting. Don't touch.
Reg_P: Regulator P setting. Affects speed/stability. Don't touch.
Reg_I: Regulator I setting. Affects speed/stability. Don't touch.
Reg_D: Regulator D setting. Affects speed/stability. Don't touch.
LogInterval: (Default 0=Turned off). Seconds between samples recorded to flash when
stick is powered but not enumerated (i.e in a wall plug).
ui16StartupBits: &n bsp; Config bits:
Bit 0 : Default 1= Reset baseline on power up
Bit 1-15: Reserved
Some flags (volatile):
(if bit 15 is set on a flag it is displayed in the Airmonitor graph)
WARMUP Stick is in warmup state and flashes the red/green led
BURN-IN ; ; ; ; Burn-in minutes left
RESET BASELINE &nbs p; Sent from the PC to start a baseline reset procedure
CALIBRATE HEATER Sent from the PC to start a calibrate heater procedure
Inside the form for this menu selection there is also a network section.
This is an experimental network support. Airmonitor can either be off the network,
act as a server (waiting for other AirMonitor programs to access it at the specified port),
or act as a client (connect to the specified port on the specified ip/host name).
Network support protocol is described later in the section "Network protocol".
- Recalibrate heater
This will send a command to all sticks and tell them to recalibrate the chip heater PID parameters.
- Search for updates
This will simply start a web browser and access the url stored in the first iAQ Stick.
Usually this brings you to the manufacturers web page.
- Upgrade firmware
This will place all connected sticks in DFU (Device Firmware Upgrade) mode. They will deatach
themselves from the USB host, reconfigure as DFU devices and re-connect.
The driver needed to talk to a DFU is included in Atmels FLIP package (search the Internet for "Atmel FLIP" or
browse to http://www.atmel.com/dyn/products/tools_card.asp?tool_id=388 6).
The driver is typically located in "C:\Program Files\Atmel\Flip 3.3.4\usb" after installation of the FLIP package.
When FLIP is installed you can use it (the windows gui or BATCHISP) to reprogram the sticks firmware.
Only do this on one stick at the time. You will need an Intel HEX file from the iAQ stick vendor with
the new firmware.
When the upgrade is done, reset the stick (reload eeprom defaults) by, at the command prompt, write
"airmonitor.exe /RST" (see Airmonitor command line options in the help file).
Settings-Plot
-------------
This menu exists in non-engineering mode as well, but now there are some more settings available.
Curve
-----
There are more curves available in a stick than just the VOC level. The new pull-down box gives you
the possibility to set the parameters for each available curve.
By default Airmonitor only shows the first curve.
Scroll
------
Unchecking this box will give "wandering cursor" type of graph instead of the scrolling graph.
The benefit is that the "wandering cursor" is less cpu demanding and easier to measure with the cursor.
Margins
-------
This sets the margins, in pixels, for the plot area.
----------------------------------------------------------
Network protocol
----------------
The network protocol can be tested by placing the Airmonitor program in "server" mode (see above) and
telnet to localhost 5800 (default). A telnet session might look like this:
c:\>telnet localhost 5800
iAQ USB server Version 2.40.0 svn:$Rev: 1702 $ $Date: 2011-01-17 11:23:13 +0100
Ready
0001:iAQ>
The available commands are:
add [USB:0] mcu|nChannels|CH0|.ChID|.Ylabel|.Yunit|.LastValue ; Add a sensor to the server
help &n bsp; Help text
bye &nb sp; Exit
ls &nbs p; Get list of all sensors
m <message> Print message
trg &nb sp; Get all sensor readings
update [USB:0] nChannels|.LastValue|.LastValue|.LastValue... &nb sp; Update values for specified sensor
updateplot Update server plot
If you are a client and you only wish to read out the values of the server sensors,
simply use the commands "ls" initially and then "trg" at regular intervals.
Remember to wait for the prompt "iAQ>" before sending a new command.
add
---
Adds a new "virtual" sensor to the server. In this case the server adds
a sensor provided by the connecting client.
The parameter is an identifying list of sensor channels, formatted like:
[interface:path] mcu|number-of-channels|channel-0-name|channel-0-id|channel-0 -Ylabel|channel-0-Yunit|channel-0-last-value
|channel-1-name|channel-1-id|channel-1-Ylabel|channel-1-Yuni t|channel-1-last-value
| ...
|channel-n-name|channel-n-id|channel-n-Ylabel|channel-n-Yuni t|channel-n-last-value
Example:
0003:iAQ>add [EMU:0:0]EMU|5|0|RND() level|ppm|1537|1|Debug|i16|1568|2|PWM|ui16|1542|3|Rh|ohm|15. 62|4|Rs|ohm|1556
0004:iAQ>add [USB:\\?\hid#vid_03eb&pid_2013#6&1f0ff5bf&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}:0]ATmega32U4|5|0|CO2/VOC level|ppm|350|1|Debug|i16|815|2|PWM|ui16|412|3|Rh|ohm|0|4|Rs |ohm|0
0005:iAQ>
help
----
Prints a short help text.
bye
---
Close connection.
ls
---
Lists all connected sensors. The list is formatted as sequential "add" commands and is ended with the "updateplot"
statement. This is so that a connecting AirMonitor can use the same parser for incoming messages as for queries.
Example:
0006:iAQ>ls
add [EMU:0:0]EMU|5|0|RND() level|ppm|1537|1|Debug|i16|1568|2|PWM|ui16|1542|3|Rh|ohm|15. 62|4|Rs|ohm|1556
add [USB:\\?\hid#vid_03eb&pid_2013#6&1f0ff5bf&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}:0]ATmega32U4|5|0|CO2/VOC level|ppm|350|1|Debug|i16|815|2|PWM|ui16|412|3|Rh|ohm|0|4|Rs |ohm|0
updateplot
0007:iAQ>
m <message>
-----------
This prints a message on the Airmonitor screen. For test purposes.
Example:
0006:iAQ>m Hello World!
0007:iAQ>
trg
---
Get current sample values. This gest a list in the following form:
update [interface:path]number-of-channels|channel-0-value|channel-1-value| ... channel-n-value
Example:
0003:iAQ>trg
update [USB:\\?\hid#vid_03eb&pid_2013#6&1f0ff5bf&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}:0]5|350|814|400|0|0
update [USB:\\?\hid#vid_03eb&pid_2013#6&1f0ff5bf&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}:0]5|350|814|400|0|0
0004:iAQ>
update
------
This command updates values for a "virtual" server sensor previously added with the "add" command.
The syntax is the same as the string response to the "trg" command:
update [interface:path]number-of-channels|channel-0-value|channel-1-value| ... channel-n-value
updateplot
----------
This sends a request to the server to update his plot, typically after a virtual sensor has been added.
The server plot will be cleared.
Ok, danke, nützliche Infos! Werde damit mal etwas rumspielen.
Ich hab mittlerweile 4 von diesen Sticks hier liegen und das Register Reg_Set unterscheidet sich bei allen, die anderen Register sind gleich. Ich gehe davon aus, dass Reg_Set vom Werk aus kalibriert wird und gerätespezifisch ist um Fertigungstoleranzen auszugleichen. Eine Änderung daran ändert auf jeden Fall auch deutlich den Messwert.
Die Sensoren sollen ja aber einige Stunden/Tage "einbrennen", um ihre optimalen Werte zu liefern. Ich könnte mir vorstellen, dass die daher ab Werk nur grob "vorkalibriert" sind (ohne Einbrennen) und dass man daher als Benutzer noch etwas optimieren kann, wenn man dann nochmal händisch etwas anpasst. Leider hab ich kein Referenzgerät, so dass ich die Sticks nur zueinander kalibrieren kann.
Ich verstehe an diesem PID-Reglern nicht, wie das zu dem Sensor passt, da es doch Begriffe aus der Regeltechnik sind. Ich bin da totaler Laie, aber da geht es doch immer um Soll- und Ist-Werte, oder? Wie trifft das auf einen einfach Sensor zu, der ja nix regelt, sondern einfach immer nur stupide einen Wert liefert?
Ich habe absolut Null Ahnung von Regelungstechnik, bin mir nur ziemlich sicher dass die Register sowas bedeuten :)
Schritt 1: nimm deine 4 Sensoren, schreib dir alle Werte auf, leg sie nebeneinander und mach nen kompletten Reset samt den paar Stunden Burn-In in einem leeren Raum mit geschlossenen Fenstern.
Dann vergleich nochmal Werte und Kurven.
Welches Kommando das ist steht im Readme, meine Modulversion kann es setzen.
Hat eigentlich jemand eine Ahnung, was "Recalibrate Heater" macht bzw. unter welchen Bedingungen man das ausführen sollte/dürfte? Ich hab mich noch nicht getraut, das zu drücken :/
Das sollte das komplette "Einbrennen" über mehrere Stunden am Anfang durchführen, d.h. erst nachdem der Stick eine längere Zeit in Betrieb war, werden die Referenzwerte gesetzt und Daten gewonnen.
Macht wahrscheinlich nur dann einen Unterschied, wenn der Stick tatsächlich längere Zeit nicht in Betrieb war.
Ist aber gefahrlos.
Ok danke, gut zu wissen.
Aber ich habe gerade ein anderes seltsames Verhalten festgestellt:
Ich hab hier 3 Sticks laufen und bei allen die Bits gesetzt, so dass sie sich nicht beim Starten neu auf einen Basiswert "kalibrieren". Ich habe sie an der frischen Luft kalibriert und sie liefen jetzt auch ca. 4 Wochen hier mit gewünschten Werten zwischen 450 und 2000.
Nun habe ich alle Sticks einmal abgezogen und USB-Verlängerungen angebracht, um sie besser positionieren zu können. Seitdem diesem Neustart liefern alle drei auf einmal Werte größer 2000, auch in gut belüfteter Umgebung. :(
Ich kann mir das Verhalten nicht erklären, da sich die Sticks ja wegen den gesetzten Bits nicht neu kalibrieren sollten beim Booten. Und selbst wenn sie es tun würden, dann müsste ich ja bei allen drei Sticks nach dem Neustart Werte um 450 sehen (und nicht 2000).
Ich wollte eigentlich meine einmal gemachte Kalibration beibehalten. Kann sich jemand erklären, wieso die Sticks nach dem Booten jetzt auf einmal so hohe Werte zeigen?
Also ich bin mir nicht sicher, ob durch dein Recalibrate Heater nicht etwas schief gelaufen ist. Die normale Funktion ist ui16StartupBits=0. Vom Einbrennen sollte man meines Wissens besser die Finger lassen.
Sollte eigentlich nur dann notwendig sein und einen Unterschied machen, wenn der Sensor längere Zeit nicht in Betrieb war.
Ich hatte das vorgestern mal gemacht da ich nach dem Wechsel auf einen anderen Rechner das Gefühl hatte, dass der Sensor etwas zu enthusiastisch reagiert und auch zu hohe Werte anzeigt. Das hat sich aber leider dadurch nicht gebessert.
Ich muss bei Gelegenheit mal nachsehen ob andere Einstellungen weiterhelfen.
Hat den Raumluftfühler schon jemand in die Abluft eines Paul Novus 300 Lüftungsgerätes gehängt?
Das Gerät wirkt sehr dicht - komplett aus Styropor.
Daher würde mich der einfachste Weg ins Gerät interessieren.
Vielleicht habt ihr eine Idee.
Ich habe den Stick direkt an RasPi B+ (USB 1.1) angeschlossen.
Direkt danach erhalte ich noch einmalig ein plausiblen Wert. Doch dann kommt nur noch "Out of range" & Co.
airsensor -d
2015-06-26 23:13:29, DEBUG: Active
2015-06-26 23:13:29, DEBUG: Init USB
2015-06-26 23:13:40, DEBUG: USB device found
2015-06-26 23:13:40, DEBUG: Read any remaining data from USB
2015-06-26 23:13:41, DEBUG: Return code from USB read: -110
2015-06-26 23:13:41, DEBUG: Write data to device
2015-06-26 23:13:41, DEBUG: Return code from USB write: 16
2015-06-26 23:13:41, DEBUG: Read USB
2015-06-26 23:13:42, DEBUG: Return code from USB read: 16
2015-06-26 23:13:43, DEBUG: Read USB [flush]
2015-06-26 23:13:43, DEBUG: Return code from USB read:
2015-06-26 23:13:41, VOC: 450, RESULT: OK
2015-06-26 23:13:53, DEBUG: Write data to device
2015-06-26 23:13:53, DEBUG: Return code from USB write: -16
2015-06-26 23:13:53, DEBUG: Read USB
2015-06-26 23:13:53, DEBUG: Return code from USB read: -16
2015-06-26 23:13:53, ERROR: Invalid result code: -16
2015-06-26 23:13:54, DEBUG: Read USB [flush]
2015-06-26 23:13:54, DEBUG: Return code from USB read: -16
2015-06-26 23:13:53, VOC: 21546, RESULT: Error value out of range
2015-06-26 23:14:04, DEBUG: Write data to device
2015-06-26 23:14:05, DEBUG: Return code from USB write: -110
2015-06-26 23:14:05, DEBUG: Read USB
2015-06-26 23:14:06, DEBUG: Return code from USB read: -110
2015-06-26 23:14:06, ERROR: Invalid result code: -110
2015-06-26 23:14:07, DEBUG: Read USB [flush]
2015-06-26 23:14:07, DEBUG: Return code from USB read: 16
2015-06-26 23:14:04, VOC: 21546, RESULT: Error value out of range
2015-06-26 23:14:17, DEBUG: Write data to device
2015-06-26 23:14:18, DEBUG: Return code from USB write: -110
2015-06-26 23:14:18, DEBUG: Read USB
2015-06-26 23:14:19, DEBUG: Return code from USB read: -110
2015-06-26 23:14:19, ERROR: Invalid result code: -110
2015-06-26 23:14:20, DEBUG: Read USB [flush]
2015-06-26 23:14:21, DEBUG: Return code from USB read: -110
2015-06-26 23:14:17, VOC: 21546, RESULT: Error value out of range
In Fhem kommt eigentlich gar nichts an. Vorhin stand kurz der Manufacture in den Internals. Aber ich habe noch keine VOC-Readings erhalten.
Fhem-Log
2015.06.26 23:13:39 3: CO20: CO20 device found
2015.06.26 23:13:39 3: CO20: CO20 device opened
2015.06.26 23:13:49 3: CO20: read failed
2015.06.26 23:13:49 3: CO20: disconnected
2015.06.26 23:13:49 3: CO20: CO20 device found
2015.06.26 23:13:49 3: CO20: CO20 device opened
2015.06.26 23:14:00 3: CO20: read failed
2015.06.26 23:14:00 3: CO20: disconnected
2015.06.26 23:14:00 3: CO20: CO20 device found
2015.06.26 23:14:02 3: CO20: failed to open CO20 device
2015.06.26 23:14:02 3: CO20: disconnected
2015.06.26 23:14:13 3: CO20: CO20 device found
2015.06.26 23:14:15 3: CO20: failed to open CO20 device
2015.06.26 23:14:15 3: CO20: disconnected
lsusb
Bus 001 Device 007: ID 03eb:2013 Atmel Corp.
dmesg
[ 7869.762721] usb 1-1.5: new full-speed USB device number 7 using dwc_otg
[ 7869.867003] usb 1-1.5: New USB device found, idVendor=03eb, idProduct=2013
[ 7869.867045] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 7869.867066] usb 1-1.5: Product: iAQ Stick
[ 7869.867085] usb 1-1.5: Manufacturer: AppliedSensor
/etc/udev/rules.d/99-usb.rules
# iAQ
SUBSYSTEM=="usb", ATTR{idVendor}=="03eb", ATTR{idProduct}=="2013", MODE="0666"
Was mich ein wenig wundert. Woher weiß das Fhem-Modul eigentlich, wo Airsensor installiert ist.
Oder wird direkt die USB-Schnittstelle abgefragt?
Erster Verdacht, hat sich die USB-Stromversorgung des B+ gegenüber den alten Rpi eigentlich verbessert? Falls nicht und um das als Fehlerquelle auszuschließen, würde ich einen aktiven (unbedingt kompatiblen!) Hub dazwischen schalten. Die unzureichende Stromversorgung war am alten Rpi ein echtes Ärgernis. Ich weiß nicht, ob das beim B+ besser geworden ist.
Wenn Du erwähnst "direkt" gehe ich davon aus, dass da kein Kabel mehr zwischen ist, was, wenn es zu lang ist, auch gerne zu Kommunikationsschwierigkeiten führen kann.
Um den Fehler weiter einzugrenzen vermute ich, hast Du den Stick an einer anderen "Maschine" mal getestet und die einwandfreie Funktion bestätigen konntest.
Sorry, ich habe mich mit dem B+ noch nicht beschäftigt, daher sind das alles nur Verdachtsmomente mit dem Versuch, mögliche Fehlerquellen auszuschließen.
Auf der Suche nach der Antwort zu Deiner letzten Frage, schau doch mal ins Modul hinein.
Schöne Grüße und viel Erfolg,
John
PS: Leider gibt es noch keinen Wikiartikel. Ich hätte da zwar auch Lust drauf, muss aber erstmal ein paar andere Projekte abschließen, bevor neue gestartet werden sollten. Die Chance, sich zu verewigen... :)
Ein Raspberry ist mit USB Geräten nicht sinnvoll zu verwenden, weil sich auch beim RPi2 nichts daran geändert hat dass der ganze Aufbau der Schnittstelle kompletter Mist ist.
Entweder es funktioniert so wie es soll, oder es funktioniert nicht - dann ist allerdings jede Sekunde die ihr darin investiert nur verschwendete Zeit.
Wirf das Ding in die Ecke und vergiss einfach, dass der RasPi einen USB Anschluss hat!
Ich habe den Stick ohne Hub angeschlossen. Einen Hub würde ich unteren nutzen, denn ich will die "Installation" optisch schlank und stromsparend halten. Ich hatte halt noch einen Stick rumfliegen und dachte das wäre einfach hinzubekommen. Ich habe sowieso überall echte CO-Sensoren von Kidde (Stand-Alone). Über Fhem wäre es "Schmuck am Nachthemd" gewesen. Ich traue den Sticks sowieso nicht. Unter Windows waren der PPM-Werte damals recht merkwürdig monoton. Meine Lüftungsanlage hatte immer feinere Werte ermittelt.
Danke dennoch. Vielleicht also ein anderes mal. :-)
Hat Markus jetzt aber sehr überspitzt formuliert. ;)
Bei mir laufen 4 CO2-Sensoren an 4 RasPis (alles über B, B+ und 2). Das hatte zwar auch ein paar Herausforderungen, wie man weiter vorn im Thread lesen kann, funktioniert aber jetzt sehr gut.
Den Thread hatte ich vorher gelesen. Den einzigen Unterschied, den ich bei mir habe, ist der nicht vorhandene USB Hub. Sonst sollte alles okay bei mir sein.
Hast du einen Hub?
Nein, ich habe keine Hubs dran, aber entsprechend starke Netzteile.
Hmm. Okay. Ich nahm an, dass 2A reichen sollten. Mal schauen.
Ich habe auch 2A Netzteile. Allerdings war nicht jedes laststabil.
Ich denke, Du hast da an anderer Stelle ein Problem. Du hast aber hier nichts über deine genau Installation geschrieben, noch über sonstige angeschlossene Devices, so dass man kaum eine Aussage treffen kann.
Du hast auch nicht geschrieben, ob Dein Stick am PC mit der offiziellen Software sauber funktioniert. Hast Du das schon probiert?
Ich kann mal ein paar Netzteile ausprobieren.
Ich habe derzeit den RasPi B+ mit HM-CFG-USB2 per hmland. Außerdem einen 433 MHz Transmitter@GPIO mit 5 Volt.
Der Stick lief unter Windows einwandfrei.
Ich habe ja nun noch ein paar Ansätze, die ich ausprobieren kann. Ich halte euch auf dem laufenden. Danke.
Also 3 Sticks mit dem Stromverbrauch dürften mit hoher Wahrscheinlichkeit ein Problem sein. Versuch einfach mal, ob es nur mit dem CO20 funktioniert.
Gibt es den/die Stick(s) auch noch in irgendeinem Onlineshop? Irgendwie finde ich die nirgendwo... (also keine Herstellerhotline sondern verfügbar in einem Shop)
Wenn Du nicht in der Lage bist, mit Velux ein Telefonat zu führen, eher nein.
Du kannst auch das Kontaktformular nutzen, um die Dinger zu bestellen:
http://www.velux.de/service/kontakt/privatkundenanfragen (http://www.velux.de/service/kontakt/privatkundenanfragen)
Ich habe am Dienstag endlich den Velux Raumluftfühler mit FHEM in Betrieb genommen.
Vor dem ersten Einstecken am RPi habe ich keine Veränderungen mit der Airquality Software vorgenommen.
Zunächst hat der Sensor noch nachvollziehbare Werte geliefert.
Irgendwann hat er sich dann für mein Empfinden aber auf einem zu hohen Niveau eingependelt.
Gestern Abend habe ich dann noch auf dem Laptop die Windows Airquality Software installiert und die Rekalibrierung beim Einstecken deaktiviert.
Das Ein- und Ausstecken erfolgte als der Sensor Draußen lag.
Heute Nacht habe ich den Sensor komplett Draußen liegen gehabt und er hat Werte zwischen 450 und 500 ppm gemessen.
Als ich ihn dann heute Früh ins Schlafzimmer zurückgeholt habe, maß er Werte um die 2000 ppm, bei gefühlt guter Luft (es wurde die ganze Nacht gelüftet und Morgens sogar noch auf Stoß). Seitdem dümpelt er auch zwischen 1700 - 2000 ppm - trotz Lüften und laufender Lüftungaanlage. :-[
Gibt es hinsichtlich der Kalibrierung einen Königsweg, damit der Fühler dauerhaft nachvollziehbare Werte liefert?
Also erfahrungsgemäß liefert er, zumindest bei mir, durchaus nachvollziehbare Werte und gerade, wenn er draußen 450 misst und drinnen einen so hohen Wert, würde ich mir mal Gedanken machen.
Der Sensor ist ein VOC Sensor, er misst also nicht direkt CO2, sondern andere Kohlenstoff-Verbindungen. Meist korreliert das gut, kann aber bei Ausdünstungen von neuen Möbeln, Teppichen etc. zu gravierenden Abweichungen führen.
Also mach Dir mal Gedanken, evtl. auch darüber, was da aus deiner erwähnten Lüftungsanlage kommt.
Hi,
also ich habe pro Stockwerk einen Raspi B+ mit CO20 (Velux) und deaktivierten Calibrieren. Ansteuerung per FHEM. Die Clients senden per CloneDummy an der Server Rapsi 2, der die Daten auswertet.
Die Dinger funktionieren bis auf ein paar kleine Ausreißer doch recht stabil. Wichtig bei der Kalibrierung finde ich ist, dass der Sensor nicht im Zug steht, denn der Sensor lebt von einem Heizelement im Inneren und Zugluft kühlt, bzw. verfälscht.
Ich kann an den Sensoren sogar erkennen, wenn wir den Windeleimer öffnen, bzw. die Frau sich früh fertig macht (Haarspray, Deo). Scheinbar ist es so, dass bei den zuletzt warmen Tagen auch die Luftfeuchtigkeit eine Rolle spielt, da sich über den Tag die Luft verschlechtert hat. Öffnet man das Fenster, geht der Wert schlagartig auf 450 retour.
Alles in allem funktioniert alles, ich bin zufrieden.
mfg
NaCkHaYeD
Danke für den Hinweis mit dem Zug.
Ich habe den Sensor nun mehrfach kalibriert und denke, dass er mittlerweile auf einem vernünftigem Niveau kalibriert ist.
Die ppm-Werte sind nun meist noch im grünen Bereich, aber leider eher im Bereich der 1000 als 450 ppm.
Hier werden wir in Zukunft die Lüftung wohl doch wieder auf einer höheren Drehzahl laufen lassen müssen.
In Kürze werde ich noch einen VOC-Luftkanalfühler von Sensorshop24 erhalten.
Interessant wird sein, ob sich die Werte beider Sensoren decken werden.
Die beiden Sensoren sollen dann mir den notwendigen Input geben, um über den analogen Ausgang meines Unipi-Boards die Lüftungsanlage (Paul Novus 300) zu steuern.
Hi Pepit082,
das mit dem Steuern der Lüftungsanlage - na ich weiß nicht - wie gesagt die Dinger funktionieren recht stabil, jedoch gibt es auch hier und da ein paar Ausreißer.
Ich persönlich habe auch mit dem Gedanken der Lüftungsanlage gespielt, hier sind jedoch meines Erachtens viele Punkte zu beachten.
Ich habe bei den zuletzt hohen Temperaturen bemerkt (wir haben viel Glasflächen, sowie eine Überkopfverglasung, ähnlich Gewächshaus), das die Luftqualität auch was mit der Temperatur, Luftfeuchtigkeit zu tun hat. Hätte ich dann tagsüber die Lüftung hochgedreht, hätte ich mir die warme Luft ins Haus geholt. Wichtiger war es die Lüftungsanlage tagsüber zu minimieren und in der Nacht die Fenster aufzureißen, denn per Lüftungsanlage ändert man nichts an der Haustemperatur.
Es ist richtig, dass wenn ich z.B. in der Nacht die Leistung die Anlage drossel (Geräuschkulisse) und tagsüber normal habe, dass sich über nach der ppm Wert aufbaut und tagsüber abbaut.
Aber selbst einen Wert über 1500 sehe ich über eine gewisse Zeit nicht als dramatisch an. Es ist ja eine relative Messung (kein. def. Bezugspunkt) und auch keine dauerhafte Einwirkung. Du gehtst ja auch mal an die frische Luft.
Interessant sind die Kurvenverläufe aber dann schon.
Zur Temperatur/Luftfeuchtigkeitsmessung habe ich mir die HTU21D Chips zugelegt. Hierzu gibt es das I2C_SHT21 Modul mit identer Ansteuerung. Gibt's in diversen Shops um die €15.
mfg
NaCkHaYeD
Erweiterte Version mit Doku, fertig für den Checkin ins SVN
Danke für die Mühe. Hast Du am Code noch Änderungen vorgenommen ggü. der letzten Version?
Zitat von: volschin am 25 Juli 2015, 05:57:53
Danke für die Mühe. Hast Du am Code noch Änderungen vorgenommen ggü. der letzten Version?
Nein, nur die Doku ist neu.
ist eingecheckt.
gruss
andre
Hi,
ich habe mit der neuen Version unter Windows Probleme.
Er trennt sich immer und danach muss ich ihn komplett neu einstecken, damit das libusb Diagnosetool ihn überhaupt wieder erkennt.
Hier ein Auszug aus den Log:
2015.08.15 16:23:46.913 3: co20: CO20 device found
2015.08.15 16:23:46.914 3: co20: CO20 device opened
2015.08.15 16:23:47.936 3: NTFY return: co20:-116
2015.08.15 16:23:56.916 1: PERL WARNING: Use of uninitialized value in subroutine entry at C:/Perl/site/lib/Device/USB/Device.pm line 748.
2015.08.15 16:23:56.967 1: PERL WARNING: Use of uninitialized value in numeric ge (>=) at ./FHEM/38_CO20.pm line 310.
2015.08.15 16:23:56.967 3: co20: disconnected
2015.08.15 16:24:01.968 3: co20: filed to find CO20 device
2015.08.15 16:26:47.824 2: co20: no device
2015.08.15 16:26:47.824 3: co20: disconnected
2015.08.15 16:26:47.826 3: co20: CO20 device found
2015.08.15 16:26:47.828 3: co20: CO20 device opened
2015.08.15 16:26:57.886 3: co20: disconnected
2015.08.15 16:27:02.887 3: co20: filed to find CO20 device
In Device.pm steht ab Zeile 748:
my $retlen = Device::USB::libusb_interrupt_read(
$self->{handle}, $ep, $bytes, $size, $timeout
);
Habt ihr eine Idee? Ich hoffe, es ist kein zu spezielles Windows-Problem.
Ich verwende übrigens ActivePerl 5.16.3.
Ich habe jetzt erstmal zur alten Version von co20 zurückgewechselt.
Gruß
Spiff.
Zitat von: Spiff am 15 August 2015, 17:18:39
Habt ihr eine Idee? Ich hoffe, es ist kein zu spezielles Windows-Problem.
Ich verwende übrigens ActivePerl 5.16.3.
Ich habe jetzt erstmal zur alten Version von co20 zurückgewechselt.
Setz bitte testhalber mal die Attribute
retries und
timeout (z.B. 3/10) und probier es nochmal mit der aktuellen Version.
Wenn es damit klappt dann hab ich das verbockt - sorry.
Andre, bitte die Version im Anhang zeitnah einchecken - hab vergessen ein paar Variablen zu initialisieren :-\
Markus
Hallo Markus!
Zitat von: Markus M. am 15 August 2015, 17:51:15
Setz bitte testhalber mal die Attribute retries und timeout (z.B. 3/10)...
Brauchte ich nicht, geht jetzt auch so (oder soll ich?).
Super, vielen Dank!! Der Abend ist gerettet. :-)
Im Übrigen kann ich jetzt auch
advanced 1 setzen, ohne es als globales Attribut definieren zu müssen, das ging vorher irgendwie auch nicht. Kann aber auch mein Fehler eines fehlenden shutdown restart gewesen sein.
Danke nochmal & viele Grüße
Spiff
Zitat von: Spiff am 15 August 2015, 18:02:21Brauchte ich nicht, geht jetzt auch so (oder soll ich?).
Du meinst mit der Version aus dem Anhang?
Wenn du die genommen hast zeigt mir das natürlich auch, dass das Problem daran lag :)
Hmm... Entweder hatten sonst alle ausser dir die Attribute bereits gesetzt, seit 3 Wochen kein Update gemacht oder es fliegt einem tatsächlich nur bei Windows um die Ohren.
Na egal, alles wird gut ;)
Ja, die Version aus dem Anhang funktioniert jetzt. Ich habe die alte nochmal gegengecheckt. Fehler in der neuen Version behoben. advanced ging vorher auch schon, das nehme ich auf meine Kappe. :)
Viele Grüße
Spiff
einchecken oder nicht :) ?
gruss
andre
Zitat von: justme1968 am 15 August 2015, 18:31:50
einchecken oder nicht :) ?
Definitiv :)
timeout und
retries waren nicht initialisiert, was das USB Modul von Windows leider nicht vertragen hat.
Hab grade nachgesehen und hatte die Attribute selbst auch nicht gesetzt gehabt - Linux User waren also nicht betroffen.
Ich hab jetzt mal Standardwerte von 10sec und 3x gesetzt, das sollte funktionieren.
Ich glaube ich sollte mich langsam mal um einen Dev Account bemühen...
hab es eingecheckt.
gruss
andre
Ach so, gibt es eigentlich überhaupt die Möglichkeit, mehrere Sticks an einem PC zu unterscheiden? Ich habe bisher nur einen Stick, überlege aber, mehr davon zu kaufen, falls das irgendwann mal geht. Es wäre natürlich schade, wenn die Werte dann bunt und zufällig durcheinandergewürfelt würden. :)
Gruß
Spiff
du kannst im define bus:device mit angeben. dann wird die automatische suche deaktiviert und du sprichst ein konkretes device direkt an.
beides bekommst du per lsusb.
du musst aber sicher stellen das sich die reihenfolge am bus nicht ändert. also alles aus. beide sticks rein und dann booten. am besten zwei drei mal und jeweils nach den werten schauen.
wenn du zusätzliche devices an den usb bus anschliesst kann sich die nummerierung nach einem neustart ändern.
da die dinger scheinbar keine eindeutige id oder seriennummer haben geht es so viel ich weiss leider nicht genauer.
gruss
andre
Zitat von: justme1968 am 15 August 2015, 19:27:20da die dinger scheinbar keine eindeutige id oder seriennummer haben geht es so viel ich weiss leider nicht genauer.
Euer Einstieg falls ihr es reinbasteln wollt:
get co20device stick_data -> $hash->{SERIALNUMBER} ;)
Ah cool, dann ginge es also doch noch besser!
Meiner z.B. hat 48313631373015082216 (uffz!) als Serialnumber.
Wie würde man das am besten machen? Ich denk mal laut, vielleicht kann ich versuchen, das einzubauen.
Wenn das define in meinem Fall dann so aussieht: define co20-Wohnzimmer co20 48313631373015082216
müsste ja erstmal über das Modul eine Verbindung zum ersten co20-Stick hergestellt werden, über das get stick_data die Serialnumber herausgefunden werden und wenn die gleich der im define stehenden Nummer ist, wird die Adresse für das zu definierende Gerät übernommen. Wenn nicht: weiter zum nächsten Stick.
Das Aktualisieren der Seriennummer sollte man immer direkt nach dem Connect und vor der Zuordnung zur Aktualisierung durchführen, falls 2 Sticks die Adresse getauscht haben und auf das dann falsche gespeicherte Internal zugegriffen würde.
Dann müsste man wahrscheinlich noch einbauen, dass er es nicht in einer Endlosschleife immer wieder von vorne versucht, sobald alle Sticks abgefragt wurden und kein passender dabei war, oder? Obwohl... er soll ja eigentlich auch merken, wenn ein Stick eingesteckt wird.
Gruß
Spiff.
ich würde es etwas anders machen:
bei einem bestimmten parameter (z.b. MASTER) geht das modul beim starten alle sticks durch und legt automatisch für jeden ein stick ein device an.
das definieren von hand würde ich nur als notlösung sehen weil man erst etwas anlegen muss um die id zu bekommen und dann damit erst das eigentliche device anlegen kann.
also kann man es auch gleich automatisieren.
oder fällt jemandem ein fall ein bei dem mehr als ein stick am system steckt aber nur einer eingebunden werden soll?
gruss
andre
Zitat von: justme1968 am 15 August 2015, 21:26:00
bei einem bestimmten parameter (z.b. MASTER) geht das modul beim starten alle sticks durch und legt automatisch für jeden ein stick ein device an.
Du meinst, sofern der gefundene Stick nicht schon angelegt wurde?
Zitat von: justme1968 am 15 August 2015, 21:26:00
oder fällt jemandem ein fall ein bei dem mehr als ein stick am system steckt aber nur einer eingebunden werden soll?
Nein, das dürfte im Normalfall niemand wollen. :-)
Das mit dem Autocreate finde ich super! Ist man ja auch schon von HM-Geräten z.B. "gewohnt". :)
Also du würdest IMMER einen Master definieren, der auch definiert bleibt? Was ist mit plug-&-pray-Funktionalitäten? Mir wäre ein automatisches Suchen, sobald ein solcher Stick eingesteckt wird, lieber, als es manuell anzustoßen - oder meintest du die Master-Geschichte nur, wenn man neu anfängt bzw. einen neuen Stick hinzufügen will? Das wäre gut!
Ich würde es gut finden, wenn die gleichen Commandos wie bei den anderen Modulen verwendet werden, in dem Fall wäre"autocreate" vielleicht richtig? Schon vorhandene Sticks neu zu organisieren, weil man die Sticks von Wohnzimmer und Schlafzimmer ausgetauscht hat, sollte kaum vorkommen.
Und wenn, um sicher zu gehen:
vielleicht kann man zum Identifizieren die LED der Sticks benutzen: bei einem
set co20 identify könnte man
KNOB_CO2_VOC_level_warn2 einmal auf 0 setzen, dann auf einen extrem hohen Wert, das 3x wiederholt und dann wieder auf den ursprünglichen Wert. Wenn die LED darauf "live" reagiert, müsste der jeweilige Stick rot blinken. Vorraussetzung ist natürlich, dass man den ursprünglichen Wert auslesen kann, damit man nichts verstellt.
Gruß
Spiff
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
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
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.
So ist es, bei mir hat auch jeder Stick seinen eigenen RasPi, die per FHEM2FHEM über WLAN angekoppelt sind. Kein Kabelsalat.
Zitat von: volschin am 16 August 2015, 00:32:05So 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?
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.
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.
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.
Zitat von: volschin am 16 August 2015, 17:21:53
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?!
$hash->{timeout} = AttrVal($name,"timeout",1000);
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.
Zitat von: volschin am 16 August 2015, 17:55:03
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)
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.
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):
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?
Zitat von: PEPITO82 am 18 August 2015, 08:07:45
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.
Zitat von: Markus M. am 18 August 2015, 11:14:38
Setz den Wert doch mal auf 1000 und schau ob es das besser macht.
Leider nein:
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 openedDer 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.
Hattest du retries und timeout vorher auch schon gesetzt gehabt?
Das scheint leider mal wieder so ein Fall zu sein in dem Windows völlig anders reagiert.
Hat noch jemand dieses Verhalten seit dem Update?
Hattest du retries und timeout vorher auch schon gesetzt gehabt?
Das scheint leider mal wieder so ein Fall zu sein in dem Windows völlig anders reagiert.
Hat noch jemand dieses Verhalten seit dem Update?
Retries und Timeout hatte ich zuvor nicht gesetzt.
Lediglich Interval = 60.
Hallo zusammen,
ich bin gerade dabei Teile meiner Plots auf DBLog umzustellen. Die Luftqualität mit der Ampelfarben-Notation habe ich aber noch nicht hinbekommen.
Mein aktueller Code sieht jetzt so aus:
#DbLog <SPEC1>:voc::$fld[3]>1000?1000:$fld[3]
#DbLog <SPEC1>:voc::$fld[3]>1500?1500:$fld[3]
#DbLog <SPEC1>:voc::$fld[3]>4000?4000:$fld[3]
#DbLog <SPEC1>:voc:0:
plot "<IN>" using 1:2 axes x1y2 title '.' ls l1fill lw 0.2 with lines,\
"<IN>" using 1:2 axes x1y2 title '.' ls l4fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title '.' ls l0fill lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title '.' ls l7 lw 1 with lines
Das funktioniert schon insoweit, dass die Kurve komplett in grün angezeigt wird. Ich habe im Wiki gelesen, dass ich $fld[] auf $val umstellen muss, habe es aber noch nicht so ganz verstanden.
Beginnen müsste es wohl so
#DbLog <SPEC1>:voc:::$val
Kann mir jemand auf die Sprünge helfen?
Gruß
Veit
Manchmal klären sich die Dinge dann doch schneller. Immer noch nicht komplett verstanden, aber es funktioniert.
#DbLog <SPEC1>:voc:::$val=($val>1000?1000:$val)
#DbLog <SPEC1>:voc:::$val=($val>1500?1500:$val)
#DbLog <SPEC1>:voc:::$val=($val>4000?4000:$val)
#DbLog <SPEC1>:voc:0:
hab die version von hier: http://forum.fhem.de/index.php/topic,13166.msg323200.html#msg323200 (http://forum.fhem.de/index.php/topic,13166.msg323200.html#msg323200) eingecheckt.
gruss
andre
Ich bin gerade etwas am Rätsel, wie man den CO-20 Homekit beibringen sollte.
Es kennt folgende Charakteristiken:
/**
* Characteristic "Air Particulate Density"
*/
Characteristic.AirParticulateDensity = function() {
Characteristic.call(this, 'Air Particulate Density', '00000064-0000-1000-8000-0026BB765291');
this.format = 'float';
this.maximumValue = 1000;
this.minimumValue = 0;
this.stepValue = 1;
this.readable = true;
this.supportsEventNotification = true;
this.value = this.getDefaultValue();
};
inherits(Characteristic.AirParticulateDensity, Characteristic);
/**
* Characteristic "Air Particulate Size"
*/
Characteristic.AirParticulateSize = function() {
Characteristic.call(this, 'Air Particulate Size', '00000065-0000-1000-8000-0026BB765291');
this.format = 'uint8';
this.readable = true;
this.supportsEventNotification = true;
this.value = this.getDefaultValue();
};
inherits(Characteristic.AirParticulateSize, Characteristic);
// The value property of AirParticulateSize must be one of the following:
Characteristic.AirParticulateSize._2_5_M = 0;
Characteristic.AirParticulateSize._10_M = 1;
/**
* Characteristic "Air Quality"
*/
Characteristic.AirQuality = function() {
Characteristic.call(this, 'Air Quality', '00000095-0000-1000-8000-0026BB765291');
this.format = 'uint8';
this.readable = true;
this.supportsEventNotification = true;
this.value = this.getDefaultValue();
};
inherits(Characteristic.AirQuality, Characteristic);
// The value property of AirQuality must be one of the following:
Characteristic.AirQuality.UNKNOWN = 0;
Characteristic.AirQuality.EXCELLENT = 1;
Characteristic.AirQuality.GOOD = 2;
Characteristic.AirQuality.FAIR = 3;
Characteristic.AirQuality.INFERIOR = 4;
Characteristic.AirQuality.POOR = 5;
AirParticulateSize ist nicht zu gebrauchen, Air Particulate Density ist auf 1000 begrenzt und funktioniert möglicherweise nur zusammen mit Size. Muss man nochmal probieren. Möglicherweise ließe sich Density missbrauchen, indem man den ppm Wert durch 10 teilt und nach oben abriegelt.
In einem ersten Schritt fände ich es gut ein Reading für AirQuality einzubauen. Das könnte man zwar auch als Userreading, aber es muss ja nicht jeder für sich machen.
Die Frage ist, wie man die Schwellen umrechnet und ob das evtl. über Attribut konfigurierbar sein sollte.
Meine Idee wäre:
UNKNOWN = 0; bei Disconnected
EXCELLENT = 1; <=600
GOOD = 2; >600
FAIR = 3; >800
INFERIOR = 4; >1000
POOR = 5; >1500
Was denkt Ihr?
Es gibt auch noch
/**
* Characteristic "Carbon Dioxide Level"
*/
Characteristic.CarbonDioxideLevel = function() {
Characteristic.call(this, 'Carbon Dioxide Level', '00000093-0000-1000-8000-0026BB765291');
this.format = 'float';
this.maximumValue = 100000;
this.minimumValue = 0;
this.stepValue = 100;
this.readable = true;
this.supportsEventNotification = true;
this.value = this.getDefaultValue();
};
inherits(Characteristic.CarbonDioxideLevel, Characteristic);
/**
* Characteristic "Carbon Dioxide Peak Level"
*/
Characteristic.CarbonDioxidePeakLevel = function() {
Characteristic.call(this, 'Carbon Dioxide Peak Level', '00000094-0000-1000-8000-0026BB765291');
this.format = 'float';
this.maximumValue = 100000;
this.minimumValue = 0;
this.stepValue = 100;
this.readable = true;
this.supportsEventNotification = true;
this.value = this.getDefaultValue();
};
inherits(Characteristic.CarbonDioxidePeakLevel, Characteristic);
CarbonDioxideLevel passt am Besten für den Wert, auch wenn der stepValue = 100 nicht optimal ist, aber für die Genauigkeit muss das dann ausreichend sein.
Gruß
Veit
Zitat von: volschin am 20 August 2015, 09:32:09
Ich bin gerade etwas am Rätsel, wie man den CO-20 Homekit beibringen sollte.
Wieso? CO2 passt eindeutig am besten.
Mit Partikeln hat hat das hier ja nicht wirklich was zu tun.
Das wäre eher was für Pollenbelastung, Sandstürme etc. :)
Ich bin gerade etwas am Rumtesten. Leider lässt sich CO2 nur in Verbindung mit einem ist erhöht oder nicht abfragen.
Da gibt es wirklich nichts für Air Quality?
Was benutzt dann z.B. der Elgato Eve Sensor?
Ich bin gerade noch am Testen. Für einen bestimmten Service gibt es nur bestimmte Characteristics, die Du verwenden darfst. Allerdings kannst Du ein Accessory wieder aus mehreren Services zusammenbauen. Und da sind das dann evtl. AirQuality und CarbonDioxid Sensor.
Sent from my iPhone using Tapatalk
in der standart liste ist in der richtung nichts dabei.
elgato verwendet vermutlich einen custom service dafür. das geht eigentlich problemlos. mache ich für das volume der sonos devices auch.
der haken ist das es nicht mit siri integriert ist.
wenn jemand raus bekommt was elgato für eine id verwendet wäre die Integration vermutlich besser. das gleiche gilt für den tür und fenster sensor. ich vermute die graphen die es auf den eve screenshots zu sehen gibt basieren auch auf custom services.
gruss
andre
Hallo zusammen,
habe mal versucht, mich durch den ganzen Thread zu lesen, um für mich eine Anleitung zu finden wie ich den Sensor nun in Betrieb nehmen soll.
Ich darf mal zusammen fassen:
- Die Windows Software ist nicht mehr nötig, da mit advanced = 1 , sich alles einstellen lässt.
- Die Autokalibrierung sollte abgeschaltet werden mit KNOB_ui16StartupBits = 0
- Vor Inbetriebnahme, am besten an frischer Luft mit einem USB-Netzteil mal ein paar Stunden laufen lassen
- Also dann einfach das Ding an meinem Rpi anschließen (ausreichendes Netzteil vorhanden), etwas warten und dann define ....
Läuft denn nun das Teil zuverlässig oder nicht, die Aussagen sind doch recht widersprüchlich.
Im Voraus Vielen Dank
Hallo Rampler,
korrekt beschrieben.
Und ja, es läuft stabil. Wichtig ist ein laststabiles Netzteil für den RPi und auch die Messfrequenz. Mit der aktuellen Version habe ich keine Probleme, meine Messfrequenz ist 5 Minuten.
Gruß
Veit
Zitat von: Rampler
- Vor Inbetriebnahme, am besten an frischer Luft mit einem USB-Netzteil mal ein paar Stunden laufen lassen
- Also dann einfach das Ding an meinem Rpi anschließen (ausreichendes Netzteil vorhanden), etwas warten und dann define ....
Läuft denn nun das Teil zuverlässig oder nicht, die Aussagen sind doch recht widersprüchlich.
Anstecken und definieren, Raum gut lüften während der burn-in Phase die ca. 30h dauert, morgen mal gucken ob die Werte passen und dann die Kalibrierung einfach abschalten.
Das Modul läuft stabil genug, solange du nicht wie weiter oben ne ganze Spule Kabel dazwischen klemmst ;)
@Markus M. & @volschin
erstmal DANKE :)
30h ist schon lange, aber wenn's was bringt... (mach ich jedenfalls)
Habe heute mal drei Stück bestellt, einer soll auf RPI und zwei unter FEHM2FHEM (openwrt) laufen, bin mal gespannt...
So, die Sensoren sind da...
Allerdings sehe ich nur einen disconnect...
2015.09.04 15:09:51 3: IAM: CO20 device found
2015.09.04 15:09:51 3: IAM: failed to open CO20 device
2015.09.04 15:09:51 3: IAM: disconnected
2015.09.04 15:09:51 2: IAM: no device
2015.09.04 15:09:51 3: IAM: CO20 device found
2015.09.04 15:09:51 3: IAM: failed to open CO20 device
2015.09.04 15:09:51 3: IAM: disconnected
2015.09.04 15:11:05 2: IAM: no device
2015.09.04 15:11:05 3: IAM: CO20 device found
2015.09.04 15:11:05 3: IAM: failed to open CO20 device
2015.09.04 15:11:05 3: IAM: disconnected
Der lsusb -v -d 03eb:2013 sagt:
Bus 001 Device 010: ID 03eb:2013 Atmel Corp.
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 32
idVendor 0x03eb Atmel Corp.
idProduct 0x2013
bcdDevice 10.00
iManufacturer 1
iProduct 2
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 41
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 53
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 10
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 10
Wo muss ich denn die USb rule kodieren ?
SUBSYSTEM=="usb", ATTR{idVendor}=="03eb", ATTR{idProduct}=="2013", MODE="0666"
Habe jetzt mal eine /etc/udev/rules.d/50-usbsticks.rules erstellt und neu gestartet, leider ohne Erfolg...
JETZT TUTS...
die Rule muss zwingend 99-usb.rules heißen
Nachdem ich den Sensor nun erfolgreich in Betrieb genommen habe ich nun doch noch einige Fragen.
Möchte mit
set AZ.iam KNOB_ui16StartupBits 0
die automatische Kalibrierung abschalten.
Eine Abfrage mit:
get AZ.iam knob_data
zeigt dass der Wert immer noch auf 1 steht.
Stattdessen sehe ich folgende Fehlermeldungen:
2015.09.05 22:16:00 1: PERL WARNING: substr outside of string at ./FHEM/38_CO20.pm line 543.
2015.09.05 22:16:00 1: PERL WARNING: Use of uninitialized value in ord at ./FHEM/38_CO20.pm line 54
Bitte das Ganze mal mit Loglevel (verbose) 5 posten.
(Und vorher einmal kurz den Stick neu anstecken)
Woran lag es eigentlich dass es vorher nicht gleich geklappt hatte?
Zitat von: Markus M. am 05 September 2015, 23:15:02
Bitte das Ganze mal mit Loglevel (verbose) 5 posten.
(Und vorher einmal kurz den Stick neu anstecken)
Woran lag es eigentlich dass es vorher nicht gleich geklappt hatte?
Also, habe mal nur für den get AZ.iam knob_data das verbose auf 5 gesetzt:
2015.09.06 13:26:21 5: Cmd: >get AZ.iam knob_data<
2015.09.06 13:26:21 4: getdata write -110
2015.09.06 13:26:21 5: datalen 0
Merkwürdigerweise funktioniert es ab und zu...
Das sieht leider wie das "übliche" Raspi Problem mit USB aus.
Setz mal den Timeout hoch, ansonsten gibt es leider nicht viel was du tun kannst.
(Abgesehen vom üblichen Hokuspokus mit anderen Netzteilen, Kabeln, USB 1.0 Settings, etc.)
Zitat von: Markus M. am 06 September 2015, 21:25:18
Das sieht leider wie das "übliche" Raspi Problem mit USB aus.
Setz mal den Timeout hoch, ansonsten gibt es leider nicht viel was du tun kannst.
(Abgesehen vom üblichen Hokuspokus mit anderen Netzteilen, Kabeln, USB 1.0 Settings, etc.)
Danke Markus,
auf USB 1.0 via cmdline.txt habe ich bereits umgestellt...
Glaube dass das einzige, was evtl. eine Besserung bringt ist der Timeout ...
Ist aber alles sehr zeitraubend, werde wohl weiter testen.
Wenn man nichts verändert läuft es eigentlich sehr gut... ;)
Wahrscheinlich kommen diese Meldungen von den Timeouts oder ?
2015.09.06 21:28:20 1: PERL WARNING: substr outside of string at ./FHEM/38_CO20.pm line 543.
2015.09.06 21:28:20 1: PERL WARNING: Use of uninitialized value in ord at ./FHEM/38_CO20.pm line 543.
2015.09.06 13:56:08 1: PERL WARNING: substr outside of string at ./FHEM/38_CO20.pm line 408.
2015.09.06 13:56:08 1: PERL WARNING: Use of uninitialized value in ord at ./FHEM/38_CO20.pm line 408.
Trotzdem machen mich solche Meldungen nervös...
bis denne
Zitat von: Rampler am 06 September 2015, 22:05:20
Danke Markus,
auf USB 1.0 via cmdline.txt habe ich bereits umgestellt...
Glaube dass das einzige, was evtl. eine Besserung bringt ist der Timeout ...
Ist aber alles sehr zeitraubend, werde wohl weiter testen.
Wenn man nichts verändert läuft es eigentlich sehr gut... ;)
Unter Umständen.
Das Problem ist, dass der RasPi mit dem Stick Probleme bekommen kann, sobald mehr als ein Datenpaket in kurzer Abfolge geschickt wird.
Das passiert immer dann wenn z.B. die Stick-Infos abgefragt werden.
Im schlimmsten Fall musst du die Settings doch mit Windows machen und unter FHEM die Finger von den Settings lassen.
ZitatWahrscheinlich kommen diese Meldungen von den Timeouts oder ?
2015.09.06 21:28:20 1: PERL WARNING: substr outside of string at ./FHEM/38_CO20.pm line 543.
2015.09.06 21:28:20 1: PERL WARNING: Use of uninitialized value in ord at ./FHEM/38_CO20.pm line 543.
2015.09.06 13:56:08 1: PERL WARNING: substr outside of string at ./FHEM/38_CO20.pm line 408.
2015.09.06 13:56:08 1: PERL WARNING: Use of uninitialized value in ord at ./FHEM/38_CO20.pm line 408.
Genau. Hier werden Daten erwartet die nicht da sind weil sie der Stick nicht geliefert hat bzw. das Kommando erst gar nicht angenommen hat.
ZitatTrotzdem machen mich solche Meldungen nervös...
Weichei :)
Die Version im Anhang macht das zwar nicht besser, sollte aber die Meldungen nicht mehr als unschöne Warnung ausgeben.
Probier das doch mal aus.
Gruss, Markus
ZitatWeichei :)
Die Version im Anhang macht das zwar nicht besser, sollte aber die Meldungen nicht mehr als unschöne Warnung ausgeben.
Probier das doch mal aus.
Gruss, Markus
Guten Morgen Markus,
sieht gut aus, konnte bis jetzt die Meldungen nicht mehr provozieren. :)
Gruss Klaus
Zitat von: MarcoR am 05 Mai 2014, 07:26:03
Hallo alle Miteinander.
Hat jemand den C02-Stick schon mal unter OpenWRT zum laufen gebracht ?
-> ATTITUDE ADJUSTMENT (12.09, r36088)
Weil hier hab ich weder das Perl-Usb Packet finden können,
noch scheint unter dem Ding das Perl-Cpan Modul vernünftig zu laufen.
-> perl -MCPAN -e shell
liefert
Untagged opnames: ne i_le sc ... <snip>
Can't locate object method "maybe_command" via package "MM" at /usr/lib/perl5/5.10/CPAN.pm line 1140.
Compilation failed in require.
BEGIN failed--compilation aborted.
Gruß
Marco
Hallo Marco,
bist Du weiter gekommen ?
Habe hier ein relativ neues Image r46584 Chaos Calmer (self compiled), der Fehler ist der gleiche ! :(
Hab mal zum Test alle PERL Module installiert.
Gruß Klaus
cpan alleine wäre aber auch noch nichts nützen. du brauchst ein komplettes perl inklusive native schnittstelle, ein kompiler und die native libusb inklusive developer headern.
ich denke du sparst die sehr sehr viel arbeit wenn du plattform wechselst und zumindest den usb stick an einem anderen direkt unterstützten system betreibst.
gruss
andre
Vermutlich muss dafür erst mal libusb in der richtigen Version mit in OpenWrt kompiliert werden.
Als nächstes dürftest du dann über eine ganze Menge Dependencies stolpern die fehlen.
Wenn du das irgendwie hinbekommst, veröffentliche doch bitte die Konfiguration hier :)
Andre: Vermutlich geht es hier um Hardware, auf der nichts anderes als OpenWrt läuft
Zitat von: Markus M. am 06 September 2015, 22:50:02
Weichei :)
Die Version im Anhang macht das zwar nicht besser, sollte aber die Meldungen nicht mehr als unschöne Warnung ausgeben.
Probier das doch mal aus.
Gruss, Markus
Hallo Markus,
heute ist wieder eine Meldung gekommen:
PERL WARNING: substr outside of string at ./FHEM/38_CO20.pm line 408.
2015.09.08 14:02:51 1: PERL WARNING: Use of uninitialized value in ord at ./FHEM/38_CO20.pm line 408.
Dumme Frage, Du hast nicht zufällig ein Update gemacht und die Datei überschrieben?
Zitat von: volschin am 08 September 2015, 17:37:50
Dumme Frage, Du hast nicht zufällig ein Update gemacht und die Datei überschrieben?
Klar habe ich, dachte dass die "neue" Version eingecheckt wurde...
Ist ja aber noch da, werde einfach nochmal kopieren ..
Findet das Update/Korrektur den Weg in die Repository ?
gruß Klaus
Ja, tut es :)
Ich werde künftig die Pflege des Moduls von Andre übernehmen und habe auch seit gestern SVN Schreibzugriff.
Ich checke die Änderung dann heute Abend mal ein.
edit: erledigt, ist im SVN
Markus
Zitat von: Markus M. am 09 September 2015, 08:36:57
edit: erledigt, ist im SVN
Da sage ich doch einfach mal DANKE ;)
Hallo Markus,
habe heute wieder noch einigen Commands diese Fehlermeldung erhalten:
PERL WARNING: substr outside of string at ./FHEM/38_CO20.pm line 543.
2015.09.11 12:16:01 1: PERL WARNING: Use of uninitialized value in ord at ./FHEM/38_CO20.pm line 543.
Eine Meldung ist jedenfalls weg...
Gruß Klaus
Hat jemand noch eine Bezugsquelle für diesen Stick? Ich kann denn nirgends mehr finden.
Zitat von: traxanos am 11 September 2015, 15:08:16
Hat jemand noch eine Bezugsquelle für diesen Stick? Ich kann denn nirgends mehr finden.
Den Stick gibt's bei VELUX, leider kann dieser nur telefonisch bestellt werden. Ist aber kein Problem, ich habe drei bestellt, kamen auch prompt (2 Tage Lieferzeit). Die Rechnung kommt ein paar Tage später, also alles bestens...
Telefonische Bestellung
Privatkundenbetreuung: 01806/33 33 99
Montag bis Freitag von 8 bis 17 Uhr.
(20 Cent inkl. MwSt. pro Anruf aus dem deutschen Festnetz. Mobilfunkhöchtpreis: 60 Cent / Anruf inkl. MwSt.)Guckst Du hier:
http://www.velux.de/produkte/lueftungsloesungen-belueftung/raumluftfuehler (http://www.velux.de/produkte/lueftungsloesungen-belueftung/raumluftfuehler)
Wenn man die Schalter etc. erstmal verstanden hat, funktionieren die Teile echt super...
gruß Klaus
@volschin: es gibt (inzwischen?) einen air quality service mit möglichen werten von 1-5. das würde genau passen.
Zitat von: volschin am 20 August 2015, 09:32:09
Die Frage ist, wie man die Schwellen umrechnet und ob das evtl. über Attribut konfigurierbar sein sollte.
Meine Idee wäre:
UNKNOWN = 0; bei Disconnected
EXCELLENT = 1; <=600
GOOD = 2; >600
FAIR = 3; >800
INFERIOR = 4; >1000
POOR = 5; >1500
Was denkt Ihr?
ich würde das erst mal so einbauen.
gruss
andre
Genau aus dem File für HomeKit kam die Idee.
Machst Du die Stufen konfigurierbar?
Hallo zusammen,
neulich war die Rede von openwrt und co20..., ob also der USB Stick unter openwrt erkannt wird.
Habe jetzt auf meinem Router TPLINK ArcherC7 (mips Architektur) Fhem mit USB Unterstützung für PERL am laufen.
Soll heißen, dass auf openwrt der CO20 USB Stick erkannt wird.
Ebenso bin ich der Meinung dass ab sofort auch kein SER2NET Umweg mehr nötig ist, um unter openwrt einen CUL-Stick anzusprechen.
Möglich wurde das, weil ein Entwickler für openwrt bei github das Paket perl-device-usb zur Verfügung gestellt hat (auf meine Anfrage). ;)
gruß Klaus
Cool!
Hast du eine Anleitung, was man tun muss um auf einem minimalen OpenWrt den Stick zu verwenden?
Zitat von: Markus M. am 15 September 2015, 23:13:44
Cool!
Hast du eine Anleitung, was man tun muss um auf einem minimalen OpenWrt den Stick zu verwenden?
Schon, ist die Frage, wo fange ich an...
Baust Du dir Dein Openwrt Image (Buildroot) selbst, oder nimmst Du ein fertiges bin File ?
Für den Fall, dass Du Dir ein eigenes Image bastelst, brauchst du nur die folgenden Quellen (über make menuconfig auswählen):
- kmod-usb-storage (Kernel Modules ==> USB Support)
- kmod-fs-ext4 (Kernel Modules ==> Filesystem)
- block-mount (Base System)
- e2fsprogs (Utilities ==> Filesystem mkfs.ext4..)
- fdisk (Utilities ==> disc)
- swap-utils ((Utilities ==> disc)
- tar (utilities)
- perl
- perl-www
- perl-xml-parser
- perlbase-math
- perlbase-autoloader
- perl-device-usb
Die Beschreibung in den Klammern, soll helfen die Einträge im menuconfig zu finden.
Wie gesagt, das einzige, was neu ist, ist das Modul "
perl-device-usb".
Es gibt ja auch schon ein wiki für fhem auf openwrt.
http://www.fhemwiki.de/wiki/OpenWRT (http://www.fhemwiki.de/wiki/OpenWRT)
Da mein Router genug Speicher hat, kann ich alle Module direkt in den Speicher legen. Auf dem USB-Speicherstick ist also nur FHEM und SWAP..
Gruß Klaus
Selbst da drauf läuft FHEM mit USB Support für den CO20 Stick:
http://www.amazon.de/TripMate-tragbarer-Flash-Speicher-Leserger%C3%A4t-Smartphones/dp/B00JE5GFFG (http://www.amazon.de/TripMate-tragbarer-Flash-Speicher-Leserger%C3%A4t-Smartphones/dp/B00JE5GFFG)
Stick anschließen und dann FHEM2FHEM die VOC Werte and den RPI übertragen, funktioniert wunderbar...
Habe das dazugehörige Flash File erstellt ...
Guckst Du ...
Warum eigentlich so kompliziert mit Perl, FHEM, FHEM2FHEM etc.? Ist es nicht einfacher, den Wert regelmäßig mit dem Programm airsensor auszulesen und per telnet bei FHEM einzuliefern? Da braucht man nur das eine Programm, keine Abhängigkeiten etc.
Zitat von: vbs am 19 September 2015, 20:13:33
Warum eigentlich so kompliziert mit Perl, FHEM, FHEM2FHEM etc.? Ist es nicht einfacher, den Wert regelmäßig mit dem Programm airsensor auszulesen und per telnet bei FHEM einzuliefern? Da braucht man nur das eine Programm, keine Abhängigkeiten etc.
Da hast Du eigentlich recht...., muss ich mir ansehen, habe ich irgendwie gar nicht in Betracht gezogen..
Zumal, es auf schwacher Hardware sicherich perfomanter wäre!
Hallo ,
Habe mir gerade bei Velux auch den Stick geordert für 19,50E, weil ich ihn sonst nicht mehr gefunden habe.
Was mich aber auch interessieren würde ob jemand den Sensor iAQ-2000 via I²C an den RPi oder Arduino via Firmata mal mit FHEM gekoppelt hat?
Damit könnte man sich doch auch einen guten Raumsensor bauen?
http://www.mikrocontroller.net/articles/IAQ-2000#IAQ-2000
http://forum.arduino.cc/index.php?topic=121550.0
http://makeithappend.org/de/archives/1561
http://www.yoctopuce.com/EN/products/usb-environmental-sensors/yocto-voc
Möglich, nur warum sollte man das zu den Preisen zu denen der Sensor (scheinbar nicht) zu bekommen ist tun wollen?
Mein Gedanke war es mit einigen Arduinos Raumsensoren zu bauen, und dies via Firmata an den FHEM anzubinden.
Der Arduino hat leider kein USB, aber dafür I²C.
Ist in dem CO-20 dieser iAQ-2000 verbaut?
Zitat von: Edi77 am 22 September 2015, 17:31:11Ist in dem CO-20 dieser iAQ-2000 verbaut?
Siehe Bild
Ich würde jetzt mal vermute, nach den Bilder die ich wo anders gesehen habe das ist der iAQ2000 und ein ATMEL 32U4 :D
Jetzt ist nur die Frage, wie könnte ich das an einen Arduino anschließen?
Guten Morgen,
habe gestern etwas experimentiert mit Reset_Baseline, dabei kommt es immer wieder zu:
PERL WARNING: Use of uninitialized value $val in bitwise and (&) at ./FHEM/38_CO20.pm line 511.
PERL WARNING: Use of uninitialized value $val in concatenation (.) or string at ./FHEM/38_CO20.pm line 513.
PERL WARNING: substr outside of string at ./FHEM/38_CO20.pm line 543.
PERL WARNING: Use of uninitialized value in ord at ./FHEM/38_CO20.pm line 543.
Wäre super, wenn die Fehlermeldungen noch abgefangen werden.
Was ist eigentlich der Unterschied zwischen reset_baseline und Flag_RESET_BASELINE ?
Dachte, wenn ich ein reset_baseline mache, wird das Flag gesetzt, doch warum kann ich dann das Flag auch noch setzen, verstehe ich nicht ..
Gruß
Klaus
Da müsste ich mal nachsehen.
Das kann aktuell leider etwas dauern.
Die Fehler kommen wahrscheinlich wieder von nem Timeout.
Zitat
Die Fehler kommen wahrscheinlich wieder von nem Timeout.
Korrekt, aber unschön... (Manche Timeouts verursachen, dank Deiner Hilfe keine Fehlermeldung mehr)
PS: Habe jetzt den Sensor auf drei verschiedenen Kleinrechner am laufen (RPI, TP-LINK Archer C7, und HooToo Router), überall das USB Kommunikationsproblem, zugegeben sind alles nicht wirklich echte Rechner mit USB....
ZitatDas kann aktuell leider etwas dauern.
Nur keine Eile ...
gruß Klaus
Zitat von: Rampler am 29 September 2015, 19:38:43
Korrekt, aber unschön...
Oh...
Der Fehler lag ganz woanders: flag_XXX war nie zum Setzen gedacht.
Und in Zeile 543 passiert irgendwas was ich gerade nicht ganz verstehe.
Kannst du mal die reset_xxx Kommandos testen, wenn du das nächste Mal einen Stick zurücksetzen willst?
Ich bin mir gerade nicht zu 100% sicher ob das tatsächlich funktioniert.
Die Version dazu ist im Anhang.
Hallo Markus,
ok, die Set xxx flag_xxx sind nun weg. DANKE
Beim reset_baseline oder auch reset_device passiert folgendes:
2015.10.03 13:25:26 4: FHEMWEB:192.168.1.3:49903 POST /fhem&detail=WZ.iam&dev.setWZ.iam=WZ.iam&cmd.setWZ.iam=set&arg.setWZ.iam=reset_baseline&val.setWZ.iam=; BUFLEN:0
2015.10.03 13:25:26 4: FHEMWEB:192.168.1.3:49903 GET /fhem?detail=WZ.iam; BUFLEN:0
2015.10.03 13:25:26 4: name: /fhem?detail=WZ.iam / RL:2769 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.10.03 13:25:26 4: Connection closed for FHEMWEB:192.168.1.3:49902: Connection reset by peer
2015.10.03 13:25:26 4: FHEMWEB:192.168.1.3:49903 GET /fhem?XHR=1&inform=type=status;filter=WZ.iam;since=1443871525;fmt=JSON×tamp=1443871533123; BUFLEN:0
2015.10.03 13:25:32 4: FHEMWEB:192.168.1.3:49901 POST /fhem?detail=WZ.iam&dev.getWZ.iam=WZ.iam&cmd.getWZ.iam=get&arg.getWZ.iam=air_data&val.getWZ.iam=&XHR=1&addLinks=1; BUFLEN:0
2015.10.03 13:25:32 4: WZ.iam: write error -145/-145 (1)
2015.10.03 13:25:32 4: name: /fhem?detail=WZ.iam&dev.getWZ.iam=WZ.iam&cmd.getWZ.iam=get&arg.getWZ.iam=air_data&val.getWZ.iam=&XHR=1&addLinks=1 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
Danach ist der Adapter disconnected ..
Nachtrag, manchmal funktioniert es aber, sehr merkwürdig..
War oder ist mit der eingecheckten Version aber auch so...
gruß Klaus
Hallo Martin Markus,
checkst du die Version von #382 ein ?
Die set flag_xxx Geschichte ist damit definitv bereinigt.
gruß klaus
PS: Nachtrag, muss natürlich Markus heißen ...
Sorry, sollte natürlich Markus heißen .... ;)
Kann leider noch etwas dauern, ich muss mein System erst noch wiederherstellen und habe dazu aktuell nur wenig Zeit.
Hallo,
hab seit gestern meinen Raspberry zum Fhem gemacht.
Als erstes den Voltcraft CO20 Sensor drangestöpselt.
War ein wenig mühsam rauszufinden, das der sehr leicht verwendbar ist. Daher für andere Anfänger meine Definition:
define co20 CO20
attr co20 interval 60
attr co20 room Wohnzimmer
define FileLog_co20 FileLog ./log/CO20-WZ-%Y-%m-%d.log co20
attr FileLog_co20 logtype co20:plot,text
attr FileLog_co20 room Wohnzimmer
define SVG_1 SVG FileLog_co20:co20:CURRENT
attr SVG_1 room Wohnzimmer
Freue mich schon auf viele Möglichkeiten mit dem Fhem.
Als nächstes kommen Funksteckdosen und Temperaturfühler dran ;-)
Harald
Kurz 2 Fragen (habe den Velux Stick):
- was bedeuten Werte > 2000? bzw. wieso werden sie auf 2000 beschraenkt, ist das anders beim Velux?
- mein label/titel ist momentan <L1> hab ich da was vergessen (attr?) oder was sollte da rein?
Danke,
Christoph
@chbla
Könntest Du bitte den Auszug aus der fhem.cfg und die dazupassende "gplot"-Datei posten.
Habe auch den Stick von Velux und läuft wunderbar...
Hi, klar:
define co20 CO20
attr co20 interval 60
attr co20 room Wohnzimmer
define FileLog_co20 FileLog ./log/CO20-WZ-%Y-%m-%d.log co20
attr FileLog_co20 logtype co20:plot,text
attr FileLog_co20 room Wohnzimmer
define SVG_1 SVG FileLog_co20:co20:CURRENT
attr SVG_1 room Wohnzimmer
und
# Created by FHEM/98_SVG.pm, 2015-10-19 17:18:54
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
set ytics "good" 750, "ok" 1250, "bad" 1750
set y2tics "" 1000,"" 1500
set grid y2tics
set ylabel ""
set y2label "Air quality (ppm)"
set yrange [450:2000]
set y2range [450:2000]
#FileLog_co20 4:voc::
#FileLog_co20 4:voc::$fld[3]>1000?1000:$fld[3]
#FileLog_co20 4:voc::$fld[3]>1500?1500:$fld[3]
#FileLog_co20 4:voc::$fld[3]>2000?2000:$fld[3]
plot "<IN>" using 1:2 axes x1y2 title 'Air quality (ppm)' ls l5 lw 0.2 with lines,\
"<IN>" using 1:2 axes x1y2 title ' ' ls l1fill lw 0.2 with lines,\
"<IN>" using 1:2 axes x1y2 title ' ' ls l4fill lw 0.2 with lines,\
"<IN>" using 1:2 axes x1y2 title ' ' ls l0fill lw 0.2 with lines
Nur der erste Teil wurde von mir erstellt. Ich glaube das L1 muss doch irgendwie als attr gesetzt werden, nicht? Currval oder so
Bin nicht ganz sicher, hab schon eine weile nichts mehr an meinem Fhem setup geaendert :)
Das Attribute heißt Label:
attr Label "Air quality - Min $data{min1}, Max $data{max1}, Last $data{currval1}" beim Plot ...
@Markus
läuft dein Rechner wieder ?
Wie siehts aus mit dem einchecken ?
gruß Klaus
Danke fuer den Tipp! Label passt jetzt.
Kanns sein das die Sensoren driften? im Anhang mal ein Bild, da wo es Richtung 0 geht hab ich gelueftet.
Und irgendwie gehts danach ziemlich schnell in den roten Bereich? Das duerfte dann ja nicht mehr sein als vorher..
Habe die Kalibrierung bei jedem einstecken abgeschaltet und dann so ca. 20 min nach lueften urspruenglich resettet, damit
der Wert nicht zuweit unten ist.. aber so scheint das nicht brauchbar zu sein ..
Na so schnell auch nicht. Du solltest mal meinen Toilettensensor sehen ;-)
Naja, es gibt dafuer eben keinen Grund, man sieht wies vorher war, dann kanns nach dem Lueften (das war eigentlich die einzige Aktion in der Wohnung)
nicht ploetzlich schlechter als vorher sein.
Habe das bei 2 Sensoren an unterschiedlichen stellen beobachtet.
Ja, ein wenig Drift ist bei den Sensoren ganz normal.
Zitat von: Rampler am 25 Oktober 2015, 08:00:02@Markus
läuft dein Rechner wieder ?
Wie siehts aus mit dem einchecken ?
Jein, ist aber seit eben eingecheckt ;)
Das scheint mir aber schon einiges an drift zu sein .. wie soll man denn so ein Ding richtig verwenden?
Bei mir gibt es eine solche Drift nicht, oder zumindest nicht in relevantem Ausmaß. Es gibt eine gewisse Sensitivität für die Luftfeuchtigkeit.
Eine Drift kann ich nicht feststellen !
Die Sensoren sind sehr sensibel. Würde mal behaupten, wenn Du lüftest und die Werte schlechter werden, dann ist die Aussenluft auch schlecht. (evtl Holzkamin etc.). Meine drei Sensoren liefern jedenfalls nachvollziehbare Ergebnisse.
Anmerkung: Meine Schwellwerte musste ich allerdings erhöhen, bis 1500 ppm gut(grün), von 1500 bis 3500 ok (gelb), alles drüber schlecht, also rot.
gruß klaus
Hallo,
Meiner läuft jetzt auch so eine Woche und springt immer mal wieder völlig ohne Grund.
In letzter Zeit springts jedoch seltener. Wäre so ein ein Wochen Burn-In?
Hab ihn inzwischen auch so 5-6 mal neu gestartet. (Und bin mit nicht sicher, wie der auto-Kalibrier Schalter im Moment steht, da sich der immer mal wieder auf Autokalibrieren bei Einschalten zurücksetzt...)
Gruss, Harald
Habe auch die Erfahrung gemacht, dass es eher die Qualität der Außenluft ist, die driftet. :)
Habe da mal eine Frage...
Wenn ich den Stick am PC (Windows 7) über die Air-Monitor Software betreibe, kann ich jederzeit einen Reset-Baseline durchführen, und der Wert wird dann zuverlässig auf 450 ppm zurück gesetzt.
Am Raspberry und auch auf zwei Router (TP-Link und Hootoo) funktioniert das eher mehr weniger. Soll heißen geht eigentlich bei mir nur zu 50 %, digital halt, geht, geht mal nicht. Das Abfragen der Air-Werte alle 10 Min funktioniert dagegen absolut zuverlässig. Nur der Rest halt nicht, also sämtliche andere Funktionen, wie Knob data, Level_warn1 etc...
Beim ausführen der genannten Funktionen hat das meist einen disconnect zur Folge ..
Ist das bei euch auch so ?
gruß Klaus
Da muesste man mal einen Test machen und einfach einen der Sensoren aussen anbringen. Dann sieht man ob das die Aussenluft oder Drift ist.
Zitat von: Rampler am 27 Oktober 2015, 09:03:12Am Raspberry und auch auf zwei Router (TP-Link und Hootoo) funktioniert das eher mehr weniger. Soll heißen geht eigentlich bei mir nur zu 50 %, digital halt, geht, geht mal nicht. Das Abfragen der Air-Werte alle 10 Min funktioniert dagegen absolut zuverlässig. Nur der Rest halt nicht, also sämtliche andere Funktionen, wie Knob data, Level_warn1 etc...
Beim ausführen der genannten Funktionen hat das meist einen disconnect zur Folge ..
Ist das bei euch auch so ?
Nein, da ich einen Laptop für FHEM verwende.
Auf dem RasPi wär's allerdings das gleiche, das ist bedingt durch die miserable USB Implementierung.
Du kannst noch versuchen mit dem Timeout Wert ein wenig rumzuspielen, ansonsten ist da nichts zu machen.
Konfigurieren am Besten am PC. War bei mir auch so.
Hallo,
Ich habe die letzten 28 Seite nur mal kurz überflogen.
Habe jetzt den RPi2 am laufen mit fhem5.7
Das kleine Programm von
http://code.google.com/p/usb-sensors-linux/wiki/Install_AirSensor_Linux
wie dort beschriebe installiert und getestet, die Werte werden ausgelesen.
Wenn ich das jetzt weiter richtig deute soll die airsensor in /opt/fhem/airsensor kopiert werden und dann via cronjob von Seite 1 send2fhem ausgelesen werden
oder gibt es eine aktuellere send2fhem oder geplot ?
Danach in fhem definieren? Richtig?
Da ich leider im fhemwiki als auch sonst wo keine Anleitung wollte ich nur mal nachfragen ob das so richtig wäre?
Warum verwendest Du nicht das Modul, dass FHEM mitliefert?
gute Idee, aber wie bindet man das ein?
Fhem, Commandref http://fhem.de/commandref.html#CO20, CO20
VG Sven
verdammt einfach ....... ;D
hätte ich nicht gedacht.
Bei mir kommen jetzt die Daten an.
Allerdings hätte ich jetzt da doch eine frage:
Wie ruft das 38_CO20.pm die Daten vom Sensor ab?
Ich habe gesehen das mein Sensor die Standard Adresse hat ,und das wohl im Modul hinterlegt ist.
Eigentlich würde ja dann das ./airsensor nicht mehr benötigt weil es in 38_CO20.pm integriert ist?
das modul greift direkt per usb auf den sensor zu. du brauchst keine andere software ausser dem modul.
gruss
andre
Ok, verstehe, DANKE
Und wie ist das wenn man an einem RPi mehrere CO20 angeschlossen hat, haben die ja die gleiche USB Device Kennung nur einen USB Port.
Wie müsste ich dann mit 38_CO20.pm die Daten auslesen?
siehe commandref. es gibt ein paar möglichkeiten die auseinander zu halten.
gruss
andre
So,
ich hab heute den Sensor bekommen,
gleich mal die lib Installiert, und den Sensor eingebunden...
leider steht da immer noch disconnected...
und ich weiss nicht mehr weiter...
unter Airsensor -o funktioniert der Sensor problemlos...
define WoZi_co20 CO20
attr WoZi_co20 interval 300
define FileLog_WoZi_co20 FileLog ./log/WoZi_co20-%Y.log WoZi_co20:voc:.*
define weblink_co20 SVG FileLog_WoZi_co20:airquality:CURRENT
[170432.262410] usb 1-3.4.2: new full-speed USB device number 12 using xhci_hcd
[170432.282149] usb 1-3.4.2: New USB device found, idVendor=03eb, idProduct=2013
[170432.282158] usb 1-3.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[170432.282162] usb 1-3.4.2: Product: iAQ Stick
[170432.282166] usb 1-3.4.2: Manufacturer: AppliedSensor
[170432.282374] usb 1-3.4.2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
[170432.282382] usb 1-3.4.2: ep 0x2 - rounding interval to 64 microframes, ep desc says 80 microframes
[170432.290573] hid-generic 0003:03EB:2013.0003: hiddev0,hidraw2: USB HID v1.11 Device [AppliedSensor iAQ Stick] on usb-0000:00:14.0-3.4.2/input0
2016.01.08 15:55:06 2: WoZi_co20: no device
2016.01.08 15:55:06 3: WoZi_co20: CO20 device found
2016.01.08 15:55:06 3: WoZi_co20: failed to open CO20 device
2016.01.08 15:55:06 3: WoZi_co20: disconnected
ich seh grad, das der User nicht drauf zugreifen kann - ich probier nochmal und meld mich dann wieder...
Die Rechtevergabe des Sensors war falsch - jetzt darf auch fhem auf den Stick zugreifen...
Ich habe jetzt 2 der CO20 Sensoren, einer Outdoor an einem RPi2 mit FHEM2FHEM angebunden, und einer am FHEM Master ( VMWare ) selbst
define RPi60FHEM FHEM2FHEM 192..........:7072 LOG:.*
define CO20OUTDOOR cloneDummy co20outdoor
attr CO20OUTDOOR room KS300
define FileLog_CO20OUTDOOR FileLog ./log/CO20OUTDOOR-%Y-%m.log co20outdoor
attr FileLog_CO20OUTDOOR logtype text
attr FileLog_CO20OUTDOOR room KS300
define SVG_FileLog_CO20OUTDOOR SVG FileLog_CO20OUTDOOR:SVG_FileLog_CO20OUTDOOR:CURRENT
attr SVG_FileLog_CO20OUTDOOR plotsize 1024,200
attr SVG_FileLog_CO20OUTDOOR room KS300
attr SVG_FileLog_CO20OUTDOOR title "Air quality (ppm) Min $data{min1}, Max $data{max1}, Last $data{currval1}"
# +++++++++++++++++++++++++++++++++++++++++++++++++++++++
define co20_Buero CO20 03eb:2013
attr co20_Buero interval 300
attr co20_Buero room KS300
define FileLog_co20_Buero FileLog ./log/co20_Buero-%Y-%m.log co20_Buero
attr FileLog_co20_Buero logtype text
attr FileLog_co20_Buero room KS300
define SVG_FileLog_co20_Buero_1 SVG FileLog_co20_Buero:SVG_FileLog_co20_Buero_1:CURRENT
attr SVG_FileLog_co20_Buero_1 plotsize 1024,200
attr SVG_FileLog_co20_Buero_1 room KS300
attr SVG_FileLog_co20_Buero_1 title "Air quality (ppm) Min $data{min1}, Max $data{max1}, Last $data{currval1}"
Jetzt habe ich das Problem trotz
sudo nano /etc/udev/rules.d/99-usb.rules
# iAQ
SUBSYSTEM=="usb", ATTR{idVendor}=="03eb", ATTR{idProduct}=="2013", MODE="0666"
und
◦Device::USB hast to be installed on the FHEM host.
It can be installed with 'cpan install Device::USB'
or on debian with 'sudo apt-get install libdevice-usb-perl''
Das ich meistens kein Zugriff bekomme
2016.01.12 15:19:35 3: co20_Buero: CO20 device found
2016.01.12 15:19:37 3: co20_Buero: failed to open CO20 device
2016.01.12 15:19:37 3: co20_Buero: disconnected
2016.01.12 15:19:37 4: initialUsbCheck exec usb create
2016.01.12 15:19:37 1: usb create starting
2016.01.12 15:19:37 1: usb create end
Was bedeutet meistens?
Was passiert wenn du den Sensor direkt auf der Maschine ansprichst?
Hallo,
Es ist mir nur 2 mal gelungen das er open angezeigt hat, und dann immer disconnected.
~ $ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 005: ID 03eb:2013 Atmel Corp.
Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
$ lsusb -vs 002:004
Bus 002 Device 004: ID 03eb:2013 Atmel Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 32
idVendor 0x03eb Atmel Corp.
idProduct 0x2013
bcdDevice 10.00
iManufacturer 1 AppliedSensor
iProduct 2 iAQ Stick
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 41
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 53
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 10
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 10
Device Status: 0x0000
(Bus Powered)
Ich vermute mal das irgendwas mit den rechten nicht stimmt oder das ein anderer Prozess das device sperrt
Die Stromversorgung am RPi ist bei Dir gesichert und das USB-Kabel nicht zu lang, oder?
"Manchmal" und ab und zu "disconnects" hört sich stark nach nicht ausreichender Powersupply an. Ist natürlich nur ein Verdacht aber eine beliebte Fehlerquelle.
Hallo,
vielleicht habe ich mich nicht so ganz deutlich ausgedrückt, der 2te CO20 der nicht funktioniert hängt am Master, also ein ESX Server mit 32GB RAM und i5 3470.
Aber das Verlängerungskabel könnte noch sein ;) ???
Edit: Ok es geht auch nicht ohne Verlängerungskabel :(
Zitat von: KölnSolar am 29 Januar 2015, 21:39:17
die Version von Markus ist äußerst hilfreich und sollte eingechecked werden !
Meine bisher unbeantworteten Fragen kann ich mittlerweile selber beantworten: Bei verbesserter Luft gegenüber der gespeicherten Kalibrierung "rekalibriert" sich der co20 im laufenden Betrieb selbständig. Außerdem ist der Sensor für Raucher eher ungeeignet: eine Zigarette signalisiert sofort eine schlechte Luftqualität. Ja, ihr habt recht, ich sollte das Rauchen aufgeben :-[
Markus
Weiß wer, ob der Sensor die automatische Rekalibrierung im laufenden Betrieb auch macht wenn man die power-up Kalibrierung deaktiviert hat?
Zitat von: chunter1 am 13 Januar 2016, 13:19:21
Weiß wer, ob der Sensor die automatische Rekalibrierung im laufenden Betrieb auch macht wenn man die power-up Kalibrierung deaktiviert hat?
Tut er bei mir, leider. Das konnte ich ihm noch nicht abgewöhnen und schränkt seinen Nutzen doch irgendwie ein.
Irgendwie werd ich das Gefühl nicht los, dass man in den Sensor keine Zeit/Geld investieren sollte :o
Er ist zwar günstig, aber man hat nie ein dauerhaft, konsistent und wartungsfrei funktionierendes System?!
Zitat von: chunter1 am 13 Januar 2016, 16:06:13
Irgendwie werd ich das Gefühl nicht los, dass man in den Sensor keine Zeit/Geld investieren sollte :o
Er ist zwar günstig, aber man hat nie ein dauerhaft, konsistent und wartungsfrei funktionierendes System?!
Meine 2 Exemplare (Maisonette-Wohnung, offene Treppe, einer unten, einer oben) verhalten sich beide ziemlich identisch, was schonmal gut ist. Beide driften, und zwar gleich stark, das heißt, sie tendieren dazu, sich an die schlechte Raumluft "zu gewöhnen" und zeigen (vermutlich) mit der Dauer weniger Konzentration an, als wirklich existiert - was man daran merkt, dass Sie sich beim Lüften ruck-zuck in Richtung 450 ppm (untere Grenze) bewegen und dann dort verharren. Um zu erkennen, wann die Luft beim Lüften komplett ausgetauscht ist, reicht das aber in guter Näherung! Bei starkem Wind geht es schneller, bei Windstille dauert es länger. Also man kann damit "auf den Punkt" die Fenster wieder zu machen - das ist die einzige Funktion, die gut verwendbar ist (von um-die-Wette-Verdauen bei Partys einmal abgesehen ... sorgt aber stets für Heiterkeit, den Sensor rot zu flatulieren)
Definitiv allein nicht geeignet sind sie jedenfalls nach meiner bisherigen Erkenntnis, um festzustellen, ob jetzt gelüftet werden müsste oder nicht.
Ich habe mir jetzt einen co2mini zusätzlich bestellt (siehe entsprechenden Thread), der die echte co2-Konzentration misst, um diesen Eindruck zu untermauern. Ich werde jetzt mal beides über eine Zeitlang parallel loggen und die Kurven dann veröffentlichen. Mein Plan ist ersteinmal zu gucken, ob meine Vermutung stimmt (Drift) und ob man ggf. einen Vorteil hat, beides zu messen ... die CO-20 reagieren jedenfalls ja prima auf alles Übelriechende, was der CO2-Mini nicht mitbekommt. Wenn man mit dem CO2-Mini also den Drift aus dem CO-20 herausrechnet, könnte das Ergebnis optimal sein ...
Ich habe erst seit kurzem den CO-20 und warte schon gespannt auf deine Ergebnisse peterk_de.
Hatte gehofft den CO-20 für das "lüften" gebrauchen zu können, aber ich hätte besser alle Seiten hier erst lesen sollen. ;)
Naja mal abwarten was sich hier noch evtl. tut.
Z.Z. gibt es keinen vergleichbaren (brauchbaren) und in fhem nutzbaren Sensor oder ?
Grüße Marcel
Zitat von: Ma_Bo am 13 Januar 2016, 17:54:58
Ich habe erst seit kurzem den CO-20 und warte schon gespannt auf deine Ergebnisse peterk_de.
Hatte gehofft den CO-20 für das "lüften" gebrauchen zu können, aber ich hätte besser alle Seiten hier erst lesen sollen. ;)
Naja mal abwarten was sich hier noch evtl. tut.
Z.Z. gibt es keinen vergleichbaren (brauchbaren) und in fhem nutzbaren Sensor oder ?
Grüße Marcel
Doch, den co2mini halt - leider kostet er mit 80 Euro aktuell auch ein vielfaches und ist wesentlich größer - damit ist es sicher schwieriger, damit viele Räume auszustatten. Hab ihn gerade fertig installiert und an den gleichen Pi wie meinen einen Voltcraft CO-20 gehängt. Mal gucken, wie die beiden sich so im Vergleich schlagen! Aktuell liegen die Messwerte erstaunlich nah beieinander (Co20: 865 ppm, Co2mini: 968 ppm - gelüftet zuletzt heute morgen; Raum war weitestgehnd ungenutzt - aber ist halt oben das schlafzimmer in unserer Maisonettewohnung ohne Tür nach unten)
Also ich kann das mit dem automatischen Rekalibrieren im Betrieb nicht bestätigen. Ich hab hier 3 Sticks seit ca. 6 Monaten am Laufen, die ich alle einmalig gemeinsam draußen gleichzeitig kalibriert habe. Seitdem laufen sie durch und geben auch seitdem plausible Werte.
Zitat von: peterk_de am 13 Januar 2016, 18:04:17
Doch, den co2mini halt - leider kostet er mit 80 Euro aktuell auch ein vielfaches und ist wesentlich größer - damit ist es sicher schwieriger, damit viele Räume auszustatten.
Ich denke, dass man dann gleich die wohnzimmertaugliche Netatmo Wetterstation nehmen sollte.
Hat Sonometer, CO2, Temperatur, Luftfeuchte Signalleds Wlan einen Außensensor, cloud App und perfekte fhem integration.
Da sind die 80€ für den co2mini vergleichsweise viel.
Zitat von: chunter1 am 13 Januar 2016, 21:26:35
cloud App
Das ist doch aber gerade ein Grund es NICHT zu kaufen ^^ Oder kann man Big Brother Funktionen ausschalten?
Btw. der Co2mini hat auch Temperatur drin (alle) und einige auch humidity (kommt auf die OEM-version an, meiner wohl offenbar nicht). Und die FHEM-Anbeindung ist tadellos. Nur das Sonometer fehlt.
Mal ein kurzer Bericht vorab:
Vor ca. einer Stunde gelüftet. CO20 knallte wie üblich schlagartig nach einer Weile aufs Minimum (450ppm), da war der CO2mini noch bei 800 ppm und folgte allmählich, bis er 5 Minuten später bei 506ppm ankam. Da hab ich zugemacht; der CO20 war da dann schon wieder auf fast 600ppm hochgegangen ... also das, was ich immer beobachte, langes Lüften ist für das Ding wie ne Art "Reset".
Aktuell steht der CO20 bei 1500ppm und der CO2mini bei 680ppm ... der Zweite wert kommt mir DEUTLICH realistischer vor, die Luft riecht noch sehr frisch.
Aber ich muss das länger testen.
Zitat von: Ma_Bo am 13 Januar 2016, 17:54:58
Ich habe erst seit kurzem den CO-20 und warte schon gespannt auf deine Ergebnisse peterk_de.
Hatte gehofft den CO-20 für das "lüften" gebrauchen zu können, aber ich hätte besser alle Seiten hier erst lesen sollen. ;)
Naja mal abwarten was sich hier noch evtl. tut.
Z.Z. gibt es keinen vergleichbaren (brauchbaren) und in fhem nutzbaren Sensor oder ?
Grüße Marcel
Ich weiß nicht, wo ihr alle Euer Problem habt. Ich habe 4 Sensoren im Einsatz, 2 davon für die Ansteuerung einer automatischen Fensteröffnung für Schlafzimmer und Bad. Und das funktioniert seit längerem tadellos.
Ich hab heute den Sensor über Nacht im Freien gehabt.
In der Früh dann im Freien kalibriert und das Flag zur power-up Selbstkalibrierung deaktiviert.
Bin dann ohne den Stick abzustecken in den Vorraum gegangen bei dem seit ca. 20 Minuten die Haustüre offen stand.
Da schießt der Messwert auf 22000 hoch. WTF!?!
Der Raum war mit eiskalter, frischer Luft vollgepumpt.
Sorry, aber für mich ist der Sensor einfach nur kompletter Mist der irgendwie irgendwo irgendwas in totaler Abhängigkeit von Temperatur, Luftfeuchtigkeit und Vorbelastung anzeigt.
Hallo,
nach den unterschiedlichen Beiträgen zu urteilen, funktioniert der Sensor bei einigen Usern gut, bei anderen leider nicht. Ich hatte den Sensor für etwa 60 Tage in dem Abluftkanal unserer Lüftungsanlage installiert und war sehr zufrieden mit den Ergebnissen. Ich habe ihn danach durch einen TGS2600 an einem Arduino und MYSENSOR ersetzt, weil dieser kleiner ist und leichter in das restliche Umfeld integriert werden kann.
Um die Diskussion, ob der Sensor gut oder schlecht ist, zu versachlichen, sollten wir vielleicht mehr Fakten zusammentragen. Adhoc fallen mir die folgenden Kriterien ein:
- Label (Voltcraft, Velux, ...)
- ca. Kaufdatum:
- USB Anschluss (stromversorgter USB Hub, Raspberry, ...)
- Betriebssystem Hostrechner (Windows, Linux, ...)
- Schnittstelle zu fhem (CO20-Modul oder airsensor und Skript, ...)
- tägliche Betriebsdauer (24h/Tag, ...)
Wer hat weitere Kriterien?
Meine Werte:
- Label (Voltcraft, Velux, ...): Velux
- ca. Kaufdatum: 09/2015
- USB Anschluss (stromversorgter USB Hub, Raspberry, ...): Raspberry
- Betriebssystem Hostrechner (Windows, Linux, ...): Linux
- Schnittstelle zu fhem (CO20-Modul oder airsensor und Skript, ...): airsensor und Skript
- tägliche Betriebsdauer (24h/Tag, ...): 24h
VG
Sven
Nachdem im co-20 USB-Stick keinerlei Temperatur- oder Luftfeuchtigkeitssensor verbaut ist, muss das Teil ja komplett ungenau sein da die Kompensationsfaktoren nicht ermittelt werden können.
Fazit... nette Spielerei bei konstanter Raumtemperatur und Luftfeuchtigkeit - aber im Grunde rausgeschmissenes Geld!?
Hier meine Daten:
- Label: REHAU
- Kaufdatum: 7.1.2016
- USB Anschluss: Sony Laptop
- Betriebssystem Hostrechner: Windows
- Schnittstelle zu fhem: -
- tägliche Betriebsdauer: -
Zitat von: vbs am 24 April 2015, 21:03:14
Hat eigentlich jemand eine Ahnung, was "Recalibrate Heater" macht bzw. unter welchen Bedingungen man das ausführen sollte/dürfte? Ich hab mich noch nicht getraut, das zu drücken :/
Weiß das wer?
Sorry, hab ein paar Beiträge übersehen :)
Ich habe mittlerweile auch 4 Netatmo Bases rumstehen - nicht teurer als der CO2mini.
Der Nachteil ist die Datenfrequenz von 5 Minuten bei Updates alle 10 Minuten.
Den Sensor draussen zu kalibrieren ist keine gute Idee.
Da ist die Baseline dann dermaßen weit unten dass drinnen viel zu hohe Werte rauskommen.
Einfach kurz lüften, Fenster zu und dann die Kalibration starten, dann klappt das.
Und ja, auf Zigaretten reagiert er extrem - soll er aber ja auch.
Hier wird nicht CO2 gemessen sondern VOC.
Zitat von: Edi77 am 12 Januar 2016, 18:15:58vielleicht habe ich mich nicht so ganz deutlich ausgedrückt, der 2te CO20 der nicht funktioniert hängt am Master, also ein ESX Server mit 32GB RAM und i5 3470.
Ach so!
Hast du mal versucht die beiden Sticks zu wechseln?
Normalerweise ist es immer der RasPi
Zitat von: volschin am 13 Januar 2016, 23:01:58...für die Ansteuerung einer automatischen Fensteröffnung für Schlafzimmer und Bad.
Was verwendest du dafür?
Zitat von: chunter1 am 14 Januar 2016, 11:14:49
Weiß das wer?
Einen kompletten Reset und die "Einbrennfunktion" wie bei der ersten Installation die 48h dauert.
Kann man machen wenn man das Ding längere Zeit nicht in Betrieb hatte, braucht man aber im Normalfall nicht.
Wenn du zu seltsame Werte bekommst kannst du das mal ausprobieren, kaputt geht dabei nichts.
Das Tool von Rehau, aktuelle Version 2.44 http://www.rehau.com/de-de/privatkunden/raumluftsensor/-/1560976, bietet nach einem Doppelklick und Halten von <STRG>-Taste weitere Infos zum Stick durch Drücken des Buttons "Sensor Informationen".
Diese lauten bei mir:
Application Version: 2.44.0 (Rev: 2145 Date: 2013-08-20 20:10:57 +0200 )
Device 0:
Name: iAQ Stick
Firmware: 1.12p5 $Revision: 346 $
Protocol: 5
Hardware: C
Processor: ATmega32U4
Serial number: S/N:5534383230371501040C
Web address:
Plot title: Air Quality Trend
Channels: 5
... Channel 0:CO2/VOC level
... Channel 1:Debug
... Channel 2:PWM
... Channel 3:Rh
... Channel 4:Rs
Knobs: 8
... Knob CO2/VOC level_warn1:1000
... Knob CO2/VOC level_warn2:1500
... Knob Reg_Set:173
... Knob Reg_P:3
... Knob Reg_I:10
... Knob Reg_D:0
... Knob LogInterval:0
... Knob ui16StartupBits:1
Flags: 5
... WARMUP=0
... BURN-IN=0
... RESET BASELINE=0
... CALIBRATE HEATER=0
... LOGGING=0
Zitat von: chunter1 am 14 Januar 2016, 08:45:22
Sorry, aber für mich ist der Sensor einfach nur kompletter Mist der irgendwie irgendwo irgendwas in totaler Abhängigkeit von Temperatur, Luftfeuchtigkeit und Vorbelastung anzeigt.
Ganz so krass sehe ich das nicht, aber von der Tendenz ähnlich. Es kommt halt immer darauf an, was man damit messen will. Hier mal der Anfang des Vergleiches meiner Messreihe.
Rot ist der CO20 (Reading VOC in ppm CO2 äquiv.), grün ist der CO2mini. Die Messwerte vor dem Lüften gegen 21:00 Uhr gestern bitte ignorieren, da habe ich den neuen Sensor angebastelt gehabt und auch Tagsüber schon resettet etc. Davor ist ist also kein typischer Verlauf des CO20 zu sehen. Raum: Oberer Stock offene Maisonettwohnung, ca. 70qm Fläche insgesamt, 2 Personen überwiegend schlafend anwesend, Nichtraucherhaushalt. Den CO20 habe ich genauso in Betrieb genommen wie hier schon beschrieben (draußen eingebrannt, resettet, rekalibrierung noch aufm Balkon aus - das ganze mit 2 Stück davon die sich nebeneinandergelegt auch immer noch weitgehend identisch verhalten).
Im Diagramm ist aber jetzt schon zu sehen, was ich oben als "Drift" bezeichnet habe und für mich typisch ist: Die Werte korrelieren NICHT mit dem CO2-Gehalt der Luft- sie verlaufen von der Tendenz her in die gleiche Richtung, aber die Amplitude ist ganz, ganz anders. Kann ja auch gar nicht gleich sein - der Sensor misst ja ganz andere Partikel. Die Frage ist nur, wo ist bei denen jetzt ein allgemein anerkannter Grenzwert? Gibts offensichtlich nicht.
Für CO2 findet man da ne ganze Menge Richtwerte, die auf sehr viel Erfahrung basieren (aber auch nur Orientierungswerte sind, da sie ja auf der Annahme basieren, dass der CO2-gehalt weitestgehend durch menschliche Atmung verursacht wurde). Für den CO20 muss man sich das offensichtlich also komplett selbst austüfteln und hat eben anhand dieses Wertes keine absoluten "Vergleichswerte". Dafür misst der aber eben auch z.B. strenge Gerüche oder Blähungen, die der CO2mini absolut gar nicht mitbekommt.
Was man bis jetzt in meinem Diagramm noch nicht sieht: Wenig vertrauenserweckend kommt beim CO20 leider hinzu, dass, wenn man mal länger nicht lüftet (sagen wir, 24h - sollte man nicht tun, kommt aber in der Praxis möglicherweise des Öfteren vor), er einfach beim Lüften rasant auf 450 ppm runterknallt und dort dann exakt bei diesem Wert ein paar Minuten verharrt - weil die intelligenten Entwickler offenbar gedacht haben, "Hups, unter 400 ppm kann das CO2 ja nicht liegen - müssten nach unserem internen Algorithmus jetzt aber eigentlich so sein - da sind wir wohl etwas abgedriftet beim messen ... warten wir besser mal, bis sich unser interner Sensormesswert (gemessener Widerstand) beim Minimum eingependelt hat, solange geben wir einfach 450 ppm aus ..." Das lustige: Wenn man automatisch belüftet, mag das so super sein, das Ding wird immer wieder "rekalibriert". Wenn man aber manuell z.B. selten genutzte Räume entsprechend Lüften will, spielt der Effekt eine größere Rolle und die Messwerte sind absolut gesehen weniger zuverlässig.
Das Fazit, was ich daraus ziehen soll, ist mir noch nicht ganz klar. Der CO20 misst, und das kann man denke ich so sagen, irgendwas, was irgendwie durchaus mit der Luftqualität zusammenhängt - nur wie, das ist nicht so einfach zu sagen, also absolut gesehen. Beispiel: Ich komme nach Hause. Das Ding zeigt 2100 ppm. Sollte man Lüften?;-)
Vermutlich ist eine Kombination beider Werte, bei dem man mit dem CO2mini den Drift aus dem CO20 herausrechnet, besser. Das ist aber auch strenggenommen Unsinn, da die beiden unterschiedliche Sachen messen ... schöner wäre es, wenn der Co20 einfach mal nicht driften würde ;-) Für Automatische Belüftung, für die der iAQ im CO20 gebaut wurde, da taugt der Algorithmus aber ja laut Userberichten.
ZitatDen Sensor draussen zu kalibrieren ist keine gute Idee.
Da ist die Baseline dann dermaßen weit unten dass drinnen viel zu hohe Werte rauskommen.
Einfach kurz lüften, Fenster zu und dann die Kalibration starten, dann klappt das.
Wie erklärst du dir dann das von mir beschriebene Verhalten beim Lüften? Das deutet doch eigentlich darauf hin, dass die Baseline auf die Dauer höher wird!
Zitat von: SvenJust am 14 Januar 2016, 11:33:32
Das Tool von Rehau, aktuelle Version 2.44 http://www.rehau.com/de-de/privatkunden/raumluftsensor/-/1560976, bietet nach einem Doppelklick und Halten von <STRG>-Taste weitere Infos zum Stick durch Drücken des Buttons "Sensor Informationen".
Diese lauten bei mir:
... Knob Reg_Set:173
... Knob ui16StartupBits:1
Das ist lediglich das bereits bekannte Programm mit Rehau Label.
Deine automatische Kalibrierung ist noch aktiv, siehe ui16StartupBits.
Reg_Set ist bei mir bei 147, dein Wert erscheint mir hoch. Sind deine Werte eher zu extrem oder zu niedrig?
Ich bekomme relativ "normale" Werte raus, siehe Anhang.
Sobald ich unter dem Sensor eine Pizzaschachtel aufmache oder auch nur jemand 2 Räume weiter "Gas" ablässt, bin ich bei 2000.
Das Ding funktioniert bei mir also einwandfrei.
Zitat von: peterk_de am 14 Januar 2016, 11:38:29Wie erklärst du dir dann das von mir beschriebene Verhalten beim Lüften? Das deutet doch eigentlich darauf hin, dass die Baseline auf die Dauer höher wird!
Hast du eventuell die automatische Kalibrierung aktiv?
Ansonsten kannst du mal versuchen, den
r_s Wert zu loggen.
Das ist der interne Widerstand des Sensors vor der Berechnung des
voc Werts.
Zitat von: Markus M. am 14 Januar 2016, 12:04:27
Ansonsten kannst du mal versuchen, den r_s Wert zu loggen.
Das ist der interne Widerstand des Sensors vor der Berechnung des voc Werts.
Kannst du bitte mal deine Rs, Rh, Reg_set Werte posten.
Zitat von: Markus M. am 14 Januar 2016, 11:54:59
Das ist lediglich das bereits bekannte Programm mit Rehau Label.
Deine automatische Kalibrierung ist noch aktiv, siehe ui16StartupBits.
Reg_Set ist bei mir bei 147, dein Wert erscheint mir hoch. Sind deine Werte eher zu extrem oder zu niedrig?
Ich bekomme relativ "normale" Werte raus, siehe Anhang.
Sobald ich unter dem Sensor eine Pizzaschachtel aufmache oder auch nur jemand 2 Räume weiter "Gas" ablässt, bin ich bei 2000.
Das Ding funktioniert bei mir also einwandfrei.
Bei mir sind die Werte pausibel, der Stick war auch mit dieser Einstellungen in der Lüftungsanlage eingebaut. Die regelmäßige Kalibierung war mir nicht aufgefallen, allerdings gib es täglich Situationen bei denen die Luft in Haus gut ist. ;)
Zitat von: chunter1 am 14 Januar 2016, 12:27:15Kannst du bitte mal deine Rs, Rh, Reg_set Werte posten.
KNOB_Reg_D 0
KNOB_Reg_I 10
KNOB_Reg_P 3
KNOB_Reg_Set 147
KNOB_ui16StartupBits 0
debug 729 2016-01-14 13:08:51
pwm 351 2016-01-14 13:08:51
r_h 147.23 2016-01-14 13:08:51
r_s 207676 2016-01-14 13:08:51
voc 595 2016-01-14 13:08:51
Zitat von: Markus M. am 14 Januar 2016, 11:15:24
Den Sensor draussen zu kalibrieren ist keine gute Idee.
Da ist die Baseline dann dermaßen weit unten dass drinnen viel zu hohe Werte rauskommen.
Einfach kurz lüften, Fenster zu und dann die Kalibration starten, dann klappt das.
Ich denke, das kann man so pauschal wohl nicht sagen. Ich habe ziemlich lange rumprobiert und schlußendlich dann eben draußen kalibriert. Die Werte sind jetzt zumindest ähnlich denen des CO2mini. Und wenn ich die Räume lüfte, dann komme ich auch runter bis zu Werten zwischen 450-550. Also von viel zu hohen Werten würde ich da nicht reden.
Ich könnte mir nur noch vorstellen, dass beim burn-in etwas nicht gepasst hat.
Muss der Sensor während des Burn-Ins ständig in Frischluftumgebung sein, oder wie macht ihr das?
Momentan wird das problematisch weils draußen Minusgrade hat und wer weiß was der Sensor da anstellt...
Merkwürdig, dass mein Rs so extrem niedrig ist?
Sollte das nicht der gemessene Sensorwiderstand in Ohm sein?
Meine Werte:
KNOB_Reg_D 0
KNOB_Reg_I 10
KNOB_Reg_P 3
KNOB_Reg_Set 140
KNOB_ui16StartupBits 0
debug 800
pwm 98
r_h 140.12
r_s 2270
voc 570
Hier findet man alle Antworten auf die Fragen (Burn-In Prozedur, Abhängigkeiten von Gase/Luftfeuchte , Beschaltung etc.) zum Sensor!
So wie's aussieht, ist es der gleiche Sensor-Chip nur in anderem Gehäuse.
http://ams.com/eng/content/download/686543/1787717/file/AS-MLV-P2_Datasheet_EN_v2.pdf (http://ams.com/eng/content/download/686543/1787717/file/AS-MLV-P2_Datasheet_EN_v2.pdf)
Hier zerlegt:
http://blog.sciencenet.cn/blog-393548-920138.html (http://blog.sciencenet.cn/blog-393548-920138.html)
Und hier der gleiche Sensor im 5€ Airwick Freshmatic. :)
http://www.mikrocontroller.net/articles/IAQ-2000 (http://www.mikrocontroller.net/articles/IAQ-2000)
Zitat von: Markus M. am 14 Januar 2016, 11:15:24
Ich habe mittlerweile auch 4 Netatmo Bases rumstehen - nicht teurer als der CO2mini.
Habe mir mal diese Netatmo-Stationen angesehen. Gefallen mir eigentlich gut. Habe jedoch gelesen, dass die das gleiche Problem haben wie der CO20: Sie werden kalibriert auf einen Basiswert und messen dann eben nur relativ zu diesem. Liefern also keine Absolutwerte. Weiß jemand, wie das bei dem CO2mini ist?
Zitat von: vbs am 14 Januar 2016, 20:02:58
Habe mir mal diese Netatmo-Stationen angesehen. Gefallen mir eigentlich gut. Habe jedoch gelesen, dass die das gleiche Problem haben wie der CO20: Sie werden kalibriert auf einen Basiswert und messen dann eben nur relativ zu diesem. Liefern also keine Absolutwerte. Weiß jemand, wie das bei dem CO2mini ist?
Der CO2mini liefert Absolutwerte, man braucht nix kalibrieren, USB ran und fertig. Siehe auch meine Ausführungen + Plot oben.
Ich befürchte, der Bedarf der Kalibrierung ist messtechnisch bedingt. Ich will darauf hinaus, dass es keinen Sensor gibt, der bei einer CO2-Konzentration direkt und ohne Weiteres einen digitalen PPM-Wert ausgibt.
Das Messprinzip ist meisten optisch und bedingt daher - aufgrund der eingesetzten Bauteile - immer eine Umrechnung (Kalibrierung), d.h. welche gemessenen Absorption -> Spannung entspricht welchem CO2-Wert. Das kann natürlich werkseitig bereits geschehen sein (CO2mini ist noch im Zulauf) oder unter der Annahme, dass in der Umgebung normalerweise eine gewisse CO2-Konzentration angenommen werden kann. Darauf kann dann kalibriert werden.
Der Luftqualitätssensor misst ja auch eigentlich gar keine CO2-Konzentration, sondern spricht auf VOC an. Bis zu gewissen Konzentrationen lassen sich diese aber mit der CO2-Konzentration korrelieren.
Bei mir laufen auch 2 Netatmos und ich habe den Wert, bei dem das Fenster aufgeht mittlerweile an meinen Wohlfühlfaktor angepasst. Da ist der genaue PPM-Wert eher informativ, da auch von der Position von Quelle und Fenster abhängig. Frei nach dem Motto: wer viel misst, misst mist... ;)
Vielleicht habe ich demnächst mal die Gelegenheit, den CO2mini gegen ein geeichtes Gerät zu vergleichen. Dann läßt sich mehr sagen und auch über die Netatmos.
PS: Ab und zu haut Amazon die für unter 120euro raus. Auch teuer aber plug and play. CO2-mini ist ja recht frisch und braucht immer die Verbindung über USB.
Edith sagt:
Der Sensor selbst kostet meistens schon min. 60-80Euro. Da wird das ganze dann irgendwo integriert leider nicht günstiger :(.
Ich hatte vor einiger Zeit mal darüber nachgedacht, solch einen Sensor an einen Panstamp dranzuhängen. Da kostete die Netatmo im Schnitt aber noch 170!
@ peterk_de,
bist Du sicher, dass der CO2mini nicht kalibriert werden kann? Das würde mich sehr überraschen. Wie oben angedeutet ist meiner noch im Zulauf.
Edith hat sich nochmal gemeldet:
Sorry, hatte vorher nicht selbst gesucht. :o
Mit der Windows-Software lässt sich der Sensor wohl auf einen bestimmten PPM-Wert oder "out door" kalibrieren. Vorausgesetzt man hat die Möglichkeiten eine genauen Konzentration zuzuführen...
http://www.co2meter.com/collections/fixed-wall-mount/products/co2mini-co2-indoor-air-quality-monitor (http://www.co2meter.com/collections/fixed-wall-mount/products/co2mini-co2-indoor-air-quality-monitor)
Kennt ihr die Archos Weather Station (=Alternative zu Netatmo)?
Hab mich wahrscheinlich blöd ausgedrückt: Glaube ja, dass der Sensor (wie wahrscheinlich fast alle Sensor) in irgendeiner Form kalibriert sein muss. Die Frage für mich ist eigentlich, ob der Sensor werksseitig kalibriert wird oder ob das der Benutzer selbst machen muss (wie bei CO20 oder Netatmos). Die allermeisten Benutzer haben wahrscheinlich keine Möglichkeit, einen CO2-Sensor korrekt zu kalibrieren.
Sieht dem Netatmo-Konzept sehr ähnlich. Leider auch, dass die Daten in deren Cloud geladen werden, von wo aus man sie abrufen müsste. Bin mir unsicher, ob da schon jemand was zu geschrieben hat.
Das ist es auch, was mich an der Netatmolösung stört. Sollten die mal pleite gehen, kann man die Sensoren ja getrost in die Tonne hauen, weil man an die Daten nicht mehr dran kommt. Darüber hinaus lässt sich anhand des CO2-Verlaufes erahnen, ob jemand nicht zuhause ist. :( Aber manchmal muss man einen Tot sterben, daher bin ich auf den CO2mini gespannt. Kann sein, dass dann die Netatmos langfristig rausfliegen.
@vbs,
sorry, wollt nur keine falschen Hoffnungen wecken. Hab nochmal in der Anleitung vom CO2mini geschmökert. Es müsste mehrere Modi für die Kalibrierung geben, je nachdem, was der Sensor innerhalb von 8 Tagen ausgesetzt ist.
Zitat von: vbs am 14 Januar 2016, 20:02:58
Sie werden kalibriert auf einen Basiswert und messen dann eben nur relativ zu diesem. Liefern also keine Absolutwerte.
Wenn Du einen Sensor auf einen Basiswert kalibrierst, dann gibt er doch hinterher den Absolutwert an. Oder habe ich Dich falsch verstanden?
Die Netatmos zeigen von Zeit zu Zeit auch Werte unter 400ppm an, d.h. dann die Kalibrierung stimmt nicht mehr ganz.
Ja er zeigt zwar einen Absolutwert an, aber da ja derjenige CO2-Wert, der zum Zeitpunkt des Einsteckens des CO20-Sticks herrscht, als 450 ppm angesehen wird, ist der später ausgegebene Absolutwert ja im Prinzip völlig beliebig (außer beim Einstecken herrschten tatsächlich 450 ppm). Also ja, absolut, aber mit einem (mMn) beliebigem Nullpunkt (bzw. 450-Punkt).
Ich hab gestern meinen CO2mini bekommen und bei dem ist es zumindest nicht so, dass er sich beim Einstecken auf einen Wert kalibriert. Ich habe also (noch) Hoffnung, dass er wirklich werkskalibriert ist und diese Kalibrierung auch dauerhaft behält. In der Software kann man jedoch tatsächlich auch selbst neu kalibrieren. Falls es eine Werkskalibration gibt, würde man sich diese damit natürlich kaputt machen also werde ich davon erstmal die Finger lassen.
Dass der VOC beim Einstecken eine Kalibrierung durchführt kannst Du ihm über die Windows-Software abgewöhnen. Ist etwas versteckt, aber hier weiter oben im Thread beschrieben.
Ich bin sehr gespannt auf dem CO2mini.
Zitat von: chunter1 am 14 Januar 2016, 16:28:00
Hier findet man alle Antworten auf die Fragen (Burn-In Prozedur, Abhängigkeiten von Gase/Luftfeuchte , Beschaltung etc.) zum Sensor!
So wie's aussieht, ist es der gleiche Sensor-Chip nur in anderem Gehäuse.
http://ams.com/eng/content/download/686543/1787717/file/AS-MLV-P2_Datasheet_EN_v2.pdf (http://ams.com/eng/content/download/686543/1787717/file/AS-MLV-P2_Datasheet_EN_v2.pdf)
Äußerst spannend. Das kannte ich noch nicht, ich hatte nur ein Datenblatt gesehen, wo der Sensor schon auf einer Platine mit Schaltung beschrieben wurde, aber nicht vom nackten Sensorelement selbst.
Neue Erkenntnis daraus:
- Die Raumtemperatur beim Kalibrieren ist sehr relevant. Idealerweise 23 Grad C, max. Abweichung +/- 3 Grad. Draußen ist das also nur im Sommer sinnvoll!
- Das Kalibrieren macht erst nach 4 (!) Tagen Burn-In-Phase Sinn, d.h. der Sensor muss 4 Tage gemessen haben. Bis dahin driften die Widerstandswerte noch.
Das gilt unabhängig von der Elektronik, die die VOC-Äquivalente ausrechnet. Ich werde meinen daher wohl mal in einem gut durchgelüfteten und wohltempertierten Raum neu kalibrieren. Ich habe das seinerzeit auf dem Balkon nach nur 48h einbrennen und bei 15-16 Grad gemacht, also fairerweise nicht ganz optimal.
Obwohl meine Messreihe im Vergleich zum CO2mini bislang gar nicht soooooo schlecht aussieht. Die Kurven korrelieren ganz gut, insbesondere der nackte Widerstandswert ... der Drift kommt bislang nicht vor. Allerdings sind sie vom angezeigten Betrag her halt völlig verschieden, so dass das problem mit den vergleichswerten bleibt. Die vorgegebenen grenzwerte, mit dem das Ding ausgeliefert wird (und die LED-Farbe ändert), sind jedenfalls Mist und nach einer Stunde immer schon überschritten. So oft kann ich nicht Lüften ;-) Mal gucken ob eine Rekalibrierung das ändert ...
Zitat von: peterk_de am 15 Januar 2016, 11:19:43
Die vorgegebenen grenzwerte, mit dem das Ding ausgeliefert wird (und die LED-Farbe ändert), sind jedenfalls Mist und nach einer Stunde immer schon überschritten. So oft kann ich nicht Lüften ;-)
Genau das hab ich mir auch gedacht ;)
Evtl. kannst du mit dem CO2mini neue Grenzen die besser passen ermitteln und uns mitteilen.
Eine andere Frage ist, ob der Burn-In nicht schon in der Produktion durchgeführt wurde?
Ich würde meine Produkte jedenfalls nur fertig eingebrannt an die Kunden versenden - aber wer weiß!?!
Hallo Gemeinde,
vielleicht in dieser laufenden Diskussion etwas offtopic.
Ich benutze schon seit über einem Jahr den Voltrcraft Sensor, zunächst mit Airmonitor-Abruf über einen Cron-Job, ein paar Wochen später mit dem co20 Plugin vom André. Ich habe darüber auch damals in meinem Blog geschrieben.
https://blog.moneybag.de/luftqualitaets-sensor-voltcraft-co-20-ein-erfahrungsbericht/
Das Teil funktioniert bei mir tadellos im Wohn- und Schlafzimmer. Ich habe den Rehau-Sensor ebenfalls gekauft, welcher genau der gleiche ist wie damals der Voltcraft. Ich habe mal aus Spaß mal 2 Airwicks und einen MQ 2 - Sensor mit MYsensors neben dem Voltcraft und Rehau gestellt , und zeigen in der Grafik (natürlich mit anderen Werten) den gleichen Verlauf, siehe hier :
https://blog.moneybag.de/mq-2-sensor-und-luftqualitaets-sensor-ein-vergleich/
und hier
https://blog.moneybag.de/fhem-airwick-freshmatic-compact-als-geruchs-sensor-mit-mysensors-umgebaut/
Ich möchte mich jetzt nicht um exakte Verläufe hier streiten, für Normaluser wie mich reicht das dicke.
LG
/robin
Zitat von: fh168 am 16 Januar 2016, 09:18:45
Ich habe den Rehau-Sensor ebenfalls gekauft, welcher genau der gleiche ist wie damals der Voltcraft. Ich habe mal aus Spaß mal 2 Airwicks und einen MQ 2 - Sensor mit MYsensors neben dem Voltcraft und Rehau gestellt , und zeigen in der Grafik (natürlich mit anderen Werten) den gleichen Verlauf, siehe hier :
Kannst du bitte mal deinen "Reg_Set" Wert posten.
peterk_de kannst due den co2mini bzw. airco2ntrol mini definitiv empfehlen?
Chunter, ja. Der tut was er soll und die CO2-Werte passen zu dem, was man überall liest (und wie ich mir die Luft hier auch vorgestellt habe). Integration in FHEM ist ein Traum und lief auf meinem Raspberry sofort.
Ob man jetzt diese Absolutwerte und den Vergleich zu etablierten Qualitätsskalen braucht - und dafür das 4fache auf den Tisch legt - das ist die Frage. Kann man für einen Raum sicherlich mal machen. Dass die Luft schlechter geworden ist, sagt dir der CO20 aber auch und genauso gut - z.B. indem du dir einmal Werte merkst, die 3 Stunden nach dem Lüften aufgetreten sind, ohne dass jemand im Raum war (Referenzwert "gut") und mal nach 24h nicht-Lüften, wenn du von draußen reinkommst und denkst "IHHH" (Referenzwert für "schlecht"). Nur wie schlecht dein schlecht ist - weißte dann halt nicht. Ist sicher im Altbau ja anders als im superdichten Neubau. Aber du kannst dann immer erkennen, ob du eher bei deinem "IHHH" oder bei deinem "Frisch" liegst ;-)
Eine Meldung "Lang genug gelüftet" bekommst du mit dem CO20 ebenfalls genauso gut hin wie mit dem CO2mini, weil beide wirklich auf die Minute gleich schnell bei < 650 ppm gefallen sind; Ventilatorsteuerung sollte auch mit beiden gleich gut funktionieren; nur die hohen Werte sind halt nicht absolut vergleichbar.
Ich persönlich (als Perfektionist ;-)) werde CO20 + CO2Mini beide im Schlafzimmer/Wohnzimmer lassen (hängen bei uns ja zusammen) und auch noch das Kinderzimmer so ausstatten. Im Wohnzimmer/Kinderzimmer macht das m.E. am meisten Sinn, da die Nutzung bei uns hier mehr variiert als im Schlafzimmer - da hält sich halt die gleiche Personenzahl immer gleich lang schlafend auf, so dass die Kurven eh immer gleich sind ... und nachts steht auch keiner für's Lüften auf.
OK, da ich jetzt inzwischen noch zweimal gefragt wurde:
Voltcraft CO20 vs. CO2mini - Zusammenfassung
Voltcraft CO20 - pro:
- Er sagt zuverlässig, ob du Luftqualität einem vorher selbst zu ermittelnden Vergleichswert entspricht
- Er berücksichtigt dabei auch organische Ausdünstungen, die auch andere Ursachen als menschliche Atmung oder Verbrennungsprozesse haben (z.B. Putzmittel, Essensgeruch)
- Sehr preiswert
- Sehr klein
- Eingebaute, große Ampel-LED für die Luftqualität
Voltcraft CO20 - contra:
- Die Messwerte haben für sich genommen keine absolute Aussagekraft. Je nach Kalibrierung und Art der Luftkontamination kann "2500ppm" eine ganz unterschiedliche Luftqualität bedeuten.
- Die Kalibrierung ist im Vergleich zum CO2mini aufwändig und garantiert (offenbar) trotzdem keine Vergleichbarkeit der Messwerte
- Temperaturabhängigkeit: Reading schwankt mit sich ändernder Umgebungstemperatur
- Die Ampel-Anzeige ist i.d.R. selbst nachzujustieren und passt mit den Werten ab Werk nicht immer
- Ein Burn-In ist notwendig (mindestens 2, offenbar eher 4 Tage)
CO2mini - pro:
- Er liefert absolute CO2-Werte. Diese sind mit anderen, zahlreich publizierten Werten direkt absolut vergleichbar. 2500ppm z.B. heißt mit hoher Wahrscheinlichkeit "sehr stark verbrauchte Luft"; Werte um die 450ppm bedeuten "Innenluftqualität entspricht Außenluftqualität".
- Werkskalibriert - anstecken und los geht's.
- Eingebaute LCD-Anzeige mit Messwert + kleine Ampel-LED (dreistufig), die Ampel zeigt recht breit anerkannte Grenzwerte an
- Eingebauter Temperatur-Sensor und (bei manchen Modellen) auch eingebauter Luftfeuchtigkeitssensor
CO2mini - contra:
- Er liefert nur eine Aussage darüber, wie verbraucht die Luft durch die Anwesenheit / Aktivität von Lebewesen oder Verbrennungsprozessen ist. Essensgeruch, Putzmittel, überdurchschnittlich schlechte Körperhygiene etc. berücksichtigt er nicht.
- Vier mal so teuer wie der CO20
- Größer als der CO20
@Chunter
voltcraft
r_s
310300
2016-01-17 12:45:48
rehau
r_s
315919
2016-01-17 12:41:29
@ peterk_de
Danke für die gute Zusammenfassung. Kann Dir in allen Punkten nur zustimmen.
Falls es noch jemand anderes interessiert (die SW ließ ja hoffen):
Zitat von: peterk_de am 17 Januar 2016, 10:48:24
... bei manchen Modellen auch eingebauter Luftfeuchtigkeitssensor
Der "ohne" wird wohl auch von co2meter.com vertrieben und heißt dort RAD-0301. Ein ähnlicher Sensor mit RH heißt dort RAD-0201 und sieht dem AirCO2ntrol Observer' CO2-Monitor/TFA-Dostmann CO2-Monitor TFA 31.5002 mehr als ähnlich. Daher vermute ich einfach mal, der läuft mit gleicher USB-Spec.
Leider ist der Preis so sehr out-of-scope, dass ein Ersatz bestehender Temp/RH-Sensoren durch einen kombinierten Sensor für mich nicht in Betracht kommt. :(
Hallo,
Ich habe seit dem 12.1.16 einen CO20 im Outdoor Einsatz, um evtl. Geruchsbelästigung eines nahegelegenen Bauernhofs zu erfassen.
Allerdings stellte ich fest das der CO20 wohl ehr die Temperatur misst ?! siehe Anhang
Ich denke der CO20 ist dafür wohl ehr ungeeignet, Vorschlag was ich sonst nehmen könnte?
Der CO2mini misst ja nur CO2 ......
Hier noch 2 Dateien zum vergleich, bei steigender Temperatur steigt auch immer ppm
Ja, da würde ich sagen, dass das so zu erwarten ist. Die geringere Temperatur führt zu einer langsameren Reaktion der VOC-Moleküle am Sensor. Deswegen wird der ja auch beheizt. Der CO20 kalibriert den Heizspulenwiderstand aber nicht ständig nach, so dass die Heizung im Sensor Temperaturschwankungen überhaupt nicht ausgleicht. Das ist auch im Raum ein Problem, da hast du aber normalerweise keine 15 Grad Temperaturschwankung, wie in deinem Plot.
Mit anderen Worten, outdoor kannste das Ding vergessen. Heißt ja aber deshalb ja auch "Indoor" ;-)
Ein Versuch war es wert, den nur so lernt man ;)
Wie verhält sich den der MQ-2 MQ-7?
Ich hatte so ein Ding angschafft um 1m überm Katzenklo zu messen, wenn es wieder mal Zeit ist, letzteres zu reinigen. Funktionierte absolut nicht! Die menschliche Nase ist da um ein vielfaches empfindlicher, dagegen wird das Ding sofort rot, wenn man in der Nähe eine Spiritusflasche aufgeschraubt hinstellt. Das riecht man wiederum als Mensch nicht. Also mMn. kannst Du das mit den Schweinen vom Nachbarbauern vergessen unabhängig von der Temperatur.
Dazu sollte man wissen, dass ein VOC-Sensor auf flüchtige Kohlenstoffverbindungen reagiert, aber nicht auf stinkende Pisse, die schwerpunktmäßig durch NH3 (Ammoniak) charakterisiert wird.
Der MQ-135 reagiert auf NH3, https://www.olimex.com/Products/Components/Sensors/SNS-MQ135/resources/SNS-MQ135.pdf
Zusammen mit einem Arduino und ggfs MYSENSORS kann man da einen funktionierenden Sensor bauen.
VG
Sven
Danke für die Info, habe mir mal einen MQ-135 bestellt.
Habe gerade mal einen CO-20 an einem CO2mini "geeicht". Also den CO-20 resettet als der CO2mini 450 gezeigt hat. Bin mal gespannt, wie synchron die jetzt laufen...
Hallo vbs,
genau das habe ich mit meinen drei CO-20 und zwei CO2mini auch vor. Hast Du schon Ergebnisse?
Gruß
Peter
Also Stand jetzt sieht nicht so gut aus:
CO2mini: 1065 ppm
CO20: 657 ppm
Direkt nach dem Kalibrieren lagen die beiden für ein paar Stunden recht nah beieinander (Abweichung <100). Mal gucken wie es weiter geht, vielleicht probier ich es noch einmal.
Zitat von: vbs am 27 Januar 2016, 21:31:11
Also Stand jetzt sieht nicht so gut aus:
CO2mini: 1065 ppm
CO20: 657 ppm
Direkt nach dem Kalibrieren lagen die beiden für ein paar Stunden recht nah beieinander (Abweichung <100). Mal gucken wie es weiter geht, vielleicht probier ich es noch einmal.
Ich habe das schon über mehrere Tage beobachtet ... wird nix. Man kann auch keinen "Umrechnungsfaktor" festlegen und auch bei niedrigen Messwerten haut es nur manchmal hin. Hängt stark davon ab, wie kalt es draußen ist, denn beim Lüften, wenn es schön kalt ist, kalibriert sich das Ding auf einen viel zu niedrigen Grundwert neu ein und geht danach sofort wieder auf 1000 hoch, wenn der CO2mini noch 580 oder so anzeigt. Wenn es draußen wärmer ist, ist es besser.
P.S.: Rekalibrierung hatte ich eigentlich mit dem Windows-Tool tatsächlich ausgeschaltet ... kann sein, dass da was schiefgelaufen ist.
Mit dem Blanken Sensormesswert sieht es besser aus. Aber ne Lineare abhängigkeit sehe ich auch da nicht ... sind halt zwei ganz verschiedene Messgrößen! Die korrelieren zwar irgendwie, aber wenn die mal im zeitlichen Verlauf übereinstimmen, ist das m.E. purer Zufall.
Zitat von: vbs am 27 Januar 2016, 21:31:11
Also Stand jetzt sieht nicht so gut aus:
CO2mini: 1065 ppm
CO20: 657 ppm
Was ihr hier grade macht ist in etwa so wie der Versuch, eine Abhängigkeit zwischen Helligkeit und Lautstärke herzustellen, nur weil es üblicherweise nach Anbruch der Dunkelheit draussen leiser wird. :)
Die beiden Geräte messen völlig unterschiedliche Dinge auf unterschiedliche Arten mit unterschiedlichen Sensoren.
Das was den co-20 meiner Meinung nach schlicht unbrauchbar macht ist seine Temperaturabhängigkeit.
Keine vernünftig reproduzierbaren Ergebnisse sind Mist!
chunter, ja, ich hab das mal mit in meine pro- und contra-liste gepackt. Vielleicht kopiert die ja mal einer ins Wiki - für nachfolgende Generationen ;-)
Hi,
ich habe mir heute den Velux Sensor am Raspberry Pi 2B installiert. Zunächst hat er problemlos funktioniert und ca. 3 Stunden lang Werte geliefert. Netzteil ist sehr gut, der aktive USB-Hub mit dem Raspi kompatibel. Das USB-Kabel ist 2,4m lang.
Beim überfliegen der 32 Forenseiten stellte ich fest, dass im Logfile unschöne Einträge drin sind:
2016.02.23 20:43:31 3: Abluft_co20: disconnected
2016.02.23 20:43:31 3: Abluft_co20: CO20 device found
2016.02.23 20:43:33 3: Abluft_co20: failed to open CO20 device
2016.02.23 20:43:33 3: Abluft_co20: disconnected
2016.02.23 20:55:39 2: Abluft_co20: no device
2016.02.23 20:55:39 3: Abluft_co20: CO20 device found
2016.02.23 20:55:41 3: Abluft_co20: failed to open CO20 device
2016.02.23 20:55:41 3: Abluft_co20: disconnected
Daraufhin habe ich, wie angeraten, in der Datei /boot/cmdline.txt den Eintrag
dwc_otg.speed=1
der Zeile vorangestellt:
dwc_otg.speed=1 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
und den Raspi neu gebootet.
Daraufhin hat fhem gar keine Daten mehr empfangen. Dann den Eintrag wieder vom Zeilenbeginn entfernt und den Raspi neu gebootet. Aber das Ergebnis bleibt dasselbe: fhem meldet im UI "STATE disconnected", im Logfile steht
2016.02.23 21:31:05 2: Abluft_co20: no device
2016.02.23 21:31:05 3: Abluft_co20: disconnected
2016.02.23 21:31:05 3: Abluft_co20: failed to find CO20 device
Experimente mit "retries 5" und "timeout 2000" halfen auch nicht.
Wie schaffe ich es nun, den Sensor wieder zum Leben zu erwecken? Das Problem dabei ist, dass Sensorkabel und USB-Hub ziemlich unzugänglich verbaut sind. Zur Not komme ich ran, aber eigentlich sollte der Sensor ja auch kein mechanisches ab/anstecken benötigen.
Die Konfiguration:
define Abluft_co20 CO20
attr Abluft_co20 advanced 1
attr Abluft_co20 retries 5
attr Abluft_co20 room Wohnzimmer
attr Abluft_co20 timeout 2000
define FileLog_Abluft_co20 FileLog /mntUSB/fhem/log/Abluft-CO20-%Y-%m.log Abluft_co20:voc.*
define Abluft_co20_Chart SVG FileLog_Abluft_co20:SVG_FileLog_Abluft_co20_1:CURRENT
attr Abluft_co20_Chart room Wohnzimmer
Raspi nur rebootet oder den CO20 stromlos gemacht?
nur rebootet.
Braucht der Sensor einen stromlosen Reset beim booten? Das wäre unschön für remote Restarts.
Habe meinen Sensor jetzt seit 1 1/2 Wochen erfolgreich in Betrieb und wollte nun einen zweiten Sensor in Betrieb nehmen. Eine Kabelverbindung ist dorthin nicht möglich. Deshalb war die Idee, den zweiten Sensor mit einem RaspberryPi + WLAN über Ser2Net anzubinden. Mir ist allerdings nicht klar, wie in diesem Fall die Device-Definition aussehen müsste. Lt. Commandref wäre es ja
define <name> CO20 [bus:device]
Der Ersatz eines USB-Devices mit Ser2Net würde aber eher so aussehen:
define Schlafzimmer_co20 CO20 raspberrypi:2003
attr Schlafzimmer_co20 advanced 1
attr Schlafzimmer_co20 retries 5
attr Schlafzimmer_co20 timeout 2000
Geht auch prompt nicht: das Device liest die Werte des direkt am FHEM-Server angeschlossenen Sensors (vermute ich anhand der praktisch identischen Werte).
Wie mache ich es richtig?
Nachtrag:
Auf Verdacht habe ich den Sensor in Ser2Net mit 9600-8-n-1 konfiguriert. Passt das?
edit:
hat sich erledigt. Habs jetzt mit FHEM2FHEM gemacht.
Hi,
mein Sensor hat heute Nacht plötzlich von einer Messung zur nächsten (=5 Minuten) einen Sprung von ca. 500 auf über 2000 ppm gemacht, ohne dass sich im Haus irgendwas geändert hätte, das die Luftqualität beeinflusst. Es gab m.M.n. auch keine Spannungsunterbrechung oder so; jedenfalls lief der FHEM-Server am selben Netzteil problemlos durch.
Hat das schon mal Jemand erlebt? Woran kann das liegen?
Nachdem die Werte nicht besser wurden, habe ich dem Sensor nun ein "reset_baseline" verpasst, da sich meine KWL sonst noch sinnlos zu Tode pumpt.
Hallo,
ich bin am Rand der Verzweiflung :(
Seit geraumer Zeit versuche ich einen REHAU Raumluftsensor dazu zu bewegen mir Daten in FHEM zu zeigen.
Ich bekomme außer DISCONNECTED keine Anzeige hin.
Mit lsusb wird der Stick mit 001:004 angezeigt.
listco20 zeigt:
Interval 1800
Name co20
Notifydev global
Nr 764
NTFY_ORDER 50-co20
RECONECT 1
STATE disconnected
TYPE CO20
fail 1
seq2 103
seq4 1
Gibt es irgendwo eine Schritt für Schritt Anleitung für Dummies?
Gruß
Michael
Schon mal die Mühe gemacht und die commandref gelesen? Was willst Du mehr an Anleitung?
Zitat von: fmth am 05 April 2016, 11:53:25
Gibt es irgendwo eine Schritt für Schritt Anleitung für Dummies?
Ein paar Beiträge weiter oben gibt es z.B. meine Konfiguration, die so funktioniert. Du kannst sie natürlich um die Adresse 001:004 erweitern.
Falls Du zu viel rum experimentiert hast, musst Du den Sensor evtl. mal stromlos machen. Anders habe ich ihn manchmal nicht mehr ans laufen bekommen. Wenn Du aber den Server laufen lässt und nur die USB-Verbindung zum Sensor kappst, dann ändert sich die Adresse, also nochmal per lsusb checken.
Und "get air_data" oder "get update" darf man auch nicht so ernst nehmen. Da tut sich oft für 1 - 2 Minuten gar nichts.
Hallo willybauss,
vielen Dank für deine Antwort.
Deine Konfiguration habe ich so wie sie da steht übernommen, jedoch immer noch ohne Erfolg.
Ich nehme an das FHEM keine Berechtigung hat auf den Sensor zu zugreifen.
In der COMANDREF wird Bezug auf eine Anleitung genommen: Install_AirSensor_Linux usb-sensors-linux
Vermutlich liegt mein Fehler da :-(
Diese Anleitung habe ich jetzt bestimmt schon 10 mal durchgeackert leider immer noch ohne Erfolg.
Gruß
Michael
Fang doch mal damit an ein paar Worte über deine Hardware und dein OS zu sagen, das könnte schon weiterhelfen.
Eventuell fehlt ja nur eine udev Regel für das USB Device.
Hast Du auch das in der Commandref beachtet?:
ZitatDevice::USB hast to be installed on the FHEM host.
It can be installed with 'cpan install Device::USB'
or on debian with 'sudo apt-get install libdevice-usb-perl''
Hallo,
danke für die Tips,
Kaum macht man es richtig, schon klappts.
Es fehlte die udef Regel......
Gruß
Michael
Hallo!
Habe nach den vielen Anleitungen und Tipps die Kurve geschafft.
Aber ich habe im Web immer neben dem Namen open stehen.
Ich möchte aber den voc: ppm Wert darstellen.
lg
Wolfgang
#Luftqualitätsensor Reha
define Abluft_co20 CO20
attr Abluft_co20 advanced 1
attr Abluft_co20 group Sensoren
attr Abluft_co20 interval 30
attr Abluft_co20 retries 5
attr Abluft_co20 room Haus
attr Abluft_co20 timeout 2000
#attr Abluft_co20 group Sensoren
define FileLog_Abluft_co20 FileLog /opt/fhem/log/Abluft-CO20-%Y-%m.log Abluft_co20:voc.*
define Abluft_co20_Chart SVG FileLog_Abluft_co20:SVG_FileLog_Abluft_co20_1:CURRENT
attr Abluft_co20_Chart room Haus
Da steht immer opened. Es ist ja nur das Statusdisplay. Wenn Du Dir den Zahlenwert ansehen willst kannst Du Dir z.B. ein Dashboard anlegen. Besser fände ich ein Diagramm, so dass Du die Historie des ganzen Tages siehst. Da kannst Du dann zusätzlich den letzten Messwert im Titel einblenden. sh. Anhang.
Habs gefunden
attr Abluft_co20 stateFormat voc ppm
lg
Wolfgang
Hallo willybauss
Kannst du bitte mal dein Plot hier reinstellen.
lg
Wolfgang
schon wieder was gelernt... Dir ist aber klar, dass Du von nun an nie mehr weißt, ob das Device noch Daten liefert oder ob der angezeigte Wert schon 3 Wochen alt ist, weil das Device nichts mehr tut?
Eine Zeile darunter im Web habe ich den Plot. Dort sehe ich die Zeit.
Hallo zusammen,
musste leider auf eine neue Hardware gehen, der alte Router war defekt (Openwrt).
Jetzt will das Teil keine Werte mehr liefern..
Bekomme ständig found disconnect, auffällig ist, dass das alle 70 Sekunden passiert..
2016.05.12 15:49:45 3: SZ.iam: CO20 device found
2016.05.12 15:49:45 3: SZ.iam: CO20 device opened
2016.05.12 15:50:28 3: SZ.iam: disconnected
2016.05.12 15:50:28 3: SZ.iam: CO20 device found
2016.05.12 15:50:28 3: SZ.iam: CO20 device opened
2016.05.12 15:51:32 3: SZ.iam: disconnected
2016.05.12 15:51:32 3: SZ.iam: CO20 device found
2016.05.12 15:51:32 3: SZ.iam: CO20 device opened
2016.05.12 15:52:42 3: SZ.iam: disconnected
2016.05.12 15:52:42 3: SZ.iam: CO20 device found
2016.05.12 15:52:42 3: SZ.iam: CO20 device opened
2016.05.12 15:53:52 3: SZ.iam: disconnected
2016.05.12 15:53:52 3: SZ.iam: CO20 device found
2016.05.12 15:53:52 3: SZ.iam: CO20 device opened
2016.05.12 15:55:02 3: SZ.iam: disconnected
2016.05.12 15:55:02 3: SZ.iam: CO20 device found
2016.05.12 15:55:02 3: SZ.iam: CO20 device opened
2016.05.12 15:56:12 3: SZ.iam: disconnected
2016.05.12 15:56:12 3: SZ.iam: CO20 device found
2016.05.12 15:56:12 3: SZ.iam: CO20 device opened
Hat jemand einen Tip für mich ?
mal unter windows probieren ? Wenns da auch nicht geht, dann wohl kaputt.
wenn es unter windows geht: USB-Stromversorgung ? Ist ja immer wieder ein Thema bei dem Teil. Intervall etwas höher setzen ?
Mehr fällt mir leider nicht ein :-\
Markus
Danke Markus ...
Mit Umzug auf die neue Hardware, musste ich den USB-HUB auch tauschen, haben sich beide nicht so richtig vertragen.
Ales alles wieder gut ..
Hallo zusammen,
wenn ich einen "get iam knob_data" sende, bekomme ich:
2016.05.13 13:01:28 5: Cmd: >get SZ.iam knob_data<
2016.05.13 13:01:28 5: 64 48 48 48 57 59 67 79 50 47 86 79 67 32 108 101
@0009;CO2/VOC le
2016.05.13 13:01:28 5: 118 101 108 95 119 97 114 110 49 59 112 112 109 59 49 59
vel_warn1;ppm;1;
2016.05.13 13:01:28 5: 48 59 53 48 48 48 59 48 59 2 220 5 59 67 79 50
0;5000;0;�;CO2
2016.05.13 13:01:28 5: 47 86 79 67 32 108 101 118 101 108 95 119 97 114 110 50
/VOC level_warn2
2016.05.13 13:01:28 5: 59 112 112 109 59 49 59 48 59 53 48 48 48 59 48 59
;ppm;1;0;5000;0;
2016.05.13 13:01:28 5: 59 112 112 109 59 49 59 48 59 53 48 48 48 59 48 59
2016.05.13 13:01:28 5: 73 110 116 101 114 118 97 108 59 115 59 49 59 48 59 54
Interval;s;1;0;6
2016.05.13 13:01:28 5: 53 53 51 53 59 48 59 2 0 0 59 117 105 49 54 83
5535;0;;ui16S
2016.05.13 13:01:28 5: 116 97 114 116 117 112 66 105 116 115 59 59 49 59 48 59
tartupBits;;1;0;
2016.05.13 13:01:28 5: 54 53 53 51 53 59 48 59 2 1 0 59 59 10 0 0
65535;0;;;
2016.05.13 13:01:28 5: 54 53 53 51 53 59 48 59 2 1 0 59 59 10 0 0
2016.05.13 13:01:28 5: 54 53 53 51 53 59 48 59 2 1 0 59 59 10 0 0
2016.05.13 13:01:29 5: 54 53 53 51 53 59 48 59 2 1 0 59 59 10 0 0
2016.05.13 13:01:29 5: 54 53 53 51 53 59 48 59 2 1 0 59 59 10 0 0
2016.05.13 13:01:29 5: 54 53 53 51 53 59 48 59 2 1 0 59 59 10 0 0
2016.05.13 13:01:29 5: 54 53 53 51 53 59 48 59 2 1 0 59 59 10 0 0
2016.05.13 13:01:29 5: 144
2016.05.13 13:01:29 5: datalen 144
allerdings wird nichts im FHEM angezeigt.
Mache ich das bei einem funktionierendem System bekomme ich:
2016.05.13 12:47:31 5: Cmd: >get WZ.iam knob_data<
2016.05.13 12:47:31 5: 64 48 48 48 50 59 67 79 50 47 86 79 67 32 108 101
@0002;CO2/VOC le
2016.05.13 12:47:31 5: 118 101 108 95 119 97 114 110 49 59 112 112 109 59 49 59
vel_warn1;ppm;1;
2016.05.13 12:47:31 5: 48 59 53 48 48 48 59 48 59 2 220 5 59 67 79 50
0;5000;0;�;CO2
2016.05.13 12:47:31 5: 47 86 79 67 32 108 101 118 101 108 95 119 97 114 110 50
/VOC level_warn2
2016.05.13 12:47:31 5: 59 112 112 109 59 49 59 48 59 53 48 48 48 59 48 59
;ppm;1;0;5000;0;
2016.05.13 12:47:31 5: 2 172 13 59 82 101 103 95 83 101 116 59 59 49 59 48
�
;Reg_Set;;1;0
2016.05.13 12:47:31 5: 59 50 48 48 59 48 59 2 172 0 59 82 101 103 95 80
;200;0;�;Reg_P
2016.05.13 12:47:31 5: 59 59 49 59 48 59 49 48 48 48 59 48 59 2 3 0
;;1;0;1000;0;
2016.05.13 12:47:31 5: 59 82 101 103 95 73 59 59 49 59 48 59 49 48 48 48
;Reg_I;;1;0;1000
2016.05.13 12:47:31 5: 59 48 59 2 10 0 59 82 101 103 95 68 59 59 49 59
;0;
;Reg_D;;1;
2016.05.13 12:47:31 5: 48 59 49 48 48 48 59 48 59 2 0 0 59 76 111 103
0;1000;0;;Log
2016.05.13 12:47:31 5: 73 110 116 101 114 118 97 108 59 115 59 49 59 48 59 54
Interval;s;1;0;6
2016.05.13 12:47:31 5: 53 53 51 53 59 48 59 2 0 0 59 117 105 49 54 83
5535;0;;ui16S
2016.05.13 12:47:31 5: 116 97 114 116 117 112 66 105 116 115 59 59 49 59 48 59
tartupBits;;1;0;
2016.05.13 12:47:31 5: 54 53 53 51 53 59 48 59 2 0 0 59 59 10 0 0
65535;0;;;
2016.05.13 12:47:31 5: 54 53 53 51 53 59 48 59 2 0 0 59 59 10 0 0
2016.05.13 12:47:31 5: 240
2016.05.13 12:47:31 5: datalen 240
Ist schon merkwürdig ...
Merkwürdig ist auch, dass im immer mal wieder für VOC eine Nullbekomme...
Ist es möglich, die 38_CO20.pm so zu ändern, dass bei einem Lesefehler, statt VOC 0, nichts geschrieben wird ?
Mir fehlen leider die Kenntnisse ...
Klaus
komisch, VOC=0 kenne ich gar nicht. Meiner sinkt nie unter 450. Steigt der r_s über den kalibrierten "Sommerwert(ca. 200.000)" zB. beim Lüften im Winter, rekalibriert der Sensor sich.
Du könntest Dein Fehlerbild mit einem userReadings oder einem (wahrscheinlich komplizierten) Regexp in der FileLog definition ausfiltern.
Grundsätzlich sollte er auch nie unter den 450 anzeigen. Wenn nicht, ist das tatsächlich ein Fehler. Es wäre dann sinnvoll den im Modul abzufangen.
Vielleicht wäre es trotzdem sinnvoll, den ausgelesenen Wert auch anzuzeigen, um in solch einem Fall festzustellen, dass die Kalibrierung erneuert werden sollte.
Oder bekommt man das noch irgendwie anders mit?
Hab mittlerweile auch einen richtigen CO2-Sensor und ich habe festgestellt, den VOC-Sensor zu Kalibrieren, ist nicht wirklich trivial, wenn man das denn wirklich versucht.
Hallo zusammen,
möchte mich nochmal melden, zum Thema VOC=0.
Sorry für die Hektik die ich verbreitet habe. Es liegt/lag alleine an meinem Rechner, nach einigem gebastel tut es wieder einwandfrei.
Ich habe mir so ein GL inet Teil http://www.amazon.de/Gl-iNet-generation-configuration-surveillance-downloading/dp/B00OTV378I/ref=sr_1_1?ie=UTF8&qid=1463585370&sr=8-1&keywords=gl+inet (http://www.amazon.de/Gl-iNet-generation-configuration-surveillance-downloading/dp/B00OTV378I/ref=sr_1_1?ie=UTF8&qid=1463585370&sr=8-1&keywords=gl+inet) bestellt und zuerst mit USB-Hub betrieben. Dieser ist jedoch gar nicht nötig, da der Nano Router genug Speicher hat. Hängt der Air-Stick direkt am Nano Router funktioniert alles zu meiner Zufriedenheit. Bin richtig begeistert von dem Teil.
Wenn also einer Unterstützung braucht, um einen Air-Stick via FHEM2FHEM an seine Heimautomation anzuschließen, kann ich höchstwahrscheinlich gute Unterstützung bieten.
bis die Tage
Klaus
Hallo Klaus,
Schön, dass er bei Dir jetzt läuft. Würde mich interessieren, woran es bei Dir schlußendlich lag.
Habe mein System gerade umgezogen und dabei auch wieder festgestellt, generell für die Inbetriebnahme des Sensors und die softwareseitige Konfiguration sollte man zunächst die stabilste HW-Konfiguration zum Laufen bekommen (ohne zu lange oder qualitativ zu schlechte Kabel, zusätzliche inkompatible Hubs oder nicht ausreichend Stromstabilität auf dem USB-Port (RPi-Krankheit)), z.B. direkt am USB-Port und ohne weitere Stick, die den Port stromseitig zusätzlich belasten könnten. Dann hat man zumindest dieses als Fehlerquelle ausgeschlossen.
OT:
Eine Frage noch zum GL inet, hab ich das richtig verstanden, das Ding hat einen telnet oder ssh Zugang und Du hast dort eine FHEM-Instanz installiert, die Dir die Daten per FHEM2FHEM auf Deine Hauptinstanz überträgt? Auch wenn der Rpi nur unwesentlich teurer ist, finde ich das immer einen ganz schönen Verhau, gleich nen ganzen Rechner für einen Remotesensor zu spendieren. Stromverbrauch wäre natürlich auch spannend, obwohl der RPi ja auch sehr sparsam daher kommt.
Denke, da gäbe es sicherlich noch andere Anwendungsfälle und vielleicht wäre das auch einen Wikiartikel wert. ;)
Schöne Grüße,
John
Zitat von: joshi04 am 18 Mai 2016, 19:08:39
Eine Frage noch zum GL inet, hab ich das richtig verstanden, das Ding hat einen telnet oder ssh Zugang und Du hast dort eine FHEM-Instanz installiert, die Dir die Daten per FHEM2FHEM auf Deine Hauptinstanz überträgt? Auch wenn der Rpi nur unwesentlich teurer ist, finde ich das immer einen ganz schönen Verhau, gleich nen ganzen Rechner für einen Remotesensor zu spendieren. Stromverbrauch wäre natürlich auch spannend, obwohl der RPi ja auch sehr sparsam daher kommt.
Denke, da gäbe es sicherlich noch andere Anwendungsfälle und vielleicht wäre das auch einen Wikiartikel wert. ;)
Schöne Grüße,
John
Hallo John,
völlig korrekt. Ich betreibe den GL (6416) mit einem abgespecktem FHEM, nur für den Sensor. Und ja, ich habe auch schon an einen RPI 3 gedacht, jedoch braucht der mir für dieses Vorhaben zuviel Strom. Der GL kommt mit unter 1 Watt daher. Der GL hat ausserdem noch zwei LAN Anschlüsse. Ich bin gerade am überlegen, ob ich nicht noch so ein Teil ins Clo installieren soll, um bei übermäßigem VOC Wert den Bad Lüfter anzuwerfen...
Abgespecktes FHEM soll heißen, alles oder fast alles was nicht zum Sensor gehört gehört, habe ich einfach gelöscht. FHEM2FHEM tut trotzdem wunderbar. Der Speicherbedarf für diese FHEM Instanz ist damit unter 5 Mbyte geschrumpft, und damit ideal für Nano Router.. (der Rouer hat immerhin 16 Mbyte Flash)
bis die Tage
Klaus
Irgendwie schaffe ich es nicht den REHAU Sensor zum laufen zu bringen.
Ich habe zwar im Log Device found aber failed to open.
Unprofessionellerweise läuft mein FHEM mit root-Rechten, das sollte es insofern nicht sein.
Sind die notwendigen Perl-Module denn sauber installiert?
Poste doch mal Definition und Log mit Level 5
Sent from my iPhone using Tapatalk
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: 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
Ah ja, ich habe auch eine wh3080 die über pywwv per libusb angesprochen wird.
Zitat von: Markus M. am 23 Mai 2016, 17:59:27
Poste doch mal Definition und Log mit Level 5
Zitat von: drdownload am 23 Mai 2016, 20:50:14
Ganz banal: mit rehau.sensoren.wohnzimmer co20 definiert.
:-\
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 ;)
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
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.
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.
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.
Du hast Recht:
https://forum.fhem.de/index.php/topic,13166.msg322854.html#msg322854 (https://forum.fhem.de/index.php/topic,13166.msg322854.html#msg322854)
und folgende.
Wenn sie sich "per USB" nicht unterscheiden, kann man udev vergessen.
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.
Ü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.
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.
Zitat von: Markus M. am 13 Juni 2016, 00:22:16
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.
define Mythz THZ /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0@115200Aber das geht halt nur, wenn das Device in /dev/serial/by-id/ auftaucht und einen eindeutigen Namen hat.
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
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...
@Markus
vielen Dank für die schnelle Bearbeitung, ich werde es heute Abend Zuhause teste. Was meinst du mit blockierend?
LG
Wenn der Sensor nicht reagiert wenn er soll, was beim Pi USB ja vorkommen kann, steht FHEM erst mal bis zum Timeout.
Wenn du also sowieso schon Disconnects hast, wirst du auch mit dieser Lösung nicht glücklich werden.
Aber probiers erst mal aus.
Sent from my iPhone using Tapatalk
Gestern mal mit der Definition über die Seriennummer laufen lassen, das Ergebnis nach ein paar Stunden war leider eine komplette Blockade von FHEM.
Habe die Datei weiter oben nochmal aktualisiert, bis jetzt sieht alles gut aus.
Habs gerade versucht. Scheint zu funktionieren.
Aufruf mit z.B.
define Zuluft_co20 CO20 4831363137301503181C
nach weiteren Tests:
- überlebt auch einen "shutdown restart von fhem
- überlebt auch einen Reboot des Raspi
Nach dem Reboot hatte ich bisher immer Probleme mit den Sensoren und musste deshalb beim Reboot alles stromlos machen. Scheint aus meiner Sicht alles ok zu sein :) :) :)
Besten Dank für die schnelle Realisierung.
Was es nicht überstehen dürfte ist ein Abziehen des Sticks mit Änderung der ID.
Probier das bei Gelegenheit mal aus und probier auch mal set reconnect_id und set reconnect_serial
für einen reconnect über ID und SERIALNUMBER.
Anschliessend kannst du mal die Version im Anhang testen und dich nächste Woche nochmal melden.
Wenn es bis dann ohne Probleme läuft, checke ich den Code ein.
mach ich.
@belu:
wäre nett, auch von Dir Testergebnisse zu haben ;)
Zitat von: Markus M. am 14 Juni 2016, 23:58:25
Was es nicht überstehen dürfte ist ein Abziehen des Sticks mit Änderung der ID.
Probier das bei Gelegenheit mal aus und probier auch mal set reconnect_id und set reconnect_serial
für einen reconnect über ID und SERIALNUMBER.
Anschliessend kannst du mal die Version im Anhang testen und dich nächste Woche nochmal melden.
Wenn es bis dann ohne Probleme läuft, checke ich den Code ein.
- Testsoftware lt. Deinem Beitrag vom 13. Juni 10:38
- Stick im Betrieb abgezogen und wieder angesteckt => disconnect
- set reconnect_serial => opened; Stick wird also wiedergefunden; das ging früher nicht
- set reconnect_id => habe ich nicht getestet, da ich ja jetzt keine ID mehr im DEF spezifiziert habe
Dann werde ich jetzt die neue Testsoftware einspielen und dasselbe testen. Was ist daran anders?
Zitat von: willybauss am 17 Juni 2016, 22:05:13- Stick im Betrieb abgezogen und wieder angesteckt => disconnect
erwartetes Verhalten
Zitat- set reconnect_serial => opened; Stick wird also wiedergefunden; das ging früher nicht
Hättest du noch ein paar mal machen können - hier scheint das Problem zu liegen, wenn es einen Timeout gibt o.ä.
Zitat- set reconnect_id => habe ich nicht getestet, da ich ja jetzt keine ID mehr im DEF spezifiziert habe
Doch, hast du :)
Die ID wird beim Verbinden abgespeichert und eine erneute Verbindung wird immer erst über die ID probiert.
ZitatDann werde ich jetzt die neue Testsoftware einspielen und dasselbe testen. Was ist daran anders?
Punkt 1 sollte jetzt funktionieren. Wenn du danach ein Update machst, sollte der Stick wieder verbinden.
Ansonsten: einfach mal ne Woche laufen lassen. Wenn das klappt, bin ich zufrieden.
- Testsoftware lt. Deinem Beitrag vom 14. Juni 23:58
- Stick im Betrieb abgezogen => Status bleibt "opened", auch noch nach 5 Minuten :-\
- shutdown restart, um ein disconnect zu erzwingen => immernoch opened => gefällt mir gar nicht
- und wieder angesteckt => immer noch opened
- set reconnect_serial => opened; schwer zu beurteilen, wie das zu bewerten ist
edit:
auf jeden Fall liefert der Stick aktuelle Werte => zumindest jetzt stimmt das "opened"
@ Markus M.:
Habe jetzt in meinem letzten Beitrag rot markiert, was nicht funktioniert. Kann ja nicht sein, dass der Stick "opened" ist wenn er gar nicht angeschlossen ist.
Wäre schick, wenn Du was dazu sagen könntest, besser sogar noch fixen,
Eigentlich sollte sich an der Stelle nichts geändert haben.
Probier mal die hier.
- Testsoftware lt. Deinem Beitrag vom 20. Juni 14:50
- Software installiert (ins .../FHEM Verzeichnis kopiert)
- shutdown restart
- Stick A ==> "disconnected"
- Stick B ==> "opened"
- Stick C ==> "disconnected"
- Stick C kann ich nach mehreren Versuchen mit "set reconnect_serial" auf "opened" bringen
- Stick A bleibt hartnäckig auf "disconnected"; ich lasse ihn so, um zu sehen, ob er sich selbst "heilt"
- Stick B im Betrieb abgezogen => Status bleibt "opened", auch noch nach 5 Minuten :-\ ==> selbes Problem wie oben
- shutdown restart, um ein disconnect zu erzwingen =>
--- Stick A opened
--- Stick B disconnected
--- Stick C opened
--- ==> also das richtige Ergebnis
- und Stick B wieder angesteckt => immer noch disconnected
- nach 5 Minuten ein Refresh der Anzeige (F5) => immer noch disconnected
Damit wir nicht aneinander vorbei reden: erwartest Du, dass der disconnectete Stick sich im Lauf deer Zeit selber wieder connected und auf "opened" geht? Das scheint - wenn überhaupt - nur unzuverlässig zu gehen.
Oder erwartest Du, dass ich nach dem wieder anstecken des Sticks manuell "set reconnect_serial" mache? Das hatte schon in der Testversion vom 13.6. funktioniert. In der heutugen Version ist es eher unzuverlässig.
Haaaaloooo Markus,
wäre nett auf die Testergebnisse und die Fragen bei Gelegenheit ein Feedback zu bekommen :)
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.
Zitat von: Markus M. am 23 Juni 2016, 14:24:01
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.
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:
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
Usb-hub ?
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.
Hallo, danke für die schnellen Antworten. Ich werde es nächste Wiche testen
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?
Ich nutze eine raspberry Pi 3. als Netzteil habe ich das eine Amazon Fire tv Sticks genommen
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.
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.
Zitat von: willybauss am 23 Juni 2016, 14:31:47
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.
Zitat von: Markus M. am 26 Juni 2016, 14:16:13
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
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.
Zitat von: willybauss am 26 Juni 2016, 15:00:56
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.
ZitatBei 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.
ZitatEvtl. 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.
Zitat von: Markus M. am 26 Juni 2016, 15:46:02
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.
Zitat von: Markus M. am 26 Juni 2016, 15:46:02
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.
Zitat von: Markus M. am 26 Juni 2016, 15:46:02
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.
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 ... :-\
Zitat von: willybauss am 26 Juni 2016, 16:00:01
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?
Zitateingecheckte 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?
Zitat von: Markus M. am 26 Juni 2016, 16:12:08
Alles was du davon bisher gesehen hast, war der unscheinbare fail Counter in den Internals.
Habe grade geschaut. Der steht bei allen 3 Sticks auf 0. Bei einem Stick war er mal kurz auf 2, dann wieder auf 0.
Zitat von: Markus M. am 26 Juni 2016, 16:12:08
Wie hattest du die drei Sticks vorher definiert? Mit der ID?
ja
Zitat von: Markus M. am 26 Juni 2016, 16:12:08
Hast du mal mit dmesg nachgesehen was beim Einstecken oder Booten passiert?
Erkennt der Rechner den Stick überhaupt immer?
nein, habe ich nicht geschaut. Kann ich auch grade nicht. Aber wenn er nicht erkannt würde, würde auch der reconnect kaum zum Erfolg führen.
Ich sehe grade, dass ich bei den Sticks mit den langen Leitungen ziemlich relaxte Settings habe:
retries 20
timeout 10000
Weiß nicht, ob das aktuell noch so notwendig ist. Da es so funktioniert will ich es nicht ohne Not ändern. Hat aber evtl. auch nichts mit den "error"s zu tun, denn die kamen auch bei dem Stick, der nur an einer 2m-Leitung hängt.
Hallo,
ich habe heute mal Zeit gefunden zum testen, habe die erste Version die am stabilisten läuft laut Willy getestet.
Also er findet die Sticks und ordnet sie auch zu, aber es dauert ewig, und ich kann keinen Save mehr machen, irgendwie hängt sich dann FHEM weg. Selbst ein Service Stop ist dann etwas unbeeindruckt. Kill -9 sonst keine chance.
Also der Ansatz ist gut. Wie bekommen wir das stabiler hin?
LG
Zitat von: belu am 26 Juni 2016, 18:31:26Also der Ansatz ist gut. Wie bekommen wir das stabiler hin?
Probier das doch nochmal mit
verbose 5
ich bins nochmal.
Ich habe gesehen dass ich gem. der Commadref wohl doch noch einen Zwischenschritt vergessen habe, danke für den Hinweis :)
Jetzt ist mir aber beim Abarbeiten der Schritte aufgefallen, dass ich für das Compilen der Software den Befehl:
wget http://usb-sensors-linux.googlecode.com/svn/trunk/airsensor/airsensor.c
durchführen soll. Hier erhalte ich jedoch den Hinweis:
HTTP request sent, awaiting response... 404 Not Found
2016-06-27 17:36:37 ERROR 404: Not Found.
Kann mir jemand einen funktionierenden Link nennen wo ich die Software dowloaden kann ?
Schau mal hier:
https://github.com/tuxedo0801/usb-sensors-linux/tree/master/airsensor (https://github.com/tuxedo0801/usb-sensors-linux/tree/master/airsensor)
oder hier:
http://www.iamklaus.org/de/bessere-luft-fur-1950-e/ (http://www.iamklaus.org/de/bessere-luft-fur-1950-e/)
vielen Dank für die schnelle Antwort.
beim Compilen (gcc -o airsensor airsensor.c -lusb) der Datei kommt folgender Fehler :-[
gcc -o airsensor airsensor.c -lusb
airsensor.c:5:1: error: expected identifier or '(' before '<' token
airsensor.c:8:19: warning: character constant too long for its type [enabled by default]
airsensor.c:27:5: error: stray '\302' in program
airsensor.c:27:5: error: stray '\267' in program
airsensor.c:27:5: error: stray '\302' in program
airsensor.c:27:5: error: stray '\267' in program
airsensor.c:139:28: warning: missing terminating ' character [enabled by default]
airsensor.c:139:3: error: missing terminating ' character
airsensor.c:283:46: error: invalid suffix "bb97d61f2e65222ed9debfb" on floating constant
airsensor.c:380:11: error: invalid suffix "be4d38" on integer constant
airsensor.c:386:9: error: stray '@' in program
airsensor.c:516:9: error: stray '#' in program
airsensor.c:516:149: error: expected identifier or '(' before '<' token
airsensor.c:516:189: error: expected identifier or '(' before '<' token
airsensor.c:520:9: error: stray '#' in program
airsensor.c:520:149: error: expected identifier or '(' before '<' token
airsensor.c:520:189: error: expected identifier or '(' before '<' token
airsensor.c:524:9: error: stray '#' in program
airsensor.c:524:149: error: expected identifier or '(' before '<' token
airsensor.c:524:188: error: expected identifier or '(' before '<' token
airsensor.c:528:9: error: stray '#' in program
airsensor.c:528:149: error: expected identifier or '(' before '<' token
airsensor.c:528:189: error: expected identifier or '(' before '<' token
airsensor.c:532:9: error: stray '#' in program
airsensor.c:532:149: error: expected identifier or '(' before '<' token
airsensor.c:532:189: error: expected identifier or '(' before '<' token
airsensor.c:536:9: error: stray '#' in program
airsensor.c:536:149: error: expected identifier or '(' before '<' token
airsensor.c:536:186: error: expected identifier or '(' before '<' token
airsensor.c:540:9: error: stray '#' in program
airsensor.c:540:149: error: expected identifier or '(' before '<' token
airsensor.c:540:196: error: expected identifier or '(' before '<' token
airsensor.c:544:9: error: stray '#' in program
airsensor.c:544:149: error: expected identifier or '(' before '<' token
airsensor.c:544:192: error: expected identifier or '(' before '<' token
airsensor.c:548:9: error: stray '#' in program
airsensor.c:548:149: error: expected identifier or '(' before '<' token
airsensor.c:548:191: error: expected identifier or '(' before '<' token
airsensor.c:552:9: error: stray '#' in program
airsensor.c:552:149: error: expected identifier or '(' before '<' token
airsensor.c:552:187: error: expected identifier or '(' before '<' token
airsensor.c:560:124: error: expected identifier or '(' before '<' token
airsensor.c:578:9: error: stray '\' in program
airsensor.c:582:9: error: stray '\' in program
airsensor.c:586:9: error: stray '\' in program
airsensor.c:590:9: error: stray '\' in program
airsensor.c:594:9: error: stray '\' in program
airsensor.c:598:9: error: stray '\' in program
airsensor.c:610:71: error: expected identifier or '(' before '<' token
airsensor.c:639:179: error: invalid suffix "d" on integer constant
airsensor.c:639:211: error: invalid suffix "d" on integer constant
airsensor.c:639:243: error: invalid suffix "d" on integer constant
airsensor.c:639:275: error: invalid suffix "d" on integer constant
airsensor.c:639:307: error: invalid suffix "d" on integer constant
airsensor.c:639:339: error: invalid suffix "d" on integer constant
airsensor.c:647:9: error: stray '\' in program
airsensor.c:655:9: error: stray '\' in program
airsensor.c:663:71: error: expected identifier or '(' before '<' token
airsensor.c:692:71: error: expected identifier or '(' before '<' token
airsensor.c:752:71: error: expected identifier or '(' before '<' token
airsensor.c:824:9: error: stray '#' in program
airsensor.c:824:9: error: stray '#' in program
airsensor.c:840:9: error: stray '#' in program
airsensor.c:840:9: error: stray '#' in program
airsensor.c:856:9: error: stray '#' in program
airsensor.c:856:9: error: stray '#' in program
airsensor.c:872:9: error: stray '#' in program
airsensor.c:872:9: error: stray '#' in program
airsensor.c:888:9: error: stray '#' in program
airsensor.c:888:9: error: stray '#' in program
airsensor.c:1012:193: error: invalid suffix "sec..." on integer constant
airsensor.c:1232:9: error: stray '\' in program
airsensor.c:1232:9: error: stray '\' in program
airsensor.c:1232:9: error: stray '\' in program
airsensor.c:1232:9: error: stray '\' in program
airsensor.c:1232:9: error: stray '\' in program
airsensor.c:1232:9: error: stray '\' in program
airsensor.c:1232:9: error: stray '\' in program
airsensor.c:1232:9: error: stray '\' in program
airsensor.c:1232:9: error: stray '\' in program
airsensor.c:1232:9: error: stray '\' in program
airsensor.c:1232:9: error: stray '\' in program
airsensor.c:1232:9: error: stray '\' in program
airsensor.c:1232:9: error: stray '\' in program
airsensor.c:1232:9: error: stray '\' in program
airsensor.c:1232:9: error: stray '\' in program
airsensor.c:1232:9: error: stray '\' in program
airsensor.c:1300:9: error: stray '\' in program
airsensor.c:1444:9: error: stray '\' in program
airsensor.c:1452:183: error: invalid suffix "d" on integer constant
airsensor.c:1452:215: error: invalid suffix "d" on integer constant
airsensor.c:1452:247: error: invalid suffix "d" on integer constant
airsensor.c:1452:279: error: invalid suffix "d" on integer constant
airsensor.c:1452:311: error: invalid suffix "d" on integer constant
airsensor.c:1452:343: error: invalid suffix "d" on integer constant
airsensor.c:1456:9: error: stray '\' in program
airsensor.c:1472:9: error: stray '\' in program
airsensor.c:1480:183: error: invalid suffix "d" on integer constant
airsensor.c:1480:215: error: invalid suffix "d" on integer constant
airsensor.c:1480:247: error: invalid suffix "d" on integer constant
airsensor.c:1480:279: error: invalid suffix "d" on integer constant
airsensor.c:1480:311: error: invalid suffix "d" on integer constant
airsensor.c:1480:343: error: invalid suffix "d" on integer constant
airsensor.c:1484:9: error: stray '\' in program
airsensor.c:1536:72: error: expected identifier or '(' before '<' token
airsensor.c:1546:28: warning: missing terminating ' character [enabled by default]
airsensor.c:1546:3: error: missing terminating ' character
airsensor.c:1577:18: error: expected identifier or '(' before numeric constant
Hm, beim mir läuft das nach dem Download von der iamklaus.org-Seite sauber durch.
Hat Dein Download vielleicht nicht richtig geklappt? Hatte vorhin auch kleine Probleme, dass der Download nicht komplett war. Mit der Fehlermeldung kann ich leider nichts anfangen. Aber es scheint ja gleich von Anfang an nicht zu funktionieren. Schau doch mal ins File rein, ob das alles so richtig aussieht. Bei mir geht es mit nem Kommentarfeld los.
Hast Du die Möglichkeit, das auf einem anderen System nochmal zu probieren?
ich habe es jetzt auch nochmal mit dem zweiten Link probiert. Scheinbar ist die Datei am ersten Link defekt.
Das kompolieren hat wohl auch geklappt.
jetzt steht ja in der "Goolge Anleitung", dass man das Ganze nochmal testen solle mit
sudo ./airsensor -o 2013-04-28 14:55:56, VOC: 450, RESULT: OK
Hier bekomme ich dann die Meldung:
sudo: unable to resolve host (none)
Ich bin zwar Laie in der ganzen Materie aber irgendwie habe ich das Gefühl, dass der Stick nicht richtig erkannt wird, kann das sein ?
Habe auch mal restartet, passiert aber nichts :(
wget http://www.iamklaus.org/download/airsensor/ -o airsensor.c
gcc -o airsensor airsensor.c -lusb
sudo ./airsensor
Funktioniert natürlich nur fehlerfrei, wenn FHEM nicht parallel auf den Stick zugreift.
Perfekt, tausend Dank, jetzt habe ich den Stick soweit, dass er in FHEM als Opened angezeigt wird :)
Super, danke :)
Jetzt wurde ja hier im Forum geschrieben, dass man im Advanced Menü die Seriennummer auslesen soll.
Ist es sinnvoll die zu hinterlegen ? Nur damit der reconnect geht ?
Zitat von: Joker2002 am 27 Juni 2016, 18:25:56Jetzt wurde ja hier im Forum geschrieben, dass man im Advanced Menü die Seriennummer auslesen soll.
Ist es sinnvoll die zu hinterlegen ? Nur damit der reconnect geht ?
Nein.
Das braucht man überhaupt nur, wenn man mehrere Sticks an einem Rechner betreibt - und auch dann ist es nur sinnvoll, wenn die USB ID nicht gleich bleibt.
Der Connect über die Seriennummer ist durch die zusätzliche USB Kommunikation der fehleranfälligste Weg.
so, nachdem der Sensor soweit eine Nacht lang gelaufen ist frage ich mich, ob die Werte soweit stimmen....
ich hatte den Sensor vorher 3 Tage an der "frischen Luft" kalibirieren lassen.
Im Laufe des Abends stieg dann der Messwert an und pendelt seit dem immer zwischen 2350 und 2400, trotz geöffnetem Fenster bzw. Tür.
r_h liegt bei 169,4
r_s derzeit bei 251266
voc 509
Gibt es irgendwo eine Legende, was sich hinter den Readings tatsächlich verbirgt ? In der Commandref habe ich dazu leider nur wenig Information erhalten ausser dass r_h resistance of heating element in Ohm (?) und r_s resistance of sensor element in Ohm (?) bedeutet.
Gibt es möglicherweise auch eine Tabelle die man als Vergleichswert anlgegen kann, welcher Wert der optimale Raumluftwert ist ?
Was hast Du bei dir zusammenkonfiguriert? Der voc ist der Wert und wenn der unten bei 509 steht, ist das für mich nicht zwischen 2350 und 2400!?
Sent from my iPhone using Tapatalk
Ah, OK, das wusste ich nicht, dass der Wert im Reading des "VOC" der wichtige ist. Ich dachte es muss entweder der "r_h" oder "r_s" Wert sein; daher auch meine Frage ob es eine Tabelle/ Legende gibt, die das erklärt ;)
Irgendwo hier im Thread. Die Berechnungsmethode natürlich nicht.
Kurzfassung: es geht nur die Kalibrierung auch den Basiswert und die Einstellung knob_reg_set die bereits bei kleinen Änderungen die Amplitude vergrößert oder verkleinert.
Sent from my iPhone using Tapatalk
Anders als bezeichnet und mM etwas verwirrend misst der Sensor die Konzentration eines Gasgemisches (VOC), dass bis zu einer gewissen Konzentration mit dem Wert für CO2 korrelliert, glaube ca. 1000ppm. Ich der Umgebung herscht ca. 350-400ppm CO2, weshalb dieses der ungefähre Wert ist, der in der Umgebung auch vom voc-Sensor gemessen werden sollte. Der Sensor ist stark temperaturabhängig, weshalb eine Kalibrierung im Winter schwierig ist. Physiologische Effekte (z. B. Müdigkeit) sind mM ab ca. 1000ppm co2 festzustellen. Zum Zusammenhang VOC und CO2, sowie die Effekte gibt es diverse wissenschaftliche Studien. Bitte Google dazu einmal selbst. Bitte such auch mal nach appliedsensor voc. Da findet sich ein bisschen was zum Thema. Als Usb ist es immer die gleiche Hardware nur unter verschiedensten Namen. Fa gibts dann auch die Win-SW.
Habe festgestellt, dass bei mir VOC und CO2 (echter Sensor) nicht wirklich korrellieren, d.h. der VOC-Wert keine Rückschlüsse auf den wirklichen CO2-Gehalt zulassen. Was nicht heißt, dass man nicht danach steuern könnte. Für mich ist der Stick eher ein "Miefsensor", dessen Zahlenwert subjektiv ist, was dann auch die Kalibrierung erübrigt. Das ist ja sowieso nur die zahlentechnische Umsetzung der Spannung vom Sensormodul.
Ok, danke für die Tipps, werde mich mal schlau machen.
Ich wollte den Sensor eh nur als eine Reminder nutzen wenn es im Zimmer zu "miefig" wird :).
Hallo,
ich möchte nun auch in die Raumluftüberwachung einsteigen.
Sollte ich nun den iaq-2000 kaufen, oder gibt es ein Nachfolgemodell / andere Empfehlung?
Daran schließt sich die folgende Frage, wo kann ich den Sensor kaufen?
Ich habe in meinen Recherchen keinen Bezugspunkt gefunden, der dem genannten Preisniveau entspricht.
Greets
Byte
Zitat von: Bytechanger am 18 Juli 2016, 08:29:47
Ich habe in meinen Recherchen keinen Bezugspunkt gefunden, der dem genannten Preisniveau entspricht.
Klingt jetzt nicht so, als ob die Recherche vollständig war. Den Thread lesen oder einfach mal die Worte "velux raumluftsensor" in Google eingeben sollte bereits helfen. Bei Rehau scheint er derzeit vergriffen zu sein.
Danke für den Hinweis. In der Tat scheint der Rehau nicht mehr greifbar. Leider scheint dies im Augenblick auch für die VELUX Geschichte zu gelten.
Greets
Byte
Vermutlich die letzten die es je zu kaufen geben wird: BayWa (https://www.baywa.de/shop/produkte/bau/ausbau/sensoren/warnmelder/baywa-raumluftwaechter-p982168/baywa-raumluftwaechter-982170)
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
Zitat von: Bytechanger am 18 Juli 2016, 11:29:42
Leider scheint dies im Augenblick auch für die VELUX Geschichte zu gelten.
Hast Du dort angerufen? Auf der Webseite spricht alles für Lieferbarkeit.
Oh cool, Mouser und Digikey kannte ich noch nicht. Dann dürfte die Verfügbarkeit erst mal gesichert sein :)
Sent from my iPhone using Tapatalk
Hallo,
Ich wollte auch mal über MySensors einen MQ2 anbinden mit Temperaturkompensation, vielleicht hat das ja schon jemand gemacht?
Ich bin hier echt am verzweifeln. Versuch nun einen CO20 seit Stunden einzubinden.
Hardware ist ein Pi3 mit Jessie . Fhem ist aktuell.
'cpan install Device ist erledigt
'sudo apt-get install libdevice-usb-perl ebenso gemacht, ohne Fehler durch.
In fhem Ordner airsensor erstellt und wget http://www.iamklaus.org/download/airsensor/ -o airsensor.c kopiert. Doch dann beim compilieren gcc -o airsensor airsensor.c -lusb kommen Fehler.
Fhem ist shutdown. Stick neu gesteckt
Hier die Meldung.
root@raspberrypi:/opt/fhem/airsensor# gcc -o airsensor airsensor.c -lusb
airsensor.c:1:1: error: expected identifier or '(' before '--' token
--2016-08-12 22:27:12-- http://www.iamklaus.org/download/airsensor/
^
airsensor.c:1:8: error: invalid digit "8" in octal constant
--2016-08-12 22:27:12-- http://www.iamklaus.org/download/airsensor/
^
airsensor.c:2:50: error: too many decimal points in number
Resolving www.iamklaus.org (www.iamklaus.org)... 81.169.145.157, 2a01:238:20a:202:1157::
^
airsensor.c:2:66: error: invalid suffix "a01" on integer constant
Resolving www.iamklaus.org (www.iamklaus.org)... 81.169.145.157, 2a01:238:20a:202:1157::
^
airsensor.c:2:75: error: invalid suffix "a" on integer constant
Resolving www.iamklaus.org (www.iamklaus.org)... 81.169.145.157, 2a01:238:20a:202:1157::
^
airsensor.c:3:51: error: too many decimal points in number
Connecting to www.iamklaus.org (www.iamklaus.org)|81.169.145.157|:80... connected.
^
airsensor.c:3:67: error: too many decimal points in number
Connecting to www.iamklaus.org (www.iamklaus.org)|81.169.145.157|:80... connected.
^
airsensor.c:6:1: error: stray '\342' in program
Saving to: 'index.html'
^
airsensor.c:6:1: error: stray '\200' in program
airsensor.c:6:1: error: stray '\230' in program
airsensor.c:6:1: error: stray '\342' in program
airsensor.c:6:1: error: stray '\200' in program
airsensor.c:6:1: error: stray '\231' in program
airsensor.c:8:68: error: invalid suffix "M" on floating constant
0K ..... 100% 90.3M=0s
^
airsensor.c:8:74: error: invalid suffix "s" on integer constant
0K ..... 100% 90.3M=0s
^
airsensor.c:10:6: error: invalid digit "8" in octal constant
2016-08-12 22:27:15 (90.3 MB/s) - 'index.html' saved [5828/5828]
^
airsensor.c:10:1: error: stray '\342' in program
2016-08-12 22:27:15 (90.3 MB/s) - 'index.html' saved [5828/5828]
^
airsensor.c:10:1: error: stray '\200' in program
airsensor.c:10:1: error: stray '\230' in program
airsensor.c:10:1: error: stray '\342' in program
airsensor.c:10:1: error: stray '\200' in program
airsensor.c:10:1: error: stray '\231' in program
root@raspberrypi:
Stick wird erkannt und ist wenn Fhem an auf disconnect.
Bitte um Hilfe. Danke
Hallo miktin,
du musst da gar nix compilieren...
Stick einstecken, und ein :
define mystick CO20
absetzen, und gut ist ...
Das hab ich auch erst gemacht ist aber disconnect.
hatte ich auch mal. Versuch mal mit eingestecktem Stick einen Reboot des Raspi.
Keine Ahnung wie oft ich schon rebootet habe. Will nicht, ist und bleibt disconnected. Unter Windows läuft er und bringt Daten mit der Rehau Software.
was gibt lsusb als root?
wenn dein fhem nicht als root läuft musst du die device rechte z.b. per udev regel anpassen. in der commandref ist ein link wie das geht.
gruss
andre
Gehe von aus das du das meinst. create the udev rule as above. Wie stelle ich das an?
Zitat von: miktin am 13 August 2016, 12:42:56
Gehe von aus das du das meinst. create the udev rule as above. Wie stelle ich das an?
Wenn da steht "... as above", dann sollte ja weiter oben stehen wie es geht.
Ich bin begeistert.......
Hallo zusammen,
ich verwende momentan das Programm airsensor.c (ohne fhem) zum Auslesen der Sensorwerte. Ich möchte nun im laufenden Betrieb zwischendurch mal die Baseline resetten (rekalibrieren). Im fhem-Modul ist dies ja implementiert, wobei ich den Code dazu nicht komplett verstehe.
Ich suche den Befehlsstring, den ich für das Rekalibrieren an den Sensor schicken muss, ähnlich wie dies in airsensor.c für das Abfragen der Messwerte gemacht wird:
memcpy(buf, "\x40\x68\x2a\x54\x52\x0a\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40", 0x0000010);
ret = usb_interrupt_write(devh, 0x00000002, buf, 0x0000010, 1000);
Gruß
Peter
Zitat von: PumpkinEater am 23 August 2016, 10:07:29Ich suche den Befehlsstring, den ich für das Rekalibrieren an den Sensor schicken muss, ähnlich wie dies in airsensor.c für das Abfragen der Messwerte gemacht wird:
memcpy(buf, "\x40\x68\x2a\x54\x52\x0a\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40", 0x0000010);
ret = usb_interrupt_write(devh, 0x00000002, buf, 0x0000010, 1000);
Naja, aus Hex Code übersetzt heisst das in etwa "
@h*TR\n@@@@@@@@@"
Möchtest du airsensor erweitern? Der größte Unterschied zum Modul ist, dass ich wo immer möglich die Characters lesbar in den Code geschrieben habe und die Kommandos 1:1 aus der Windows App übernommen sind.
Für den Reset musst du statt "
TR" bzw. "
TRF?" "
FLAGSET;RESET BASELINE=" schicken, vorher noch ein bisschen passenden Krempel, nachher auch :)
Einfach die Funktion
CO20_dataset einmal von oben nach unten durchgehen, dann hast du's.
Hi Markus,
danke fir die Info.
puh, Perl ;)
Müsste dann ungefähr so lauten:
"@gTRF?\n@@@@@@@@@" (erstes Write)
"@0001FLAGSET;RESET BASELINE=\n@@@" (zweites und drittes Write a 16 Byte)
Vielleicht installiere ich Dein Modul testweise mal in FHEM und logge dann die resultierenden Strings, bevor ich etwas zerschieße ...
Gruß
Peter
Mach das doch am besten einfach über das Modul.
Sent from my iPhone using Tapatalk
Habe diese Woche mal wieder ein Update gemacht. Und wie das letzte mal war wieder anschließend das Logfile voll mit
2016.09.16 17:31:48 3: Wohnzimmer_co20: disconnected
2016.09.16 17:31:48 3: Wohnzimmer_co20: CO20 device found
2016.09.16 17:31:48 3: Wohnzimmer_co20: CO20 device opened
2016.09.16 17:34:27 3: Zuluft_co20: disconnected
2016.09.16 17:34:27 3: Zuluft_co20: CO20 device found
2016.09.16 17:34:27 3: Zuluft_co20: CO20 device opened
2016.09.16 17:39:58 3: Schlafzimmer_co20: disconnected
2016.09.16 17:39:58 3: Schlafzimmer_co20: CO20 device found
2016.09.16 17:39:58 3: Schlafzimmer_co20: CO20 device opened
2016.09.16 17:43:37 3: Zuluft_co20: disconnected
2016.09.16 17:43:37 3: Zuluft_co20: CO20 device found
2016.09.16 17:43:37 3: Zuluft_co20: CO20 device opened
2016.09.16 17:44:29 3: Wohnzimmer_co20: disconnected
2016.09.16 17:44:29 3: Wohnzimmer_co20: CO20 device found
2016.09.16 17:44:29 3: Wohnzimmer_co20: CO20 device opened
Und wie das letzte mal habe ich anschließend das upgedatete Modul durch dieses ersetzt:
https://forum.fhem.de/index.php/topic,13166.msg461408.html#msg461408 (https://forum.fhem.de/index.php/topic,13166.msg461408.html#msg461408)
Das Problem ist dadurch schlagartig beseitigt.
Da es hier nach wie vor keine Lösung gibt habe ich nun das co20-Modul auf die exclude_from_update Liste gesetzt.
Hallo zusammen,
bin neu hier und auf FHEM gestoßen seitdem ich unsere KWL Miefabhängig steuern will.
Ich nutze meinen alten Raspberry PI. Habe einen Rehau Airmonitor. Die KWL wird über Fritzbox Dect geschaltet. Soweit ist schon mal alles eingebunden.
Nun würde ich etwas Starthilfe bei der weiteren Programmierung benötigen.
Könntet ihr mir mal die Syntax für eine einfache Bedingung geben bitte?
Z.b falls voc > 1000 schalte FB_Dect12 aus, das ganze alle 5 Minuten prüfen. Wie fange ich an?
Vielen Dank scho mal
Gesendet von iPhone mit Tapatalk
Hi sasasch,
ich habe das ganze schon hinter mir - mit einer Tecalor THZ. Das ist ein Kombigerät mit Heizungswärmepumpe und integrierter KWL. Den Code meiner Lösung (mit 2 CO20-Sensoren in Wohn- und Schlafzimmer) findest Du hier:
https://forum.fhem.de/index.php/topic,33452.msg458926.html#msg458926 (https://forum.fhem.de/index.php/topic,33452.msg458926.html#msg458926)
Die Lösung funktioniert ganz ordentlich. Wahrscheinlich musst Du noch ein bisschen an den Parametern spielen - bei welchen Mief-Werten wird zwischen den Stufen umgeschaltet usw.
Das kannst Du mal als Einstiegshilfe nehmen und für Deine Bedingungen anpassen. Falls Dir da was fehlt ist es evtl. in den Konfigurationsbeispielen der THZ enthalten, die ich im ersten Beitrag dieses Threads angehängt habe.
Viel Spaß damit.
Willy
Super vielen Dank. Das ist für den generellen Einstieg schon mal ne Menge Code.
Würde mich über einen Einzeiler für die vorhin gestellte Bedingung trotzdem freuen, taste mich da erst step Byte step ran um es einfach besser verstehen zu können.
Gruß
Gesendet von iPhone mit Tapatalk
Den kannst Du Dir aus dem genannten Code basteln.
Aus dem
define extraVent_Wohnzimmer DOIF ( ([Wohnzimmer_co20:voc_avg] > 3600)\
...
(set extraVent_Wohnzimmer_value 3, {Log 1,"extraVent_Wohnzimmer set to level 3"}) \
...
musst Du die "(set ..." Zeile ersetzen durch
sowas ähnliches
set Mythz p07FanStageDay 3
Wie der Code für Dein FBDect aussieht weiß ich aber nicht. Ich gehe davon aus, dass Du das selbst im Griff hast.
Dann halt noch die öffnenden und schließenden Klammern abgleichen. Wenn Du magst passt das - der Unübersichtlichkeit zuliebe - in eine Zeile.
Ok super vielen Dank
Gesendet von iPhone mit Tapatalk
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
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
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.
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....
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.
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
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.
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
Ok jetzt gehts auch mit DOIF. Der Fehler lag an der zusätzlichen Einklammerung außen
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?
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.
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.
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
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?
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.
Funktionieren die Sticks denn mit der Windows Software?
Sent from my iPhone using Tapatalk
Ich habe mir die Software von ams.com heruntergeladen. Leider wird kein Treiber beim Stecken des Sticks installiert, so dass die Software den Stick auch nicht findet. Der Stick meldet sich mit "ATm32U4DFU" unter Windows. Ich habe mal ein wenig gesucht aber einen passenden Treiber konnte ich nicht finden.
Und da war keine andere Software dabei oder verlinkt?
Wer übrigens noch einen Stick braucht: http://www.ebay.de/itm/381974644457 (http://www.ebay.de/itm/381974644457)
Bin der Meinung, ich musste nichts installieren. Wie oben aber geschrieben, kann ich es nicht prüfen.
Es könnte allerdings auch daran liegen, dass ich eine Arduino IDE installiert hatte, die glaube ich auch einen Treiber installiert für einen Atmega.
Aber auch beim Velux Raumluftsensor und Voltcraft CO2 gab es keinen Hinweis auf die Notwendigkeit, einen speziellen Treiber installieren zu müssen.
Hast Du ggf. noch eine alternative Installation, bei der Du das testen könntest?
Soweit ich mich erinnern kann, lief es bei mir unter Windows "out-of-the-box".
zumindest der 'original' stick wird direkt ohne treiber auf usb ebene angesprochen. das ist ja auch der grund warum er überhaupt in fhem und mit linux zum laufen zu bekommen ist. kein treiber nötig.
Danke schonmal für die Ideen, aber
Arduino IDE habe ich auch drauf. Alternative Installation (ebenfalls mit Arduino IDE) habe ich auch schon probiert. Es kommt immer wieder Frage nach dem Treiber.
Die Software habe ich von hier http://www.appliedsensor.com/eng/Products/Environmental-Sensors/Air-Quality-Sensors/iAM. Dorthin musste ich mich Durchklicken. Der Beipackzettel sagt nur appliedsensor.com. Die Abbildung auf der Seite sieht aber genau aus wie mein Stick. Die Software sagt dann: "no IAQ Stick found"
Hm, wenn keiner von beiden Sticks auf zwei Systemen unter Windows nicht gefunden werden würde ich zum einen vorsorglich den Onlinekauf schon einmal widerrufen bevor die 14 Tage um sind und zum anderen mich an den Verkäufer wenden, dass die Stick in ihrer "normalen Umgebung" nicht funktionieren.
Das sieht ja fast so aus, als ob Deine Sticks "anders" wären, obwohl gleich beide? Sehr interessant.
Unabhängig vom Interface, die LED geht aber und wechselt auch schön die Farbe, oder?
Nein, die LED leuchtet gar nicht. (bei beiden Sticks)
Dann würde ich die direkt mal reklamieren.
Soweit ich mich erinnere, leutet die LED unabhängig, sobald der Stick Power über ein USB-Netzteil bekommt.
Oder das sind andere, als ich denke...
Irgendwie klingt das langsam so als hättest du nur die blanke Hardware...
Wenn du den Stick in ein USB Netzteil steckst sollte sich zumindest irgendwas tun.
Sent from my iPhone using Tapatalk
Zitat von: Markus M. am 22 Februar 2017, 16:07:18
Wenn du den Stick in ein USB Netzteil steckst sollte sich zumindest irgendwas tun.
Genau so sollte es sein.
Bist du sicher, dass die nicht zu viel Spannung abbekommen hatten? Handynetzteile liefern im Schnelllademodus teils über 8 Volt. Vielleicht hat so ein Netzteil die Sensoren fälschlicherweise als Handy erkannt.
Eine aktualisierte Version ist seit heute im Update.
Keine Neuerungen, die lästigen Initialisierungsfehler der kaputten USB Lib beim Start sind damit aber weg :)
Waren eigentlich noch irgendwelche Features offen?
Ich hab in meiner persönlichen Version noch ein paar Änderungen, weiss aber nicht mehr für was die waren.
Hauptsächlich zur Verwendung mehrerer Sticks, wenn ich mich recht erinnere.
Bitte mal die Version im Anhang ein paar Tage testen und Bescheid geben, ob damit alles funktioniert.
Ich hatte den Stick jetzt schon seit Längerem nicht mehr in Betrieb weil mir FHEM damit öfter abgeschmiert ist - ist bei mir aber wahrscheinlich eher ein USB-Problem.
Gruß, Markus
abgeschmiert oder nur nicht mehr voll funktionsfähig ?
Ich habe auf nem RPi3 mit Jessie und USB-Stick-Boot seit neustem das Phänomen, dass keine Daten mehr geschrieben werden, obwohl fhem noch läuft. Ziehe ich den Stick ab, passiert ein Wunder: fhem läuft weiter, loggt wieder und führt sogar gequeuete ats aus ???
Zitat von: KölnSolar am 28 Februar 2017, 17:50:40
abgeschmiert oder nur nicht mehr voll funktionsfähig ?
Ich habe auf nem RPi3 mit Jessie und USB-Stick-Boot seit neustem das Phänomen, dass keine Daten mehr geschrieben werden, obwohl fhem noch läuft. Ziehe ich den Stick ab, passiert ein Wunder: fhem läuft weiter, loggt wieder und führt sogar gequeuete ats aus ???
Richtig, blockiert.
Teilweise klappt das mit dem Abziehen, teilweise aber auch nicht mehr.
Dann kann man nicht mal mehr den perl Prozess killen.
Vielen Dank für die Hinweise. Ich habe die Stücks nun reklamiert.
Hat jemand so ein Teil eigentlich mal aufgemacht? Da sollte ja vermutlich der Iaq-Core von AMS mit I2C-Schnittstelle drin sein. Falls man den Zerstörungsfrei herausbekommt, wäre es 10 Euro billiger, das komplette USB-Teil zu kaufen und zu zerlegen als nur den Chip zu kaufen (spannend in verbindung mit nem ESP8266 oder nem Raspberry Zero W).
Leider ist das Gehäuse offenbar verklebt -ich hab Angst, dass es "Knack" macht ;)
Zitat von: peterk_de am 06 März 2017, 07:23:07Hat jemand so ein Teil eigentlich mal aufgemacht?
Na klar (https://uploads.tapatalk-cdn.com/20170306/ac8f213f3bded16995206dbb72872c81.jpg)
Haha super ^^ Aber OK, dann kann ich mir das Öffnen/Ablöten sparen, da ist irgendwas anderes drin, vermutlich ne analoge Variante ohne separate Logik. Der Stand-alone-I2C-Sensor sieht anders aus. Dann wird mein Mini-VOC-Sensor wohl einfach nen Raspberry Zero mit der kompletten USB-Platine.
FYI: Es gibt wieder einen auf eBay - http://www.ebay.de/itm/CO2-USB-Sensor-BayWa-CO-20-Voltcraft-/382026080389 (http://www.ebay.de/itm/CO2-USB-Sensor-BayWa-CO-20-Voltcraft-/382026080389)
Zitat von: Markus M. am 03 April 2017, 11:10:12
FYI: Es gibt wieder einen auf eBay - http://www.ebay.de/itm/CO2-USB-Sensor-BayWa-CO-20-Voltcraft-/382026080389 (http://www.ebay.de/itm/CO2-USB-Sensor-BayWa-CO-20-Voltcraft-/382026080389)
Verkaufe auch einen - wer Interesse hat, melden ;)
Hat eigentlich noch jemand das Phänomen dass der Stick manchmal aussteigt und dabei FHEM komplett blockiert?
Ich versuche dem gerade nachzugehen.
ja, aber seit Tagen Ruhe.
Grüße Markus
Zitat von: KölnSolar am 03 April 2017, 14:49:51
ja, aber seit Tagen Ruhe.
Passiert bei mir auch nur alle paar Wochen.
Wohl wenn der Stick sich komplett aufhängt.
Dann hilft nur noch entweder abstecken oder ein Reboot.
Ich beobachte das mal mit mehr Logging.
Ich denke der Modul Aufbau ist bei solchen Fällen suboptimal.
Hatte ich auch kürzlich. Bei mir gab es ne Vorwarnung: Extrem hohe Werte über ca. 2 Tage, danach hat sich alles wie ihr beschreibt aufgehängt. Der Stick ist aber im unterschied zu euch nun offenbar völlig hinüber, er wird gar nicht mehr als USB-Gerät erkannt.
Update mit den Definitionen via ID und Serial, mehr Debugging auf Verbose 4.
Zitat von: peterk_de am 03 April 2017, 19:29:01Der Stick ist aber im unterschied zu euch nun offenbar völlig hinüber, er wird gar nicht mehr als USB-Gerät erkannt.
Probier mal einen anderen Port. Leuchtet noch was bzw. funktioniert er ansonsten noch?
Hallo zusammen,
nach heutigem Update bekomme ich folgende Fehlermeldungen:
2017.04.15 09:54:56 3: AZ.iam: write error -110/-110 (1)
2017.04.15 09:55:27 3: AZ.iam: write error -110/-110 (2)
2017.04.15 10:15:57 3: AZ.iam: write error -110/-110 (1)
2017.04.15 10:16:27 3: AZ.iam: write error -110/-110 (2)
2017.04.15 10:36:57 3: AZ.iam: write error -110/-110 (1)
2017.04.15 10:37:27 3: AZ.iam: write error -110/-110 (2)
2017.04.15 10:57:57 3: AZ.iam: write error -110/-110 (1)
2017.04.15 10:58:27 3: AZ.iam: write error -110/-110 (2)
Bin wieder auf dem Stand vom:
# $Id: 38_CO20.pm 13545 2017-02-28 01:00:53Z moises $
zurück.
Viele Grüße
Klaus
PS: Sensor wird auf RPI betrieben...
Vermutlich nur Logeinträge wo vorher keine waren.
Kannst du das vergleichen? Bin grade unterwegs.
Zitat von: Markus M. am 15 April 2017, 12:21:06
Vermutlich nur Logeinträge wo vorher keine waren.
Kannst du das vergleichen? Bin grade unterwegs.
Jo, merkwürdigerweise habe ich im CO20 Filelog zu der Zeit der Fehlemeldungen trotzdem IAM Werte !
Wie kann ich die Fehlermeldungen ausblenden ? (Verbose ?)
FHEMlog:
2017.04.15 11:18:57 3: AZ.iam: write error -110/-110 (1)
2017.04.15 11:19:27 3: AZ.iam: write error -110/-110 (2)
2017.04.15 11:39:57 3: AZ.iam: write error -110/-110 (1)
2017.04.15 11:40:27 3: AZ.iam: write error -110/-110 (2)
2017.04.15 12:00:57 3: AZ.iam: write error -110/-110 (1)
2017.04.15 12:01:27 3: AZ.iam: write error -110/-110 (2)IAMLog:
2017-04-15_11:19:57 AZ.iam voc: 520
2017-04-15_11:40:57 AZ.iam voc: 571
2017-04-15_12:01:57 AZ.iam voc: 567
2017-04-15_12:11:46 AZ.iam voc: 585Sind das Retries ?
Viele Grüße
Klaus
Zitat von: Rampler am 15 April 2017, 12:26:29
Jo, merkwürdigerweise habe ich im CO20 Filelog zu der Zeit der Fehlemeldungen trotzdem IAM Werte !
Wie kann ich die Fehlermeldungen ausblenden ? (Verbose ?)
Sind das Retries ?
Mit Verbose 2 sind sie weg.
Sieht den Zeiten nach tatsächlich nach Retries aus.
OK, verbose "2" verhindert die Meldung !
Habe jedoch ein weiteres Problem, nach Restart von FHEM steht der Adapter auf error. Muss den ganzen Raspberry restarten, dann geht der Adapter erst wieder auf open. Das ist mit der alten Version nicht so ...
Zitat von: Rampler am 15 April 2017, 15:25:12
OK, verbose "2" verhindert die Meldung !
Habe jedoch ein weiteres Problem, nach Restart von FHEM steht der Adapter auf error. Muss den ganzen Raspberry restarten, dann geht der Adapter erst wieder auf open. Das ist mit der alten Version nicht so ...
Mach mal einen Neustart mit Verbose 4, damit solltest du ziemlich detailliert sehen was passiert.
Hallo Markus,
aktuelles Modul, Verbose 4, FHEM restart :
List device:
Internals:
FAIL 2
ID 001:004
INTERVAL 1200
NAME AZ.iam
NOTIFYDEV global
NR 271
NTFY_ORDER 50-AZ.iam
SERIALNUMBER
STATE error
TYPE CO20
manufacturer AppliedSensor
product iAQ Stick
Readings:
2017-04-15 18:11:08 AZ.iam 725
2017-04-15 18:28:13 SZ.iam 1241
2017-04-15 18:27:36 WC.iam 1049
2017-04-15 18:18:04 WZ.iam 848
2017-04-15 18:11:08 debug 839
2017-04-15 18:11:08 pwm 538
2017-04-15 18:11:08 r_h 175.03
2017-04-15 18:11:08 r_s 107335
2017-04-15 18:11:08 voc 725
Helper:
defined none
retries 3
seq2 103
seq4 1
timeout 8000
Attributes:
advanced 1
event-on-update-reading voc
icon cul
interval 1200
room Arbeitszimmer
timeout 8000
verbose 4
Meldungen Fhemlog:
2017.04.15 18:31:02 3: AZ.iam: write error -110/-110 (1)
2017.04.15 18:31:32 3: AZ.iam: write error -110/-110 (2)
2017.04.15 18:32:02 4: AZ.iam got 4067ad0245031702ee4300006fb0010000000000000000000000000000000000 / 32 / 64
2017.04.15 18:36:06 4: AZ.iam got 4068ca0247031a02ee430000aca4010000000000000000000000000000000000 / 32 / 64
Trotz "error" state habe ich aktuelle VOC Werte ..
Auch ein "get AZ.iam air_data" liefert aktuelle Werte, aber state "error"
bis dann
Klaus
Hallo,
mit der neuesten Version gibt es:
PERL WARNING: Use of uninitialized value in string ne at ./FHEM/38_CO20.pm line 267.
bis die Tage
Klaus
Moin, moin,
irgendwie komme ich nicht weiter!
Was habe ich gemacht:
1. Ich habe den Velux co20 in mein raspberry PI3 mit Fhem gesteckt.
2. Ich habe "sudo apt-get install libdevice-usb-perl" ausgeführt.
3. Ich habe in meine Config folgendes eingetragen:
define co20 CO20
attr co20 interval 60
attr co20 room Wohnzimmer
define FileLog_co20 FileLog ./log/CO20-WZ-%Y-%m-%d.log co20
attr FileLog_co20 logtype co20:plot,text
attr FileLog_co20 room Wohnzimmer
define SVG_1 SVG FileLog_co20:co20:CURRENT
attr SVG_1 room Wohnzimmer
Ergebnis:
Im Wohnzimmer bekomme ich "co20 disconnected" angezeigt!
Was habe ich falsch gemacht?
Im Log steht:
2017.05.02 17:15:06 2: co20: no device
2017.05.02 17:15:06 3: co20: CO20 USB connect
2017.05.02 17:15:06 3: co20: CO20 device found
2017.05.02 17:15:06 3: co20: failed to open CO20 device
2017.05.02 17:15:06 3: co20: disconnected
Die Verbindung zum Stick haut nicht hin. Raspberries sind generell problematisch.
Schon mal an einem Hub mit eigener Stromversorgung probiert?
Klappt es gar nicht oder nur manchmal.
Hi Markus,
ich habe es ja mal hinbekommen, allerdings ist es schon fast ein Jahr her, aber nun habe ich mal neu aufgesetzt aber .... funzt net.
Raspi komplett runter fahren, 1 Muínute stromlos machen und dann neu booten hilft bei mir auch in hartnäckigen Fällen. Steckt der Stick direkt im Raspi, oder ist da ein Kabel dazwischen? Evtl. das Kabel wechseln/kürzen.
Der CO20 braucht ne Menge Strom, Perl USB verkraftet keine schnellen Anfragen und mit einem Raspi wird das Ganze zum Glücksspiel, besonders wenn noch andere USB-Geräte dranhängen.
Du kannst nur ausprobieren ob irgendeine Konstellation aus Hub und USB Settings klappt.
So dramatisch wie Markus das immer formuliert ist das mit dem Raspi nun auch wieder nicht. Ich habe 3 CO20-Sensoren, davon 2 sogar über USB-RJ45-Verlängerungen angeschlossen. Alle Sensoren hängen an USB-Hubs, zusammen mit ner ganzen Latte CULs und USB-RS232-Wandler. Das läuft extrem zuverlässig. Da ist der Homematic-CUL am selben USB-Hub wesentlich unzuverlässiger; der will alle paar Wochen einen Restart.
Die Hubs müssen für den Raspi geeignet sein (=> googeln!) und sie brauchen eine eigene, sehr gute Stromversorgung mit dicken Kabeln. Die Kabel für die CO20 müssen ebenfalls sehr gut sein. Eine meiner USB-RJ45-Verlängerungen wurde erst stabil, als ich ein cat6- durch ein cat7-Kabel ersetzt habe, beide 1m lang.
Auf meinen RASPI 2 läuft der Stick auch direkt am USB-Port.
Bei mir läuft es so:
Internals:
CHANGED
INTERVAL 1200
LAST_POLL 2017-05-03 09:48:15
NAME AZ.iam
NOTIFYDEV global
NR 271
NTFY_ORDER 50-AZ.iam
STATE opened
TYPE CO20
fail 0
manufacturer AppliedSensor
product iAQ Stick
retries 3
seq2 243
seq4 1
tag
timeout 8000
Readings:
2017-05-03 09:48:15 debug 835
2017-05-03 09:48:15 pwm 538
2017-05-03 09:48:15 r_h 174.28
2017-05-03 09:48:15 r_s 117560
2017-05-03 09:48:15 voc 490
Attributes:
advanced 1
event-on-update-reading voc
icon cul
interval 1200
room Arbeitszimmer
timeout 8000
verbose 2
Bei mir läuft es sehr stabil, allerdings darf der Intervall nicht zu klein gewählt werden. Am besten läuft der Stick bei mir mit der Version 38_CO20.pm vom 28.2.17.
Was auch immer geholfen hat, war ein erneutes anstecken des Sticks. (oder eboot rpi)
Folgende Notizen hatte ich mir damals gemacht (wobei ich RPI 2 mit wheezy habe):
- Der Stick muss beschreibbar sein, dafür unter /etc/udev/rules.d/ eine 99-usb.rules anlegen umd mit
mit SUBSYSTEM=="usb", ATTR{idVendor}=="03eb", ATTR{idProduct}=="2013", MODE="0666"
füllen.
- USB.Speed auf 1.1 begrenzen:
/boot/cmd/cmdline.txt dwc_otg.speed=1 einfügen
- Perl USB Unterstützung installieren:
sudo apt-get install libdevice-usb-perl
Viel Spaß
Update: Definition mit Seriennummer (bei mereren Sticks) funktioniert wieder problemlos
Hallo Markus,
danke für das update..
Mit dem update ist leider der in Post #646 beschriebene Fehler noch vorhanden...
Viele Grüße
Klaus
Zitat von: Rampler am 12 Mai 2017, 12:15:23
Hallo Markus,
danke für das update..
Mit dem update ist leider der in Post #646 beschriebene Fehler noch vorhanden...
Der liegt ja auch nicht unbedingt am Modul.
Dein Stick reagiert nur nicht immer gleich.
Setz mal das Intervall auf 120 und schau ob es dann besser wird.
Du kannst auch den Timeout über das entsprechende Attribut hochsetzen. Standard sind 1000ms.
Zitat von: Markus M. am 12 Mai 2017, 12:21:41
Der liegt ja auch nicht unbedingt am Modul.
Dein Stick reagiert nur nicht immer gleich.
Setz mal das Intervall auf 120 und schau ob es dann besser wird.
Du kannst auch den Timeout über das entsprechende Attribut hochsetzen. Standard sind 1000ms.
Habe ich getestet, leider auch ohne Erfolg. Mir ist schon bewusst, dass der Rpi bezüglich USB problematisch ist.., doch mit der Version vom 28.02 läuft der Stick einwandfrei.
Mit der aktuellen 38_CO20.pm bekomme ich auch Werte, jedoch steht der Status auf Error..
Bei der ersten Abfrage ist er noch opened, dannach geht er auf Error.
Wäre mal interresant ob andere hier ähnliche Erfahrungen haben ?
bis die Tage
Klaus
Jetzt verstehe ich was du meinst!
Mach morgen einfach noch mal ein Update.
Zitat von: Markus M. am 12 Mai 2017, 15:18:07
Mach morgen einfach noch mal ein Update.
Guten Morgen, update ist durch ! DANKE
Jetzt ist der Status auf "retry", macht ja auch mehr Sinn da ja Daten geliefert werden.
Habe noch zwei Sensoren an Openwrt/Lede Router, diese melden open.
Der Status sagt jetzt quasi aus, wie zuverlässig die USB Verbindung ist, oder ?
bis die Tage
Klaus
EDIT: Sollte der Status nicht auf open sein, und z.B. der Fail counter hochzählen ?
Zitat von: Rampler am 13 Mai 2017, 08:07:48
Der Status sagt jetzt quasi aus, wie zuverlässig die USB Verbindung ist, oder ?
Sollte der Status nicht auf open sein, und z.B. der Fail counter hochzählen ?
Passiert beides.
Auch RECONNECT zählt hoch, beginnt dabei aber wieder mit "open".
Sollte ich dafür Readings anlegen?
Zurück zu open wenn es ohne zweiten Versuch klappt?
Zitat von: Markus M. am 13 Mai 2017, 14:41:03
Auch RECONNECT zählt hoch, beginnt dabei aber wieder mit "open".
Sollte ich dafür Readings anlegen?
Zurück zu open wenn es ohne zweiten Versuch klappt?
Nachdem der Stick letzendlich funktioniert (ich bekommen gemäß Intervall alle Werte) sollte der Status m.M auf "open" stehen. Ein zusätzliches "retries" Reading wäre glaub sinnvoller. Das Reading "retries" sollte dann immer die benötigten Retries für den letzten Lesevorgang anzeigen. Ohne notwendige Retries dann halt "0".
bis die Tage
Klaus
PS:
aktuell ist FAIL und RECONNECT auf 0
Ca. so?
Schneller geht's nimmer ..
War kurz auf retry, und geht dann irgendwann wieder open, muss ich noch ein wenig beobachten, sieht aber schon richtig gut aus ..
Klaus
Für mich passt das jetzt so einwandfrei !!
Gibt's dann morgen per update ?
Vermutlich irgendwann nächste Woche.
Bitte mal diese Version ausprobieren, eventuell klappt es damit auch mit nem Raspberry besser.
Zitat von: Markus M. am 16 Mai 2017, 22:14:15
Bitte mal diese Version ausprobieren, eventuell klappt es damit auch mit nem Raspberry besser.
Klappt einwandfrei, Stick ist open, liefert gemäß Intervall Daten, alles gut.
Abrage von stick_data, knob_data funktioniert auch...
Interessant zu wissen wäre, ob es damit noch zu Verbindungsabbrüchen oder zum komplettem Blockieren (bei mir ab und zu, nach mehreren Tagen Betrieb) kommt und ob kleinere Intervalle möglich sind.
Intervalle geht nur so (Intervall stand auf 30 Sec):
2017-05-17_15:48:59 AZ.iam voc: 571
2017-05-17_15:49:59 AZ.iam voc: 569
2017-05-17_15:50:59 AZ.iam voc: 558
2017-05-17_15:51:59 AZ.iam voc: 536
2017-05-17_15:52:59 AZ.iam voc: 565
2017-05-17_15:53:59 AZ.iam voc: 565
2017-05-17_15:54:59 AZ.iam voc: 565
2017-05-17_15:55:59 AZ.iam voc: 573
2017-05-17_15:56:59 AZ.iam voc: 565
2017-05-17_15:57:59 AZ.iam voc: 579
2017-05-17_15:58:51 AZ.iam voc: 586
2017-05-17_15:58:59 AZ.iam voc: 585
2017-05-17_15:59:59 AZ.iam voc: 654
2017-05-17_16:00:59 AZ.iam voc: 633
2017-05-17_16:01:59 AZ.iam voc: 626
2017-05-17_16:02:59 AZ.iam voc: 623
2017-05-17_16:03:59 AZ.iam voc: 707
2017-05-17_16:04:59 AZ.iam voc: 709
2017-05-17_16:05:59 AZ.iam voc: 777
2017-05-17_16:06:59 AZ.iam voc: 705
2017-05-17_16:07:59 AZ.iam voc: 672
2017-05-17_16:08:59 AZ.iam voc: 682
2017-05-17_16:09:59 AZ.iam voc: 674
2017-05-17_16:10:59 AZ.iam voc: 702
2017-05-17_16:12:00 AZ.iam voc: 633
2017-05-17_16:13:00 AZ.iam voc: 627
2017-05-17_16:14:00 AZ.iam voc: 701
Der Stick geht währenddessen immer mal wieder auf retry, und fail 1...
Das sind 60, wird also nicht wirklich besser :)
Zumindest funktioniert es nicht schlechter als vorher.
Werde ich so demnächst ins Update packen.
Hi Markus,
bei mir mit der Version relativ schnell nach einem Update auf disconnected. Ich hatte allerdings nur ein reload und kein shutdown/restart gemacht. Werde weiter beobachten.
Grüße Markus
Edit: Jetzt nach shutdown/restart geht der Sensor nicht mehr in den Status connected, sondern nur noch auf open. Dazu dann permanente Logmeldungen:
2017.05.17 17:21:08 3: co20: write error -110/-110 (1)
2017.05.17 17:21:38 3: co20: write error -110/-110 (2)
2017.05.17 17:23:38 3: co20: write error -110/-110 (1)
2017.05.17 17:24:08 3: co20: write error -110/-110 (2)
2017.05.17 17:26:08 3: co20: write error -110/-110 (1)
2017.05.17 17:26:38 3: co20: write error -110/-110 (2)
Früher gab es nur eine einmalige -110 Meldung nach dem booten.
Internals:
CFGFN includeOther.cfgPI
FAIL 0
ID 001:013
INTERVAL 90
LAST_POLL 2017-05-17 17:29:38
NAME co20
NOTIFYDEV global
NR 560
NTFY_ORDER 50-co20
RECONNECT 0
SERIALNUMBER
STATE open
TYPE CO20
manufacturer AppliedSensor
product iAQ Stick
Readings:
2017-05-17 17:29:38 debug 775
2017-05-17 17:29:38 pwm 388
2017-05-17 17:29:38 r_h 155.09
2017-05-17 17:29:38 r_s 201670
2017-05-17 17:29:38 state open
2017-05-17 17:29:38 voc 525
Helper:
defined none
retries 5
seq2 108
seq4 1
timeout 1000
Attributes:
advanced 1
interval 90
retries 5
Funktion scheint aber einwandfrei.
Zitat von: KölnSolar am 17 Mai 2017, 17:18:48
Jetzt nach shutdown/restart geht der Sensor nicht mehr in den Status connected, sondern nur noch auf open.
connected gab's noch nie.
ZitatDazu dann permanente Logmeldungen
Raspberry? Hattest du vorher auch schon die gleichen Einstellungen?
Wichtiger ist, dass regelmässig Daten kommen.
Zitatconnected gab's noch nie.
Hätt ich schwören können, aber wenn Du es sagst, ist es auch so ;)
ZitatRaspberry? Hattest du vorher auch schon die gleichen Einstellungen?
Ja RPi3 mit Jessie. Einstellungen hab ich schon immer so.
Daten kommen regelmäßig(Logeinträge auch :() Zwischendurch hab ich mal state=retry.
2017.05.17 19:08:28 3: co20: write error -110/-110 (1)
2017.05.17 19:08:58 3: co20: write error -110/-110 (2)
2017.05.17 19:09:28 3: co20: write error -110/-110 (3)
2017.05.17 19:09:59 3: co20: write error -110/-110 (4)
2017.05.17 19:11:59 3: co20: write error -110/-110 (1)
2017.05.17 19:12:29 3: co20: write error -110/-110 (2)
2017.05.17 19:14:29 3: co20: write error -110/-110 (1)
2017.05.17 19:14:59 3: co20: write error -110/-110 (2)
2017.05.17 19:16:59 3: co20: write error -110/-110 (1)
2017.05.17 19:17:29 3: co20: write error -110/-110 (2)
2017.05.17 19:19:29 3: co20: write error -110/-110 (1)
2017.05.17 19:20:00 3: co20: write error -110/-110 (2)
2017.05.17 19:22:00 3: co20: write error -110/-110 (1)
2017.05.17 19:24:01 3: co20: write error -110/-110 (1)
2017.05.17 19:26:01 3: co20: write error -110/-110 (1)
2017.05.17 19:26:32 3: co20: write error -110/-110 (2)
2017.05.17 19:28:32 3: co20: write error -110/-110 (1)
2017.05.17 19:29:02 3: co20: write error -110/-110 (2)
2017.05.17 19:31:02 3: co20: write error -110/-110 (1)
2017.05.17 19:31:32 3: co20: write error -110/-110 (2)
2017.05.17 19:33:32 3: co20: write error -110/-110 (1)
2017.05.17 19:34:02 3: co20: write error -110/-110 (2)
2017.05.17 19:36:02 3: co20: write error -110/-110 (1)
2017.05.17 19:36:32 3: co20: write error -110/-110 (2)
2017.05.17 19:40:03 3: co20: write error -110/-110 (1)
2017.05.17 19:40:33 3: co20: write error -110/16 (2)
2017.05.17 19:41:03 3: co20: write error -110/-110 (3)
2017.05.17 19:41:34 3: co20: write error -110/-110 (4)
2017.05.17 19:43:34 3: co20: write error -110/-110 (1)
2017.05.17 19:44:04 3: co20: write error -110/-110 (2)
Die write error's habe ich auch, allerdings mit "verbose 2" unterdrückt ...
..nur mit der Version vom 28.02 nicht ..
# $Id: 38_CO20.pm 13545 2017-02-28 01:00:53Z moises $
Und das auch nur auf dem RPI..
Hi,
das Modul Device::USB wurde vor 2 Wochen geupdatet und dann direkt der Status auf DEPRECATED gesetzt (wegen Zeitmangels des Autors).
Habt ihr mal die neue Version 0.37 ausprobiert?
Changes for version 0.37
- Deprecate module
- Correct usage of Inline::C
- Convert to xt-based author tests for non-installation tests.
- Fix failing author tests.
- Move code to github and cleanup repo.
Da ich fhem auf Windows nutze und Device::USB sich dort ab einer bestimmten Perl-Version nicht mehr installieren lässt, überlege ich, einen oder mehrere RPis mit Sensoren (auch co20) auszustatten und mittels FHEM2FHEM mit der Hauptinstanz zu verbinden.
Oder gibt es mittlerweile bessere Alternativen, um Luftqualität zu messen, da dieser Stick ja doch ein paar Schwächen hat (Temperaturabhängigkeit, Eichung, USB-Probleme mit RPi)?
Viele Grüße
Spiff
Hi Markus,
ZitatInteressant zu wissen wäre, ob es damit noch zu Verbindungsabbrüchen oder zum komplettem Blockieren (bei mir ab und zu, nach mehreren Tagen Betrieb) kommt und ob kleinere Intervalle möglich sind.
Mit der Version aus #667 weder Abbrüche(also keine Meldung no device nach disconnected), noch Blockieren seit 14 Tagen auf dem RPi3. Interval 90.
Ich denke, Du kannst es einchecken.
Grüße Markus
Ich habe seit es draußen wärmer ist das Problem (genau wie im letzten Sommer), dass die voc-Werte plötzlich extrem ansteigen. Im Winter sind 1000 bis max. 2000 normal (wenn Besuch da ist oder gekocht wird auch mal 3000), jetzt klettern die Werte schnell auf über 4000 -5000 und bleiben dort auch dauerhaft. reset_baseline hilft nur für ein paar Stunden. Der Effekt ist im Prinzip bei allen 3 Sensoren ähnlich.
Habt ihr das auch so? Ist das normal?
Das Blöde daran ist, dass ich die Drehzahlen meiner KWL anhand der Sensoren steuere. Die Anlage läuft dann permanent auf höchster Stufe, was ja nicht wirklich sinnvoll ist. Muss ich für Winter- und Sommermonate verschiedene Grenzwerte verwenden?
gefühlt erreiche ich auch im Sommer höhere Werte. Gefühlt allerdings deshalb, weil ich den eigentlich entscheidenden Wert r_s mitlogge. Der ist im Sommer(höhere Luftfeuchtigkeit/Raumtemperatur ?) höher als im Winter.
Bei mir spielt das aber insofern keine Rolle, dass der Stick eigentlich eine zu hohe Baseline hat. Bedeutet: Ich resette den Stick und wenn ich dann lüfte, fällt VOC bis 450. r_s steigt immer weiter bis irgendwo zwischen 200.000 - 250.000. Allerdings sinkt nach dem Lüften der r_s-Wert relativ schnell ab und der VOC steigt. Der VOC pendelt sich dann in der Regel bei ca. 800 ein. Nun hat der Stick sich quasi neu kalibriert und der VOC ist danach plausibel. Du müsstest also mal beobachten wie sich der r_s Wert verhält.
Hast Du vielleicht eine sommerliche VOC-Quelle ?
Edit: Ich wird bei mir das Gefühl nicht los, dass das Laden meines Rasenmäher-Akkus zu schlechtem VOC führt :-\
Der Sensor wird beheizt um VOC zu messen.
Dass bei wärmerer Umgebungstemperatur dann höhere Werte gemessen werden als im Winter, ist ohne Kalibrierung zwischendurch relativ logisch.
Vielleicht hilft es, wenn du ein wenig an den internen Stellschrauben drehst.
Zitat von: Markus M. am 12 Juni 2017, 10:53:42
Der Sensor wird beheizt um VOC zu messen.
Dass bei wärmerer Umgebungstemperatur dann höhere Werte gemessen werden als im Winter, ist ohne Kalibrierung zwischendurch relativ logisch.
Vielleicht hilft es, wenn du ein wenig an den internen Stellschrauben drehst.
Auch nach Neukalibrierung ist er innerhalb weniger Stunden wieder auf riesigen Werten >4-5000.
Gibts zu den internen Stellschrauben mehr Details oder einen Link zum einlesen?
Zitat von: Spiff am 29 Mai 2017, 11:45:45
Hi,
das Modul Device::USB wurde vor 2 Wochen geupdatet und dann direkt der Status auf DEPRECATED gesetzt (wegen Zeitmangels des Autors).
Habt ihr mal die neue Version 0.37 ausprobiert?
Changes for version 0.37
- Deprecate module
- Correct usage of Inline::C
- Convert to xt-based author tests for non-installation tests.
- Fix failing author tests.
- Move code to github and cleanup repo.
Da ich fhem auf Windows nutze und Device::USB sich dort ab einer bestimmten Perl-Version nicht mehr installieren lässt, überlege ich, einen oder mehrere RPis mit Sensoren (auch co20) auszustatten und mittels FHEM2FHEM mit der Hauptinstanz zu verbinden.
Oder gibt es mittlerweile bessere Alternativen, um Luftqualität zu messen, da dieser Stick ja doch ein paar Schwächen hat (Temperaturabhängigkeit, Eichung, USB-Probleme mit RPi)?
Viele Grüße
Spiff
Hi
Gibt es neues zu dem Thema?
Ich habe auch immer Meldungen im Log.
[Code ]2017.07.01 18:24:45 3: co20: write error -110/-110 (1) 2017.07.01 18:25:15 3: co20: write error -110/-110 (2)
[/Code ]
Grüssle, Jens
Gesendet von meinem F5121 mit Tapatalk
Ich werde mein Glück mal damit
https://forum.fhem.de/index.php/topic,41750.0.html
versuchen. Die Rückmeldungen, auch Amazon-Bewertungen, klingen ermutigend.
Zitat von: Markus M. am 12 Juni 2017, 10:53:42
Der Sensor wird beheizt um VOC zu messen.
Dass bei wärmerer Umgebungstemperatur dann höhere Werte gemessen werden als im Winter, ist ohne Kalibrierung zwischendurch relativ logisch.
Laut Datenblatt wird der Sensor intern auf 300°C erwärmt. Da sollte bei sinnvoller Temperaturregelung eine konstante Sensortemperatur machbar sein, bei der sich 5° Änderung der Raumtemperatur ausregeln lassen. Wenn das in der Praxis dennoch nicht gegeben ist, ist es eher ein Spielzeug und kein zuverlässiges Messinstrument.
Zitat von: willybauss am 02 Juli 2017, 11:22:36
Wenn das in der Praxis dennoch nicht gegeben ist, ist es eher ein Spielzeug und kein zuverlässiges Messinstrument.
Das ist eigentlich auch mein Verständnis von dem Ding. Für den Preis von 15€ jedoch ok. Für ernsthafte Messungen habe ich mir mal so einen vThings CO2 Monitor gekauft. Der hat (wenn man den CDM7160 wählt) mit calibration-free CO2-Sensor, der dauerhaft akkurate Werte ausspucken soll:
http://shop.vair-monitor.com/index.php?rt=product/product&product_id=133
Kostet allerdings auch deutlich mehr...
Noch mehr als die Temperatur hat die Luftfeuchtigkeit Einfluss auf die Messung. Es ist eben kein Labormessgerät, reicht aber für die meisten Steuerungszwecke im Home.
wenn noch jemand einen nicht produktiv eingesetzten Sensor hat, könnte der den rc_s-Wert und Temp. und Luftfeuchte loggen. Vermutlich am Besten an der frischen Luft, wo das Ding zwar eigentlich keinen Sinn macht, die Schwankungen aber deutlicher werden.. Mit den so gewonnen Daten könnte man den Einfluss grob ermitteln und via Umrechnungsformel in einem User-Reading einen korrekteren Wert errechnen.
Grüße Markus
Hallo,
nach den Umzug auf den RasPi 3 bekomme ich folgende Meldung im Log:
2017.09.17 23:03:26 3: co20: write error -110/-110 (2)
Ich vermute da stimmt mit der Installation etwas nicht. Der Stick ist initialisiert
und liefert Werte.
Jens
Moin,
ich habe mittlerweile das Problem, dass der Sensor komplett aussteigt und nach einigen Tagen auf Disconnected steht.
Ein ausstöpseln einstöpseln löst das und dann geht es wenige Tage um wieder so zu Enden.
Ich frage mich gerade welche im SVN die aktuellste Version der 38_CO20.pm ist :-)
Kann mir jemand helfen?
Leider nein, da genau das auch bei mir passiert. Und zwar teilweise mit komplettem Freeze des Systems.
Ich denke mal dass das Modul umgebaut werden müsste auf anderes IO Handling. Mir fehlt dazu aber mittlerweile die Zeit.
Gibt es vielleicht jemanden, der das CO20 Modul als Maintainer übernehmen will?
:-\ :'( Ojee
Das ist schade. Aber vielen Dank für das bis hier geleistete. 8)
Leider fehlt mir für sowas ein wenig die Fähigkeit und das Know How.
Ich betreibe die Sensoren zuverlässig mit einem externen Program, welches regelmäßig den Sensor abfragt und dann den Wert in ein Dummy in FHEM setzt (per netcat->Telnet):
https://github.com/verybadsoldier/airsensor
Das Script sieht dann z.B. so aus:
#!/bin/sh
HOST=minion
PORT=7072
DEVICE=fl_airSensor
READING=airQuality
PARAMS_PRE="-l 15000 -e 5 -i 10 -c "
USER_CMD="echo \"setreading $DEVICE $READING %d\" | nc -w10 $HOST $PORT"
./airsensor $PARAMS_PRE "$USER_CMD"
Ist nicht sonderlich elegant, aber tut bei mir seit Jahren seinen Dienst.
;) Das sieht aus, als könntest du ggf. auch das Modul umbauen *g* :-D
Kannst du mit deinem Tool auch den Sensor resetten und so?
Also meine 4 Stück laufen jetzt seit langem sehr stabil an ihren Raspis. Allerdings wird fhem einmal pro Woche nach automatisiertem Update neu gestartet. Der Raspi meistens nur nach einem Kernel-Update alle 2-3 Monate.
Also bei mir ist von stabil leider nicht zu reden. Es war lange lange Zeit sehr stabil. Einmal kam was mit einer Version des Moduls und seitdem war aber auch wieder alles ruhig.
Ich sagmal seit 2 Wochen oder so ist damit absolut Ende.
Dass die Dinger nicht dauerhaft stabil laufen, liegt wahrscheinlich auch an den einzelnen Sticks. Manche funktionieren perfekt, andere hängen sich nach Tagen oder Wochen irgendwann mal auf.
Aber so plötzlich? Vorher war es jahrelang stabil. Glaube nicht, dass es jetzt auf einmal der Stick ist.
Die Frage wäre ja nun was ist einfacher Modulumbau und -pflege oder gibt es alternative Sensoren, die schon eingebunden sind oder ggf einfach was direkt ans Pi anzuschließen wäre.
Ich habe den schon länger bei mir auf dem Schreibtisch in Betrieb:
https://www.amazon.de/gp/product/B00TH3OW4Q
Allerdings immer noch nicht in FHEM, obwohl es wohl ein Modul gibt.
Wenn diese Geräte nur nicht so "teuer" währen ...
Saftiger Kurs! ;) ::)
Ich wäre für stabiles Laufen dieser Sensoren hier :-D
Das Gerät im Link misst aber nur CO2, nicht VOC. Dafür nehme ich zum Beispiel mittlerweile Netatmo Stationen.
Hättets Du einen Link? Kann mir aktuell nichts davon vorstellen ...
Die Innensensoren funktionieren doch nicht ohne die Wetterstation, oder?
Gesendet von iPhone mit Tapatalk
Zitat von: volschin am 13 Februar 2018, 09:43:26Die Innensensoren funktionieren doch nicht ohne die Wetterstation, oder?
Ich hab bei mir in jedem Raum eine Basisstation stehen.
Wenn man lange genug bei eBay sucht, findet man ab und zu welche mit defektem Außensensor etc., die günstiger sind als dein CO2 Messgerät.
Nachteil ist allerdings, dass man nur alle 11 Minuten Messwerte bekommt und nur einen Datenpunkt alle 5 Minuten hat.
Ich habe mal das Attribut retries auf 15 gesetzt - aktuell läuft er damit.
Hatte die Netatmo Dinger auch ne Zeit lang in Betrieb, mich dann aber wieder davon getrennt, da man anhand der Verläufe perfekt Rückschlüsse auf anwesende Personen ziehen konnte und ich das nicht online haben wollte. Aber das entscheidet jeder selbst. Die Minico2, wie auch alle anderen Sensoren, die wirklich Co2 und nicht voc messen, sind halt systembedingt so teuer, da die messmethode und der zugehörige Sensor so teuer ist. MiniCo2 war bei mir auch ne Weile erfolgreich in Betrieb, bist ich auf Vair-Monitor-Sensoren umgestiegen bin (leider nicht mehr im Business). Aber falls jemand den dort verbauten Sensor an einen RPI oder Aduino gehängt bekommt... Mit voc-Sensoren wird es natürlich deutlich günstiger, misst aber auch nur voc, was eine andere Aussage hat als CO2. Danach regeln kann man natürlich trotzdem.
Gesendet von iPhone mit Tapatalk
Jemand Erfahrung hier mit? "MG811: Kohlendioxid (CO2)"
https://tutorials-raspberrypi.de/raspberry-pi-gas-sensor-mq2-konfigurieren-und-auslesen/
Wobei ich das hier dann, da mobiler interessanter finde: http://esp8266-server.de/MQTT/CO2-Sensor.html
Es wäre nicht ganz unschön wenn der Sensor nicht mehr mit Kabel mit dem Pi verbunden ist :-)
Wobei im gleichen Raum nich das Problem sein sollte. Soooo sollte sich der CO2 Gehalt im Raum nicht unterscheiden. Wenn doch, hast Du ein Lüftungsproblem ....
Auf wen beziehst du dich? Ich kann dem gerade nicht folgen :o :)
Zitat von: Wernieman am 13 Februar 2018, 14:20:13
Wobei im gleichen Raum nich das Problem sein sollte. Soooo sollte sich der CO2 Gehalt im Raum nicht unterscheiden. Wenn doch, hast Du ein Lüftungsproblem ....
Zitat von: Markus M. am 13 Februar 2018, 11:13:17
Nachteil ist allerdings, dass man nur alle 11 Minuten Messwerte bekommt und nur einen Datenpunkt alle 5 Minuten hat.
Ich messe sowieso nur alle 5 min. Aber wieso bekommt man nur alle 11 Min Messwerte?
Die Netatmo Dinger laden ihre Werte auf einen externen Netatmo Server, von dem man sie dann anrufen kann. Meines Wissens hat man auf das Intervall der Messungen/Hochladen keinen Einfluss.
Ich hab das Gefühl, dass der gelegentliche Ausfall mit Freezes zusammenhängt. Seitdem ich mit freezemon meine Bösewichter identifiziert u. korrigiert habe, läuft der Sensor (gefühlt) super stabil.
Grüße Markus
Meiner läuft seit dem ich Retries auf 15 habe nun auch den 3. Tag anstandslos durch :-)
Ich habe den Raumluftsensor von Voltcraft / Rehau softwaremäßig etwas angepasst, sodass er jetzt die Voc-Daten mithilfe eines Raspis per MQTT überträgt.
Vielleicht für node-red / ioBroker interessant.
infos hier: https://blog.moneybag.de/iobroker-usb-raumluft-sensor-daten-ueber-mqtt-uebertragen/
LG
/robin
:) Coole Sache!
Eventuell gibt es jetzt einen etwas zuverlässigeren Sensor, der noch dazu auch über WLAN angebunden werden kann. Probleme mit zu langen USB-Kabeln sollten damit erledigt sein. Bin gespannt, ob/wann/wer ihn in FHEM einbinden wird. Ich bin damit wohl überfordert.
https://www.idevices.de/ (https://www.idevices.de/)
:D Najo schon was teurer ;-)
Aber immerhin.
Das mit der Zuverlässigkeit würde ich nochmal Hi terfragen, wie Du zu der Aussage kommst? USB-Kabelprobleme mag ja bei manchen sein, aber wenn die wie vermutet, einen Bosch BME 680 verbaut haben sollten, wüsste ich nicht, warum derbezüglich der Messwerte zuverlässiger sein sollte.
Moin ;)
Ich habe tatsächlich immer noch den REHAU in Betrieb und auch eigentlich sehr verlässlich.
Aktuell stolpert der aber hart über write errors im Log.
Was ich nun nicht weiß ist, ob es Probleme des Gerätes oder des Modules sind.
Jedenfalls geht z. B. die Kalibrierung und ähnliche snicht mehr.
2019.03.25 20:34:38 5: setdata write -110
2019.03.25 20:34:38 4: set data failed: @0001FLAGSET;CALIBRATE HEATER=▒
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Wie immer: entweder es funktioniert oder es funktioniert nicht.
Wenn du am System nichts geändert hast, zeigt der Stick eventuell Alterungserscheinungen.
Das zeigt sich dann natürlich bei Aktionen die unmittelbar Feedback benötigen zuerst.
Mh naja - das System wird natürlich generell up to date gehalten.
Das kann ja durchaus auch in der Kommunikation mit USB mal was verändern.
Ich habe übrigens zuletzt auch massivere Probleme mit der Stabilität von 2 Sensoren gehabt, fielen immer wieder im Abstand mehrerer Tage aus. Es half nur abziehen und wieder Anstecken. Da ich sowieso mal einen Umbau vor hatte, habe ich sie auf Dauerbetrieb mit dem C-Programm mit Messungen alle 30s umgestellt, in das ich mir noch einen kleinen mqtt publish eingebaut habe. Lösung funktioniert seit 3 Wochen ohne einen Ausfall. Irgendwas macht das C-Programm anscheinend besser.
Welches C-Programm ?
Airsensor.c
Ich glaube das hier war die Basis
https://github.com/tuxedo0801/usb-sensors-linux/blob/master/airsensor/airsensor.c
Kannst du deine Lösung im Detail darstellen?
Bei mir besteht das gleiche Problem, beide Sensoren gehen seit Monaten nach kurzer Zeit auf Disconnect und lassen sich nur durch stromlosmachen wieder aktivieren.
Danke.
Nein, wenn Du nicht Entwickler bist, ist das momentan nichts für Dich. Ich habe mqtt auch erstmal dreckig in den Code reingebaut um zu testen, ob es was bringt und weil ich von den dezentralen FHEM weg will.
Nutzt Du Docker?
Hallo allesamt,
ich hole mal diesen Foreneintrag mal aus der versenkung :-\
Mein Raspberry seine SD-Karte ist leider hopps gegangen (und ich hatte kein backup .....) und jetzt bin ich gerade daran alles wieder einzurichten. Ich habe alles soweit durch, nur der Voltcraft/Velux Sensor liefert mir noch keine Daten. Ich habe auf dem PI FHEM schon installiert und es läuft 1a per Fhem2Fhem mit meinem virtuellen Raspberry Ideal.
Es ist also ein naktes Raspi-OS (immer noch raspi1 ;) )
Der Velux steckt und leuchtet grün
folgendes wurde in Fhem gemacht:
"
define co20 CO20
attr co20 advanced 1
attr co20 interval 120"
auf dem pi wurde folgendes ausgeführt
sudo apt-get install libdevice-usb-perl
sudo apt-get install build-essential
sudo apt-get install libdevice-usb-perl
sudo cpan install Device::USB
wget http://usb-sensors-linux.googlecode.com/svn/trunk/airsensor/airsensor.c (das es nicht mehr gibt!)
Kann mir einer helfen? Kann mir einer das airsensor.c (das man anscheinend braucht) mal hier einstellen?
Das kennst du? Wenn neu, dann vielleicht damit:
https://wiki.fhem.de/wiki/Co2mini
Gruss
Enno
hi enno,
ne kenne ich nicht, aber bei mir sind gerade die finanziellen Lagen nicht roßig und 69$ sind mir einfach zu viel Geld und warum nicht das alte was funktioniert hat wieder nutzen? Für das detail habe ich aber schon ne Netatmo am laufen.
Grüße
Hatte denn der CO20 Sensor kurz vor dem Absturz des Raspi noch Daten geliefert? Meine Sensoren haben schon vor Jahren aufgehört, Daten zu senden. Ich musste deshalb die SensorSteuerung der KWL außer Betrieb nehmen. Das scheint ein allgemeines Problem zu sein, dass die Dinger irgendwann nicht mehr arbeiten wollen ...
er hatte ab und an mal seine Tage (habe ich ne Frau oder was gekauft? :D), aber ansich hat er ständig schön brav funktioniert und das selbst ein paar Stunden vor dem Ausfall.
Aber allgemein mache ich doch alles richtig, oder? Hab ich vielleicht einen Punkt vergessen und nicht gemacht?
wird vermutlich an dem "(das es nicht mehr gibt!)" liegen ?
Ich schau mal, ob ich es noch auf meinem Raspi finde.
Zitat von: willybauss am 04 November 2022, 17:55:41
wird vermutlich an dem "(das es nicht mehr gibt!)" liegen ?
Passt das vielleicht noch?
https://github.com/verybadsoldier/airsensor/blob/master/airsensor.c
ich habs nicht mehr gefunden, sorry
Zitat von: willybauss am 04 November 2022, 21:57:47
ich habs nicht mehr gefunden, sorry
Kein Problem. Ich denke mal langsam ich muss den co2 von netatmo dann abgreifen
Zitat von: enno am 04 November 2022, 18:21:03
Passt das vielleicht noch?
https://github.com/verybadsoldier/airsensor/blob/master/airsensor.c
Ich habe es mal kompiliert und eingebunden. Aber der sensor liefert keine Daten. Also das bekannte Problem
Ergänzung.
Er steht aber als disconnected da.
Ich werde später mal das Skript manuell ausführen und hoffen das es noch Daten liefert.
Ergänzung zur Ergänzung.
Er verbindet sich und verliert die Verbindung. Ich werde ihn mal direkt an den pi hängen und nicht über meine 5m USB Verlängerung
Sieht nicht gut aus
Hi,
habe das gefunden: https://code.google.com/archive/p/airsensor-linux-usb/downloads
Und im Anhang die Datei von meinen PI.
Zitat von: Jewe am 05 November 2022, 08:48:55
Hi,
habe das gefunden: https://code.google.com/archive/p/airsensor-linux-usb/downloads
Und im Anhang die Datei von meinen PI.
das sieht gut aus (zumindest auf der ssh session). Jetzt fehlt noch die einbindung in Fhem, aber die läuft noch nicht
define co20 CO20
attr co20 advanced 1
attr co20 interval 120
attr co20 room Heizungsraum
# CFGFN
# FAIL 0
# FUUID 636616c9-f33f-c5e3-4a48-b911484955f63384
# ID 001:060
# INTERVAL 120
# NAME co20
# NOTIFYDEV global
# NR 91
# NTFY_ORDER 50-co20
# RECONNECT 1
# SERIALNUMBER
# STATE disconnected
# TYPE CO20
# eventCount 9
# READINGS:
# 2022-11-05 07:55:29 state disconnected
# helper:
# defined none
# retries 3
# seq2 103
# seq4 1
# timeout 1000
#
setstate co20 disconnected
setstate co20 2022-11-05 07:55:29 state disconnected
[Edit]
Ja meine Zeit läuft eine Std hinterher.... ;)
Hast Du den CO20 direkt eingesteckt? Ist die 5m Verlängerung eine aktive USB-Verlängerung ?
Wird der USB-Sensor erkannt: dmesg | tail
Test mit: sudo ./airsensor
Zitat von: Jewe am 05 November 2022, 09:10:07
Hast Du den CO20 direkt eingesteckt? Ist die 5m Verlängerung eine aktive USB-Verlängerung ?
Wird der USB-Sensor erkannt: dmesg | tail
Test mit: sudo ./airsensor
ja steckt direkt und sensor wird erkannt als Applied sensor was soviel ich noch weiß normal ist (siehe Screenshot)
ich weiß auch noch das nur ein device / task auf den Sensor zugreifen kann und habe im übrigen immer schön brav den task beendet, aber jetzt bin ich wirklich mit dem latein am ende. HW passt und liefert daten. SW den code kompiliert und er läuft auch. Aber wie das mit Fhem dann ist und wie das den Taskaufruft da bin ich raus
Du musst irgendwelche rules ändern. Schaumal hier
https://www.meintechblog.de/2018/02/low-price-raumluftsensor-fuer-fhem/
Ich kann mich noch dunkel erinnern, dass es drauf ankommt, in welchem USB-Slot des Raspi der Sensor steckt. Das war irgendwie immer Try&Error.
Zitat von: Jewe am 05 November 2022, 11:26:32
Du musst irgendwelche rules ändern. Schaumal hier
https://www.meintechblog.de/2018/02/low-price-raumluftsensor-fuer-fhem/
ach Jewe stimmt da war was (ach Gott ist das lange her das Ding einzurichten..... :o ::) ::) ::))
mein pi macht noch ne sicherung die vermutlich bis in den späten Nachmittag läuft und dann kann ich den neustarten ;).
Ich werde berichten.
Zitat von: willybauss am 05 November 2022, 11:34:30
Ich kann mich noch dunkel erinnern, dass es drauf ankommt, in welchem USB-Slot des Raspi der Sensor steckt. Das war irgendwie immer Try&Error.
Naja er wird ja erkannt! War das nicht das er einfach dann nicht ging?
Wird er vom Raspi erkannt, oder auch von fhem? Oben lese ich, dass er in fhem "disconnected" ist. In der fhem config des Sticks muss ja ebenfalls der USB-Zugriffspfad definiert sein.
Das fehlt vmtl. noch:
Schließlich muss FHEM über einen UDEV-Eintrag noch die Rechte erhalten, um nachfolgend ebenfalls auf die Messwerte des Sensors zuzugreifen. Dazu wird mit folgendem Befehl eine neue Datei angelegt.
sudo nano /etc/udev/rules.d/99-usb.rules
Die Datei erhält anschließend den folgenden Inhalt:
SUBSYSTEM=="usb", ATTR{idVendor}=="03eb", ATTR{idProduct}=="2013", MODE="0666" ```
Nach dem Speichern der Datei (CRTL & X // Y // ENTER) wird schließlich noch ein Reboot des Smart Home Servers durchgeführt.
sudo reboot
In FHEM:
define co20 CO20
attr co20 advanced 1
Zitat von: Jewe am 05 November 2022, 14:42:03
Das fehlt vmtl. noch:
Schließlich muss FHEM über einen UDEV-Eintrag noch die Rechte erhalten, um nachfolgend ebenfalls auf die Messwerte des Sensors zuzugreifen. Dazu wird mit folgendem Befehl eine neue Datei angelegt.
sudo nano /etc/udev/rules.d/99-usb.rules
Die Datei erhält anschließend den folgenden Inhalt:
SUBSYSTEM=="usb", ATTR{idVendor}=="03eb", ATTR{idProduct}=="2013", MODE="0666" ```
Nach dem Speichern der Datei (CRTL & X // Y // ENTER) wird schließlich noch ein Reboot des Smart Home Servers durchgeführt.
sudo reboot
In FHEM:
define co20 CO20
attr co20 advanced 1
Hallo Jewe,
das war ja das von vorhin und der reboot steht ja noch aus da gerade ein backup läuft.
das in fhem ist ja schon geschehen ;)
Zitat von: willybauss am 05 November 2022, 13:43:39
Wird er vom Raspi erkannt, oder auch von fhem? Oben lese ich, dass er in fhem "disconnected" ist. In der fhem config des Sticks muss ja ebenfalls der USB-Zugriffspfad definiert sein.
Ja Willybauss er wird vom Raspi erkannt und von Fhem noch nicht. Da fehlt zu 99% schonmal der reboot. Dann soll es ja laut dem modul-ersteller klappen. das von Jewe bzgl usb.rules war mir nicht mehr in erinnerung ;)
wie versprochen ich melde mich nochmal. Es wurde doch 6 uhr abends ;) aber ja ein reboot hat geholfen!!!!!