[patch] I2C_TSL2561 mit IODev

[jensb]

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]

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]

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]

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 Erweitern

$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]

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

[jensb]

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]

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]

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]

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]

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]

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 Erweitern


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]

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]

Sorry, ich habe nicht ordentlich getestet.

Diese Probleme sollten jetzt alle behoben sein.

[RappaSan]

 
Allet jut nu. Läuft