Firmata mit TSL2561

[thymjan]

Hallo Jens,

hab die RC2-Modul-Version jetzt mit RPII2C und FRM-Ethernet-Arduino am Laufen. Bericht folgt.
Danke für die schnelle Änderung!

Grüße,
Stefan

p.s. floatArithmetics verändert doch nur die Genauigkeit der Berechnung, oder? Verändern sich dadurch die Werte von IR, Broadband oder Luminosity wirklich deutlich?

[jensb]

Hallo Stefan,

die "klassische" Berechnung ohne Float-Werte stammt vor Arduino-Quellcode, auf dem das FHEM-Modul z.T. basiert. Ein RPi hat aber deutlich mehr Rechenleistung und da macht die Integer-Approximation nicht viel Sinn. Die Genauigkeit mit Float-Werten ist etwas besser, z.B. bei geringer Helligkeit um 1 lux. Probier es einfach mal aus.

Grüße,
Jens

[thymjan]

Hallo Jens,

bis jetzt habe ich keine Mess- bzw. Übertragungsfehler mehr gehabt (sowohl mit Arduino Ethernet-ConfigurableFirmata als auch am I2C vom Raspi direkt).
Läuft jetzt zuverlässig, prima!

Die Float-Berechnung habe ich zum Testen ausgestellt. Dann scheinen die Werte aber nicht mehr normiert zu sein. Es ergeben sich erheblich größere Ganzzahlwerte. Ist das so gewollt?

Grüße,
Stefan

[jensb]

Hallo Stefan,

wenn du floatArithmetics abstellst, werden die Readings broadband und ir immer noch normiert, allerdings ohne Dezimalzahlen-Berechnungen, also wird faktisch immer mit verschiedenen Ganzzahlen multipliziert. Die normierten Werte sind also nicht direkt vergleichbar, wenn man zwischen mit bzw. ohne Float-Berechnung umschaltet. Die ohne Float-Berechnung sind absolut gesehen größer. Vielleicht sollte ich das noch in einem Nebensatz in der Modul-Hilfe beschreiben. Die Berechnung ohne Float-Werte ist aus meiner Sicht ohnehin nur noch zur Abwärtskompatibilität vorhanden.

Habe mich schon mit Kai abgestimmt und würde diese Version gern einchecken. Was mir für die Freigabe der Version allerdings noch fehlt ist ein Test mit direkter Anbindung z.B. über RPII2C, den ich bei mir momentan nicht machen kann, da ich alles elektromechanisch auf Firmata umgebaut habe - müsste mir erst noch eine 40polige Pfostenleiste für das Breakout bestellen . Könntest du das vielleicht testen?

Grüße,
Jens

[thymjan]

Hallo Jens,

wie schon gesagt habe ich bei mir auch einen TSL2561 mit RPII2C direkt am Raspi am Laufen. Klebt auf unserem Vogelhäuschen...

Keine Lesefehler, AutoIntegrationTime und AutoGain scheint auch zu funktionieren (siehe Anhang).
Also von meiner Seite: Klasse Arbeit, grünes Licht!

Grüße,
Stefan

[jensb]

Hallo Stefan,

danke fuer die Rueckmeldung, dass ist super . Damit wird diese Version wahrscheinlich ab dem Wochenende auch per Update verfuebar sein.

Deinen Plot finde ich auch sehr interessant. Schade dass ich den so nicht direkt mit meinem vergleichen kann, da ich eine logarithmische Korrektur vor der Darstellung mache, um gerade im Daemmerungsbereich den Plot auseinanderzuziehen - dafuer passiert dann nicht mehr viel, wenn die Sonne mal so richtig seint.

Gruesse,
Jens

[thymjan]

Hallo Jens,

Logarithmus habe ich bei mir auch eingebaut. Den Multiplikator habe ich jedoch frei Schnauze so gewählt, so dass das Maximum jeweils unter 100 bleibt:
- birddb:TSL2561:broadband:::$val=($val&&6.7*log($val))
- birddb:TSL2561:ir:::$val=($val&&6.7*log($val))
- birddb:TSL2561:luminosity:::$val=($val&&6.7*log($val)+17.303)
- birddb:TSL2561:gain:::$val=($val&&$val)
- birddb:TSL2561:integrationTime:::$val=($val&&100*$val)

Gruß,
Stefan

[jensb]

Hallo Stefan,

im Endeffekt habe ich es mir auch nur so zurecht gebogen, dass es in den Plot passt:

luminosity: $fld[4]&&7*(log($fld[4])+2.303)
ir (normiert):$fld[6]/10000

Dadurch, dass ich ir nicht logarithmisch darstelle, kann ich besser erkennen, wann mal wieder richtig die Sonne scheint.

Gruesse,
Jens

[thymjan]

Habe mittlerweile den Sensor per homebridge ins apple homekit integriert. Hier wird bei Dunkelheit der Wert 0 (absolute Dunkelheit) als Sensor-Fehler interpretiert. Müssen wir hier nachbessern (minimaler Wert 0,0001 lux)?

[jensb]

Hallo Stefan,

bin kein Physiker, aber nach meiner Vorstellung beträgt die Luminanz spätestens dann 0 lux, wenn sich in einem Raum keine Photonen mehr bewegen, z.B. bei 0 K. Diese Fall ist natürlich ziemlich theoretisch, lässt sich aber wahrscheinlich auch künstlich herstellen. 0 lux ist physikalisch also ein möglicher und damit zulässiger Wert, auch wenn Apple das nicht so sieht. Betrachtet man andererseits reales Umgebungslicht, wird man 0 lux nirgendwo auf unserer Erde finden. Wie klein die Werte werden können, kann ich nicht sagen, aber es hängt wahrscheinlich auch davon ab, wie weit man in die Wüste geht bzw. auf einen Berg steigt. Schließlich gibt es noch den Aspekt der Helligkeitssensoren selbst. Die liefern ein Signal, dass mit abnehmender Helligkeit immer kleiner wird. Dieses Signal muss von einer Elektronik erfasst werden, die einen endlichen Preis kosten soll und damit eine kleinste minimale Auflösung zur Verfügung stellt. Da es ja immer noch ein klein bisschen dunkler geht, bleibt halt unterhalb der Schwelle für die kleinste Auflösung nur der Messwert 0 lux - alles andere wäre geraten und nicht gemessen.

Mein Vorschlag: Wenn es Apple stört, dann verwende ein User-Reading, das für 0 lux einen Offset aufaddiert, damit kein Sensor-Fehler gemeldet wird. Eine Änderung am TSL2561-Modul wäre dafür nicht sinnvoll.

Grüße,
Jens

[thymjan]

Hallo Jens,
danke für Deine Antwort. Was ich sagen will (lassen wir apple mal außen vor), ist, dass wir durch die fixen Nachkommastellen am unteren Ende der Skala die weitere Differenzierung unter den Tisch fallen lassen.

Siehe Tabelle Wikipedia:

Wohnzimmer[6]   50 lx
Straßenbeleuchtung   10 lx
Kerze ca. 1 Meter entfernt   1 lx
Vollmondnacht   0,25 lx
Sternklarer Nachthimmel (Neumond)   0,001 lx
Bewölkter Nachthimmel ohne Mond und Fremdlichter   0,00013 lx

Ich denke, dass der Sensor im "dunklen Bereich" durchaus noch sinnvolle Werte messen kann.
Wir schöpfen ja auch die ganze Bandbreite durch Anpassung der Belichtungszeit und des Verstärkers aus, nur um dann mit dem Komma alles wegzuschneiden und auf 0 zu setzen. Das ist eigentlich schade.

Physik ist bei mir auch schon lange her, aber da gab's doch was mit den ersten verlässlichen Dezimalstellen in der Notation x,xxx * 10^y. Ich komme gerade leider nicht mehr auf die Fachbegriffe.

Kannst Du da mit?

Pragmatisch könnte man einfach 5 Nachkommastellen mit angeben.

Messtechnisch korrekt nach der 4. gültigen Ziffer runden (irgendwie so war das meine ich).

Gruß,
Stefan

Edit: die "signifikanten Stellen" waren das. Bei der Zahl 0 die der Sensor ausgibt habe ich die signifikanten Stellen alle weggeschnitten.

[jensb]

Hallo Stefan,

der TSL2561 ist für derartige Differenzierungen im unteren Bereich nicht geeignet. Das steht auch so ganz oben in der Modul-Hilfe:

The luminosity value returned is a good human eye reponse approximation of an illumination measurement in the range of 0.1 to 40000+ lux (but not a replacement for a precision measurement, relation between measured value and true value may vary by 40%).

Rein rechnerisch kann man mit "floatArithmetics=1" als kleinsten Wert 0.0304 lux erhalten (siehe Modul-Sourcen I2C_TSL2561_CalculateLux bzw. Sensor-Datenblatt) und natürlich ein Vielfaches davon. Aber in diesem Bereich hat das nichts mit Genauigkeit zu tun (u.a. wegen der oben erwähnten 40 % Toleranz), daher ist der kleinste vom Modul ausgegebenen Wert von 0.1 lux schon grenzwertig.

Als die Option "floatArithmetics" eingeführt wurde, ging der Wunsch genau in die andere Richtung, nämlich nach weniger Nachkommastellen (siehe Änderungseintrag in den Modul-Sourcen vom 22.03.2015). Die jetzige Lösung ist der beste Kompromiss, den ich finden konnte. Die andere Variante wäre, dass man immer den mathematisch berechneten Wert ausgibt und das Runden einem User-Reading überlässt. Das sorgt aber dafür, das sich zwei aufeinander folgende Raw-Readings immer unterscheiden, da die Messung rauschempfindlich ist.

Eine prinzipielle Änderung am Modul halte ich daher nicht für sinnvoll (aber ich lass mich da gern überstimmen). Du kannst aber eine Variante des Modul ausprobieren, indem du die Zeilen

Code Auswählen Erweitern

    if ($lux >= 100) {
      # Round to 3 significant digits if at least 100
      my $roundFactor = 10**(floor(log($lux)/log(10)) - 2);
      $lux = $roundFactor*floor($lux/$roundFactor + 0.5);
    } else {
      # Round to 1 fractional digit if less than 100
      $lux = floor(10*$lux + 0.5)/10;
    }


löscht (oder modifizierst), denn dann steht dir die maximale Auflösung zur Verfügung. Damit könntest du selbst ausprobieren, wie sich das Modul ohne Beschränkung verhält.

Grüße,
Jens

[thymjan]

Hallo Jens,

vielen Dank für Deine ausführliche Antwort. War eben auch am Recherchieren und habe im Code auch die Stelle mit dem runden der signifikanten Stellen gefunden (und das bei der Empfindlichkeit des Sensors bei 0,1 lux Schluss ist, schade).

Allerdings steht in der Beschreibung von CalculateLux:

Converts the raw sensor values to the standard SI lux equivalent. Returns 0 if the sensor is saturated and the values are unreliable.

Jetzt kann man sich streiten was unreliable/unzuverlässig heißt. 0 heißt demnach Kapitulation. Aber mit kühlem Kopf kann man ja trotzdem die Aussage machen, daß der Sensor nicht gesättigt ist. Was bleibt übrig? Ist es nun eher dunkel oder liegt eine Fehlmessung vor oder messe ich absolute Dunkelheit? Um damit arbeiten zu können entscheide ich mich für den evtl. mit Fehler gemessenen aber doch aussagekräftigeren Wert statt der 0.
Immerhin kann ich ja eine Zunahme der Helligkeit feststellen. Das ist doch auch was.

Habe den Rundungsblock momentan auskommentiert. Mein Sensor ist auf dem Dach eines Vogelhäuschens auf dem Balkon montiert. In der Adventszeit habe ich eine relativ schwache LED-Lichterkette an der Brüstung montiert. Ist die aus gibt der Sensor jetzt 0,0304 lux an (ohne Mond). Schalte ich sie ein, gibt der Sensor zuverlässig stabil (ohne Schwankungen) den Wert 0,0608 (also das Doppelte) an (ich habe ein kleines weißes Blatt zur Reflexion in der Nähe angebracht).

Teste jetzt noch das grundsätzliche Runden auf 4 signifikante Stellen.

Grüße,
Stefan

[thymjan]

Habe den Rundungsblock mit

Code Auswählen Erweitern

if ($lux != 0) {
    my $roundFactor = 10**(floor(log($lux)/log(10)) - 3);
    $lux = $roundFactor*floor($lux/$roundFactor + 0.5);
}
ersetzt.

Jetzt habe ich im Dunkelbereich mehr Infos und Apple ist auch zufrieden

Vielen Dank für Deine Hilfe.

Werde es die nächsten Tage testen und mir auch die Diagramme nochmals genau anschauen.
Melde mich dann nochmal.

Gruß,
Stefan

[jensb]

Hallo Stefan,

der Source-Kommentar

... Returns 0 if the sensor is saturated and the values are unreliable.

ist leider missverständlich: Sättigung tritt nicht bei kleiner sondern bei großer Helligkeit auf. Eine Null wird von der Berechnungsformel aber nur bei Dunkelheit und bei sehr großem IR-Anteil zurückgegeben. Sättigung kann auch ohne großen IR-Anteil auftreten, dann wird aber auch ein großer Wert für die Luminanz gemeldet. Die Formel stammt aus dem Datenblatt des Sensors.

Diese Festlegung ist unglücklich, weil man dadurch 0 lux = "Dunkelheit" von 0 lux = "nicht berechenbar" anhand des Wertes nicht unterscheiden kann. Faktisch ist "nicht berechenbar" eine vom Messwert unabhängige Eigenschaft, die man ähnlich wie "Saturated" als "state" zurück liefern könnte.

Grüße,
Jens