LPD Geschrieben August 9, 2015 at 22:15 Geschrieben August 9, 2015 at 22:15 Hi, ich habe seit 2 Tagen das neue Ambient Light V2 Bricklet für meine Wetterstation eingesetzt. Der Sensor soll die Sonnenlichtintensität messen, daher habe ich ersteinmal den größtmöglichen Bereich (64000lx) und eine möglichst große Integrationszeit (400ms) gewählt. Eigentlich klappt auch alles wie es sollte, nur scheinen Werte oberhalb von 38070.90 Lx nicht dargestellt zu werden (siehe Anhang: Graph ist nach oben abgeschnitten...). Ich vermute den Fehler bei der Einstellung des Verhätnisses Messbereich/Integrationszeit - welche Werte würdet Ihr nehmen bzw. empfehlen? Zitieren
Nic Geschrieben August 10, 2015 at 08:57 Geschrieben August 10, 2015 at 08:57 Wenn du viel Licht erwarten kannst, würde ich die Integrationszeit niedrig halten. Je weniger Licht desto eher Erhöhung der Integrationszeit, damit das Rauschen verringert wird. Ähnlich dem Sensor einer Digitalkamera. Zitieren
photron Geschrieben August 11, 2015 at 13:18 Geschrieben August 11, 2015 at 13:18 Nic beschreibt das schon richtig. Mit höheren Integrationszeiten verringert sich das Rauschen, aber du kannst nicht mehr unbedingt denn vollen Messbereich abdecken. Ich füge dazu gleich noch einen Hinweis in die API Dokumentation ein. Da war allerdings auch noch ein Problem im Plugin des Bricklets, dass zu falschen Messwerten führen konnte, wenn der Sensor aufgrund zu langer Integrationszeiten gesättigt war. Flashe bitte mal über Brick Viewer das angehängt korrigierte Plugin auf das Bricklet und teste mal mit 50ms oder 100ms als Integrationszeit.ambient-light-v2-bricklet-2.0.1-rc1.bin Zitieren
LPD Geschrieben August 13, 2015 at 21:37 Autor Geschrieben August 13, 2015 at 21:37 Hallo, vielen Dank ersteinmal für die Hilfe. Ich hab' natürlich gleich Nic's Rat umgesetzt und die Integrationszeit auf 100ms herabgsetzt. Das Ergebnis ist wirklich besser geworden (vgl. Graph1) Nach dem Aufspielen von Protons Update habe ich aber Aussetzer (bei 100ms) - siehe Graph2 ?! Anhand der Anzahl der Downloads haben anscheinend auch andere dieses Update ausprobiert - hat noch jemand Probs mit Aussetzern? Ich werde morgen nocheinmal mit dem gleichen Wert aufzeichnen - vielleicht hat ja nur ein Vogel mein Gehäuse schön gefunden ... Zitieren
photron Geschrieben August 14, 2015 at 17:16 Geschrieben August 14, 2015 at 17:16 Ich hab heute mal den ganzen Tag eine Messreihe laufen lassen. Alle 5 Sekunden abgefragt und ich kann keine Aussetzer feststellten. Es war heute aber auch nicht sonnig. Maximal 10000 Lux gabs. Zitieren
LPD Geschrieben August 14, 2015 at 19:25 Autor Geschrieben August 14, 2015 at 19:25 Nun, der heutige Graph sieht zwar auf den ersten Blick etwas besser aus, alledings kann ich hier auch wieder Einbrüche erkennen, speziell wenn die Werte großen Schwankungen ausgesetzt sind - schade. Vielleicht messe ich ja einfach nur zu häufig (1/min) und die Übertragung mit den anderen Werten (Temperatur, Feuchte) über POE auf einen Raspi dauert einfach zu lange ... Zitieren
photron Geschrieben August 17, 2015 at 11:39 Geschrieben August 17, 2015 at 11:39 Diese Lücken in den Graphen sind mir nicht klar. Zeichnet das Tool keinen durchgehenden Graph, sondern nur Punkte? Oder sind die Lücken absichtlich da? Kannst du mal dein Skript zeigen, dass die Daten abfragt und in die RRD Datei packt? Einmal pro Minute 3 Werte messen sollte überhaupt kein Problem sein. Fragst du die Daten per GetIlliminance() ab? Behandelt dein Script Fehler die der GetIlliminance() Aufruf haben kann, z.B. Timeout? Das einzige was ich in Firmware 2.0.1 geändert habe ist die Behandlung ungültiger Werte vom Sensor. Firmware 2.0.0 hat versucht die zu verwenden und hat dann potentiell falsche Ergebnisse geliefert. Das war der Grund warum deine erste Messreihe mit 64000 Lux Messbereich und 400 ms Integrationszeit bei 38070 Lux stecken geblieben ist. In 2.0.1 werden ungültige Werte jetzt ignoriert. Dass heißt, wenn der Sensor in Sättigung läuft, weil der Messbereich zu klein und/oder die Integrationszeit zu lang ist, dann liefert das Bricklet so lange den letzten gültige Messwert bis der Sensor wieder gültige Werte liefert. Zitieren
LPD Geschrieben August 21, 2015 at 17:40 Autor Geschrieben August 21, 2015 at 17:40 Hallo photron, sorry, wenn ich erst jetzt antworten kann: Kannst du mal dein Skript zeigen, dass die Daten abfragt und in die RRD Datei packt? Gerne: Die Daten werden minütlich mittels crontab abgeholt, ein Graph wird alle 15 Minuten erstellt. Hier sind folgende Zeilen eingetragen: [...] * * * * * /home/lpd/aussenwerte.sh > /home/lpd/aussenwerte.lst 2>&1 */15 * * * * /home/lpd/helligkeitsgraph.sh Das shellscript aussenwerte.sh sieht so aus: #!/bin/bash HOST=192.xxx.yyy.zzz UID_MASTER=1ABcdE UID_TEMPERATURE=aBc UID_HUMIDITY=dEF UID_AMBIENTLIGHT=gHi OutsideTemperature1=$(/usr/local/bin/tinkerforge --host $HOST call temperature-bricklet $UID_TEMPERATURE \ get-temperature --execute "echo 'scale=2; {temperature} / 100' | bc | xargs printf '%.1f\n'| tr ',' '.'") OutsideHumidity1=$(/usr/local/bin/tinkerforge --host $HOST call humidity-bricklet $UID_HUMIDITY \ get-humidity --execute "echo 'scale=2; {humidity} / 10' | bc | xargs printf '%.1f\n'| tr ',' '.'") OutsideLuminance1=$(/usr/local/bin/tinkerforge --host $HOST call ambient-light-v2-bricklet $UID_AMBIENTLIGHT \ get-illuminance --execute "echo 'scale=2; {illuminance} / 100' | bc | xargs printf '%.1f\n'| tr ',' '.'") /usr/bin/rrdtool update aussenwerte.rrd N:$OutsideTemperature1:$OutsideHumidity1:$OutsideLuminance1 echo "Temperatur: $OutsideTemperature1 °C" echo "Feuchte: $OutsideHumidity1 %Rh" echo "Helligkeit: $OutsideLuminance1 lx" ... in der Datei aussenwerte.lst stehen dann die letzten Werte und/oder Fehlermeldungen drin, z.B.: Temperatur: 24.8 °C Feuchte: 37.2 %Rh Helligkeit: 16284.9 lx Für die Erstellung der Graphen hab ich folgendes Script (helligkeitsgraph.sh) #!/bin/sh rrdtool graph TagesHelligkeit.gif \ --start end-1d \ --vertical-label "lx" \ -w 1200 -h 400 \ --title "Tages-Aussenwerte Helligkeit" \ DEF:l1=aussenwerte.rrd:helligkeit:AVERAGE \ DEF:l1min=aussenwerte.rrd:helligkeit:MIN \ DEF:l1max=aussenwerte.rrd:helligkeit:MAX \ VDEF:l1durch=l1,AVERAGE \ VDEF:l1a=l1,LAST \ VDEF:lmina=l1min,MINIMUM \ VDEF:lmaxa=l1max,MAXIMUM \ LINE3:l1#00ff00:"Helligkeit\n" \ GPRINT:l1a:"aktuell\: %5.2lf lx\n" \ GPRINT:l1durch:"Durchschnitt\: %5.2lf lx\n" \ GPRINT:lmina:"tiefste\: %5.2lf lx\n" \ GPRINT:lmaxa:"höchste\: %5.2lf lx\n" \ > /dev/null Mehr mache ich derzeit nicht - hat ja auch bisher (mit dem 'alten' Bricklet) prima geklappt. Bestimmt hab' ich aber noch einen Anfängerfehler drin - ich lerne gerne dazu ;-) Der Graph von heute sieht übrigens richtig mies aus: auch hier gibt's wieder ein riesen-gap (s.Anhang) Zitieren
photron Geschrieben August 24, 2015 at 09:56 Geschrieben August 24, 2015 at 09:56 Verstehe ich die Graphen richtig, dass da zwischen ca 15:30 und 16:00 Uhr und kurz nach 18:00 Uhr einfach Daten fehlen? Warum da ab 13 Uhr so ein glatter Einbruch drin ist, ist mir nicht klar. Ich habe deine Script jetzt mal genommen und lasse sie hier gerade mit 2 Bricklets laufen. Eines mit Plugin 2.0.0 und eines mit Plugin 2.0.1. Bei sind auf 64000 lx und 50 ms eingestellt. Ich lasse allerdings cron nach aussenwerte.lst mit ">>" statt ">" schreiben, damit ich später auch noch ältere Fehler sehen kann. Bisher läuft es. Zitieren
LPD Geschrieben August 25, 2015 at 16:40 Autor Geschrieben August 25, 2015 at 16:40 Hi, ich hab' mir nocheinmal alle Graphen angeschaut - ich glaube ich habe die Ursache des Problems gefunden.... Eine zyklische Wiederholung schliesse ich aus, da die Ausfälle willkürlich stattfinden und in keinem direkten zeitlichen Zusammenhang stehen. Da die Graphen der Temperatur, der Feuchte und die des Version1-AmbientLight-Sensors (seit Messbeginn vor ca. einem Jahr) keine Lücke aufweisen, gehe ich auch nicht von einem "Übertragungsfehler" aus. Auffallend ist jedoch, daß kurz vor jeder "Lücke" die Lichtwerte sehr hoch waren - d.h. die Sonneneinstrahlung dementsprechend auch ... ... ich vermute dass das Bricklet im direkten Sonnenlicht extrem warm wird und sich daher einfach kurzzeitig "verabschiedet". Begründen läßt sich die Vermutung damit, daß die heutige Kurve (bis jetzt) keine Unterbrechungen aufweist - die Außentemperatur ist ja auch längst nicht mehr so hoch wie in den letzten Wochen ... oder? Wie hoch darf denn die maximal zulässige Betriebstemperatur bei dem Bricklet sein? LG, LPD Zitieren
LPD Geschrieben August 25, 2015 at 16:43 Autor Geschrieben August 25, 2015 at 16:43 ... oha, während des Schreibens gab's wieder "Schluckauf" Ist ja auch wieder schön warm ... LG, LPD Zitieren
photron Geschrieben August 26, 2015 at 07:53 Geschrieben August 26, 2015 at 07:53 Mein Test hier läuft bisher ohne Probleme. Der Aufbau steht aber nicht ideal und bekommt nicht die maximale Sonne mit. Der Sensor auf dem Ambient Light v1 ist im Datenblatt bis +85°C angegeben, der des Ambient Light v2 bis +70°C. Möglich, dass die 15°C Differenz hier den Unterschied machen, aber ich glaube es nicht. Ist das Ambient Light v2 am gleiche Master Brick angeschlossen, wie die anderen Bricklets deren Graphen keine Lücken aufweisen? Kannst du mal in deinem crontab hier das > durch >> ersetzen und in aussenwerte.sh am besten auch noch date mit ausgeben? /home/lpd/aussenwerte.sh > /home/lpd/aussenwerte.lst Mich interessiert, ob zu den Zeiten an denen du Lücken im Graph hast die Shell Bindings Fehler/Timeouts melden. Zitieren
photron Geschrieben August 26, 2015 at 08:20 Geschrieben August 26, 2015 at 08:20 Ich habe hier ein Ambient Light v2 gerade mal 5 Minuten lang mit 200°C Heißluft warm gemacht, keine Probleme. Ich versucht mal meinen Testaufbau hier mehr Sonne auszusetzen. Zitieren
Loetkolben Geschrieben August 26, 2015 at 13:31 Geschrieben August 26, 2015 at 13:31 Vielleicht ist die UV Strahlung das Problem? Ist der Sensor zum Messen von (starkem) Licht oder zum messen von SONNENlicht (inkl. UV Strahlung) ausgelegt? Wuerde eine UV Filterfolie helfen? Liegt der Sensor hinter einer Scheibe? Filtert diese die UV-Strahlung? <Spass> Koennte ein Tropfen Nivea helfen? </Spass> Der Loetkolben Zitieren
photron Geschrieben August 26, 2015 at 14:52 Geschrieben August 26, 2015 at 14:52 Das Datenblatt des Sensors schweigt sich über UV aus. Das erste Bild ist von einem der zwei Ambient Light 2.0 Bricklets, die hier schon seit Montag messen. Heute morgen habe ich sie nach draußen gestellt und zu Mittag waren sie direkt in der prallen Sonne. Keine Probleme. Das zweite Bild ist von einem weiteren Ambient Light 2.0 Bricklet, dass ich zur Westseite hinter ein Fenster gestellt habe. Die ersten beiden stehen an der Ostseite und sind jetzt mehr im Schatten. Dieses steht aber gerade in der vollen Sonne, allerdings hinter einer Fensterscheibe. Auch hier bisher keine Probleme. Ich glaube mein RRD ist etwas unglücklich eingestellt, was zu diesen etwas "eckigen" Graphen führt. Zitieren
LPD Geschrieben August 27, 2015 at 22:33 Autor Geschrieben August 27, 2015 at 22:33 Hallo photron, Hallo Loetkolben, photron: Kannst du mal in deinem crontab hier das > durch >> ersetzen und in aussenwerte.sh am besten auch noch date mit ausgeben? Hab ich gerade gestartet und gegengecheckt: Aufzeichnung läuft inklusive Datum und Zeit... Ich werde morgen Abend das Log mal durchschauen und "Auffälligkeiten" posten. photron: Ist das Ambient Light v2 am gleiche Master Brick angeschlossen, wie die anderen Bricklets deren Graphen keine Lücken aufweisen? Jep - Aufbauschema findest Du im Anhang Loetkolben: Liegt der Sensor hinter einer Scheibe? Filtert diese die UV-Strahlung? Der Sensor liegt unmittelbar hinter einem ca. 1mm dicken Stück Plexiglas (ohne Filter - siehe Foto im Anhang). Soviel ich weis läßt Plexiglas weniger UV durch als Glas, bei der Dicke würde Nivea wohl eher helfen Ich melde mich morgen wieder, Grüße aus Weilrod, LPD Zitieren
kreaktiv Geschrieben August 28, 2015 at 12:32 Geschrieben August 28, 2015 at 12:32 Beim anlegen der RRD definierts du min. und max. Werte für jeden Kanal. Sind dise ausreichen definiert? Oder teile mal deine Messwerte durch 10. Vielleicht hilft es. Zitieren
LPD Geschrieben August 28, 2015 at 19:27 Autor Geschrieben August 28, 2015 at 19:27 Hi, na jetzt aber: wie erhofft gab es im Graphen wieder Ausssetzer (siehe Anhang) Geschätzt hatte ich so ca. 15:30 Uhr für den Ersten - also ab ins Logfile uns siehe da: keine Fehlermeldungen oder irgendwelche "Ungewöhnlichkeiten". Beim genaueren Hinsehen wurde ich dann doch stutzig: wie sehen denn die Werte aus: um 15:32 Uhr hatte ich für 3 Minuten Werte von 66430 lx !?! Hier liegt also das Problem: Beim Ambient Light v1 konnte der Wert nicht größer als 800lx werden - daher bin ich bei der Version 2 auch davon ausgegangen (-> Datenblatt: bis 64000lx). Wie kreaktiv schon richtig angemerkt hat: ich habe natürlich als obersten Grenzwert 64000 beim Anlegen der RRD angegeben.... Die RoundRobin-Datenbank hat völlig richtig gearbeitet und Werte außerhalb dieser Grenze als Fehlerwert interpretiert und verworfen -> daher auch keine "Punkte" im Graphen. Ich werde den Wert jetzt mal auf 80000 erhöhen - die Aussetzer sind nun bestimmt weg .... Vielen, vielen Dank - ohne Euch würde ich immer noch im Trüben fischen. Aber woher diese hohen Werte ? Grüße aus dem Hochtaunuskreis, LPD Zitieren
Loetkolben Geschrieben August 28, 2015 at 20:36 Geschrieben August 28, 2015 at 20:36 Na so was. Im Datasheet wird von "Full dynamic range from 0.01 lux to 64k lux" gesprochen. (bei 16 bit Aufloesung) Das koennten dann auch 65535 lux sein. Das Bricklet hat fuer die Lichtstaerke einen 32bit Wert. (uint32) Warum wird der eigentlich Wert als 16bit Wert nicht durchgereicht? Aus der Doku: "Gibt die Beleuchtungsstärke des Umgebungslichtsensors zurück. Der Wertbereich ist von 0 bis 6400000 und ist in Lux/100 angegeben, d.h. bei einem Wert von 45000 wurde eine Beleuchtungsstärke von 450Lux gemessen." Muss es nicht "... und ist in Lux * 100 angegeben ..." heissen? Wie du aber auf deine "66430" lux kommst kann sicherlich der Programmierer der Brickletsoftware an schnellsten beantworten. Ich vermute mal eine " *1024/1000 " Operation in der Software oder einen Tippfehler bei dir ;-). Der Loetkolben Zitieren
LPD Geschrieben August 30, 2015 at 10:22 Autor Geschrieben August 30, 2015 at 10:22 Hi, ... also den Rechtschreibfehler schliesse ich aus ! (die Log-Datei und der Graph waren wohl zu gross - daher fehlte der "rettende" Anhang ..) Jetzt aber: Ich hab meine RRD mit neuen Grenzen versehen (uG: 0.00lx, oG:100000lx) und mittels Logfile die Werte von gestern aufgezeichnet (und auf's Wesentliche gekürzt): Auffallend sind die Stellen, an denen Petrus das Sonnenlicht "ausgeknipst" hat (0 lx von 14:30 bis 14:45Uhr und 15:42 bis 16:11Uhr) und die maximalen Messwerte von 75026.8 lx um 15:01 bis 15:04 Uhr ... ... hier fehlt mir jede Erklärungsidee. aussenwerte29_08.lst Zitieren
Loetkolben Geschrieben September 4, 2015 at 12:33 Geschrieben September 4, 2015 at 12:33 Gibt es eigentlich schon einen Hinweis darauf, warum die Werte > 75.000 steigen koennen? Der Loetkolben Zitieren
photron Geschrieben September 4, 2015 at 14:52 Geschrieben September 4, 2015 at 14:52 Loetkolben: Der Sensor verwendet einen 16 Bit 2-Kanal ADC. Dies beiden 16 Bit Werte sind aber nicht in Lux, sondern müssen noch nach einer bestimmten Formel mit einander verrechnet werden um den endgültigen Messwert in Lux/100 zu erhalten. Daher mach es keinen Sinn die 16 Bit Rohdaten des Sensors durchzureichen. Lux/100 sind schon richtig. Das Bricklet gibt den Wert in hundertstel Lux an (Lux/100). Du musst ihn als durch 100 Teilen um einen Wert in Lux zu bekommen. Bezüglich der 64k Lux Grenze: Die ist nicht hart. Der Sensor kann bis zu 150% darüber messen, sprich bis zu ca. 100k Lux. Allerdings nimmt ab 64k Lux die Genauigkeit ab. Da ist kein Fehler diesbezüglich in der Firmware des Bricklets. Allerdings ist die Dokumentation nicht ganz vollständig an der Stelle. Ich habe das nun korrigiert. Zitieren
photron Geschrieben September 4, 2015 at 15:00 Geschrieben September 4, 2015 at 15:00 LPD, ich nehme mal an dein Skript würde nicht 0 ins RRD eintragen, wenn der Sensor nicht wirklich 0 geliefert hat. Ich hatte hier einen einwöchigen Test mit 3 Bricklets laufen, keine Probleme. Ich hatte sie allerdings nicht in einem geschlossenen Gehäuse wie du. Es besteht also die Chance, dass es dem Bricklet in deinem Gehäuse zu warm wird. Die Möglichkeit kann ich nicht ausschließen. Abgesehen davon gehen mir die Ideen aus. Was ich dir anbieten kann, ist dir ein neues Ambient Light Bricklet 2.0 zu zuschicken, um zu sehen ob das einen Unterschied macht. Melde dich dafür mit deiner Bestellnummer bei info@tinkerforge.com und verweise auf den Thread hier. Zitieren
photron Geschrieben September 16, 2015 at 15:15 Geschrieben September 16, 2015 at 15:15 Es gibt jetzt Plugin 2.0.2 für's Ambient Light Bricklet 2.0. Darin wird zwar nicht das aktuelle Problem dieses Threads gelöst, da es noch nicht ergründet wurde, aber es geht mehr oder weniger noch mal um das Problem, das ich schon in Version 2.0.1 angegangen habe (Sensor ist gesättigt) und um den Messbereich des Bricklets. Daher will ich das hier kurz erläutern. Wenn es viel heller als der eingestellt Messbereich ist oder die Integrationszeit zu hoch eingestellt ist für die aktuelle Helligkeit, dann kann der Sensor gesättigt sein. In diesem Fall hatte Plugin 2.0.0 versuch den Wert des gesättigten Sensors noch zu verwenden was zu falschen Ergebnissen führte. Das war das initiale Problem in diesem Thread. In Plugin 2.0.1 wurden dann im Fall eines gesättigten Sensors, dessen Messwerte ignoriert und der letzte noch gültige Werte wurde weiterhin vom Bricklet gemeldet. Das löste das Problem der falschen Werte, machte es dem Nutzer aber nicht einfach zu erkennen, dass der Sensor in Sättigung war und eigentlich die Konfiguration hätte geändert werden sollen. Stattdessen sah es so aus, als ob sich die Helligkeit nicht ändern würde. Zusätzlich war es schon seit Plugin 2.0.0 so, dass das Bricklet Werte außerhalb des eingestellten Bereichs zurückliefern konnte. Das ist bedingt dadurch, dass der Sensor ca. 150% über den eingestellten Bereich hinaus messen kann. Allerdings mit abnehmender Genauigkeit. Auch das hat hier im Thread Probleme gemacht. Wir haben uns darüber jetzt noch mal Gedanken gemacht. In Plugin 2.0.2 liefert das Bricklet jetzt 0,00 Lux zurück, wenn der Sensor in Sättigung ist. Wenn er nicht gesättigt ist, ist der minimale Wert jetzt 0,01 Lux. Dadurch kann der Nutzer jetzt direkt erkennen, ob der Sensor in Sättigung ist und entsprechend reagieren. Die Messwerte werden jetzt auf den eingestellten Messbereich +0,01 Lux beschränkt. Wenn der Messbereich also auf 0-8000 Lux eingestellt ist und das Bricklet 8000,01 Lux meldet, dann ist der wirkliche Messwert höher als 8000 Lux und der Messbereich sollte umgestellt werden. Da der 0-64000 Lux Bereich jetzt wirklich nur noch bis 64000 Lux ausgibt, gibt es einen zusätzlichen unbeschränkten (unlimited) Messbereich, der bis zum absoluten Maximum (ca. 100000 Lux) des Sensors messen kann, wobei in diesem Bereich über 64000 Lux allerdings die Genauigkeit abnimmt. Zitieren
Loetkolben Geschrieben September 16, 2015 at 16:32 Geschrieben September 16, 2015 at 16:32 Uih, das ist ja viel Neues. Sicherlich habe ich noch viele Fragen, aber eine moechte ich hier selbst beantworten. Was sind 100.000 Lux? Antwort von hier: Beleuchtungsstärke Lux (lx=lm:m²) Lichtverhältnis: Beleuchtungsstärke: Mittagssonnenlicht im Sommer 100.000 Lux Bedeckter Himmel im Sommer 10.000 Lux Regenwetter mit dunklen Wolken 1000 Lux Bürobeleuchtung 500 Lux Wohnzimmerbeleuchtung 200 Lux Treppenhausbeleuchtung 100 Lux Straßenbeleuchtung 10 Lux Dämmerlicht nach Sonnenuntergang 1 Lux Mitternacht bei Vollmond 0,2 Lux Mondloser Sternenhimmel bei Nacht 0,0005 Lux Wenn das nicht passen/stimmen sollte bitte ich um Korrektur. Der Loetkolben Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.