I2C Lichtsensor GY30 mit dem AD-Wandler BH1750FVI

Begonnen von schlawiano, 26 Mai 2016, 16:50:02

Vorheriges Thema - Nächstes Thema

schlawiano

Hallo

Nun ein weiterer Sensor für den I2C-Bus

Vll. jemand so ein Teil da und Lust zum Testen.

hier liegt das Datenblatt http://rohmfs.rohm.com/en/products/databook/datasheet/ic/sensor/light/bh1750fvi-e.pdf

Die Auflösung liegt von 1 - 65535 Lux

Unter Wikipedia https://de.wikipedia.org/wiki/Lux_(Einheit) gibt es eine nette Tabelle
mit Zuordnungen welcher Wertebereich ungefähr welchen Lichtszenario entspricht.


ich werde ihn benutzen um herauszufinden, ob im Wohnzimmer noch eine Lampe eingeschalten ist.
Sprich wenn Delta von Licht[Außen] und Licht[Wohnzimmer] negativ ist... brennt mit Sicherheit Licht,
bei positiven Delta ist natürlich keine sichere Aussage möglich  :o

Leider erlaubt er nur 2 I2C Adressen. Hier könnte man ggf. einen Multiplexer nutzen, aber die FHEM Umsetzung muss noch warten.

Über Anregungen, Hilfe , Fragen würde ich mich freuen.
Bei erfolgreichen Dauertest kommt er nächste Woche mit in den TRUNK.

Grüße Karsten



klausw

Im SVN gibt es jetzt 2 Module, die vermutlich nahezu das selbe machen:

51_I2C_BH1750.pm
52_I2C_GY30_BH1750FVI.pm

versucht das doch bitte in ein Einziges zu packen  8)
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

schlawiano

Ich war zwar erster  ;D, aber das andere Modul kann auch HiPi.

Also lösche ich meins und verwende es nur privat.

War trotzdem eine nette Anfänger-Übung...

Und danke für den Hinweis

Baut jemand gerade am Modul für den ADS1115 ? Dann würde ich mir ggf. die Entwicklung schenken

klausw

Zitat von: schlawiano am 30 Mai 2016, 14:47:51
Ich war zwar erster  ;D, aber das andere Modul kann auch HiPi.

Also lösche ich meins und verwende es nur privat.

wer ist mir egal  8)
aber das andere Modul hat wohl auch einen höheren Dynamikbereich

Zitat von: schlawiano am 30 Mai 2016, 14:47:51
Baut jemand gerade am Modul für den ADS1115 ? Dann würde ich mir ggf. die Entwicklung schenken

Schwierig zu sagen, am besten schonmal einen Thread dazu anlegen, falls die Forensuche nix zutage fördert.
Dann bringen sich evtl. Leute ein, die schon etwas geschrieben haben.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

arnoaugustin

Zitat von: schlawiano am 30 Mai 2016, 14:47:51
Ich war zwar erster  ;D, aber das andere Modul kann auch HiPi.

Also lösche ich meins und verwende es nur privat.

War trotzdem eine nette Anfänger-Übung...

...

Hi Karsten,

sorry, das hat sich echt überschnitten. Hät ich mir Arbeit sparen können (Auch wenns eher Spassarbeit war).
Ich habs erst gemerkt als Klaus mich drauf aufmerksam gemacht hat nachdem ich eingecheckt hab. Das lag scheinbar alles nur ein paar Tage auseinander. Daher sind die Module auch recht unterschiedlich im Inhalt Inhalt.
Ich hatte mir den Code auch nur gebastelt, weil der TSL2561 bei ca. 40k lux in die Sättigung geht und das Modul dann komische Werte geliefert hat.
Der BH1750 hat gestern den "volle Sonne drauf"-Test mit knapp 100k lux bestanden, während vom TSL2561 seltsame Werte kamen. Das automatische umschalten der Auflösungen funktioniert auch. HiPi hab ich noch nicht getestet, sollte aber eigentlich gehen, da aus anderen Modulen übernommen.

Ich hab eigentlich selber kein Problem mit zwei Modulen für einen Chip. Mich stört aber auch nicht, wenn jemand seine Änderungen ins 51_BH1750.pm einbringt. Ich kann mein Modul auch wieder raus nehmen (so was spart erfahrungsgemäß ja auch Zeit  ;) ).

Viele Grüße,

Arno

schlawiano

Hallo Arno,

in der Tat ein lustiger Zufall ;-) Naja, umsonst war die Arbeit sicher nicht. Deine  Idee mit der
automatischen Umschaltung der Auflösung finde ich Klasse. Bei mir lag der Schwerpunkt nur der Nutzbarkeit , Komfort... also nur ein paar Attribute mehr.

Wie wäre es wenn wir unsere Module zusammenlegen?
Entweder spendieren wir meinen Modul Deinen Auto-Resolution-Modus (vermutlich der geringere Aufwand) oder Deinem Modul mehr Komfort, Attribute. Was denkst Du ? Als Autor würden wir uns natürlich beide verewigen ;-)

HiPi konnte ich leider auch nicht testen. Bei mir bekam ich weder auf der Banane noch auf dem Raspi die Lib zum laufen. Ich glaube auch nicht, dass es gut wäre hier einfach mal HiPi in Eigenregie zu verwenden. Besser wäre es, wenn man die Kommunikation zum I2C über eine von FHEM gestellte API erfolgt.

Den TSL2561 wollte ich mir auch zulegen, da der BH1750 nur 2 I2C-Adressen unterstützt  Also ist er wohl doch eher nur für Innenräume geeignet - gut zu wissen 

Viele Grüße
Karsten

arnoaugustin

Zitat von: schlawiano am 02 Juni 2016, 09:17:55
Hallo Arno,

in der Tat ein lustiger Zufall ;-) Naja, umsonst war die Arbeit sicher nicht. Deine  Idee mit der
automatischen Umschaltung der Auflösung finde ich Klasse. Bei mir lag der Schwerpunkt nur der Nutzbarkeit , Komfort... also nur ein paar Attribute mehr.

Wie wäre es wenn wir unsere Module zusammenlegen?
Entweder spendieren wir meinen Modul Deinen Auto-Resolution-Modus (vermutlich der geringere Aufwand) oder Deinem Modul mehr Komfort, Attribute. Was denkst Du ? Als Autor würden wir uns natürlich beide verewigen ;-)

HiPi konnte ich leider auch nicht testen. Bei mir bekam ich weder auf der Banane noch auf dem Raspi die Lib zum laufen. Ich glaube auch nicht, dass es gut wäre hier einfach mal HiPi in Eigenregie zu verwenden. Besser wäre es, wenn man die Kommunikation zum I2C über eine von FHEM gestellte API erfolgt.

Den TSL2561 wollte ich mir auch zulegen, da der BH1750 nur 2 I2C-Adressen unterstützt  Also ist er wohl doch eher nur für Innenräume geeignet - gut zu wissen 〓

Viele Grüße
Karsten

Hi Karsten,
jo sehe ich auch so - macht spass sowas  :)
Man kann das gerne zusammen legen. Wo ist mir eigentlich egal.
Mir geht es eigentlich nur darum, dass das Modul die Lichtwerte holt. Automatisch für Logs etc. und händisch wenn man nur auf "Anfrage" welche braucht - die Werte sollen dabei so gut wie möglich über den gesamten Bereich dargestellt werden. Und das das Zeug muss anständig funktioniert. Nutzungseinsatz bei mir (wie bei vielen sicherlich auch): Lichtsensor für Rollosteuerung und evtl. Sonnenscheindauer für Wetterbeobachtung etc. mit automatischer. Oder eben Wert auf Anfrage um z.B. zu testen ob irgendwo licht an is etc.

Der TSL2561 hat im Vergleich mit meinem kommerziellen Luxmeter recht gut abgeschnitten, geht aber bei direkter Sonne sofort in die Sättigung. Da liefert das FHEM-Modul dann leider komische Werte anstatt den Maximalwert zu liefern und den Status auf Sättigung zu stellen.
Der 2561 hat 2 Dioden. Eine Infrarot und eine "normale" - wohl um den Infrarotanteil raus rechnen zu können und damit bessere LUX-Werte zu kriegen (die ja physiologisch definiert sind).
Der BH1750 umfasst den gesamten Tageslichtbereich inkl. direkter Sonnenstrahlung von 0.1 Lux bis über 1000000 Lux ist aber wie es aussieht nicht so genau.
Den BH1750 muss ich aber leider etwas "trimmen". Bei mir muss ich die berechneten Werte mit ca. 1,25 mal nehmen damit ich mit dem Lux-Meter und dem TSL2561 etwa gleich laufe (Dazu das Attribut "correction").
Mit der linearen Verschiebung kommt man dann ganz gut hin. Theoretisch kann man die Werte auch über eine Kalibrierungstabelle ziehen - so hab ich das mal für einen LDR gemacht den ich statt dem vorhandenen NTC in ein Funkthermometer gebaut hab. Aber wer hat schon Bock das Ding händisch zu kalibrieren, vor allem wenn er keine Möglichkeit hat das Tageslicht heller oder Dunkler zu drehen (Künstliche Lichtquellen liefern ja andere Ergebnisse).

Noch ein paar Anmerkungen zu Deinem Modul, weil ich gerade wegen zusammenführen mal rein sehe. Ich schreib einfach mal was mir auffällt:
In dem Modul sind noch sleeps drin z.B. im _Command und _InitDevice. Das blockiert FHEM, bzw. fehm steht dann einfach. Das ist besonders hart, wenn jemand z.B. über die GPIOs irgendwelche Zähler ausliest, da dann massiver Jitter entsteht. Das i2c senden/lesen muss korrekterweise über States asynchron bewerkstelligt werden. Die sleeps müssten raus.
Sättigung müsste noch abgefangen werden, bzw. müsste es dafür einen STATE geben, damit man mit einem Notify drauf reagieren kann, bzw. der Anwender weiß, dass der Sensor nicht weiter kann....
Falls man automatische Adaption verwendet muss man im Sättigungsfall nochmal lesen, da zwischen grob und dem fein Lesen dann der Lichtwechsel zu stark war (da müsste ich optimalerweise bei mir auch noch unterscheiden zw. grob und fein Lesen)
"get" zum update für die Werte ist nicht optimal, da get nicht wirklich bei asynchronem Lesen einen Wert zurück liefern kann und das viele Anwender verwirrt, da sie denken sie erhalten beim "get" den Wert zurück.
Bei I2C-Fehler muss evtl. mit Power-Down ein neues Lesen neu Aufgesetzt werden.
Ich bin mir nicht sicher, ob man das wirklich einfacher in Dein Modul einbauen kann.

Im Endeffekt macht das 51_BH1750.pm ja schon alles was man braucht:
Man kann den LUX-Wert per set updaten lassen und man kann automatisch Werte einlesen lassen. Wozu muss der Anwender noch mit den Modis rum machen? Als Anwender will von dem Sensor schließlich nur wissen wie Hell es ist und mich nicht mit dessen Internas beschäftigen - oder?
Die automatische Adaption im 51_BH1750.pm liefert auch immer Werte, die weit oberhalb der realen Genauigkeit des Sensors liegen, so dass es wenig Gründe geben sollte anders/spezieller auszulesen. Unter 5000 Lux wird z.B. immer mit der vom Sensor feinsten zur Verfügung gestellten Auflösung von 0.11 Lux gelesen. Da drüber sind es 0.5 Lux usw. usw. bis zum Grenzwert immer grober.
Real dürfte das Rauschen weit aus größer sein, so das der gesamte Bereich immer optimal abgedeckt ist.
Was meinst Du?

Evtl. sollte man den Thread hier nach Einplatinencomputer(da sind auch andere I2C-Module) verschieben, da das hier ja FHEM-Module und keine Codeschnipsel sind .

Viele Grüße,

Arno

klausw

da gebe ich auch noch bisschen Senf dazu ;)

HiPi ist in RPII2C schon implementiert, muss also nicht im Modul abgefrühstückt werden.
Ich würde es rausnehmen da überflüssig.
Es ist nur im BMP180 Modul drin, da dieses ursprünglich ein Standalone Modul war (es wurde nicht entfernt, da bestehende Installationen nach einem Update nicht mehr laufen würden).
...und im TLS ist es drin, da dieser eine Ableitung vom BMP180 Modul ist

51_I2C_BH1750.pm als Name (unabhängig vom Inhalt ;) ) ist beim Define schneller eingegeben und wäre meiner Meinung nach zu bevorzugen.

sleep hat neben der Blockierung von FHEM noch eine weitere Schwachstelle:
wenn der BH1750 z.B. über FRM angeschlossen ist und sich diese Modul wiederum über Netzwerk kommuniziert können die Übertragungszeiten entsprechend höher sein, oder auch Pakete in falscher Reihenfolge reinkommen. Bei asynchroner Übertragung, gibt es diese Probleme nicht. Wenn zwischen Auslösen der Messung und Abholung der Werte eine gewisse Zeit verstreichen muss, könnte man noch einen Timer verwenden.


RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

schlawiano

Hallo Arno, und Klaus... natürlich
Ihr habt recht , ein Sleep ist wirklich hart. Ich hatte mich an anderen Modulen orientiert, die aller Minuten mal den Sensorwert abfragen.

Arno's Variante den Polling-Timer noch mal neu darauf anzusetzen ist da weitaus eleganter.
(ich werde auch mein anderes Modul 52_I2C_HDC1008 dahingehend umbauen)

Ich denke auch wir lassen Dein Modul. Den Sensor-Modus hatte ich rein genommen, falls jemand doch mal Strom sparen will. Wozu sollten man den Sensor auch ungenutzt aktiv lassen.

Die Sache mit dem Delta sehe ich eher skeptisch, aber es ist ja abschaltbar.

Damit ist die Sache eigentlich schon durch. Wir belassen es bei Deiner Variante.
Ich werde meinen Quelltext die nächsten Tage aus dem SVN rausnehmen.

Viele Grüße
Karsten

arnoaugustin

#9
Zitat von: schlawiano am 02 Juni 2016, 13:26:39

Ich denke auch wir lassen Dein Modul. Den Sensor-Modus hatte ich rein genommen, falls jemand doch mal Strom sparen will. Wozu sollten man den Sensor auch ungenutzt aktiv lassen.

Die Sache mit dem Delta sehe ich eher skeptisch, aber es ist ja abschaltbar.
...
Der Sensor ist bei mir IMMER außer beim Auslesen im Powerdown-Modus.
Falls Du das "percentdelta" Attribut meinst: Wenn ich jede Minute etwas ins Log schreibe, dann gibt das recht große Logfiles. Wenn ich hier die Standardattribute event-on-change (oder so ähnlich, habs grad nicht im Kopf) verwende, dann nützt das praktisch nichts, da Änderungen in der letzten Stelle praktisch immer statt finden. Das Auge arbeitet aber auch mit relativen Lichtunterschieden und Änderungen unter 5% nimmt man sicher nur schwer wahr (Für Rollosteuerung, also durchaus zu gebrauchen). Wenn das Attribut nicht oder auf 0 gesetzt ist, dann wird ja auch jeder Wert als Reading generiert. 

schlawiano

Damit sollte das Thema jetzt durch sein.

Ich habe was neues dazu gelernt (die Sache mit dem Timer)... Aus der Sicht war die Diskussion gar nicht verkehrt.
Der Auto-Resolution-Modus gefällt mir.
event-on-Change wäre bei mir durch die Rundungsmöglichkeit möglich gewesen. Dein Delta ist sicher auch nutzbar.
Das mit dem One-Modus in Deinem Modul hatte ich übersehen. Damit wären wohl auch die meisten Fälle abgedeckt.
Und falls jemand doch mal den schnelleren Continuous-Modus nutzen möchten (z.B. um schnellere Lichtwechsel zu erkennen),
liegt der Quelltext ja offen.

Und damit zurück zum Eingangssatz... ;-)

arnoaugustin

Zitat von: klausw am 02 Juni 2016, 12:36:04

HiPi ist in RPII2C schon implementiert, muss also nicht im Modul abgefrühstückt werden.
Ich würde es rausnehmen da überflüssig.

Hi Klaus,
Danke für die Info.
Hab HiPi aus dem Modul raus geworfen und noch etwas aufgeräumt.

VG
Arno