[patch] I2C_TSL2561 mit IODev

jensb · 21 März 2015, 21:23:31

I2C-Fehlererkennung beim Lesen und Schreiben mit Hotplug-Support (derzeit nur für den IODev Modus nutzbar)
alternative Lux-Berechnung mit Floatingpoint-Arithmetik statt Integer-Approximation für besser Auflösung bei IR-Anteil unter 50% und unter 10 lux
Unterdrückung der Aktualisierung der Readings 'luminosity', 'broadband' und 'ir' im Zustand 'I2C Error' und 'Saturated', damit am Reading der Zeitstempel des letzten gültigen Werts stehen bleibt
Skalierung der Readings 'broadband' und 'ir' mit dem gleichen Faktor wie in der Lux-Berechnung, damit man sie "sprungfrei" z.B. in einem Plot verwenden kann
Fix für Invertierung von Attribut 'autoGain' in sub I2C_TSL2561_GetLuminosity
Fix für fehlende Rückschaltung des Reading 'state' aus den Zuständen 'Saturated' und 'Error' in den Zustand 'Initialized'


sub I2C_TSL2561_Define($$)
...
if ($main::init_done || $hash->{HiPi_used}) { ... }

locutus · 22 März 2015, 08:35:44

Hallo Jens,

von deiner Arbeit werden sehr viele Besitzer meines Add-On Boards profitieren. Dafür schon mal vielen Dank!
Ich teste das Modul (ohne HiPi) seit heute Morgen auf dem Banana Pro. Gleich als erstes sind mir die Nachkommastellen aufgefallen. Dazu habe ich eine Frage: ist es möglich die Dezimalstellen zu reduzieren? Ein entsprechendes roundDecimal Attribut, wie beim I2C_BMP180 könnte nützlich sein.

jensb · 22 März 2015, 11:41:42

Hallo locutus,

danke für die Rückmeldung.

Die Nachkommastellen gab es mit der Integer-Approximation vorher nicht. Die könnte man natürlich innerhalb des Moduls reduzieren, z.B. so wie du vorgeschlagen hast. Das Hauptproblem ist der sehr große Wertebereich bei der Beleuchtungsmessung von über 5 Zehnerpotenzen. Nur bei Lux-Werten unter 10 ist die Nachkommastelle überhaupt von Interesse.

Momentan löse ich das so:

Code Auswählen


attr stateFormat { if (ReadingsVal($name, "state", "") eq 'Initialized')  { sprintf("%.1f lux", ReadingsVal($name, "luminosity", 0)); } else { ReadingsVal($name, "state", ""); } }

und

Code Auswählen


attr userReadings logLine:luminosity { sprintf("Ev: %.1f", ReadingsVal("Sonne", "luminosity", 0)).sprintf(" IR: %d", ReadingsVal("Sonne", "ir", 0)).sprintf(" BB: %d", ReadingsVal("Sonne", "broadband", 0)); }

Bei ir und broadband sollte man nach dem Skalieren generell auf Ganzzahl runden. Das werde ich so einbauen. Bitte gib mir Rückmeldung, ob du für die luminosity ein Rundung wirklich brauchst bzw. was du von dem stateFormat-Ansatz hältst.

Jens

jensb · 22 März 2015, 12:52:55

Hallo locutus,

habe mir das mit den Nachkommastellen noch einmal durch den Kopf gehen lassen. In Anbetracht der Messgenauigkeit des Sensors könnte man generell auf 3 signifikante Stellen runden. Damit wäre der kleinste Messwert 0,01 lux (eigentlich schon kleiner als sinnvoll), ab 100 lux wäre der Wert ganzzahlig, ab 1000 wären die Einer Null, usw. Dadurch würde auch das Messwertrauschen leicht reduziert und entsprechend eine eventuelle on-change Weiterverarbeitung etwas ruhiger (und man braucht nichts zu konfigurieren).

Jens.

jensb · 23 März 2015, 20:53:14

Habe die Nachkommastellen bei 'broadband' und 'ir' ausgeblendet und mit dem Sonnenuntergang vom 22.03. auch die Nachkommastellen des Lux-Wertes optimiert. Es gibt jetzt unter 100 lux genau eine und über 100 lux keine Nachkommastelle und es wird auf 3 signifikante Stellen gerundet. Alles unter 0,1 lux mach selbst bei 402 Millisekunden Integrationszeit keinen Sinn. Der TSL2561 kennt auch einen manuellen Timingmodus. Damit könnte man versuchen, auf stabile 0,01 lux zu kommen. Wer es braucht kann sich melden.

kaihs · 23 März 2015, 21:07:22

Hallo Jens,

auch von mir erstmal vielen Dank, dass du die Umstellung gemacht hast.

Ich habe zwar selbst schon eine komplette Neuentwicklung angefangen die bei mir auch funktioniert, aber ich habe sie nie so weit gebracht, dass sie auslieferungsfähig wäre.

Daher würde ich jetzt erstmal deine Version übernehmen wenn du damit einverstanden bist.

Das Modul hat aber als 'Geburtsfehler' immer noch das Problem, dass bis zu 400ms geschlafen wird während der Sensor wandelt. Während der Zeit ist fhem blockiert was nicht gut ist.
In meiner neuen Version habe ich das schon auf eine asynchrone Verarbeitung mittels Timer umgestellt.

Magst du dich daran auch noch versuchen?
Falls nicht würde ich deine jetzige Version erstmal einchecken und dann meinen neuen Code portieren.

Gruß,

Kai

jensb · 23 März 2015, 21:20:45

Hallo Kai,

selbstverständlich kannst Du die Version übernehmen und ggf. einchecken. Es fehlt allerdings nach wie vor ein HiPi-Test.

Die Blockierung von FHEM ist mir erst heute selbst bewusst geworden, als ich das 433 MHz Software-Radio-Projekt rtl_433 in ein FHEM-Modul integrieren wollte. Die Lösung war hier ein Thread, da rtl_433 dauerhaft viel Rechenzeit benötigt. Beim TSL2561 dürft es mit einem Timer leichter sein.

Wenn du nichts dagegen hast, werde ich es mit dem Timer versuchen.

Gruß,

Jens

kaihs · 23 März 2015, 21:52:10

Hallo Jens,

den HiPI Test kann ich machen, ich habe noch einen RPi auf dem das läuft.

kaihs · 23 März 2015, 22:19:35

Sieht gut aus, funktioniert auch mit HiPI.

Lässt sich auch nachträglich auf RPII2C umstellen in dem IODev gesetzt und das Devicefile aus der Definition des Moduls entfernt wird.
Sehr schön.

Ich habe deine letzte Version jetzt eingecheckt.

jensb · 23 März 2015, 22:32:57

Hallo Kai,

danke für die schnelle Rückmeldung. Es freut mich, dass es sofort auch mit HiPi läuft.

Habe mir das mit dem Timer mal angesehen. Die I2C-Abfrage aus _Get nach _Poll zu verschieben dürfte nichts bringen, denn FHEM hängt dann weiter bei der Abarbeitung des InternalTimer.

Mein Vorschlag ohne Threads besteht darin, beim 1. Poll die Messung anzustoßen und bei einem 2. Poll 1 Sekunde später das Ergebnis einzusammeln.

Jens

kaihs · 23 März 2015, 22:44:05

Ja, dass muss asynchron passieren.

Schau dir mal meine Version aus dem Post oben an.

Da starte ich im Get einen Timer entsprechend der Sensorwandelzeit und im Callback I2C_TSL2561_ADCReady wird das Ergebnis dann abgeholt.
Vielleicht ist das ein Ansatz den du übernehmen kannst.

Ich halte es eigentlich auch für sinnvoll ein explizites Get Kommando im Device zu haben, um unabhängig vom Pollintervall eine Wandlung anstossen zu können.

Das musst du aber nicht alles machen, da kann ich dann auch mal wieder Zeit investieren.

jensb · 23 März 2015, 22:44:05

Das zweistufige Pollen funktioniert nur bei autoGain=0. Die Regelschleife für autoGain=1 braucht aber eine synchrone Antwort vom TSL2561 - also muss die ganze Regelschleife asynchron werden. Dafür braucht man aber Threads (SONOS, OWX_ASYNC) oder gibt es einen asynchronen Timer in FHEM?

kaihs · 23 März 2015, 22:47:37

Da haben sich unsere Posts überschnitten.

Lehne ich mich zu weit aus dem Fenster wenn ich behaupte, dass die Timer in Form von InternalTimer immer asynchron sind? So habe ich es zumindest verstanden.

jensb · 23 März 2015, 23:06:05

Ich habe zwar schon ein paar mal in fhem.pl nachgesehen, wie der Kern arbeitet, aber ich möchte nicht behauten, dass ich alle Möglichkeiten verstanden haben.

Meiner Ansicht nach arbeitet HandleTimeout in einer Schleife alle InternalTimer nacheinander ab. Da HandleTimeout ein Teil der Hauptschleife in MAIN ist, gewinnt man dadurch nichts bzgl. Parallelität. Ein InternalTimer ermöglicht nur eine zeitliche Streuung der Last. Das ist in I2C_TSL2561 schon so umgesetzt: _Poll triggert _Get und _Get kann man bei Bedarf auch so aufrufen. Wahrscheinlich kommt man nur mit Threads, die ja lt. Styleguide nicht erwünscht sind, zu einer echten Entlastung des Kerns ohne auf AGC verzichten zu müssen.

kaihs · 23 März 2015, 23:14:18

Aber parallele Ausführung muss doch auch nicht unbedingt sein.
Es reicht doch, dass fhem während des Wartens auf den Sensor nicht blockiert und statt dessen z. B. andere Timer abarbeitet.
Die eigentliche Berechnung auch Basis der ausgelesenen Sensorwerte dauert ja im Vergleich nicht lange.

Wenn im AGN Fall die Einstellungen des Sensors geändert werden geht das Spiel dann wieder von vorne los, d.h. wieder Timer starten und Kontrolle an die Hauptschleife abgeben.
Macht das ganze Prozedere aber sicherlich komplizierter, ein Grund warum ich mich lange nicht zu der Änderung aufraffen konnte

jensb · 24 März 2015, 20:02:58

Hallo Kai,

du hast recht, sehe ich inzwischen genauso.

Habe aus _GetData und _GetLuminosity je einen Zustandsautomaten gemacht - der eine holt die Daten, der andere macht ggf. das AGC. _Get ruft _Poll auf, _Poll ruft _GetLuminosity auf, _GetLuminosity ruft _GetData und _CalculateLux auf. Damit hat sich der Aufrufbaum etwas verändert. In _Poll wird der delay variiert, wenn auf den Sensor gewartet wird, so wie vorher mit usleep in _GetData. Läuft seit ein paar Minuten. Mit verbose=5 kann man sehen, dass jetzt andere Sachen ausgeführt werden, während auf den Sensor gewartet wird.

Bleibt anzumerken, das derzeit nach dem Ausführen von _Get der neue Lux-Wert nicht sofort vorliegt, sondern je nach Integrationszeit erst etwas später. Ist das u.U. ein Problem? Beim Refresh über die Weboberfläche merkt man das nicht.

Werde es noch etwas testen. Anbei der aktuelle Zwischenstand, der aber noch nicht freigegeben werden sollte.

Jens

jensb · 11 April 2015, 22:34:55

Hallo Kai,

die asynchrone Messung ist aus meiner Sicht nun bereit zum öffentlichen Test und zur Übernahme in FHEM. Es hat ein bisschen gedauert, da mein Sensor in seinem verklebten Acrylgehäuse schrittweise ertrunken ist. Dadurch haben sich aber auch ein paar Testszenarien ergeben, die man sonst nicht so leicht bekommt. Inzwischen habe ich einen neuen Sensor und verwende ein anderes Gehäuse - den ersten Regen haben beide gut überstanden

.

Hier noch einmal ein Überblick aller Änderungen:

asynchrone Messung: FHEM kann nun während der Messung weiterarbeiten
Power-Management: Ändern von gain und integrationTime startet keine Messung im TSL2561 mehr
neue Attribute: disable und autoIntegrationTime
neue define Variante mit AUTO statt I2C Adresse
I2C Fehlerbehandlung für IODev/RPII2C verbessert

Für die anderen (nicht RPII2C) I2C-Busanbindungen könnte man bei Bedarf auch die I2C Fehlerbehandlung verbessern. Bei konkreten Rückmeldungen würde ich dies einarbeiten.

Bleibt noch zu erwähnen, dass man mit get immer noch neue Messwerte anfordern kann. Allerdings stehen die nun erst zeitversetzt zur Verfügung, also zwischen 13 ms und ca. 1 s später. Sofern man Event-Verarbeitung nutzt, spielt das aber keine Rolle. Auch auf der Weboberfläche merkt man das nicht.

Jens

kaihs · 13 April 2015, 11:13:07

Hallo Jens,

vielen Dank für die Verbesserungen. Ich werde sie in den nächsten Tagen testen.

Eine Sache ich mir allerdings bereits bei der vorherigen Version deines Codes aufgefallen.

Ursprünglich enthielten die Readings ir und broadband die Rohwerte der beiden Sensoren des TSL2561. In deiner Version enhalten Sie jetzt die skalierten Werte (abhängig von gain/integrationTime).
Prinzipiell ja nicht verkehrt, allerdings ist das erstmal eine Änderung des Verhaltens. Ich habe einige Logik, die auf den ir Werten basiert und entsprechend durcheinander gekommen ist.
Die skalierten Werte werden auch ziemlich groß (> 1.000.0000) und lassen sich in Plots kaum noch in ein vernünftiges Verhältnis zum luminosity Reading bringen.

Mein Vorschlag daher:
Die Readings ir und broadband sollten wieder die Rohwerte enthalten. Zusätzlich könnte es neue Reading ir_scaled und broadband_scaled geben
Was hältst du davon?

Gruß,

Kai

jensb · 14 April 2015, 19:42:05

Hallo Kai,

um die Abwärtskompatibilität ohne neue Readings wieder herzustellen, schlage ich vor, das Attribut "scaleRawValues" mit Default 0 einzuführen. Sag bitte Bescheid, wenn ich das so umsetzen soll.

Das Problem mit dem Plotten kenne ich auch, aber da gibt es eine Lösung: Verwende im SVG-Plot für luminosity den Logarithmus, z.B.

Code Auswählen

$fld[n]&&7*(log($fld[n])+2.303)

bei einer Skala von 0 bis 100. Der Plot entspricht im Verlauf dann auch besser dem Sehvermögen des Auges und es bleibt viel Dynamik in der Dämmerung.

Gruß,

Jens

kaihs · 15 April 2015, 06:45:31

Ja, das mit dem neuen Attribut umzusetzen ist okay, kannst du gerne so machen.

jensb · 18 April 2015, 20:08:46

Hallo,

anbei die neue Modul-Version (IODev + Async) zuätzlich mit neuem Attribut "normalizeRawValues" (Default = Aus) zur Wiederherstellung der Abwärtskompatibilität.

Beim Auswerten der Plots der letzten Wochen ist mir aufgefallen, das beim Umschalten von Gain oder Integration Time im Auto-Modus z.T. ein deutlicher Sprung im Lux-Wert sichtbar ist. Dafür gibt es meiner Ansicht nach mehrere mögliche Ursachen:

A) Die abschnittsweise definierten Kennlinien aus dem Datenblatt (Feature).
B) Eigenschaft des Sensors, möglicherweise auch nur meines Sensors (Feature).
C) Die Umsetzung der Formeln aus dem Datenblatt (Bug).
D) Der Messablauf (Bug).

Um dem auf den Grund gehen zu können, werde ich Gain und Integration Time als Readings anlegen und mitplotten, damit ich nachrechnen kann. Falls dies bereits jemandem aufgefallen ist, bitte melden. Mich interessiert vor allem, ob dies auch in der "alten" HiPi Version schon vorgekommen ist.

Jens

kaihs · 21 April 2015, 19:58:05

Hallo Jens,

ich werde die neue Version testen.

Ich habe die Umschaltung damals nur während der Entwicklung getestet und die Einstellungen dann auf den Defaultwerten gelassen.

Ich werde jetzt aber mal mein altes System mit der alten HiPi-Version des Moduls neben das neue stellen und die geloggten Werte mal vergleichen.

Gruß,

Kai

jensb · 21 April 2015, 20:10:07

Hallo Kai,

zu den Sprüngen kann ich inzwischen Entwarnung geben. Durch die neuen Readings für gain und integrationTime kann man das Log besser bzgl. der Auto-Funktionen auswerten. Es liegt bei mir wohl eine Variante meiner Vermutung B vor. Dadurch das mein Sensor etwa auf 1/3 der Höhe des Dachs montiert ist, senkrecht steht und fast genau nach Süden ausgerichtet ist, werden trotz des Diffusors die Sprünge im Plot morgens und abends wohl durch den relativ digitalen Dachschatten verursacht, gerade wenn man nur alle 5 bis 10 Minuten einen Messwert aufzeichnet. Je nach Beleuchtungssituation erfolgt aber keine Änderung an gain oder integrationTime im Auto-Modus.

Werde nachher die Version mit den zusätzlichen Readings posten, da die möglicherweise auch für andere interessant sind. Dann brauchst du nur eine Version zu testen.

Jens

jensb · 21 April 2015, 20:21:53

Hallo,

anbei das überarbeitete Modul I2C_TSL2561 mit

- IODev-Support
- FHEM-asynchroner Messung
- diversen neuen Attibuten und Readings (jetzt auch gain und integrationTime), siehe Doku

Jens

kaihs · 03 Mai 2015, 16:05:59

Hallo Jens,

ich habe deine Änderungen getestet und keine Probleme gefunden.

Ich habe das jetzt im Wesentlichen übernommen, mit diesen Änderungen:

- Code cleanup
- Tabstops durch zwei Leerzeichen ersetzt
- get Kommando entfernt, das war eh nicht in FHEMWEB sichtbar und macht eigentlich auch keinen Sinn
- statt dessen ein set update Kommando eingeführt, dadurch wird m. E. die Funktion klarer

Danke nochmal für deine Beiträge,

Kai

jensb · 03 Mai 2015, 19:15:56

Hallo Kai,

danke für die Rückmeldung, habe gern geholfen. Das Aufräumen (z.B. der nicht implementierten Attribute) ist eine gute Idee. Bin übrigens auch ein Freund von 2 Leerzeichen statt Tabs.

Habe mir gerade den letzten Stand mit SVN geholt. Beim Neustart gab es bei mir folgende Meldungen im fhem.log:

Code Auswählen


Prototype mismatch: sub main::I2C_TSL2561_Set ($@) vs ($) at ./FHEM/51_I2C_TSL2561.pm line 607, <$fh> line 248.
Undefined subroutine &main::tv_interval called at ./FHEM/51_I2C_TSL2561.pm line 855.

Jens

RappaSan · 04 Mai 2015, 14:20:49

Nach einem heutigen Update klappt der Lichtsensor nicht mehr.
Fehlermeldung: Wrong address, must be one of 0x29, 0x39 or 0x49 (and AUTO for IODev) 0

An der Konfiguration, die vorher prima lief, wurde nichts geändert:

define LightMeter I2C_TSL2561 /dev/i2c-1 0x39
attr LightMeter floatArithmetics 1
attr LightMeter poll_interval 5

Ist die Syntax nun nicht mehr die gleiche?

kaihs · 04 Mai 2015, 21:48:40

Sorry, ich habe nicht ordentlich getestet.

Diese Probleme sollten jetzt alle behoben sein.

RappaSan · 05 Mai 2015, 10:11:17

Allet jut nu. Läuft