FHEM Forum

Hallo zusammen,

ich verzweifel gerade damit, einen TSL2561-Sensor per I2C ans Laufen zu bekommen. Ich habe es zwar schon über den internen Anschluss im Raspberry geschafft, aber über Firmata auf einem Arduino UNO geht es einfach nicht. Die Kommunikation zum Firmata (mit Configurable Firmata) funktioniert auf jeden fall folgendes:

- Analoger Eingang
- Digitaler Eingang
- Onewire

Ich habe das Firmata-Interface folgendermaßen konfiguriert:

define FRM_0 FRM /dev/ttyACM0@57600
attr FRM_0 i2c-config 0
attr FRM_0 sampling-interval 5000

Den Sensor habe ich so konfiguriert:

define TSL2561 I2C_TSL2561 0x39
attr TSL2561 IODev FRM_0
attr TSL2561 floatArithmetics 1
attr TSL2561 poll_interval 1

Ich habe auch schon versucht vom Teilnehmer 0x39 (adresse des TSL2561) Daten zu lesen per FRM_I2C-Device. Das klappt einwandfrei. Das Device hatte ich folgendermaßen konfiguriert:

define FRM_I2C_TSL2561 FRM_I2C 57 0 32

So bekomme ich Daten vom Device zurück. Ich habe das Ganze auch schon mit einem I2C_BMP180 versucht. Das klappt auch nicht über das Firmata-Interface.

Bitte helft mir weiter! Ich werde schon verrückt.

Vielen Dank!

i2c-config muss auf 1 stehen. Damit sagst Du der Firmata auf dem Arduino, dass sie die Kommunikation auf dem I2C-Bus aufbauen soll.

Schau auch mal hier:
http://forum.fhem.de/index.php/topic,40927.0.html (http://forum.fhem.de/index.php/topic,40927.0.html)

Hallo,

möchte diesen Thread nochmal aufgreifen und fragen, ob bei Dir, eitschdie, der TSL2561 nun funktioniert. Ich schaffe es bei mir nicht.

Hier mein Code für das FRM Device:
define FRMB1 FRM 28500 [global]
attr FRMB1 i2c-config 1
attr FRMB1 sampling-interval 30000
attr FRMB1 stateFormat reading
attr FRMB1 model nano
attr FRMB1 room zConfig
attr FRMB1 group FRM


und das Device für den TSL2561:
define Lux_B I2C_TSL2561 0x39
attr Lux_B IODev FRMB1
attr Lux_B poll_interval 1
attr Lux_B integrationTime 402
attr Lux_B autoGain 0
attr Lux_B gain 1
attr Lux_B room B_Test
attr Lux_B group zConfig_B


Der Nano hat configurable Firmata V2.06 ohne Servo und ohne Stepper für Standard USB Kommunikation drauf. Die Kommunikation selbst erfolgt dann über einen ESP8266-01 per WLAN und das funktioniert auch mit den Tastern und den LEDs an PWM über FHEM (auch mit Slider) ohne Probleme.

Flashe ich den Example Code von Adafruit wird der TSL2561 sauber ausgelesen und per USB ausgegeben. Also sollte man die Verkabelung auch ausschließen können.

Das Modul FRM_I2C gibt auch Werte für den TSL2561 Sensor ohne Fehlermeldung zurück.

Was mache ich falsch? Was fehlt? (Ich gehe davon aus, dass I2C_TSL2561 grundsätzlich funktionieren würde)

Edit: Das habe ich noch im LOG gefunden:
Use of uninitialized value in string eq at ./FHEM/51_I2C_TSL2561.pm line 1360.
Die Zeile sieht aber vom Syntax her oK aus.

Ich habe den TSL2561 noch nie auf diesem Weg benutzt, d.h. der entsprechende Code könnte durchaus noch fehlerhaft sein.

Allerdings scheint es mir verdächtig, dass du als IODev beim TSL2561 das FRM Device (FRMB1) und nicht das FRM_I2C Device eingetragen hast.
Kannst du das bitte mal ausprobieren.

Wenn ich die Reference richtig verstanden habe, ist der FRMB1 mein I2C device, oder? Ich habe auch I2C auf dem Firmata aktiviert.

Oder ich brauche einen kleinen Schubser in die richtige Richtung. Wie hast Du das seither in FHEM definiert?

Das FRM Device ist schon richtig.
FRM_I2C wird meines Wissens nur verwendet um reine I2C Befehle zu senden.
Ist dein System aktuell?
Das I2C_TSL2561 Modul ist erst vor ein paar Wochen ins FRM Modul eingebunden worden.
Was steht denn im Log bei Verbose 5?

System ist absolut aktuell. Habe jetzt auf ein Testsystem mit Ubuntu 15 gewechselt. Alle Updates, Patches installiert. FHEM meldet bei "update check" "nothing to do".

Das kommt bei verbose 5 an Meldungen:

2015.10.20 01:15:09 5: I2C_TSL2561_Poll: start
2015.10.20 01:15:09 5: I2C_TSL2561_Disable: start
2015.10.20 01:15:09 5: I2C_TSL2561_Disable: end
2015.10.20 01:15:09 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.10.20 01:15:09 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.10.20 01:15:09 5: I2C_TSL2561_Enable: start
Use of uninitialized value in string eq at ./FHEM/51_I2C_TSL2561.pm line 1360.
2015.10.20 01:15:09 5: I2C_TSL2561_Enable: end
2015.10.20 01:15:09 5: I2C_TSL2561_Disable: start
2015.10.20 01:15:09 5: I2C_TSL2561_Disable: end
2015.10.20 01:15:09 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 0
2015.10.20 01:15:09 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.10.20 01:15:09 5: I2C_TSL2561_Poll: 60 s
2015.10.20 01:15:09 3: received String_data: I2C: Too few bytes received

Kannst Du damit was anfangen? Gerne stelle ich weitere Infos zur Verfügung.

Hmm, bei den Logs vom TSL kann dir eher Kai weiterhelfen. Damit habe ich mich noch nicht befasst.
Die letzte Meldung scheint vom FRM zu sein (Verbose 5 hast du global aktiviert?).
Hier (http://forum.fhem.de/index.php/topic,40927.0.html) könntest du eine Lösung finden.
Es geht zwar um einen anderen Sensor aber in dem Thread liegt das Problem an der Firmata Konfiguration.

Sorry, ich muss da momentan passen.
Ich habe Firmata noch nie genutzt. Um den Fehler zu reproduzieren, müsste ich mir erst so eine Konfiguration aufbauen und dazu fehlt mir aktuell die Zeit.
Ich habe aktuell zu viele andere Baustellen.

Habe bei mir den TSL2561 mit ConfigurableFirmata am Arduino nano (per Ethernet) und Arduino micro (per USB) getestet.
Die Autokonfiguration der Adresse funktioniert nicht, als Adresse wird 10 bzw. 0x0a angenommen.
Mein TSL2561 ist auf 0x39 bzw. 57 eingestellt.

Folgende Konfiguration habe ich vorgenommen:
define Lichtsensor I2C_TSL2561 0x39
attr Lichtsensor IODev FRM_0
attr Lichtsensor floatArithmetics 1
attr Lichtsensor poll_interval 5
attr Lichtsensor verbose 5

FRM_0 habe ich fürs debugging ebenfalls auf verbose 5 gestellt.

Hier das Logfile der Arduino nano / USB-Version (habe das Log etwas gekürzt, da einige 1-Wire Sensoren und ein SHT21 auch am Arduino mit dranhängen):

2015.10.21 11:37:06 1: I2C_TSL2561_Define start: 3/Lichtsensor I2C_TSL2561 0x39
2015.10.21 11:37:06 3: Opening FRM_0 device /dev/ttyACM0
2015.10.21 11:37:06 3: Setting FRM_0 serial parameters to 57600,8,N,1
2015.10.21 11:37:06 3: FRM_0 device opened
2015.10.21 11:37:06 5: FRM:>ff
2015.10.21 11:37:06 5: SW: ff
2015.10.21 11:37:09 3: querying Firmata Firmware Version
2015.10.21 11:37:09 5: FRM:>f079f7
2015.10.21 11:37:09 5: SW: f079f7
2015.10.21 11:37:09 5: FRM:<f079020643006f006e0066006900670075007200610062006c0065004600690072006d006100740061002e0069006e006f00f7
2015.10.21 11:37:09 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_06
2015.10.21 11:37:09 5: FRM:>f069f7
2015.10.21 11:37:09 5: SW: f069f7
[...]
2015.10.21 11:37:09 5: FRM:>f40a07
2015.10.21 11:37:09 5: SW: f40a07
2015.10.21 11:37:09 1: OWX: 1-Wire bus OWio1: interface Firmata detected in FRM_0
2015.10.21 11:37:17 0: Featurelevel: 5.6
2015.10.21 11:37:17 0: Server started with 49 defined entities (version $Id: fhem.pl 9218 2015-09-09 19:43:43Z rudolfkoenig $, os linux, user fhem, pid 22841)
2015.10.21 11:37:17 5: FRM:>f07640007301f7
2015.10.21 11:37:17 5: SW: f07640007301f7
2015.10.21 11:37:17 5: FRM:>f07640080200f7
2015.10.21 11:37:17 5: SW: f07640080200f7
2015.10.21 11:37:17 5: FRM:>f07640007501f7
2015.10.21 11:37:17 5: SW: f07640007501f7
2015.10.21 11:37:17 5: FRM:>f07640080200f7
2015.10.21 11:37:17 5: SW: f07640080200f7
2015.10.21 11:37:17 5: I2C_TSL2561_Poll: start
2015.10.21 11:37:17 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.10.21 11:37:17 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.10.21 11:37:17 5: I2C_TSL2561_Enable: start
2015.10.21 11:37:17 5: FRM:>f07639080a010100f7
2015.10.21 11:37:17 5: SW: f07639080a010100f7
Use of uninitialized value in string eq at ./FHEM/51_I2C_TSL2561.pm line 1360.
2015.10.21 11:37:17 5: I2C_TSL2561_Enable: end
2015.10.21 11:37:17 5: I2C_TSL2561_Disable: start
2015.10.21 11:37:17 5: FRM:>f076390000010000f7
2015.10.21 11:37:17 5: SW: f076390000010000f7
2015.10.21 11:37:17 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/51_I2C_TSL2561.pm line 1396.
2015.10.21 11:37:17 5: I2C_TSL2561_Disable: end
2015.10.21 11:37:17 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 0
2015.10.21 11:37:17 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.10.21 11:37:17 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 574.
2015.10.21 11:37:17 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 575.
2015.10.21 11:37:17 5: I2C_TSL2561_Poll: 300 s
2015.10.21 11:37:17 5: FRM:<f0774000000058002801f7f0774000000014012a00f7f07739000a015000f7
2015.10.21 11:37:17 5: onI2CMessage address: '64', register: '0' data: [88,168]
2015.10.21 11:37:17 5: empfangen: 88 168
2015.10.21 11:37:17 5: onI2CMessage address: '64', register: '0' data: [148,42]
2015.10.21 11:37:17 5: empfangen: 148 42
2015.10.21 11:37:17 5: onI2CMessage address: '57', register: '138' data: [80]
2015.10.21 11:37:17 5: Lichtsensor RX register 10, 1 byte: 80
2015.10.21 11:37:17 5: I2C_TSL2561_I2CRcvID: sensorId TSL2561 Package T/FN/CL Rev. 0
2015.10.21 11:37:19 5: FRM:>f073400af7
2015.10.21 11:37:19 5: SW: f073400af7
[...]
2015.10.21 11:37:23 5: FRM:<034a7f584c1823316036f7
2015.10.21 11:37:23 1: OWX: 1-Wire devices found on bus OWio1 (OWX_10_9884DE020800,OWX_10_DAC2DE020800,TWand,OWX_10_F7DFDE020800,OWX_10_8FCCDE020800,TDecke)
2015.10.21 11:37:23 5: FRM:>f073010af7
2015.10.21 11:37:23 5: SW: f073010af7
[...]
2015.10.21 11:37:25 5: FRM:>f0732c0a104c32742d0002005213005800402ff7
2015.10.21 11:37:25 5: SW: f0732c0a104c32742d0002005213005800402ff7
2015.10.21 11:37:25 5: FRM:<f073430a0b00
2015.10.21 11:37:25 5: FRM:<68003049517f7f1d404007f7
2015.10.21 11:40:13 5: I2C_TSL2561_Poll: start
2015.10.21 11:40:13 5: I2C_TSL2561_Disable: start
2015.10.21 11:40:13 5: FRM:>f076390000010000f7
2015.10.21 11:40:13 5: SW: f076390000010000f7
2015.10.21 11:40:13 5: I2C_TSL2561_Disable: end
2015.10.21 11:40:13 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.10.21 11:40:13 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.10.21 11:40:13 5: I2C_TSL2561_Enable: start
2015.10.21 11:40:13 5: FRM:>f07639080a010100f7
2015.10.21 11:40:13 5: SW: f07639080a010100f7
2015.10.21 11:40:13 5: I2C_TSL2561_Enable: end
2015.10.21 11:40:13 5: I2C_TSL2561_Disable: start
2015.10.21 11:40:13 5: FRM:>f076390000010000f7
2015.10.21 11:40:13 5: SW: f076390000010000f7
2015.10.21 11:40:13 5: I2C_TSL2561_Disable: end
2015.10.21 11:40:13 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 0
2015.10.21 11:40:13 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.10.21 11:40:13 5: I2C_TSL2561_Poll: 300 s
2015.10.21 11:40:13 5: FRM:<f07739000a015000f7
2015.10.21 11:40:13 5: onI2CMessage address: '57', register: '138' data: [80]
2015.10.21 11:40:13 5: Lichtsensor RX register 10, 1 byte: 80
2015.10.21 11:40:13 5: I2C_TSL2561_I2CRcvID: sensorId TSL2561 Package T/FN/CL Rev. 0
2015.10.21 11:40:15 5: I2C_TSL2561_Poll: start
2015.10.21 11:40:15 5: I2C_TSL2561_Disable: start
2015.10.21 11:40:15 5: FRM:>f076390000010000f7
2015.10.21 11:40:15 5: SW: f076390000010000f7
2015.10.21 11:40:15 5: I2C_TSL2561_Disable: end
2015.10.21 11:40:15 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.10.21 11:40:15 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.10.21 11:40:15 5: I2C_TSL2561_Enable: start
2015.10.21 11:40:15 5: FRM:>f07639080a010100f7
2015.10.21 11:40:15 5: SW: f07639080a010100f7
2015.10.21 11:40:15 5: I2C_TSL2561_Enable: end
2015.10.21 11:40:15 5: I2C_TSL2561_Disable: start
2015.10.21 11:40:15 5: FRM:>f076390000010000f7
2015.10.21 11:40:15 5: SW: f076390000010000f7
2015.10.21 11:40:15 5: I2C_TSL2561_Disable: end
2015.10.21 11:40:15 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 0
2015.10.21 11:40:15 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.10.21 11:40:15 5: I2C_TSL2561_Poll: 300 s
2015.10.21 11:40:15 5: FRM:<f07739000a015000f7
2015.10.21 11:40:15 5: onI2CMessage address: '57', register: '138' data: [80]
2015.10.21 11:40:15 5: Lichtsensor RX register 10, 1 byte: 80
2015.10.21 11:40:15 5: I2C_TSL2561_I2CRcvID: sensorId TSL2561 Package T/FN/CL Rev. 0

Da liegt noch was mit der Kommunikation im Argen... Muss man wohl Schritt für Schritt debuggen.

Und so sollte es eigentlich aussehen (direkt am raspi I2C):
2015.10.21 14:35:35 5: I2C_TSL2561_Poll: start
2015.10.21 14:35:35 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.10.21 14:35:35 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.10.21 14:35:35 5: I2C_TSL2561_Enable: start
2015.10.21 14:35:35 5: PimoroniI2C: vom client empfangen|direction: i2cwrite|reg: 128|data: 3|i2caddress: 57
2015.10.21 14:35:35 5: PimoroniI2C: HWaccess I2CAddr: 0x39
2015.10.21 14:35:35 5: PimoroniI2C: vom client empfangen|direction: i2cwrite|reg: 128|data: 3|i2caddress: 57
2015.10.21 14:35:35 5: PimoroniI2C: HWaccess block schreiben, Reg: 0x80 Inh(dec):|3|, laenge: |2|
2015.10.21 14:35:35 5: PimoroniI2C ->Client gefunden: TSL2561, I2Caddress: 57 Data: 3
2015.10.21 14:35:35 5: PimoroniI2C: vom client empfangen|direction: i2cread|nbyte: 1|reg: 128|i2caddress: 57
2015.10.21 14:35:35 5: PimoroniI2C: HWaccess I2CAddr: 0x39
2015.10.21 14:35:35 5: PimoroniI2C: vom client empfangen|direction: i2cread|nbyte: 1|reg: 128|i2caddress: 57
2015.10.21 14:35:35 4: PimoroniI2C: HWaccess blockweise lesen setze Registerpointer auf 128
2015.10.21 14:35:35 5: PimoroniI2C ->Client gefunden: TSL2561, I2Caddress: 57 Gelesen: 3
2015.10.21 14:35:35 5: TSL2561 RX register 0, 1 byte: 3
2015.10.21 14:35:35 5: I2C_TSL2561_I2CRcvControl: is enabled
2015.10.21 14:35:35 5: I2C_TSL2561_Enable: end
2015.10.21 14:35:35 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 1
2015.10.21 14:35:35 5: I2C_TSL2561_Poll: 0.403 s
2015.10.21 14:35:35 5: I2C_TSL2561_Poll: start
2015.10.21 14:35:35 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 1
2015.10.21 14:35:35 5: PimoroniI2C: vom client empfangen|direction: i2cread|nbyte: 2|reg: 172|i2caddress: 57
2015.10.21 14:35:35 5: PimoroniI2C: HWaccess I2CAddr: 0x39
2015.10.21 14:35:35 5: PimoroniI2C: vom client empfangen|direction: i2cread|nbyte: 2|reg: 172|i2caddress: 57
2015.10.21 14:35:35 4: PimoroniI2C: HWaccess blockweise lesen setze Registerpointer auf 172
2015.10.21 14:35:35 5: PimoroniI2C ->Client gefunden: TSL2561, I2Caddress: 57 Gelesen: 220 6
2015.10.21 14:35:35 5: TSL2561 RX register 12, 2 byte: 220 6
2015.10.21 14:35:35 5: I2C_TSL2561_I2CRcvChan0 1756
2015.10.21 14:35:35 5: PimoroniI2C: vom client empfangen|direction: i2cread|nbyte: 2|reg: 174|i2caddress: 57
2015.10.21 14:35:35 5: PimoroniI2C: HWaccess I2CAddr: 0x39
2015.10.21 14:35:35 5: PimoroniI2C: vom client empfangen|direction: i2cread|nbyte: 2|reg: 174|i2caddress: 57
2015.10.21 14:35:35 4: PimoroniI2C: HWaccess blockweise lesen setze Registerpointer auf 174
2015.10.21 14:35:35 5: PimoroniI2C ->Client gefunden: TSL2561, I2Caddress: 57 Gelesen: 19 4
2015.10.21 14:35:35 5: TSL2561 RX register 14, 2 byte: 19 4
2015.10.21 14:35:35 5: I2C_TSL2561_I2CRcvChan1 1043
2015.10.21 14:35:35 5: I2C_TSL2561_Disable: start
2015.10.21 14:35:35 5: PimoroniI2C: vom client empfangen|direction: i2cwrite|reg: 128|data: 0|i2caddress: 57
2015.10.21 14:35:35 5: PimoroniI2C: HWaccess I2CAddr: 0x39
2015.10.21 14:35:35 5: PimoroniI2C: vom client empfangen|direction: i2cwrite|reg: 128|data: 0|i2caddress: 57
2015.10.21 14:35:35 5: PimoroniI2C: HWaccess block schreiben, Reg: 0x80 Inh(dec):|0|, laenge: |2|
2015.10.21 14:35:35 5: PimoroniI2C ->Client gefunden: TSL2561, I2Caddress: 57
2015.10.21 14:35:35 5: I2C_TSL2561_Disable: end
2015.10.21 14:35:35 5: I2C_TSL2561_GetLuminosity: calc state 2 acqui state 0
2015.10.21 14:35:35 5: I2C_TSL2561_Poll: 300 s

Hallo,
auch ich habe Probleme den TSL2561 über die Firmata zum laufen zu bringen. Im state des Moduls steht: I2C Error, im FRM: I2C: Too few bytes received.
Mit einem einfachen Sketch werden die Werte korrekt ausgelesen, daher kein Verdrahtungsfehler möglich. Tippe auf einen Fehler i.d. Firmata.
Gruß Doesel

Zitat von: thymjan am 21 Oktober 2015, 12:04:32
Habe bei mir den TSL2561 mit ConfigurableFirmata am Arduino nano (per Ethernet) und Arduino micro (per USB) getestet.
Die Autokonfiguration der Adresse funktioniert nicht, als Adresse wird 10 bzw. 0x0a angenommen.
Mein TSL2561 ist auf 0x39 bzw. 57 eingestellt.
[...]

Da liegt noch was mit der Kommunikation im Argen... Muss man wohl Schritt für Schritt debuggen.

wenn ich helfen kann gern

Was heißt denn Autokonfiguration?

Für den TSL liefert FRM seltsamerweise auch immer die gleichen Werte zurück.

Die Frage ist, worin der Unterschied zum BMP und SHT besteht. Die Kommunikation funktioniert dort schließlich und die Schnittstelle sollte kompatibel zum RPII2C sein.

ZitatDefine

define TSL2561 I2C_TSL2561 [<I2C device>] <I2C address>

<I2C device> mandatory for HiPi, must be omitted if you connect via IODev
<I2C address> may be 0x29, 0x39 or 0x49 (and 'AUTO' when using IODev to search for device at startup and after an I2C error)

Examples:
        define TSL2561 I2C_TSL2561 /dev/i2c-0 0x39
        attr TSL2561 poll_interval 5
       
        define TSL2561 I2C_TSL2561 0x39
        attr TSL2561 IODev I2CModule
        attr TSL2561 poll_interval 5
       
        define TSL2561 I2C_TSL2561 AUTO
        attr TSL2561 IODev I2CModule
        attr TSL2561 poll_interval 5

Wenn ich als Adresse bei der Definition "AUTO" angebe, wird bei Anschluß des Moduls direkt am raspi die entsprechende richtige i2c Adresse gefunden. Über die Fimata kommt hier eine Fantasieadresse raus.

Naja, beim BMP180 hat's ja mit der Firmata auch nicht auf Anhieb geklappt. Hängt aber vermutlich ebenfalls nur an Kleinigkeiten.

Zitat von: thymjan am 09 November 2015, 16:35:57
Wenn ich als Adresse bei der Definition "AUTO" angebe, wird bei Anschluß des Moduls direkt am raspi die entsprechende richtige i2c Adresse gefunden. Über die Fimata kommt hier eine Fantasieadresse raus.

Verstehe, das liegt sicher daran, das überhaupt nix richtig ankommt, dann kann natürlich auch die Adresssuche nicht richtig funktionieren.

Versuche seit 2 Tagen die knapp 1500 Zeilen Code zu verstehen...  :o

Mit der FRM als I/O-Device funktioniert die ganze Initialisierung nicht. Das Modul I2C_TSL2561 wird aufgerufen, bevor die Kommunikation mit dem Arduino richtig steht. Trotz Scheitern wird die Initialisierung aber nicht wiederholt ...

Zitat von: thymjan am 15 November 2015, 13:06:20
Versuche seit 2 Tagen die knapp 1500 Zeilen Code zu verstehen...  :o

Mit der FRM als I/O-Device funktioniert die ganze Initialisierung nicht. Das Modul I2C_TSL2561 wird aufgerufen, bevor die Kommunikation mit dem Arduino richtig steht. Trotz Scheitern wird die Initialisierung aber nicht wiederholt ...

Hmm, kann man da ne Pause einfügen?
Scheitern bedeutet Timeout beim I2C_TSL2561 Modul?

Hab schon testweise ein usleep eingebaut. Aber dann wartet das ganze fhem und die Firmata-Initialisierung ist trotzdem erst hinterher.

Was ich auch noch nicht verstanden habe: welche sub's werden denn von der main loop / von Fhem aufgerufen, also welches ist das start-sub? Und wo steht das?

So langsam komme ich der Sache näher. In den Funktionen I2C_TSL2561_i2cread und I2C_TSL2561_i2cwrite wird sofort nach der Lese- bzw. Schreibfunktion _SENDSTAT abgefragt. So schnell ist die Firmata nicht. Daher brechen die beiden nicht unwesentlichen Funktionen immer mit Fehlermeldung ab. Ich denke hier muss etwas gewartet werden.
Vielleicht ist es auch cleverer, _SENDSTAT hier gar nicht abzufragen?

^^^
ich glaube die Annahme ist Käse....  :-\

Die Funktion schreibt an FRM und FRM schreibt an den Arduino.
Aber irgendwie kommt nix zurück, da ist noch ein Zeiger verbogen.

Der parallel laufende BMP180 läuft 1A.

Wie bekomme ich das hin, das I2C_TSL2561 erst definiert wird, wenn sich die Firmata angemeldet hat, bzw. wie kann ich I2C_TSL2561_Define erneut aufrufen?

I2C_BMP180 wird auch weit bevor die Firmata bereit ist definiert, aber dieses Modul wartet höflich bis die Firmata bereit ist.
I2C_TSL2561 schreibt sofort drauf los, bevor die Firmata bereit ist. Ist das Zufall?

2015.11.16 22:28:29 1: Including fhem.cfg
2015.11.16 22:28:29 3: telnetPort: port 7072 opened
2015.11.16 22:28:30 3: WEB: port 8083 opened
2015.11.16 22:28:30 3: WEBphone: port 8084 opened
2015.11.16 22:28:30 3: WEBtablet: port 8085 opened
2015.11.16 22:28:31 2: eventTypes: loaded 633 events from ./log/eventTypes.txt
2015.11.16 22:28:34 1: BMP180_Define start: 2/BMP180 I2C_BMP180
2015.11.16 22:28:41 1: I2C_TSL2561_Define start: 3/TSL2561.firmata I2C_TSL2561 0x39
2015.11.16 22:28:41 1: Including ./log/fhem.save
2015.11.16 22:28:42 3: FRM_1: port 3031 opened
2015.11.16 22:28:42 0: Featurelevel: 5.6
2015.11.16 22:28:42 0: Server started with 65 defined entities (version $Id: fhem.pl 9868 2015-11-12 18:04:37Z rudolfkoenig $, os linux, user fhem, pid 14134)
2015.11.16 22:28:42 5: I2C_BMP180_Poll: start
2015.11.16 22:28:42 5: I2C_BMP180_Poll: 5 min
2015.11.16 22:28:44 5: I2C_TSL2561_Poll: start
2015.11.16 22:28:44 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.11.16 22:28:44 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.11.16 22:28:44 5: I2C_TSL2561_Enable: start
2015.11.16 22:28:44 1: TSL2561.firmata: IODev is assigned to 'TSL2561.firmata' but not yet here
2015.11.16 22:28:44 1: TSL2561.firmata: IODev: HASH(0x1f786e8)
2015.11.16 22:28:44 5: I2C_TSL2561_Enable: end
2015.11.16 22:28:44 5: I2C_TSL2561_Disable: start
2015.11.16 22:28:44 1: TSL2561.firmata: IODev is assigned to 'TSL2561.firmata' but not yet here
2015.11.16 22:28:44 1: TSL2561.firmata: IODev: HASH(0x1f786e8)
2015.11.16 22:28:44 5: I2C_TSL2561_Disable: end
2015.11.16 22:28:44 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 0
2015.11.16 22:28:44 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.11.16 22:28:44 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 575.
2015.11.16 22:28:44 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 576.
2015.11.16 22:28:44 5: I2C_TSL2561_Poll: 300 s
2015.11.16 22:28:46 4: Connection accepted from FRM:192.168.1.25:1513
2015.11.16 22:28:46 5: FRM:>ff
2015.11.16 22:28:49 3: querying Firmata Firmware Version
2015.11.16 22:28:49 5: FRM:>f079f7
2015.11.16 22:28:49 5: FRM:<f079020643006f006e0066006900670075007200610062006c0065004600690072006d00610074006100f7
2015.11.16 22:28:49 3: Firmata Firmware Version: ConfigurableFirmata V_2_06
2015.11.16 22:28:49 5: FRM:>f069f7
2015.11.16 22:28:49 5: FRM:>f06bf7
2015.11.16 22:28:49 5: FRM:<f06a7f7f7f7f7f7f7f7f7f7f7f7f7f7f0001020304050607f7
2015.11.16 22:28:49 5: FRM:<f06c7f7f0101091c7f01010308091c7f7f010103087f010103087f01017f01017f010103087f7f7f7f7f01017f01017f01017f01017f010106017f010106017f7f7ff7
2015.11.16 22:28:49 5: FRM:>f07a6807f7
2015.11.16 22:28:49 5: FRM:>f41206
2015.11.16 22:28:49 5: FRM:>f41306
2015.11.16 22:28:49 5: FRM:>f0780100f7
2015.11.16 22:28:49 5: FRM Kommunikation mit I2C ...
2015.11.16 22:28:49 5: FRM auf I2C lesen ...
2015.11.16 22:28:49 5: FRM:>f07677082a011600f7
2015.11.16 22:28:49 5: FRM Adresse: 119|Register: 170|22 byte(s)
2015.11.16 22:28:49 5: FRM:>f40201
2015.11.16 22:28:49 5: FRM:>900000
2015.11.16 22:28:49 5: FRM:>f40303
2015.11.16 22:28:49 5: FRM:<f07777002a01200035007b012d014501700105015d016200700136001800190073000000290000010000510176010a003c00f7
2015.11.16 22:28:49 5: onI2CMessage address: '119', register: '170' data: [32,53,251,173,197,240,133,221,98,240,54,24,25,115,0,41,128,0,209,246,10,60]
2015.11.16 22:28:49 5: BMP180 empfangen: 32 53 251 173 197 240 133 221 98 240 54 24 25 115 0 41 128 0 209 246 10 60
2015.11.16 22:28:49 5: in get cal: 32 53 251 173 197 240 133 221 98 240 54 24 25 115 0 41 128 0 209 246 10 60
2015.11.16 22:28:49 5: FRM UPDATE Adresse: 119|Register: 170|Daten: 32 53 251 173 197 240 133 221 98 240 54 24 25 115 0 41 128 0 209 246 10 60

Hallo thymjan,

um es vorweg zu nehmen, ich habe zwar einen Arduino irgendwo rumliegen, aber noch nie mit Frimata gearbeitet.

In deinem  letztes Logging sind ein paar interessante Stellen:

Zitat
2015.11.16 22:28:41 1: I2C_TSL2561_Define start: 3/TSL2561.firmata I2C_TSL2561 0x39
...
2015.11.16 22:28:44 1: TSL2561.firmata: IODev is assigned to 'TSL2561.firmata' but not yet here

Letztere kommt nicht direkt aus dem TLS2561-Modul und bestätigt die Vermutung, dass der I2C-Zugriff erfolgt, bevor Firmata alles vorbereitet hat, hier nach 3 Sekunden.

Zitat
2015.11.16 22:28:34 1: BMP180_Define start: 2/BMP180 I2C_BMP180
...
2015.11.16 22:28:42 5: I2C_BMP180_Poll: start
2015.11.16 22:28:42 5: I2C_BMP180_Poll: 5 min
...
2015.11.16 22:28:49 3: Firmata Firmware Version: ConfigurableFirmata V_2_06
....
2015.11.16 22:28:49 5: BMP180 empfangen: 32 53 251 173 197 240 133 221 98 240 54 24 25 115 0 41 128 0 209 246 10 60

Das BMP180-Modul wartet bis Firmata bereit ist, bevor es "richtig" loslegt, hier ca. 15 Sekunden.

Der Unterschied liegt u.U. daran, dass das BMP180-Modul im XXX_Initialize das IODevice nur initialisiert, wenn FHEM betriebsbereit ist und für die Nachtinitialisierung die InitFn bei FHEM registriert, während das TSL2561-Modul noch keine nachträgliche Initialisierung unterstützt.

Ich könnte fürs erste versuchen, einen Hack zum Testen zur Verfügung zu stellen, in dem der Initialisierungsablauf ähnlich wie im BMP180-Modul durchgeführt wird. Falls es klappt, muss aber kaihs entscheiden, ob das Modul angepasst wird.

LG, Jens

Hallo thymjan,

hier eine inoffizielle Version zum Ausprobieren. Mehr ist heute nicht drin und ich werde wahrscheinlich auch bis Sa. nichts weiter machen können. Vielleicht hilft diese Version trotzdem ein Stück weiter.

LG, Jens

Hallo Jens,

die 'not yet here' Meldung kommt auch aus dem TSL2561-Modul, ich habe da schon rum gepfuscht:

sub I2C_TSL2561_i2cwrite($$$) {
  my ($hash, $reg, @data) = @_;
  my $success = 1;

  if ($hash->{HiPi_used}) {
    eval {
      $hash->{devTSL2561}->bus_write($reg, join (' ',@data));
      I2C_TSL2561_I2CRec($hash, {
        direction => "i2cwrite",
        i2caddress => $hash->{I2C_Address},
        reg => $reg,
        data => join (' ',@data),
      });
    };
    Log3 ($hash, 1, $hash->{NAME} . ': ' . I2C_TSL2561_Catch($@)) if $@;
  } elsif (defined (my $iodev = $hash->{IODev})) {
    eval {
      CallFn($iodev->{NAME}, "I2CWrtFn", $iodev, {
      direction => "i2cwrite",
      i2caddress => $hash->{I2C_Address},
      reg => $reg,
      data => join (' ',@data),
      });
    };
    if (defined $hash->{$iodev->{NAME}.'_SENDSTAT'}) {
      if ($hash->{$iodev->{NAME}.'_SENDSTAT'} eq 'error') {
        readingsSingleUpdate($hash, 'state', STATE_I2C_ERROR, 1);
        $success = 0;
      }
    } else {
      $success = 0;
      Log3 ($hash, 1, $hash->{NAME} . ': ' . "IODev is assigned to '$hash->{NAME}' but not yet here");
      Log3 ($hash, 1, $hash->{NAME} . ': ' . "IODev: $hash->{IODev}");
    }
  } else {
    Log3 ($hash, 1, $hash->{NAME} . ': ' . "no IODev assigned to '$hash->{NAME}'");
    $success = 0;
  }

  return $success;
}


Der rote Ausdruck ist durch die fehlende FRM-Firmata Kommunikation noch nicht definiert (siehe post http://forum.fhem.de/index.php/topic,40875.msg347669.html#msg347669 (http://forum.fhem.de/index.php/topic,40875.msg347669.html#msg347669))
2015.10.21 11:37:17 5: I2C_TSL2561_Poll: start
2015.10.21 11:37:17 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.10.21 11:37:17 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.10.21 11:37:17 5: I2C_TSL2561_Enable: start
2015.10.21 11:37:17 5: FRM:>f07639080a010100f7
2015.10.21 11:37:17 5: SW: f07639080a010100f7
Use of uninitialized value in string eq at ./FHEM/51_I2C_TSL2561.pm line 1360.
2015.10.21 11:37:17 5: I2C_TSL2561_Enable: end
2015.10.21 11:37:17 5: I2C_TSL2561_Disable: start
2015.10.21 11:37:17 5: FRM:>f076390000010000f7
2015.10.21 11:37:17 5: SW: f076390000010000f7
2015.10.21 11:37:17 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/51_I2C_TSL2561.pm line 1396.
2015.10.21 11:37:17 5: I2C_TSL2561_Disable: end
2015.10.21 11:37:17 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 0
2015.10.21 11:37:17 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.10.21 11:37:17 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 574.
2015.10.21 11:37:17 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 575.
2015.10.21 11:37:17 5: I2C_TSL2561_Poll: 300 s

Stefan

Hallo Stefan,

gut zu wissen, hatte aber vom Ablauf des Loggings bereits diese Ecke vermutet.

Bitte probier die Testversion aus. Es ist aber recht wahrscheinlich, dass sie u.a. an dieser Stelle noch etwas Feinschliff benötigt, um z.B. die Perl-Fehlermeldungen los zu werden.

LG, Jens

Hi Jens,

Danke für Deine Anpassung, hab dein Modul eingespielt. Im log sieht man keine große Veränderung:
2015.11.17 20:39:13 1: Including fhem.cfg
2015.11.17 20:39:14 3: telnetPort: port 7072 opened
2015.11.17 20:39:15 3: WEB: port 8083 opened
2015.11.17 20:39:15 3: WEBphone: port 8084 opened
2015.11.17 20:39:15 3: WEBtablet: port 8085 opened
2015.11.17 20:39:16 2: eventTypes: loaded 637 events from ./log/eventTypes.txt
2015.11.17 20:39:18 3: Connecting to database SQLite:dbname=/opt/fhem/fhem.db with user
2015.11.17 20:39:18 3: Connection to db SQLite:dbname=/opt/fhem/fhem.db established for pid 20593
2015.11.17 20:39:18 3: Connection to db SQLite:dbname=/opt/fhem/fhem.db established
2015.11.17 20:39:19 1: BMP180_Define start: 2/BMP180 I2C_BMP180
[...]
2015.11.17 20:39:25 1: I2C_TSL2561_Define start: 3/TSL2561.firmata I2C_TSL2561 0x39
2015.11.17 20:39:25 1: Including ./log/fhem.save
2015.11.17 20:39:26 3: FRM_1: port 3031 opened
2015.11.17 20:39:26 0: Featurelevel: 5.6
2015.11.17 20:39:26 0: Server started with 65 defined entities (version $Id: fhem.pl 9868 2015-11-12 18:04:37Z rudolfkoenig $, os linux, user fhem, pid 20593)
2015.11.17 20:39:26 5: I2C_BMP180_Poll: start
2015.11.17 20:39:26 5: I2C_BMP180_Poll: 5 min
2015.11.17 20:39:26 5: I2C_TSL2561_Poll: start
2015.11.17 20:39:26 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.11.17 20:39:26 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.11.17 20:39:26 5: I2C_TSL2561_Enable: start
Use of uninitialized value in string eq at ./FHEM/51_I2C_TSL2561.pm line 1366.
2015.11.17 20:39:26 5: I2C_TSL2561_Enable: end
2015.11.17 20:39:26 5: I2C_TSL2561_Disable: start
2015.11.17 20:39:26 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/51_I2C_TSL2561.pm line 1402.
2015.11.17 20:39:26 5: I2C_TSL2561_Disable: end
2015.11.17 20:39:26 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 0
2015.11.17 20:39:26 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.11.17 20:39:26 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 580.
2015.11.17 20:39:26 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 581.
2015.11.17 20:39:26 5: I2C_TSL2561_Poll: 300 s
2015.11.17 20:39:30 4: Connection accepted from FRM:192.168.1.25:1582
2015.11.17 20:39:30 5: FRM:>ff
2015.11.17 20:39:33 3: querying Firmata Firmware Version
2015.11.17 20:39:33 5: FRM:>f079f7
2015.11.17 20:39:33 5: FRM:<f079020643006f006e0066006900670075007200610062006c0065004600690072006d00610074006100f7
2015.11.17 20:39:33 3: Firmata Firmware Version: ConfigurableFirmata V_2_06
2015.11.17 20:39:33 5: FRM:>f069f7
2015.11.17 20:39:33 5: FRM:>f06bf7
2015.11.17 20:39:33 5: FRM:<f06a7f7f7f7f7f7f7f7f7f7f7f7f7f7f0001020304050607f7f06c7f7f0101091c7f01010308091c7f7f010103087f010103087f01017f01017f010103087f7f7f7f7f01017f01017f01017f01017f010106017f010106017f7f7ff7
2015.11.17 20:39:33 5: FRM:>f07a6807f7
2015.11.17 20:39:33 5: FRM:>f41206
2015.11.17 20:39:33 5: FRM:>f41306
2015.11.17 20:39:33 5: FRM:>f0780100f7
2015.11.17 20:39:33 5: FRM Kommunikation mit I2C ...
2015.11.17 20:39:33 5: FRM auf I2C lesen ...
2015.11.17 20:39:33 5: FRM:>f07677082a011600f7
2015.11.17 20:39:33 5: FRM Adresse: 119|Register: 170|22 byte(s)
2015.11.17 20:39:33 5: FRM:>f40201
2015.11.17 20:39:33 5: FRM:>900000
2015.11.17 20:39:33 5: FRM:>f40303
2015.11.17 20:39:33 5: FRM:<f07777002a01200035007b012d014501700105015d016200700136001800190073000000290000010000510176010a003c00f7
2015.11.17 20:39:33 5: onI2CMessage address: '119', register: '170' data: [32,53,251,173,197,240,133,221,98,240,54,24,25,115,0,41,128,0,209,246,10,60]
2015.11.17 20:39:33 5: BMP180 empfangen: 32 53 251 173 197 240 133 221 98 240 54 24 25 115 0 41 128 0 209 246 10 60
2015.11.17 20:39:33 5: in get cal: 32 53 251 173 197 240 133 221 98 240 54 24 25 115 0 41 128 0 209 246 10 60
2015.11.17 20:39:33 5: FRM UPDATE Adresse: 119|Register: 170|Daten: 32 53 251 173 197 240 133 221 98 240 54 24 25 115 0 41 128 0 209 246 10 60


Modul versucht immer noch Zugriff auf I2C-Bus zu bekommen bevor FRM bereit ist. Bereits in XXXpoll wird ja schon auf I2C geschrieben.

Gruß,
Stefan

Hallo Stefan,

hast du mal bis zum 2. Poll gewartet oder set update ausgelöst? In XXXX_Poll sind derzeit noch keine Verriegelungen, so dass es natürlich nach wie vor zu Fehlern kommt, bis Firmata da ist, falls mein Ansatz überhaupt greift.

LG, Jens

Stimmt, im define die Kommunikation zu starten ist nicht optimal.
Das I2C_****_Init hat nicht nur die Aufgabe zu warten bis das Physikalische Modul (hier FRM) fertig initialisiert ist, es soll auch bei einer Verbindungsunterbrechung das Ganze wieder Initialisieren. Macht bei Anbindung über Netzwerk durchaus Sinn.

Was mich weiterhin irritiert ist die Verwendung der Funktion I2C_TSL2561_I2CRec

$hash->{I2CRecFn} wird vom IODEV aufgerufen, wenn eine Antwort auf einen Befehl der über CallFn abgesetzt wurde zurück kommt.
Das heisst, diese Funktion sollte nicht von innerhalb des Moduls 51_I2C_TSL2561 aufgerufen werden. Es kann in diesem Fall schließlich nicht sichergestellt werden, ob schon eine Antwort vorliegt.

Die Verbindung muss asynchron laufen:

Slave Modul (TSL2561) sendet Anfrage an IODEV in dem es die I2CWrtFn des IODEV aufruft:
CallFn($iodev->{NAME}, "I2CWrtFn", $iodev, {
direction  => "i2cread",
i2caddress => $hash->{I2C_Address},
reg => $reg,
nbyte => $nbyte
});
kann natürlich auch i2cwrite sein.

Das IODEV verarbeitet jetzt diese Anfrage. Wärenddessen macht das Slave Modul (TSL2561) nix.

Wenn Das IODEV die Antwort vom I2C Chip hat dann schickt es die Antwort an die $hash->{I2CRecFn} des Slave Moduls

Dieses kann die Antwort verarbeiten.

Das aktuelle Konstrukt im TSL2561 Modul funktioniert vermutlich nur Zufällig auf dem Pi.

Dann ist doch auch die direkte Überprüfung von XX_SENDSTAT in sub XX_i2cwrite und sub XX_i2cread nicht im Sinne des Erfinders, oder? Hab mir vorher an dem Konstrukt
if ($hash->{$iodev->{NAME}.'_SENDSTAT'} eq 'error')
die Zähne ausgebissen und hab's dann schließlich auskommentiert.

Habe mein FRM-Modul mit log-Infos zugepflastert für genauere Rückmeldungen. Ist im Anhang.

Habe mir auch überlegt, dass die Poll-Funktion einfacher gestaltet werden sollte. Ein Großteil könnte doch in eine Measurement-Funktion ausgelagert werden, die nur während einer Messung ausgeführt wird und nicht gleich beim Start beim "einfachen" Festlegen des Poll-Intervals.

Zitat von: thymjan am 18 November 2015, 13:58:23
Dann ist doch auch die direkte Überprüfung von XX_SENDSTAT in sub XX_i2cwrite und sub XX_i2cread nicht im Sinne des Erfinders, oder? Hab mir vorher an dem Konstrukt
if ($hash->{$iodev->{NAME}.'_SENDSTAT'} eq 'error')
die Zähne ausgebissen und hab's dann schließlich auskommentiert.

Nee, die Überprüfung sollte ausschließlich in der I2CRecFn erfolgen. Woanders macht sie keinen Sinn.

i2c read und write sollten auch maximal Funktionen sein, die einen Lese/Schreibbefehl absetzen. Sie dürfen keinesfalls auf eine Antwort warten.
Die Antwort kommt von allein über die I2CRecFn. Von dort muss auch die Verarbeitung der gelesenen Werte angetriggert werden.

Das SHT21 Modul ist evtl. ein gutes Beispiel. Im BMP180 ist halt auch noch der alte HiPi Kram drin. Der macht es etwas unübersichtlich.

Eine Separate Funktion um die Rohdaten in lesbare Werte zu Wandeln ist sehr sinnvoll.

Das TSL2561 ist halt ursprünglich für den direkten Einsatz am Pi konzipiert gewesen. Das war das BMP Modul auch, dort musste ich einiges umändern.

Bin nun einen Schritt weiter. Die Kommunikation mit dem Sensor funktioniert jetzt (angelehnt an das Modul für den BMP180).
Das Modul wartet jetzt auch auf $main::init_done bevor es zu lesen/schreiben anfängt.
Musste dazu viel Code nach "hinten packen" also z.B. aus Define nach Init usw.
HiPi habe ich erst mal rausgeschmissen.

Nun müssen die State-Machines wieder zum Laufen gebracht werden... eine kleine Herausforderung.
Wo ich den Code aus der alten Poll-Funktion hin packen soll, weis ich auch noch nicht.

Der aktuelle Stand (liest noch keine Messwerte aus) im Anhang.

2015.11.19 20:21:45 0: Server shutdown
2015.11.19 20:21:50 1: Including fhem.cfg
2015.11.19 20:21:50 3: telnetPort: port 7072 opened
2015.11.19 20:21:52 3: WEB: port 8083 opened
2015.11.19 20:21:52 3: WEBphone: port 8084 opened
2015.11.19 20:21:52 3: WEBtablet: port 8085 opened
2015.11.19 20:21:53 2: eventTypes: loaded 645 events from ./log/eventTypes.txt
[...]
2015.11.19 20:22:03 1: I2C_TSL2561_Define start: 3/Lichtsensor I2C_TSL2561 0x39
2015.11.19 20:22:03 1: I2C_TSL2561_Define Lichtsensor I2C_TSL2561 0x39
2015.11.19 20:22:03 1: Including ./log/fhem.save
2015.11.19 20:22:04 3: FRM_1: port 3031 opened
2015.11.19 20:22:04 0: Featurelevel: 5.6
2015.11.19 20:22:04 0: Server started with 64 defined entities (version $Id: fhem.pl 9868 2015-11-12 18:04:37Z rudolfkoenig $, os linux, user fhem, pid 2184)
2015.11.19 20:22:07 5: I2C_TSL2561_Poll: start
2015.11.19 20:22:07 5: I2C_TSL2561_Enable: start
2015.11.19 20:22:07 5: I2C_TSL2561_Enable: end
2015.11.19 20:22:07 5: I2C_TSL2561_Poll: 5 min
2015.11.19 20:22:08 4: Connection accepted from FRM:192.168.1.25:1773
2015.11.19 20:22:08 5: FRM:>ff
2015.11.19 20:22:11 3: querying Firmata Firmware Version
2015.11.19 20:22:11 5: FRM:>f079f7
2015.11.19 20:22:11 5: FRM:<f079020643006f006e0066006900670075007200610062006c0065004600690072006d00610074006100f7
2015.11.19 20:22:11 3: Firmata Firmware Version: ConfigurableFirmata V_2_06
2015.11.19 20:22:11 5: FRM:>f069f7
2015.11.19 20:22:11 5: FRM:>f06bf7
2015.11.19 20:22:11 5: FRM:<f06a7f7f7f7f7f7f7f7f7f7f7f7f7f7f0001020304050607f7f06c7f7f0101091c7f01010308091c7f7f010103087f010103087f01017f01017f010103087f7f7f7f7f01017f01017f01017f01017f010106017f010106017f7f7ff7
2015.11.19 20:22:11 5: FRM:>f07a6807f7
2015.11.19 20:22:11 5: FRM:>f41206
2015.11.19 20:22:11 5: FRM:>f41306
2015.11.19 20:22:11 5: FRM:>f0780100f7
2015.11.19 20:22:11 1: I2C_TSL2561_Init start: 0/
2015.11.19 20:22:11 5: I2C_TSL2561_FirstCall: start
2015.11.19 20:22:11 5: FRM: Kommunikation mit I2C ...
2015.11.19 20:22:11 5: FRM: auf I2C lesen ...
2015.11.19 20:22:11 5: FRM:>f076390800010100f7
2015.11.19 20:22:11 5: FRM: Adresse: 57|Register: 128|1 byte(s)
2015.11.19 20:22:11 5: I2C_TSL2561_FirstCall: end
2015.11.19 20:22:11 5: FRM:>f40201
2015.11.19 20:22:11 5: FRM:>900000
2015.11.19 20:22:11 5: FRM:>f40303
2015.11.19 20:22:11 5: FRM:<f077390000010000f7
2015.11.19 20:22:11 5: FRM: onI2CMessage address: '57', register: '128' data: 0
2015.11.19 20:22:11 5: FRM: UPDATE Adresse: 57|Register: 128|Daten: 0
2015.11.19 20:22:11 5: FRM: UPDATE FRM_1_SENDSTAT => "Ok"
2015.11.19 20:22:11 5: Lichtsensor RX register 128 (Reg 0), 1 byte: 0
2015.11.19 20:22:11 5: I2C_TSL2561_I2CRcvControl: Sensor is disabled, Power off
2015.11.19 20:22:16 5: I2C_TSL2561_Enable: start
2015.11.19 20:22:16 5: FRM: Kommunikation mit I2C ...
2015.11.19 20:22:16 5: FRM: auf I2C lesen ...
2015.11.19 20:22:16 5: FRM:>f07639080a010100f7
2015.11.19 20:22:16 5: FRM: Adresse: 57|Register: 138|1 byte(s)
2015.11.19 20:22:16 5: FRM: Kommunikation mit I2C ...
2015.11.19 20:22:16 5: FRM: auf I2C schreiben ...
2015.11.19 20:22:16 5: FRM: Adresse: 57|Register: 128|Wert: 3
2015.11.19 20:22:16 5: FRM:>f076390000010300f7
2015.11.19 20:22:16 5: FRM: Kommunikation mit I2C ...
2015.11.19 20:22:16 5: FRM: auf I2C lesen ...
2015.11.19 20:22:16 5: FRM:>f076390800010100f7
2015.11.19 20:22:16 5: FRM: Adresse: 57|Register: 128|1 byte(s)
2015.11.19 20:22:16 5: I2C_TSL2561_Enable: end
2015.11.19 20:22:16 5: FRM:<f07739000a015000f7f077390000010300f7
2015.11.19 20:22:16 5: FRM: onI2CMessage address: '57', register: '138' data: [80]
2015.11.19 20:22:16 5: FRM: UPDATE Adresse: 57|Register: 138|Daten: 80
2015.11.19 20:22:16 5: FRM: UPDATE FRM_1_SENDSTAT => "Ok"
2015.11.19 20:22:16 5: Lichtsensor RX register 138 (Reg 10), 1 byte: 80
2015.11.19 20:22:16 5: I2C_TSL2561_I2CRcvID: sensorId TSL2561 Package T/FN/CL Rev. 0
2015.11.19 20:22:16 5: FRM: onI2CMessage address: '57', register: '128' data: [3]
2015.11.19 20:22:16 5: FRM: UPDATE Adresse: 57|Register: 128|Daten: 3
2015.11.19 20:22:16 5: FRM: UPDATE FRM_1_SENDSTAT => "Ok"
2015.11.19 20:22:16 5: Lichtsensor RX register 128 (Reg 0), 1 byte: 3
2015.11.19 20:22:16 5: I2C_TSL2561_I2CRcvControl: Sensor is enabled, Power on
2015.11.19 20:22:25 5: I2C_TSL2561_GetLuminosity: start
2015.11.19 20:22:25 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 1
2015.11.19 20:22:25 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.11.19 20:22:25 5: I2C_TSL2561_GetData: start...
2015.11.19 20:22:25 5: FRM: Kommunikation mit I2C ...

Moin,

Zeile 339 ist so richtig, Habe ich von Norbert geklaut.
Da wird init mit eval aufgerufen. Also im fall eines Fehlers schmiert dann nicht das ganze FHEM ab sondern es gibt eine Meldung zurück "$@", die über die Funktion Catch besser lesbar formattiert wird.
An Init werden alle Variablen, mit Ausnahme des Namens durchgereicht.

Wozu wird die Poll Funktion eigentlich benötigt? Es sollte reichen wenn du als poll Funktion einfach sie set Funktion mit readvalues aufrufst.

Alle I2C Befehle (also auch write) bekommen eine Rückmeldung über die I2C_TSL2561_I2CRec.
Dort sollte eigentlich die einzige State Machine drinnen sein. Schließlich steht und fällt alles mit der Antwortzeit vom Chip.
Für die State Machines könntest du eine Interne Variable verwenden um die aktuelle Position in der State Machine zu speichern (beim BMP konnte man mit der Registeradresse arbeiten, die mit an das I2C_TSL2561_I2CRec übergeben wird, aber evtl. ist das für dich nicht eindeutig genug ).

Der eigentliche Sinn der poll-Funktion ist ja die Festlegung des Messintervalls von fhem aus, also ob alle 5 / 10 / 20 min usw.
Hier im Modul wird bei einer langen Integrationszeit (Belichtungszeit) des Sensors an dem poll-Intervall rumgeschraubt, damit fhem in dieser Zeit nicht brachliegt, bis die Messung vorliegt (Bereich 12-400 ms).
Außerdem wird, wenn der Sensor gesättigt ist oder unterbelichtet, gain und integration-time optimiert und die Messung direkt wiederholt.

Dann werde ich mal das ganze Gedöns in die I2CRec reinpacken...

Im hash gibt es Variablen für die states:

# Data acquisition state machine with asynchronous wait
acquiState:
  ACQUI_STATE_DISABLED          => 0,
  ACQUI_STATE_ENABLED           => 1,
  ACQUI_STATE_DATA_AVAILABLE    => 2,
  ACQUI_STATE_DATA_CH0_RECEIVED => 3,
  ACQUI_STATE_DATA_CH1_RECEIVED => 4,
  ACQUI_STATE_ERROR             => 5,

# Luminosity calculation state machine
calcState:
  CALC_STATE_IDLE           => 0,
  CALC_STATE_DATA_REQUESTED => 1,
  CALC_STATE_DATA_RECEIVED  => 2,
  CALC_STATE_ERROR          => 3,

Ahso, verstehe.
Dafür würde ich aber eher einen zweiten Timer verwenden und den poll-interval Poll Interval sein lassen.

Für einen zusätzlichen Timer im NetzerI2C (http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/00_NetzerI2C.pm#l465) hatte ich mich bei Dietmar63 bedient. (NetzerI2C_InternalTimer($$) und NetzerI2C_RemoveInternalTimer($$))
Damit kannst du solche Abfragen einfacher lösen, ohne den poll-intervall permanent zu verbiegen

Wieder einen kleinen Schritt weiter. Das Modul liest jetzt rudimentär die broadband- und ir-Werte aus.
(Dazu evtl. readValues in der fhem-Oberfläche auslösen).

Siehe Anhang.

Noch weitere Anpassungen. Problem mit uninitialisierten Variablen behoben.

Worin besteht der Unterschied den Status des Moduls/des Sensors in den Internals zu aktualisieren oder in den Readings?

Vom Bauchgefühl her würde ich in den Readings die Messwerte (also das worauf es ankommt) und in den Internals die weitergehenden Infos veröffentlichen (in welchem Status befindet sich der Sensor/das Modul).

Gibt es da irgendwelche "offiziellen" Angaben?

@thymjan

ZitatWorin besteht der Unterschied den Status des Moduls/des Sensors in den Internals zu aktualisieren oder in den Readings?

Die Grundideen hierzu sind z.B. in der FHEM-Wiki (http://www.fhemwiki.de/wiki/DevelopmentModuleIntro#Internals) beschrieben - und um es vollständig zu machen: es gibt in FHEM neben Perl-Variablen 3 weitere Speichermöglichkeiten für Einzelwerte: interne Readings (nicht persistent, meist nur innerhalb des Moduls interessant), "normale" Readings (persistent, andere Module können z.B. über Änderungen benachrichtigt werden) und Attribute (persistent, meist zur Konfiguration durch den Anwender).

Habe da auch noch mal eine Frage an dich: Wie soll es insgesamt mit deiner Entwicklung weiter gehen? Natürlich geht es dir darum, dass das ganze unter Firmata funktioniert (vom Spaß, etwas selbst zu machen mal ganz abgesehen). Aber so wie du das Modul bisher umgebaut hast, ist es nicht mehr abwärtskompatibel, da du u.a. den HiPi-Support ersatzlos entfernt hast. Mit diesem Ansatz wäre der letzte Umbau des TSL2561-Moduls viel leichter gewesen und der Code wäre wahrscheinlich auch etwas übersichtlicher - aber solche "harten" Schnitte entsprechen nicht meinem Verständnis der Philosophie der FHEM-Modulentwicklung. Andererseits ist es genauso schade, wenn du eine Lösung für Firmata findest, die dann nicht in das Standardmodul übernommen werden kann.

Meine Unterstützung hast du, wenn die Kernprobleme für Firmata auf Basis einer angepassten Version des TSL2561-Moduls gelöst werden und ich vermute, dass das auch für kaihs die Voraussetzung ist, die erforderlichen Änderungen in die neue Modulversion zu übernehmen.

LG, Jens

@jensb

Danke für Deine Hinweise. Wie Du bereits an dem geänderten Code gesehen hast, bin ich kein großer Profi. Bin momentan immer noch dabei das Modul Stück für Stück weiter zu verstehen.

Es ist nicht in meinem Interesse Benutzer, die die HiPi-Version benutzen auszuschließen.
Denkst Du es ist unmöglich, die HiPi-Unterstützung wieder einzubauen?

Die Firmata stellt ja die höchsten Anforderungen an die Asynchronität. Wenn hier ein Weg gefunden wurde, das die State-Machines zuverlässig funktionieren, sollte es mit HiPi ja erst recht funktionieren, oder gehe ich hier falsch mit meiner Annahme?
Im aktuellen Modul wird ja auf den I2C-Bus geschrieben und sofort geprüft ob alles gut gegangen ist.
Das geht ja mit der Firmata nicht mehr. Ich muss den Befehl blind abschicken, und dann mit der Antwort, die einige Zeit später ankommt, entscheiden was der nächste Schritt ist.

Muss gestehen, dass ich mich mit HiPi noch überhaupt nicht beschäftigt habe.
Vielleicht kannst Du mir grob die Vorzüge/Nachteile von HiPi und RPII2C nennen?

Letztendlich befinde ich mich ja sonst in der Sackgasse. Ohne Eure Unterstützung bekomme ich das Modul sowieso nicht so hin, dass es massentauglich wird.

Grüße,
Stefan

Hi Stefan,

langsam sollte ich mir auch einen TSL2561 zulegen, dann kann ich mitreden ;).

Ketzerisch gesprochen macht die HiPi Unterstützung keinen Sinn mehr (es sei denn ich übersehe etwas, was ich nicht glaube). Es war Anfangs eine komfortable Lösung den I2C Bus anzusprechen.
Wenn ich mich recht erinnere hat kaihs das Modul vom BMP180 abgeleitet und dieses hatte anfangs nur HiPi Unterstützung.
Als ich das RPII2C Modul geschrieben habe, hatte ich auch erst die HiPi Schnittstelle verwendet (die immer noch genutzt werden kann). Später habe ich einen für den Anwender einfacheren Weg gefunden und so war HiPi nicht mehr notwendig und praktisch jedes Linux wir von dem Modul unterstützt.

HiPi lässt sich natürlich wieder implementieren.
Frage doch den kaihs mal nach seiner Meinung. Vielleicht ist es ihm auch nicht wichtig.

Hallo Stefan,

ich kenne leider alle Möglichkeiten der HiPi-API auch nicht, da HiPi (weil schlecht gepflegt) auf meinem Raspbian nicht funktioniert hat, als ich mit I2C angefangen habe, und daher kann ich auch keine HiPi-Varianten testen. Solange kaihs nicht der Meinung ist, dass wir auf den HiPi-Support verzichten können, muss der HiPi-Code unverändert bleiben.

Was den Ablauf für IODev anbetrifft, bestehen solche Einschränkungen nicht, denn hier können wir alle testen.

LG, Jens

Habe den ursprünglichen Modul-Code überflogen und kann die Anmerkung von klausw nicht ganz nachvollziehen, dass I2CRec im IODev-Kontext innerhalb des Moduls aufgerufen wird - das erfolgt nur im HiPi-Kontext und ist damit im Sinne des Erfinders, da HiPi die IODev-Callbacks nicht kennt.

Insofern ist das Modul im IODev-Modus bereits jetzt gut für das asynchone Lesen aufgestellt und sollte eigentlich keinen großen Umbau benötigen. Werde mir morgen mal die neue Version von Stefan ansehen.

Zitat von: jensb am 21 November 2015, 23:21:14
Habe den ursprünglichen Modul-Code überflogen und kann die Anmerkung von klausw nicht ganz nachvollziehen, dass I2CRec im IODev-Kontext innerhalb des Moduls aufgerufen wird - das erfolgt nur im HiPi-Kontext und ist damit im Sinne des Erfinders, da HiPi die IODev-Callbacks nicht kennt.

Insofern ist das Modul im IODev-Modus bereits jetzt gut für das asynchone Lesen aufgestellt und sollte eigentlich keinen großen Umbau benötigen. Werde mir morgen mal die neue Version von Stefan ansehen.

Jetzt wo du es sagst, stimmt...
So hatte ich es auch im BMP180 Modul von Dirk eingebaut.

Anbei die aktuelle für Firmata modifizierte Version des Moduls I2C_TSL2561.

Alles in allem immer noch sehr rudimentär. Nun ist es aber möglich mit den Attributen gain und integrationTime zu spielen (wenn AutoGain und AutoIntegrationTime auf Null gestellt sind).
Die state-machines habe ich nach wie vor noch nicht im Griff. Luminosity ist noch ausgeschaltet.

@klausw

ZitatSo hatte ich es auch im BMP180 Modul von Dirk eingebaut.

Dann bin ich beruhigt, denn ich habe deinen Patch für das BMP180 als Basis für den TSL2561 verwendet  ;)

Hallo Stefan,

habe mir deine letzte Version angesehen. Aufgrund der vielen Änderungen ist es aber nicht leicht zu erkennen, wo der Kern deines Ansatzes liegt. Habe den Eindruck, dass ein Teil der Änderungen nicht erforderlich ist.

Da ich leider nicht selbst unter Firmata testen kann, habe ich folgenden Vorschlag: Lass uns bitte zunächst meinen Ansatz vom 17.11. weiter verfolgen. Dazu benötige ich vor allem dein Logging als Rückmeldung. Dabei hilft es, wenn du das eine oder andere Logging hinzufügst/einkommentierst bzw. kleinere Änderungen durchführst und testest, wie sie sich auswirken.

Habe jetzt den I2C-Zugriff im Poll verriegelt. Der müsste jetzt warten, bis das IODev da ist, bevor er den 1. Buszugriff durchführt. Bin gespannt, was dann passiert.

Jens

Hier das log mit 51_I2C_TSL2561-Init-Variante2.pm.

Habe nach Bereitstellen des Moduls fhem mit "shutdown restart" neu gestartet und dann im Modul 1x auf "set update" geklickt.

2015.11.22 12:19:16 1: Including fhem.cfg
2015.11.22 12:19:17 3: telnetPort: port 7072 opened
2015.11.22 12:19:18 3: WEB: port 8083 opened
2015.11.22 12:19:18 3: WEBphone: port 8084 opened
2015.11.22 12:19:18 3: WEBtablet: port 8085 opened
2015.11.22 12:19:19 2: eventTypes: loaded 651 events from ./log/eventTypes.txt
2015.11.22 12:19:21 3: Connecting to database SQLite:dbname=/opt/fhem/fhem.db with user
2015.11.22 12:19:21 3: Connection to db SQLite:dbname=/opt/fhem/fhem.db established for pid 22766
2015.11.22 12:19:21 3: Connection to db SQLite:dbname=/opt/fhem/fhem.db established
2015.11.22 12:19:23 3: Opening CUL_0 device /dev/ttyACM0
2015.11.22 12:19:24 3: Setting CUL_0 serial parameters to 9600,8,N,1
2015.11.22 12:19:24 3: CUL_0 device opened
2015.11.22 12:19:24 3: CUL_0: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.11.22 12:19:24 3: Opening myJeeLink device /dev/ttyUSB0
2015.11.22 12:19:24 3: Setting myJeeLink serial parameters to 57600,8,N,1
2015.11.22 12:19:24 3: myJeeLink device opened
2015.11.22 12:19:26 3: freezer: I/O device is myJeeLink
2015.11.22 12:19:26 3: zeta: I/O device is myJeeLink
2015.11.22 12:19:26 3: SZi: I/O device is myJeeLink
2015.11.22 12:19:26 3: KiZi: I/O device is myJeeLink
2015.11.22 12:19:26 3: Bad: I/O device is myJeeLink
2015.11.22 12:19:26 3: FHEM2FHEM opening pimoroni at 192.168.1.23:7072
2015.11.22 12:19:26 3: FHEM2FHEM device opened (pimoroni)
2015.11.22 12:19:26 3: TABLETUI: new ext defined infix:ftui: dir:./www/tablet/:
2015.11.22 12:19:26 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui ...
2015.11.22 12:19:28 3: FHEM2FHEM opening raspi3 at 192.168.1.19:7072
2015.11.22 12:19:28 3: FHEM2FHEM device opened (raspi3)
2015.11.22 12:19:28 3: Aussen: I/O device is myJeeLink
2015.11.22 12:19:28 3: delta: I/O device is myJeeLink
2015.11.22 12:19:28 1: I2C_TSL2561_Define start: 3/Lichtsensor I2C_TSL2561 0x39
2015.11.22 12:19:28 1: Including ./log/fhem.save
2015.11.22 12:19:29 3: FRM_1: port 3031 opened
2015.11.22 12:19:29 0: Featurelevel: 5.6
2015.11.22 12:19:29 0: Server started with 64 defined entities (version $Id: fhem.pl 9868 2015-11-12 18:04:37Z rudolfkoenig $, os linux, user fhem, pid 22766)
2015.11.22 12:19:32 5: I2C_TSL2561_Poll: start
2015.11.22 12:19:32 5: I2C_TSL2561_Poll: 5 s
2015.11.22 12:19:34 4: Connection accepted from FRM:192.168.1.25:1077
2015.11.22 12:19:34 5: FRM:>ff
2015.11.22 12:19:37 3: querying Firmata Firmware Version
2015.11.22 12:19:37 5: FRM:>f079f7
2015.11.22 12:19:37 5: FRM:<f079020643006f006e0066006900670075007200610062006c0065004600690072006d00610074006100f7
2015.11.22 12:19:37 3: Firmata Firmware Version: ConfigurableFirmata V_2_06
2015.11.22 12:19:37 5: FRM:>f069f7
2015.11.22 12:19:37 5: FRM:>f06bf7
2015.11.22 12:19:37 5: FRM:<f06a7f7f7f7f7f7f7f7f7f7f7f7f7f7f0001020304050607f7f06c7f7f0101091c7f01010308091c7f7f010103087f010103087f01017f01017f010103087f7f7f7f7f01017f01017f01017f01017f010106017f010106017f7f7ff7
2015.11.22 12:19:37 5: FRM:>f07a6807f7
2015.11.22 12:19:37 5: FRM:>f41206
2015.11.22 12:19:37 5: FRM:>f41306
2015.11.22 12:19:37 5: FRM:>f0780100f7
2015.11.22 12:19:37 5: FRM:>f40201
2015.11.22 12:19:37 5: FRM:>900000
2015.11.22 12:19:37 5: FRM:>f40303
2015.11.22 12:19:37 5: I2C_TSL2561_Poll: start
2015.11.22 12:19:37 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.11.22 12:19:37 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.11.22 12:19:37 5: I2C_TSL2561_Enable: start
2015.11.22 12:19:37 5: FRM: Kommunikation mit I2C ...
2015.11.22 12:19:37 5: FRM: auf I2C lesen ...
2015.11.22 12:19:37 5: FRM:>f07639080a010100f7
2015.11.22 12:19:37 5: FRM: Adresse: 57|Register: 138|1 byte(s)
Use of uninitialized value in string eq at ./FHEM/51_I2C_TSL2561.pm line 1372.
2015.11.22 12:19:37 5: I2C_TSL2561_Enable: end
2015.11.22 12:19:37 5: I2C_TSL2561_Disable: start
2015.11.22 12:19:37 5: FRM: Kommunikation mit I2C ...
2015.11.22 12:19:37 5: FRM: auf I2C schreiben ...
2015.11.22 12:19:37 5: FRM: Adresse: 57|Register: 128|Wert: 0
2015.11.22 12:19:37 5: FRM:>f076390000010000f7
2015.11.22 12:19:37 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/51_I2C_TSL2561.pm line 1408.
2015.11.22 12:19:37 5: I2C_TSL2561_Disable: end
2015.11.22 12:19:37 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 0
2015.11.22 12:19:37 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.11.22 12:19:37 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 582.
2015.11.22 12:19:37 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 583.
2015.11.22 12:19:37 5: I2C_TSL2561_Poll: 300 s
2015.11.22 12:19:37 5: FRM:<f07739000a015000f7
2015.11.22 12:19:37 5: --------------------------
2015.11.22 12:19:37 5: FRM: onI2CMessage address: '57', register: '138' data: [80]
2015.11.22 12:19:37 5: FRM: UPDATE Adresse: 57|Register: 138|Daten: 80
2015.11.22 12:19:37 5: FRM: UPDATE FRM_1_SENDSTAT => "Ok"
2015.11.22 12:19:37 5: Lichtsensor RX register 10, 1 byte: 80
2015.11.22 12:19:37 5: I2C_TSL2561_I2CRcvID: sensorId TSL2561 Package T/FN/CL Rev. 0
2015.11.22 12:19:44 5: I2C_TSL2561_Poll: start
2015.11.22 12:19:44 5: I2C_TSL2561_Disable: start
2015.11.22 12:19:44 5: FRM: Kommunikation mit I2C ...
2015.11.22 12:19:44 5: FRM: auf I2C schreiben ...
2015.11.22 12:19:44 5: FRM: Adresse: 57|Register: 128|Wert: 0
2015.11.22 12:19:44 5: FRM:>f076390000010000f7
2015.11.22 12:19:44 5: I2C_TSL2561_Disable: end
2015.11.22 12:19:44 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.11.22 12:19:44 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.11.22 12:19:44 5: I2C_TSL2561_Enable: start
2015.11.22 12:19:44 5: FRM: Kommunikation mit I2C ...
2015.11.22 12:19:44 5: FRM: auf I2C lesen ...
2015.11.22 12:19:44 5: FRM:>f07639080a010100f7
2015.11.22 12:19:44 5: FRM: Adresse: 57|Register: 138|1 byte(s)
2015.11.22 12:19:44 5: I2C_TSL2561_Enable: end
2015.11.22 12:19:44 5: I2C_TSL2561_Disable: start
2015.11.22 12:19:44 5: FRM: Kommunikation mit I2C ...
2015.11.22 12:19:44 5: FRM: auf I2C schreiben ...
2015.11.22 12:19:44 5: FRM: Adresse: 57|Register: 128|Wert: 0
2015.11.22 12:19:44 5: FRM:>f076390000010000f7
2015.11.22 12:19:44 5: I2C_TSL2561_Disable: end
2015.11.22 12:19:44 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 0
2015.11.22 12:19:44 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.11.22 12:19:44 5: I2C_TSL2561_Poll: 300 s
2015.11.22 12:19:44 5: FRM:<f07739000a015000f7
2015.11.22 12:19:44 5: --------------------------
2015.11.22 12:19:44 5: FRM: onI2CMessage address: '57', register: '138' data: [80]
2015.11.22 12:19:44 5: FRM: UPDATE Adresse: 57|Register: 138|Daten: 80
2015.11.22 12:19:44 5: FRM: UPDATE FRM_1_SENDSTAT => "Ok"
2015.11.22 12:19:44 5: Lichtsensor RX register 10, 1 byte: 80
2015.11.22 12:19:44 5: I2C_TSL2561_I2CRcvID: sensorId TSL2561 Package T/FN/CL Rev. 0


Das funktioniert schon mal.
Jetzt funktioniert in den Lese- und Schreib-Funktion die _SENDSTAT Rückmeldung nicht. Deshalb kommt die Messung nicht zustande. Und State "I2C Error" persistiert.

Hier gehts weiter:

Zitat
2015.11.22 12:19:37 5: FRM: Adresse: 57|Register: 138|1 byte(s)
Use of uninitialized value in string eq at ./FHEM/51_I2C_TSL2561.pm line 1372.

Dahinter steckt, wie du ja bereits herausgefunden hast:

if ($hash->{$iodev->{NAME}.'_SENDSTAT'} eq 'error') {
      readingsSingleUpdate($hash, 'state', STATE_I2C_ERROR, 1);
      $success = 0;
}

Kannst du die Readings deines IODev zu diesem Zeitpunkt abfragen?

Eine mögliche Variante wäre nun:

if (!defined($hash->{$iodev->{NAME}.'_SENDSTAT'}) || $hash->{$iodev->{NAME}.'_SENDSTAT'} eq 'error') {
      readingsSingleUpdate($hash, 'state', STATE_I2C_ERROR, 1);
      $success = 0;
}

unter der Annahme, das dein IODev eigentlich nach dem 1. Senden das Reading "_SENDSTAT" haben müsste.

Alternativ, unter der Annahme, dass eigentlich alles gut ist:

if (defined($hash->{$iodev->{NAME}.'_SENDSTAT'}) && $hash->{$iodev->{NAME}.'_SENDSTAT'} eq 'error') {
      readingsSingleUpdate($hash, 'state', STATE_I2C_ERROR, 1);
      $success = 0;
}


Bitte probiere die beiden Varianten aus.

LG, Jens

Bei der ersten Variante ist die Fehlermeldung weg:
2015.11.22 13:25:52 5: I2C_TSL2561_Poll: start
2015.11.22 13:25:52 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.11.22 13:25:52 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.11.22 13:25:52 5: I2C_TSL2561_Enable: start
2015.11.22 13:25:52 5: FRM: Kommunikation mit I2C ...
2015.11.22 13:25:52 5: FRM: auf I2C lesen ...
2015.11.22 13:25:52 5: FRM:>f07639080a010100f7
2015.11.22 13:25:52 5: FRM: Adresse: 57|Register: 138|1 byte(s)
2015.11.22 13:25:52 5: I2C_TSL2561_Enable: end
2015.11.22 13:25:52 5: I2C_TSL2561_Disable: start
2015.11.22 13:25:52 5: FRM: Kommunikation mit I2C ...
2015.11.22 13:25:52 5: FRM: auf I2C schreiben ...
2015.11.22 13:25:52 5: FRM: Adresse: 57|Register: 128|Wert: 0
2015.11.22 13:25:52 5: FRM:>f076390000010000f7
2015.11.22 13:25:52 5: I2C_TSL2561_Disable: end
2015.11.22 13:25:52 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 0
2015.11.22 13:25:52 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.11.22 13:25:52 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 582.
2015.11.22 13:25:52 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 583.
2015.11.22 13:25:52 5: I2C_TSL2561_Poll: 60 s
2015.11.22 13:25:54 5: FRM:<f07739000a015000f7
2015.11.22 13:25:54 5: --------------------------
2015.11.22 13:25:54 5: FRM: onI2CMessage address: '57', register: '138' data: [80]
2015.11.22 13:25:54 5: FRM: UPDATE Adresse: 57|Register: 138|Daten: 80
2015.11.22 13:25:54 5: FRM: UPDATE FRM_1_SENDSTAT => "Ok"
2015.11.22 13:25:54 5: Lichtsensor RX register 10, 1 byte: 80
2015.11.22 13:25:54 5: I2C_TSL2561_I2CRcvID: sensorId TSL2561 Package T/FN/CL Rev. 0


Bei der Variante 2 auch:
2015.11.22 13:31:40 5: I2C_TSL2561_Poll: start
2015.11.22 13:31:40 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.11.22 13:31:40 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.11.22 13:31:40 5: I2C_TSL2561_Enable: start
2015.11.22 13:31:40 5: FRM: Kommunikation mit I2C ...
2015.11.22 13:31:40 5: FRM: auf I2C lesen ...
2015.11.22 13:31:40 5: FRM:>f07639080a010100f7
2015.11.22 13:31:40 5: FRM: Adresse: 57|Register: 138|1 byte(s)
2015.11.22 13:31:40 5: I2C_TSL2561_Enable: end
2015.11.22 13:31:40 5: I2C_TSL2561_Disable: start
2015.11.22 13:31:40 5: FRM: Kommunikation mit I2C ...
2015.11.22 13:31:40 5: FRM: auf I2C schreiben ...
2015.11.22 13:31:40 5: FRM: Adresse: 57|Register: 128|Wert: 0
2015.11.22 13:31:40 5: FRM:>f076390000010000f7
2015.11.22 13:31:40 5: I2C_TSL2561_Disable: end
2015.11.22 13:31:40 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 0
2015.11.22 13:31:40 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.11.22 13:31:40 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 582.
2015.11.22 13:31:40 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 583.
2015.11.22 13:31:40 5: I2C_TSL2561_Poll: 60 s
2015.11.22 13:31:40 5: FRM:<f07739000a015000f7
2015.11.22 13:31:40 5: --------------------------
2015.11.22 13:31:40 5: FRM: onI2CMessage address: '57', register: '138' data: [80]
2015.11.22 13:31:40 5: FRM: UPDATE Adresse: 57|Register: 138|Daten: 80
2015.11.22 13:31:40 5: FRM: UPDATE FRM_1_SENDSTAT => "Ok"
2015.11.22 13:31:40 5: Lichtsensor RX register 10, 1 byte: 80
2015.11.22 13:31:40 5: I2C_TSL2561_I2CRcvID: sensorId TSL2561 Package T/FN/CL Rev. 0


Mein IODev (FRM_1) erzeugt hier keine Readings.

Die Readings bzw. List von meinem Sensor:
Internals:
   DEF        0x39
   FRM_1_SENDSTAT Ok
   HiPi_used  0
   I2C_Address 57
   IODev      FRM_1
   NAME       Lichtsensor
   NR         123
   STATE      B: 0 I: 0 L: luminosity
   TYPE       I2C_TSL2561
   acquiState 0
   autoAddress 0
   calcState  0
   sensorEnabled 0
   sensorType TSL2561 Package T/FN/CL Rev. 0
   tsl2561Gain 16
   tsl2561IntegrationTime 1
   tsl2561Package 5
   Readings:
     2015-11-22 13:33:50   broadband       0
     2015-11-22 13:33:50   gain            16
     2015-11-22 13:33:50   integrationTime 0.101
     2015-11-22 13:33:50   ir              0
     2015-11-22 13:33:50   state           I2C Error
Attributes:
   IODev      FRM_1
   autoGain   1
   autoIntegrationTime 1
   floatArithmetics 1
   gain       16
   icon       weather_light_meter
   integrationTime 101
   normalizeRawValues 1
   poll_interval 1
   room       firmata
   stateFormat B: broadband I: ir L: luminosity
   verbose    5

Mit beiden Varianten scheint auf jeden Fall die Grundinitalisierung durchzulaufen, denn du bekommst:

Zitat
2015.11.22 13:25:54 5: I2C_TSL2561_I2CRcvID: sensorId TSL2561 Package T/FN/CL Rev. 0

Sehe ich das richtig, dass der 1. I2C-Zugriff reg138=80 ca. 2 Sekunden benötigt, um tatsächlich ausgeführt zu werden?

Zitat
2015.11.22 13:25:52 5: FRM: Adresse: 57|Register: 138|1 byte(s)
...
2015.11.22 13:25:54 5: FRM: UPDATE Adresse: 57|Register: 138|Daten: 80
2015.11.22 13:25:54 5: Lichtsensor RX register 10, 1 byte: 80

Hier steckt das Hauptproblem. Beim bisherigen Ansatz mit HiPi war der Bus-Zugriff blockend. Mit IODev unter Firmata geht das so nicht.

Kann man hier vielleicht die Blockierung wieder herstellen, indem man in i2cread/write wartet, bis I2CRec die Daten hat, ohne komplett zu blockieren?

Werde dass mal bei mir einbauen und testen, ob es zumindest ohne Firmata dann noch funktioniert.

Jens

2015.11.22 14:17:08 5: I2C_TSL2561_Poll: start
2015.11.22 14:17:08 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.11.22 14:17:08 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.11.22 14:17:08 5: I2C_TSL2561_Enable: start
2015.11.22 14:17:08 5: I2C_TSL2561_i2cread: calling CallFn now...
2015.11.22 14:17:08 5: FRM: Kommunikation mit I2C ...
2015.11.22 14:17:08 5: FRM: auf I2C lesen ...
2015.11.22 14:17:08 5: FRM:>f07639080a010100f7
2015.11.22 14:17:08 5: FRM: Adresse: 57|Register: 138|1 byte(s)
2015.11.22 14:17:08 5: I2C_TSL2561_i2cwrite: Address 57 | Register 138
2015.11.22 14:17:08 5: I2C_TSL2561_Enable: end
2015.11.22 14:17:08 5: I2C_TSL2561_Disable: start
2015.11.22 14:17:08 5: I2C_TSL2561_i2cwrite: calling CallFn now...
2015.11.22 14:17:08 5: FRM: Kommunikation mit I2C ...
2015.11.22 14:17:08 5: FRM: auf I2C schreiben ...
2015.11.22 14:17:08 5: FRM: Adresse: 57|Register: 128|Wert: 0
2015.11.22 14:17:08 5: FRM:>f076390000010000f7
2015.11.22 14:17:08 5: I2C_TSL2561_i2cwrite: Address 57 | Register 128
2015.11.22 14:17:08 5: I2C_TSL2561_Disable: end
2015.11.22 14:17:08 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 0
2015.11.22 14:17:08 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.11.22 14:17:08 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 583.
2015.11.22 14:17:08 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 584.
2015.11.22 14:17:08 5: I2C_TSL2561_Poll: 60 s
2015.11.22 14:17:08 5: FRM:<f07739000a015000f7
2015.11.22 14:17:08 5: --------------------------
2015.11.22 14:17:08 5: FRM: onI2CMessage address: '57', register: '138' data: [80]
2015.11.22 14:17:08 5: FRM: UPDATE Adresse: 57|Register: 138|Daten: 80
2015.11.22 14:17:08 5: FRM: UPDATE FRM_1_SENDSTAT => "Ok"
2015.11.22 14:17:08 5: Lichtsensor RX register 10, 1 byte: 80
2015.11.22 14:17:08 5: I2C_TSL2561_I2CRcvID: sensorId TSL2561 Package T/FN/CL Rev. 0

Orange ist der Lesevorgang, blau der Schreibvorgang, der inzwischen gestartet wird.

In diesem Beispiel läuft alles innerhalb einer Sekunde ab. Das lässt die Bandbreite der Kommunikationsdauer erahnen.

Warum willst Du blockieren? Was ist der Vorteil? Ich schreibe auf den I2C-Bus (hier bekomme ich keine Antwort) und schicke danach den Lesebefehl, und bekomme dann das Antwortpäckchen und kann prüfen ob's funktioniert hat.

ZitatWarum willst Du blockieren? Was ist der Vorteil?

Der gesamte vorhandene Ablauf ist sequentiell und die Blockierung in i2cread/write stellt sicher, das sich nichts überholt, wie das derzeit der Fall ist. Der 1. I2C-Zugriff muss erst beendet sein, bevor der nächste I2C-Zugriff starten kann, denn ohne die Antwort auf die 1. Aktion zu kennen, kann man nicht die richtige nächste Frage stellen.

Hier eine weitere Testversion. Auf dem RPi klappt es mit der Blockierung zwischen i2cread/write und I2CRec über das neue internal Reading "i2cOpInProgress". Dieser Ansatz mit Warteschleife ist nicht schön, aber einen Versuch wert.

Jens

Im Log ist die Blockierung nicht nachvollziehbar:
2015.11.22 14:40:37 5: I2C_TSL2561_Poll: start
2015.11.22 14:40:37 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.11.22 14:40:37 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.11.22 14:40:37 5: I2C_TSL2561_Enable: start
2015.11.22 14:40:37 5: FRM: Kommunikation mit I2C ...
2015.11.22 14:40:37 5: FRM: auf I2C lesen ...
2015.11.22 14:40:37 5: FRM:>f07639080a010100f7
2015.11.22 14:40:37 5: FRM: Adresse: 57|Register: 138|1 byte(s)
2015.11.22 14:40:37 5: I2C_TSL2561_Enable: end
2015.11.22 14:40:37 5: I2C_TSL2561_Disable: start
2015.11.22 14:40:37 5: FRM: Kommunikation mit I2C ...
2015.11.22 14:40:37 5: FRM: auf I2C schreiben ...
2015.11.22 14:40:37 5: FRM: Adresse: 57|Register: 128|Wert: 0
2015.11.22 14:40:37 5: FRM:>f076390000010000f7
2015.11.22 14:40:37 5: I2C_TSL2561_Disable: end
2015.11.22 14:40:37 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 0
2015.11.22 14:40:37 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.11.22 14:40:37 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 585.
2015.11.22 14:40:37 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 586.
2015.11.22 14:40:37 5: I2C_TSL2561_Poll: 60 s
2015.11.22 14:40:38 5: FRM:<f07739000a015000f7
2015.11.22 14:40:38 5: --------------------------
2015.11.22 14:40:38 5: FRM: onI2CMessage address: '57', register: '138' data: [80]
2015.11.22 14:40:38 5: FRM: UPDATE Adresse: 57|Register: 138|Daten: 80
2015.11.22 14:40:38 5: FRM: UPDATE FRM_1_SENDSTAT => "Ok"
2015.11.22 14:40:38 5: Lichtsensor RX register 10, 1 byte: 80
2015.11.22 14:40:38 5: I2C_TSL2561_I2CRcvID: sensorId TSL2561 Package T/FN/CL Rev. 0


Werde bei mir mehr Logging einbauen und mich gleich wieder melden.

Hier die letzte Version mit mehr Logging. Meine Vermutung ist, dass unter Firmata I2CRec bereits aufgerufen wird, bevor die Daten da sind und damit die Blockierung beendet. Mit dem zusätzlichen Logging müsste man das "sichtbar" machen können.

Habe die Schrittweite etwas erhöht (Logging war vorher zu lang):
2015.11.22 15:16:25 5: I2C_TSL2561_Poll: start
2015.11.22 15:16:25 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.11.22 15:16:25 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.11.22 15:16:25 5: I2C_TSL2561_Enable: start
2015.11.22 15:16:25 4: Lichtsensor: I2C_TSL2561_i2cread: INIT i2cOpInProgress=3000
2015.11.22 15:16:25 5: FRM: Kommunikation mit I2C ...
2015.11.22 15:16:25 5: FRM: auf I2C lesen ...
2015.11.22 15:16:25 5: FRM:>f07639080a010100f7
2015.11.22 15:16:25 5: FRM: Adresse: 57|Register: 138|1 byte(s)
2015.11.22 15:16:25 4: Lichtsensor: I2C_TSL2561_i2cread: START i2cOpInProgress=3000
2015.11.22 15:16:25 4: Lichtsensor: I2C_TSL2561_i2cread: LOOP i2cOpInProgress=2000
2015.11.22 15:16:25 4: Lichtsensor: I2C_TSL2561_i2cread: LOOP i2cOpInProgress=1000
2015.11.22 15:16:25 4: Lichtsensor: I2C_TSL2561_i2cread: LOOP i2cOpInProgress=0
2015.11.22 15:16:25 4: Lichtsensor: I2C_TSL2561_i2cread: END i2cOpInProgress=0
2015.11.22 15:16:25 5: I2C_TSL2561_Enable: end
2015.11.22 15:16:25 5: I2C_TSL2561_Disable: start
2015.11.22 15:16:25 4: Lichtsensor: I2C_TSL2561_i2cwrite: INIT i2cOpInProgress=3000
2015.11.22 15:16:25 5: FRM: Kommunikation mit I2C ...
2015.11.22 15:16:25 5: FRM: auf I2C schreiben ...
2015.11.22 15:16:25 5: FRM: Adresse: 57|Register: 128|Wert: 0
2015.11.22 15:16:25 5: FRM:>f076390000010000f7
2015.11.22 15:16:25 4: Lichtsensor: I2C_TSL2561_i2cwrite: START i2cOpInProgress=3000
2015.11.22 15:16:25 4: Lichtsensor: I2C_TSL2561_i2cwrite: LOOP i2cOpInProgress=2000
2015.11.22 15:16:25 4: Lichtsensor: I2C_TSL2561_i2cwrite: LOOP i2cOpInProgress=1000
2015.11.22 15:16:25 4: Lichtsensor: I2C_TSL2561_i2cwrite: LOOP i2cOpInProgress=0
2015.11.22 15:16:25 4: Lichtsensor: I2C_TSL2561_i2cwrite: END i2cOpInProgress=0
2015.11.22 15:16:25 5: I2C_TSL2561_Disable: end
2015.11.22 15:16:25 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 0
2015.11.22 15:16:25 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.11.22 15:16:25 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 585.
2015.11.22 15:16:25 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 586.
2015.11.22 15:16:25 5: I2C_TSL2561_Poll: 60 s
2015.11.22 15:16:25 5: FRM:<f07739000a015000f7
2015.11.22 15:16:25 5: --------------------------
2015.11.22 15:16:25 5: FRM: onI2CMessage address: '57', register: '138' data: [80]
2015.11.22 15:16:25 5: FRM: UPDATE Adresse: 57|Register: 138|Daten: 80
2015.11.22 15:16:25 5: FRM: UPDATE FRM_1_SENDSTAT => "Ok"
2015.11.22 15:16:25 5: Lichtsensor RX register 10, 1 byte: 80
2015.11.22 15:16:25 5: I2C_TSL2561_I2CRcvID: sensorId TSL2561 Package T/FN/CL Rev. 0
2015.11.22 15:16:25 4: Lichtsensor: I2C_TSL2561_I2CRec: END


FRM scheint erst gestartet zu werden und eine Antwort zu geben, nachdem Poll am Ende ist?

Bildlich gesprochen kann ich an einem Arbeitsplatz (in einer Funktion) entweder nur Briefe verschicken oder Briefe öffnen und Entscheidungen treffen.

Der Dreh- und Angelpunkt für die Entscheidungen ist hier die I2CRec-Funktion.
Hier werden die entsprechenden Unterfunktionen aufgerufen, die dann weitere "Briefe" verschicken dürfen.

Der Countdown läuft in 1000-Schritten statt in 20-Schritten und damit viel zu schnell:

Zitat
2015.11.22 15:16:25 4: Lichtsensor: I2C_TSL2561_i2cread: START i2cOpInProgress=3000
2015.11.22 15:16:25 4: Lichtsensor: I2C_TSL2561_i2cread: LOOP i2cOpInProgress=2000

Bitte ersetzte in i2cread/write versuchsweise

      $hash->{i2cOpInProgress} -= 20;

mit

      $hash->{i2cOpInProgress} = $hash->{i2cOpInProgress} - 20;


ZitatFRM scheint erst gestartet zu werden und eine Antwort zu geben, nachdem Poll am Ende ist?

Darauf müssen wir möglicherweise noch einmal zurück kommen.

In gekürzter Form, das Forum lässt so lange Posts nicht zu:
2015.11.22 15:11:38 5: I2C_TSL2561_Poll: start
2015.11.22 15:11:38 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.11.22 15:11:38 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.11.22 15:11:38 5: I2C_TSL2561_Enable: start
2015.11.22 15:11:38 4: Lichtsensor: I2C_TSL2561_i2cread: INIT i2cOpInProgress=3000
2015.11.22 15:11:38 5: FRM: Kommunikation mit I2C ...
2015.11.22 15:11:38 5: FRM: auf I2C lesen ...
2015.11.22 15:11:38 5: FRM:>f07639080a010100f7
2015.11.22 15:11:38 5: FRM: Adresse: 57|Register: 138|1 byte(s)
2015.11.22 15:11:38 4: Lichtsensor: I2C_TSL2561_i2cread: START i2cOpInProgress=3000
2015.11.22 15:11:38 4: Lichtsensor: I2C_TSL2561_i2cread: LOOP i2cOpInProgress=2980
2015.11.22 15:11:38 4: Lichtsensor: I2C_TSL2561_i2cread: LOOP i2cOpInProgress=2960
[...]
2015.11.22 15:11:39 4: Lichtsensor: I2C_TSL2561_i2cread: LOOP i2cOpInProgress=80
2015.11.22 15:11:39 4: Lichtsensor: I2C_TSL2561_i2cread: LOOP i2cOpInProgress=60
2015.11.22 15:11:39 4: Lichtsensor: I2C_TSL2561_i2cread: LOOP i2cOpInProgress=40
2015.11.22 15:11:39 4: Lichtsensor: I2C_TSL2561_i2cread: LOOP i2cOpInProgress=20
2015.11.22 15:11:39 4: Lichtsensor: I2C_TSL2561_i2cread: LOOP i2cOpInProgress=0
2015.11.22 15:11:39 4: Lichtsensor: I2C_TSL2561_i2cread: END i2cOpInProgress=0
2015.11.22 15:11:39 5: I2C_TSL2561_Enable: end
2015.11.22 15:11:39 5: I2C_TSL2561_Disable: start
2015.11.22 15:11:39 4: Lichtsensor: I2C_TSL2561_i2cwrite: INIT i2cOpInProgress=3000
2015.11.22 15:11:39 5: FRM: Kommunikation mit I2C ...
2015.11.22 15:11:39 5: FRM: auf I2C schreiben ...
2015.11.22 15:11:39 5: FRM: Adresse: 57|Register: 128|Wert: 0
2015.11.22 15:11:40 5: FRM:>f076390000010000f7
2015.11.22 15:11:40 4: Lichtsensor: I2C_TSL2561_i2cwrite: START i2cOpInProgress=3000
2015.11.22 15:11:40 4: Lichtsensor: I2C_TSL2561_i2cwrite: LOOP i2cOpInProgress=2980
2015.11.22 15:11:40 4: Lichtsensor: I2C_TSL2561_i2cwrite: LOOP i2cOpInProgress=2960
2015.11.22 15:11:40 4: Lichtsensor: I2C_TSL2561_i2cwrite: LOOP i2cOpInProgress=2940
[...]
2015.11.22 15:11:40 4: Lichtsensor: I2C_TSL2561_i2cwrite: LOOP i2cOpInProgress=20
2015.11.22 15:11:40 4: Lichtsensor: I2C_TSL2561_i2cwrite: LOOP i2cOpInProgress=0
2015.11.22 15:11:40 4: Lichtsensor: I2C_TSL2561_i2cwrite: END i2cOpInProgress=0
2015.11.22 15:11:41 5: I2C_TSL2561_Disable: end
2015.11.22 15:11:41 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 0
2015.11.22 15:11:41 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.11.22 15:11:41 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 585.
2015.11.22 15:11:41 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 586.
2015.11.22 15:11:41 5: I2C_TSL2561_Poll: 60 s
2015.11.22 15:11:41 5: FRM:<f07739000a015000f7
2015.11.22 15:11:41 5: --------------------------
2015.11.22 15:11:41 5: FRM: onI2CMessage address: '57', register: '138' data: [80]
2015.11.22 15:11:41 5: FRM: UPDATE Adresse: 57|Register: 138|Daten: 80
2015.11.22 15:11:41 5: FRM: UPDATE FRM_1_SENDSTAT => "Ok"
2015.11.22 15:11:41 5: Lichtsensor RX register 10, 1 byte: 80
2015.11.22 15:11:41 5: I2C_TSL2561_I2CRcvID: sensorId TSL2561 Package T/FN/CL Rev. 0
2015.11.22 15:11:41 4: Lichtsensor: I2C_TSL2561_I2CRec: END

Zitat
Der Dreh- und Angelpunkt für die Entscheidungen ist hier die I2CRec-Funktion.
Hier werden die entsprechenden Unterfunktionen aufgerufen, die dann weitere "Briefe" verschicken dürfen.

Beim BMP180-Modul ist das so, aber der TSL2561-Sensor ist da anspruchsvoller. Hier sind aufgrund der Einstellvorgänge mehrere I2C-Operationen hintereinander auszuführen, um das gewünschte Ergebnis zu erreichen, also z.B. Enable + Low-Data + Hi-Data + Disable. Das wird von I2C_TSL2561_GetData koordiniert.

Das Logging zeigt, das beim Warten keine Zeit vergeht. Aber das ist hoffentlich nicht wirklich so sondern mein Versehen. usleep braucht Mikrosekunden und nicht Millisekunden. Bitte vergrößere in i2cread/write den Startwert von 3000 auf 3000000.

Dann kann ich doch die Briefe in Reihe
Enable(write) + broadband(read) + ir(read) + Disable(write)
abschicken, und habe dann am I2CRec-"Schreibtisch" zunächst den Brief broadband und dann ir zum Lesen und Entscheiden vorliegen. Nun gut, dass sind dann 2 I2CRec-Schreibtischsitzungen... die liegen nicht zur selben Zeit vor.

Hätt' ich auch drauf kommen können, bin da neulich bei dem usleep auch drauf reingefallen.
Habe die Schrittweite auf 1/10 s in usleep gestellt, damit das Log noch einigermaßen erträglich bleibt.

2015.11.22 15:50:51 5: I2C_TSL2561_Poll: start
2015.11.22 15:50:51 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.11.22 15:50:51 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.11.22 15:50:51 5: I2C_TSL2561_Enable: start
2015.11.22 15:50:51 4: Lichtsensor: I2C_TSL2561_i2cread: INIT i2cOpInProgress=3000000
2015.11.22 15:50:51 5: FRM: Kommunikation mit I2C ...
2015.11.22 15:50:51 5: FRM: auf I2C lesen ...
2015.11.22 15:50:51 5: FRM:>f07639080a010100f7
2015.11.22 15:50:51 5: FRM: Adresse: 57|Register: 138|1 byte(s)
2015.11.22 15:50:51 4: Lichtsensor: I2C_TSL2561_i2cread: START i2cOpInProgress=3000000
2015.11.22 15:50:51 4: Lichtsensor: I2C_TSL2561_i2cread: LOOP i2cOpInProgress=2900000
[...]
2015.11.22 15:50:54 4: Lichtsensor: I2C_TSL2561_i2cread: LOOP i2cOpInProgress=200000
2015.11.22 15:50:54 4: Lichtsensor: I2C_TSL2561_i2cread: LOOP i2cOpInProgress=100000
2015.11.22 15:50:54 4: Lichtsensor: I2C_TSL2561_i2cread: LOOP i2cOpInProgress=0
2015.11.22 15:50:54 4: Lichtsensor: I2C_TSL2561_i2cread: END i2cOpInProgress=0
2015.11.22 15:50:54 5: I2C_TSL2561_Enable: end
2015.11.22 15:50:54 5: I2C_TSL2561_Disable: start
2015.11.22 15:50:54 4: Lichtsensor: I2C_TSL2561_i2cwrite: INIT i2cOpInProgress=3000000
2015.11.22 15:50:54 5: FRM: Kommunikation mit I2C ...
2015.11.22 15:50:54 5: FRM: auf I2C schreiben ...
2015.11.22 15:50:54 5: FRM: Adresse: 57|Register: 128|Wert: 0
2015.11.22 15:50:54 5: FRM:>f076390000010000f7
2015.11.22 15:50:54 4: Lichtsensor: I2C_TSL2561_i2cwrite: START i2cOpInProgress=3000000
2015.11.22 15:50:54 4: Lichtsensor: I2C_TSL2561_i2cwrite: LOOP i2cOpInProgress=2900000
[...]
2015.11.22 15:50:57 4: Lichtsensor: I2C_TSL2561_i2cwrite: LOOP i2cOpInProgress=100000
2015.11.22 15:50:57 4: Lichtsensor: I2C_TSL2561_i2cwrite: LOOP i2cOpInProgress=0
2015.11.22 15:50:57 4: Lichtsensor: I2C_TSL2561_i2cwrite: END i2cOpInProgress=0
2015.11.22 15:50:57 5: I2C_TSL2561_Disable: end
2015.11.22 15:50:57 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 0
2015.11.22 15:50:57 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.11.22 15:50:57 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 585.
2015.11.22 15:50:57 1: PERL WARNING: Use of uninitialized value in multiplication (*) at ./FHEM/51_I2C_TSL2561.pm line 586.
2015.11.22 15:50:57 5: I2C_TSL2561_Poll: 60 s
2015.11.22 15:50:58 5: FRM:<f07739000a015000f7
2015.11.22 15:50:58 5: --------------------------
2015.11.22 15:50:58 5: FRM: onI2CMessage address: '57', register: '138' data: [80]
2015.11.22 15:50:58 5: FRM: UPDATE Adresse: 57|Register: 138|Daten: 80
2015.11.22 15:50:58 5: FRM: UPDATE FRM_1_SENDSTAT => "Ok"
2015.11.22 15:50:58 5: Lichtsensor RX register 10, 1 byte: 80
2015.11.22 15:50:58 5: I2C_TSL2561_I2CRcvID: sensorId TSL2561 Package T/FN/CL Rev. 0
2015.11.22 15:50:58 4: Lichtsensor: I2C_TSL2561_I2CRec: END

Insgesamt verwendet das Modul 2 Zustandsautomaten: GetLuminosity als äußere Ablaufsteuerung, um FHEM nicht während der Integrationszeit des Sensors zu blockieren und GetData für das Lesen der Messdaten. Diese Abläufe kann man natürlich so umbauen, dass die Entscheidungen alle in I2CRec getroffen werden. Sollte das Blockieren in i2cread/write nicht funktionieren, bleibt möglicherweise auch nichts anderes übrig.

Ich bin mit meiner rudimentären Version nur über diesen Weg (I2CRec) weitergekommen.

Das neue Logging zeigt, dass jetzt zwar tatsächlich Zeit vergeht, aber das IODev wie befürchtet in dieser Zeit nicht arbeiten kann, weil FHEM blockiert ist. Deine Anmerkung mit dem Poll ist damit der richtige Hinweis gewesen.

Unter Firmata muss der I2C-Zugriff also komplett asynchron laufen. Damit müssten alle Methoden, die mehr als einen I2C-Zugriff machen, so aufgeteilt werden, dass die Folgeabläufe über I2CRec angestoßen werden, wie du bei deinen Tests bereits festgestellt hast. Werde mir das mal ansehen, aber das wird etwas dauern.

Man könnte vielleicht folgendes machen: Betroffen von mehrfachen I2C-Zugriffen sind direkt die Methoden Enable, SetIntegrationTime, SetGain und indirekt vor allem GetData. Da Enable der Henkel für alle andere Abläufe ist, sollte man hier anfangen. Leider ist Enable auch eine der komplexeren Methoden, da sie insgesamt 4 I2C-Zugriffe enthält (2x I2C_TSL2561_i2cread, 1x I2C_TSL2561_i2cwrite und 1x I2C_TSL2561_SetGain) und macht damit den Einstieg nicht leicht. Trotzdem könnte man so das Modul schrittweise umbauen, ohne die Abwärtskompatibilität zu verlieren.

Da meine Zeit überwiegend auf das Wochenende begrenzt ist, wäre es von Vorteil, wenn wir das zusammen machen könnten. Ich würde mit Enable einen Anfang machen, den du testen könntest. Wenn es klappt, könntest du die anderen Methoden analog umsetzten. Aber wie du mit deinem Versuch bereits gemerkt hast, wird das nicht "mal eben" erledigt sein.

Anbei ein erster Ansatz. Habe Enable entsprechend aufgeteilt, lokale Variablen in den Hash verlagert und lasse die Methode I2CRec den Zustand von Enable über nextOperation weiter schalten. Das Ganze ist noch sehr rudimentär, aber der Weg sollte sich erkennen lassen. Schau dir insbesondere auch die Änderungen am Ende von I2CRec an.

Die nächste Herausforderung ist es, die Methode SetGain genauso umzubauen. Allerdings muss man dabei zusätzlich berücksichtigen, dass SetGain von verschiedenen Methoden aufgerufen wird, so dass man für den Rücksprung ein 2stufiges "nextOperation" braucht. Vielleicht macht es Sinn, dazu nextOperation in den Hash aufzunehmen und daraus ein Array zu machen, um einen Call-Stack nachzubilden.

Für mich ist heute erst mal Schluss. Wenn du möchtest, kannst du dir gerne SetGain vornehmen.

Hallo Jens,

wird das alles so nicht wahnsinnig kompliziert?

Muss gestehen, dass dieser Weg meine Vorstellungskraft momentan etwas überfordert. Kann das grob nachvollziehen, was Du mit nextOperation gemacht hast. Aber wenn wir jetzt mehr als eine "Subroutine" haben, die von I2CRec aufgerufen werden, wie wird das anhand von nextOperation dann gemacht? Da müssen ja bestimmte nexOperation-Sets für jede Subroutine definiert werden, um unterscheiden zu können.

Also für SetGain z.B. Enable_WriteTimingRegister und Enable_ReadTimingRegister. Oder verstehe ich etwas falsch?

Für mich schreit das Modul nach Vereinfachung. Zum Beispiel die Funktionen SetGain und SetIntegrationTime machen doch eigentlich das selbe, oder? Könnte man da nicht eine draus machen?

Und ein Messwert auslesen mache ich immer mit
- Falls Gain oder IntegrationTime verändert wurde:
  TimingRegister schreiben (write) (Gain, IntegrationTime) und Auslesen (read) zur Kontrolle
- Messung starten mit Sensor einschalten (write), überprüfen ob Sensor eingeschaltet ist (read),
  nach IntegrationTime sind Messwerte broadbband und ir da
- mit zwei Lesezugriffen (read, read) Messwerte auslesen
- Sensor ausschalten (write, read)
Das könnte doch wie eine Worklist von *einer* Funktion abgearbeitet werden?

Dann Messwerte skalieren und Lux berechnen.
Falls Sensor gesättigt oder unterbelichtet, nach einem festgelegten Algorithmus Gain und IntegrationTime optimieren und ggf. sofort neue Messung starten.
Ansonsten warten bis zum nächsten Poll.

Sorry, wenn ich etwas im Mecker-Modus bin...

Wenn die von Dir genannten sub's mit nextOperation angepasst wurden, muss dann an GetLuminosity nichts geändert werden?

Was ist der Vorteil für den Benutzer wenn das intern mit so viel Sicherheitsüberprüfungen abläuft? Können da wirklich so viele Dinge schief laufen?

Mir fehlen da einfach die Grundlagen. Bin an die Sache eher mit "keep it simple" im Hinterkopf drangegangen.
Das Du mich jetzt nicht falsch verstehst, ich möchte hier nicht abspringen.
Aber falls Du etwas zu meiner Motivation beitragen kannst, bin ich Dir dankbar!  ;)

Gruß,
Stefan

Hallo Stefan,

im Kern hast du Recht, das schreit nach Vereinfachung, sonst versteht den Code bald niemand mehr.

Allerdings sollte man dabei die vorhandenen Features mitnehmen. Außerdem steckt in den Details des jetztigen Code viel Know-How und Testaufwand. Vor allem GetLuminosity sollte dabei nicht unter die Räder kommen.

Man könnte in Poll nach IODev-Init mit einem i2cwrite PowerOn starten und in I2CRec ein modifiziertes GetLuminosity integrieren, das immer mit einem PowerOff abschließt. Behält man i2cread und i2cwrite bei, könnte das sogar mit HiPi noch funktionieren. Zumindest im IODev-Modus dürfte FHEM durch die asynchrone  Verarbeitung noch etwas mehr entblockt werden.

Ich würde dazu wieder mit meiner Version vom 17.11. anfangen, und ähnlich wie von dir vorgeschlagen zuerst die Funktionalität von GetData umsetzten und dann die von GetLuminosity hinzufügen.

LG, Jens

Guten Morgen Jens,

wenn Du mir noch ein weiteres Brainstorming erlaubst:
Vorschlag:
Die Messungs-Worklist wird in Set gestartet. Nach Starten entweder "unsauber" mit einem usleep(integrationTime) oder entblockend mit einem weiteren Timer der den zweiten Teil – das Auslesen und Ausschalten des Sensors – nach der integrationTime aufruft.
Danach wird in Rec, getriggert mit der Meldung "Sensor aus", eine Low-Level Auswertung der Messwerte gestartet. Ist der Sensor unterbelichtet oder gesättigt, nach einem festgelegten Algorithmus gain und integrationTime angepasst und die Messung mit einem Aufruf von Set respektive update wiederholt.

Liegen dann valide Messwerte vor, dann diese skalieren.
Habe ich skalierte Messwerte vorliegen, wird Lux berechnet.

Was denkst Du?

Gruß,
Stefan

Hallo Stefan,

ich möchte deine Begeistung nicht abwürgen, aber die äußeren Anwendungsfunktionen des Moduls müssen unverändert bleiben. Dazu zählen u.a. das periodische Pollen von Messwerten, die diversen Auto-Funktionen, die IO-Fehlerbehandlung und die alternativen Berechnungsfunktionen.

Damit das Rad nicht nochmal erfunden werden muss, sollte dazu so viel wie möglich vorhandener Code verwendet werden. Die Änderungen sollten sich also vor allem auf die asynchrone Folgeverarbeitung konzentrieren und so übersichtlich wie möglich ausfallen, obwohl dies gerade bei asynchroner Verarbeitung nicht ganz so leicht ist.

Ich glaube nicht, dass wir mehr als einen Timer für den Grundtakt brauchen und der kann weiterhin Poll aufrufen. In Poll wird der 1. I2C-Zugriff gestartet und in I2CRec kommt hinter die vorhandene Empfangsverarbeitung eine neue Statemachine,  die sich an GetLuminosity und GetData orientiert, den Fehlertest aus Poll enthält und im Endeffekt ein paar States mehr hat, um die Hilffunktionen wie Enable, SetGain, etc. zu integrieren. Im Gutfall läuft alles I2C-Receive-Ereignisgesteuert und ein usleep wird dazu nicht benötigt.

Wenn du deinen Ansatz umsetzten würdest, hättest du zwar schnell die ersten Ergebnisse, aber es wäre viel Aufwand, alle  aktuellen Features funktionsidentisch nachträglich zu integrieren. Wahrscheinlich wird der Code dadurch am Ende nicht kürzer und die Entwicklung dauert dadurch länger.

LG, Jens

Hallo,

anbei eine Testversion für das Modul I2C_TSL2561 mit folgenden Änderungen:

• Die neue Version erkennt, ob die I2C-Schnittstelle Blockend oder Nicht-Blockend arbeitet und stellt sich darauf ein.
  
• Fix für das state-Reading, das nach Setzen des Attributes disable=1 dauerhaft auf "Disabled" blieb
  
• Dokumentation erweitert
  

Die neuer Version ist getestet mit RPII2C (Blockend) und FRM mit FirmataEthernet (Nicht-Blockend). Weitere Tests vor allem auch mit anderen I2C-Schnittstellen sind wünschenswert. Gibt es vielleicht jemanden, der HiPi im Einsatz hat?

Viel Spaß,
Jens

Gute Arbeit, Jens!

Funktioniert jetzt ohne Fehlermeldungen mit meinem Arduino Nano mit ConfigurableFirmata über Ethernet auch.
Danke.

Habe eben noch etwas mit gain und integrationTime rum gespielt. Dabei ist mir aufgefallen, dass die Einstellungen (Readings/Internals) nur verzögert angezeigt werden.
Zunächst habe ich autoGain und autoIntegrationTime auf Null gesetzt.
Dann die Empfindlichkeit ganz runter gedreht (Gain 1, integrationTime 13ms). Bis die eingestellten Werte angezeigt werden, muss ich attr-ändern 2-3x ausführen bis die Werte in den readings/internals angekommen sind.

Folgendes stimmt doch?
Internals:
tsl2561Gain
"0" bedeutet gain=1
"16" bedeutet gain=16

tsl2561IntegrationTime
"0" bedeutet integrationTime=13ms bzw. 0.0137s
"1" bedeutet integrationTime=101ms bzw. 0.101s
"2" bedeutet integrationTime=402ms bzw. 0.402s


Bei mir stand i2c-config bisher auf 1. Damit hat's bei mir funktioniert. Das Umstellen auf 30000 ergibt für mich keine sichtbare Veränderung.
Kann es sein, dass dies nur ein Schalter ist?

Grüße,
Stefan

Hallo Stefan,

freut mich zu höhren, dass es auch bei dir grundsätzlich funktioniert.

Die z.T. scheinbar hakelige Übernahme von gain und integrationTime ist mir auch schon aufgefallen. Werde versuchen herauszufinden, was dahinter steckt. Deine Wertezuordnung müsste stimmen, schau dir dazu die Konstanten im Kopfteil des Moduls an.

Den richtigen Wert für i2c-config beim TSL2561 wollte ich noch austesten. Dieser Parameter ist Teil der Firmata-Protokollspezifikation. Um z.B. den BMP180 mit 3fachem Oversampling nutzen zu können, braucht man knapp 30 Millisekunden Verzögerung zwischen Write und Read (Datenblatt) also 30000 für i2c-config. Wenn ich bei mir z.B. nur 20000 eintrage, klappt es nicht mehr. Du verwendest allerding ConfigureableFirmata und ich StandardFirmataEthernet - vielleicht gibt es da kleine Unterschiede in der Implementierung.

Grüße,
Jens

Hallo Stefan,

dein Hinweis bzgl. der Timing-Attribute war hilfreich. Das Timing wurde bisher sowohl beim Ändern der Attribute als auch bei der automatischen Regelung von Gain und Integration Time direkt zum TSL2561 geschickt. Vor allem das Setzen als Attribut konnte erst im 2. Anlauf gelingen, da der neue Werte für ein Attribut innerhalb der AttrFn über AttrVal() noch nicht zur Verfügung steht. Habe das Schreiben des Timings nun an einer festen Stelle in die State-Machine integriert.

Auch kann ich bestätigen, dass der TSL2561 keinen bestimmten Mindestwert für i2c-config im FRM-Modul benötigt.

Viel Spaß mit der überarbeiten Version,
Jens

Hallo Jens,

das Übernehmen der Attribute geht jetzt schneller. Sobald die nächste Messung ausgelöst wird, tauchen sie in den Readings auf.
Habe mich gerade gefragt, ob es hier sinnvoll wäre, direkt durch einen Attribut-Wechsel eine Messung auszulösen?

Weiter ist mir aufgefallen – stelle die Messwerte in einem Diagramm dar – dass es im IR-Kanal zu unregelmäßigen Fehlmessungen kommt, bzw. dieser gelegentlich Null-Werte liefert.
Weis nicht so recht wie ich den Fehler präzisieren kann.
Werd mal verbose hochdrehen.

Gruß,
Stefan

Im Anhang das Diagramm von gestern. Sensorempfindlichkeit ist maximal eingestellt. Sensor befindet sich im Keller. Die roten Spikes sind die Nullmessungen des IR-Kanals. Werte werden logarithmisch dargestellt.
In dem blau-roten Block am Morgen habe ich eine LED im 2-Minuten-Takt blinken lassen. Abtastfrequenz des Sensors war bis auf die letzte Stunde am Abend auf 1 Minute eingestellt.

Hallo Stefan

ZitatHabe mich gerade gefragt, ob es hier sinnvoll wäre, direkt durch einen Attribut-Wechsel eine Messung auszulösen?

Das ist Geschmackssache, nicht jeder mag das, weil man dann nicht mehrere Attribute gleichzeitig ändern kann, ohne eine Messung auszulösen, die ja durchaus mehr als eine 1 Sekunde benötigen kann. Gerade wenn man Perl-Code (notify, DOIF) zur Abfrage nutzt, ist das nicht so gut. Als User vor dem Webfrontend muss man nur auf den Update-Knopf drücken.

Zitat... dass es im IR-Kanal zu unregelmäßigen Fehlmessungen kommt, bzw. dieser gelegentlich Null-Werte liefert.

Dieses Verhalten ist nicht typisch für den Sensor. Ich habe keine Aufzeichnung für meinen Firmata-Testaufbau, aber in der Langzeitaufzeichnung meines Sensor, der direkt am RPi hängt, kann ich keine Null-Messwerte für IR sehen, außer es ist wirklich dunkel - auch nicht mit der neuen Modulversion in den letzten Stunden.

Da kommen mehrere Dinge als Ursachen in Frage, z.B. der Sensor selbst (defekt?, Umgebungseinflüsse?) und die Übertragung über Firmata. Bei Erstem hilft ein 2. Sensor, bei Zweitem kann verbose=5 beim FRM- und I2C-TSL2561 helfen.

Da ich in meinem Testaufbau sowohl einen BMP180 als auch einen TSL2561 verwende, ist mir aufgefallen, dass es vorkommen kann, dass 2 Module kurz nacheinander ein I2C-Read absetzten und die Antworten dann gleichzeitig in einem Paket eintreffen können. Der FHEM-Protokollhandler kann das z.T. nicht dekodieren (es gibt entsprechende Logs) - wegen Implementierungsschwächen oder weil die Antworten nicht spezifikationsgemäß sind. Wenn du mehr als ein I2C-Device an Firmata hast, könntest du die anderen vorübergehend abhängen.

Hier noch eine Möglichkeit: Über Firmata kann man scheinbar auch dann I2C-Register auslesen, wenn das Device nicht mehr am I2C-Bus angeschlossen ist (z.B. nach Hot-Unplug). Es gibt zwar einen Vorschlag, um von Firmata einen I2C-Busfehler an den Host zu melden (siehe http://firmata.org/wiki/Proposals (http://firmata.org/wiki/Proposals)), aber dieses Telegramm ist in FHEM noch nicht implementiert, und ich weiß auch nicht, ob es schon von StandardFirmata bzw. ConfigurableFirmata genutzt wird. Die Werte, die dann geliefert werden, sind jedenfalls nicht immer die letzten gelesenen Werte. Also kommt auch ein Verdrahtungsproblem zwischen Arduino und den I2C-Devices in Frage.

Viel Erfolg beim Suchen,
Jens

Hallo,

da es keine weiteren Rückmeldungen zum Betriebsverhalten des Moduls gab, hier der RC1 für die neue Version des 51_I2C_TSL2561.

Viel Spaß,
Jens

Hallo Jens,

hatte ja im vorigen Post das Problem beschrieben, dass es bei mir gelegentlich im Channel 1 zu nicht validen Daten kommt.

Hier das log dazu:
2015.12.28 02:59:04 5: FRM:>f076770074012e00f7
2015.12.28 02:59:04 5: FRM:>f076770876010200f7
2015.12.28 02:59:04 5: FRM:>f076770074013400f7
2015.12.28 02:59:04 5: FRM:>f076770876010300f7
2015.12.28 02:59:04 5: FRM:<f077770076014f005d00f7
2015.12.28 02:59:04 5: onI2CMessage address: '119', register: '246' data: [79,93]
2015.12.28 02:59:04 5: FRM:<f077770076012a016c010000f7
2015.12.28 02:59:04 5: onI2CMessage address: '119', register: '246' data: [170,236,0]
2015.12.28 03:02:37 5: I2C_TSL2561_Poll: start
2015.12.28 03:02:37 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.12.28 03:02:37 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.12.28 03:02:37 5: I2C_TSL2561_Enable: start
2015.12.28 03:02:37 5: FRM:>f076390000010300f7
2015.12.28 03:02:37 5: FRM:>f076390800010100f7
2015.12.28 03:02:37 5: I2C_TSL2561_Enable: end
2015.12.28 03:02:37 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 2
2015.12.28 03:02:37 5: I2C_TSL2561_Poll: 0.4 s
2015.12.28 03:02:37 5: FRM:<f077390000010300f7
2015.12.28 03:02:37 5: onI2CMessage address: '57', register: '128' data: [3]
2015.12.28 03:02:37 5: Lichtsensor RX register 0, 1 byte: 3
2015.12.28 03:02:37 5: I2C_TSL2561_I2CRcvControl: is enabled
2015.12.28 03:02:37 5: I2C_TSL2561_Poll: start
2015.12.28 03:02:37 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 3
2015.12.28 03:02:37 5: I2C_TSL2561_Poll: 0.403 s
2015.12.28 03:02:37 5: I2C_TSL2561_Poll: start
2015.12.28 03:02:37 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 3
2015.12.28 03:02:37 5: FRM:>f07639082c010200f7
2015.12.28 03:02:37 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:02:37 5: I2C_TSL2561_Poll: start
2015.12.28 03:02:37 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:02:37 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:02:37 5: FRM:<f07739002c0161010000f7
2015.12.28 03:02:37 5: onI2CMessage address: '57', register: '172' data: [225,0]
2015.12.28 03:02:37 5: Lichtsensor RX register 12, 2 byte: 225 0
2015.12.28 03:02:37 5: I2C_TSL2561_I2CRcvChan0 225
2015.12.28 03:02:37 5: I2C_TSL2561_Poll: start
2015.12.28 03:02:37 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 6
2015.12.28 03:02:37 5: FRM:>f07639082e010200f7
2015.12.28 03:02:37 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:02:37 5: I2C_TSL2561_Poll: start
2015.12.28 03:02:37 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:02:37 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:02:37 5: FRM:<f07739002e010e000000f7
2015.12.28 03:02:37 5: onI2CMessage address: '57', register: '174' data: [14,0]
2015.12.28 03:02:37 5: Lichtsensor RX register 14, 2 byte: 14 0
2015.12.28 03:02:37 5: I2C_TSL2561_I2CRcvChan1 14
2015.12.28 03:02:37 5: I2C_TSL2561_Poll: start
2015.12.28 03:02:37 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 7
2015.12.28 03:02:37 5: I2C_TSL2561_Disable: start
2015.12.28 03:02:37 5: FRM:>f076390000010000f7
2015.12.28 03:02:37 5: I2C_TSL2561_Disable: end
2015.12.28 03:02:37 5: I2C_TSL2561_GetLuminosity: calc state 2 acqui state 0
2015.12.28 03:02:37 5: I2C_TSL2561_Poll: 300 s
2015.12.28 03:04:04 5: FRM:>f076770074012e00f7
2015.12.28 03:04:04 5: FRM:>f076770876010200f7
2015.12.28 03:04:04 5: FRM:>f076770074013400f7
2015.12.28 03:04:04 5: FRM:>f076770876010300f7
2015.12.28 03:04:05 5: FRM:<f077770076014f005c00f7f077770076012a016b010000f7
2015.12.28 03:04:05 5: onI2CMessage address: '119', register: '246' data: [79,92]
2015.12.28 03:04:05 5: onI2CMessage address: '119', register: '246' data: [170,235,0]
2015.12.28 03:07:37 5: I2C_TSL2561_Poll: start
2015.12.28 03:07:37 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.12.28 03:07:37 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.12.28 03:07:37 5: I2C_TSL2561_Enable: start
2015.12.28 03:07:37 5: FRM:>f076390000010300f7
2015.12.28 03:07:37 5: FRM:>f076390800010100f7
2015.12.28 03:07:38 5: I2C_TSL2561_Enable: end
2015.12.28 03:07:38 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 2
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: 0.4 s
2015.12.28 03:07:38 5: FRM:<f077390000010300f7
2015.12.28 03:07:38 5: onI2CMessage address: '57', register: '128' data: [3]
2015.12.28 03:07:38 5: Lichtsensor RX register 0, 1 byte: 3
2015.12.28 03:07:38 5: I2C_TSL2561_I2CRcvControl: is enabled
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: start
2015.12.28 03:07:38 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 3
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: 0.403 s
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: start
2015.12.28 03:07:38 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 3
2015.12.28 03:07:38 5: FRM:>f07639082c010200f7
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: start
2015.12.28 03:07:38 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:07:38 5: FRM:<f07739002c0161010000f7
2015.12.28 03:07:38 5: onI2CMessage address: '57', register: '172' data: [225,0]
2015.12.28 03:07:38 5: Lichtsensor RX register 12, 2 byte: 225 0
2015.12.28 03:07:38 5: I2C_TSL2561_I2CRcvChan0 225
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: start
2015.12.28 03:07:38 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 6
2015.12.28 03:07:38 5: FRM:>f07639082e010200f7
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: start
2015.12.28 03:07:38 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:07:38 5: FRM:<f07739002e010e000000f7
2015.12.28 03:07:38 5: onI2CMessage address: '57', register: '174' data: [14,0]
2015.12.28 03:07:38 5: Lichtsensor RX register 14, 2 byte: 14 0
2015.12.28 03:07:38 5: I2C_TSL2561_I2CRcvChan1 14
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: start
2015.12.28 03:07:38 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 7
2015.12.28 03:07:38 5: I2C_TSL2561_Disable: start
2015.12.28 03:07:38 5: FRM:>f076390000010000f7
2015.12.28 03:07:38 5: I2C_TSL2561_Disable: end
2015.12.28 03:07:38 5: I2C_TSL2561_GetLuminosity: calc state 2 acqui state 0
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: 300 s
2015.12.28 03:09:05 5: FRM:>f076770074012e00f7
2015.12.28 03:09:05 5: FRM:>f076770876010200f7
2015.12.28 03:09:05 5: FRM:>f076770074013400f7
2015.12.28 03:09:05 5: FRM:>f076770876010300f7
2015.12.28 03:09:05 5: FRM:<f077770076014f005e00f7
2015.12.28 03:09:05 5: onI2CMessage address: '119', register: '246' data: [79,94]
2015.12.28 03:09:05 5: FRM:<f077770076012a0165010000f7
2015.12.28 03:09:05 5: onI2CMessage address: '119', register: '246' data: [170,229,0]
2015.12.28 03:12:38 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:38 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.12.28 03:12:38 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.12.28 03:12:38 5: I2C_TSL2561_Enable: start
2015.12.28 03:12:38 5: FRM:>f076390000010300f7
2015.12.28 03:12:38 5: FRM:>f076390800010100f7
2015.12.28 03:12:38 5: I2C_TSL2561_Enable: end
2015.12.28 03:12:38 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 2
2015.12.28 03:12:38 5: I2C_TSL2561_Poll: 0.4 s
2015.12.28 03:12:39 5: FRM:<f077390000010300f7
2015.12.28 03:12:39 5: onI2CMessage address: '57', register: '128' data: [3]
2015.12.28 03:12:39 5: Lichtsensor RX register 0, 1 byte: 3
2015.12.28 03:12:39 5: I2C_TSL2561_I2CRcvControl: is enabled
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 3
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: 0.403 s
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 3
2015.12.28 03:12:39 5: FRM:>f07639082c010200f7
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5 <--- warum auch immer, hier dauert's etwas länger
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: state machine stuck, aborting
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 5 <--- die Geduld ist vorzeitig am Ende
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.12.28 03:12:39 5: I2C_TSL2561_Disable: start   <-------------------------------- Sensor wird ausgeknipst ...
2015.12.28 03:12:39 5: FRM:>f076390000010000f7
2015.12.28 03:12:39 5: I2C_TSL2561_Disable: end
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: 300 s
2015.12.28 03:12:40 5: FRM:<f07739002c0162010000f7 <----------------------------- ohje, es kommt doch noch die Antwort von Chan0 ...
2015.12.28 03:12:40 5: onI2CMessage address: '57', register: '172' data: [226,0]
2015.12.28 03:12:40 5: Lichtsensor RX register 12, 2 byte: 226 0
2015.12.28 03:12:40 5: I2C_TSL2561_I2CRcvChan0 226
2015.12.28 03:12:40 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:40 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 6
2015.12.28 03:12:40 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.12.28 03:12:40 5: FRM:>f07639082e010200f7 <-------------------------------- Sensor ist off, Chan0 soll ausgelesen werden 8-0
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 5
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 5
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 5
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 5
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 5
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 5
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 5
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 5
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 5
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 5
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: state machine stuck, aborting
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 5
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.12.28 03:12:41 5: I2C_TSL2561_Disable: start <------------------------- Sensor wird nochmal ausgeknipst, aber er schläft ja schon
2015.12.28 03:12:41 5: FRM:>f076390000010000f7
2015.12.28 03:12:41 5: I2C_TSL2561_Disable: end
2015.12.28 03:12:41 5: I2C_TSL2561_Poll: 300 s
2015.12.28 03:12:41 5: FRM:<f07739002e0100000000f7 <------------------- Inhalt von Chan0, wenn keine Messung durchgeführt wurde
2015.12.28 03:12:41 5: onI2CMessage address: '57', register: '174' data: [0,0]
2015.12.28 03:12:41 5: Lichtsensor RX register 14, 2 byte: 0 0
2015.12.28 03:12:41 5: I2C_TSL2561_I2CRcvChan1 0
2015.12.28 03:12:41 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 7
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.12.28 03:12:41 5: I2C_TSL2561_Disable: start <-------------------- und zum 3. Mal ausknipsen
2015.12.28 03:12:41 5: FRM:>f076390000010000f7
2015.12.28 03:12:41 5: I2C_TSL2561_Disable: end
2015.12.28 03:12:41 5: I2C_TSL2561_GetLuminosity: calc state 2 acqui state 0
2015.12.28 03:12:41 5: I2C_TSL2561_Poll: 300 s
2015.12.28 03:14:05 5: FRM:>f076770074012e00f7
2015.12.28 03:14:05 5: FRM:>f076770876010200f7
2015.12.28 03:14:05 5: FRM:>f076770074013400f7
2015.12.28 03:14:05 5: FRM:>f076770876010300f7
2015.12.28 03:14:05 5: FRM:<f077770076014f005d00f7
2015.12.28 03:14:05 5: onI2CMessage address: '119', register: '246' data: [79,93]
2015.12.28 03:14:05 5: FRM:<f077770076012a0168010000f7
2015.12.28 03:14:05 5: onI2CMessage address: '119', register: '246' data: [170,232,0]
2015.12.28 03:17:41 5: I2C_TSL2561_Poll: start
2015.12.28 03:17:41 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.12.28 03:17:41 5: I2C_TSL2561_GetLuminosity: starting new measurement <--- Alles neu macht der Mai. Aber ohne enable????
2015.12.28 03:17:41 5: FRM:>f07639080a010100f7 <------ Sensor wie ist dein Name? ID wird ausgelesen...
2015.12.28 03:17:41 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 1
2015.12.28 03:17:41 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.12.28 03:17:41 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 8
2015.12.28 03:17:41 5: I2C_TSL2561_GetLuminosity: error, aborting
2015.12.28 03:17:41 5: I2C_TSL2561_Disable: start
2015.12.28 03:17:41 5: FRM:>f076390000010000f7 <----- böser Sensor, da wirst du zum 4. Mal ausgeknipst
2015.12.28 03:17:41 5: I2C_TSL2561_Disable: end
2015.12.28 03:17:41 5: I2C_TSL2561_Poll: 300 s
2015.12.28 03:17:41 5: FRM:<f07739000a015000f7 <----- ui, was kommt denn da? Mein Name ist Hase ...
2015.12.28 03:17:41 5: onI2CMessage address: '57', register: '138' data: [80]
2015.12.28 03:17:41 5: Lichtsensor RX register 10, 1 byte: 80
2015.12.28 03:17:41 5: I2C_TSL2561_I2CRcvID: sensorId TSL2561 Package T/FN/CL Rev. 0 <--- Ach Du bist's... Jetzt wird neu initialisiert!
2015.12.28 03:17:41 5: I2C_TSL2561_SetTimingRegister: time 2, gain 16
2015.12.28 03:17:41 5: FRM:>f076390001011200f7
2015.12.28 03:17:41 5: FRM:>f076390801010100f7
2015.12.28 03:17:42 5: FRM:<f077390001011200f7
2015.12.28 03:17:42 5: onI2CMessage address: '57', register: '129' data: [18]
2015.12.28 03:17:42 5: Lichtsensor RX register 1, 1 byte: 18
2015.12.28 03:17:42 5: I2C_TSL2561_I2CRcvTiming: time 2, gain 16
2015.12.28 03:17:42 5: I2C_TSL2561_Poll: start
2015.12.28 03:17:42 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.12.28 03:17:42 5: I2C_TSL2561_GetLuminosity: starting new measurement <---- und jetzt ist alles wieder beim Alten. Jippi!
2015.12.28 03:17:42 5: I2C_TSL2561_Enable: start
2015.12.28 03:17:42 5: FRM:>f076390000010300f7
2015.12.28 03:17:42 5: FRM:>f076390800010100f7
2015.12.28 03:17:42 5: I2C_TSL2561_Enable: end
2015.12.28 03:17:42 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 2
2015.12.28 03:17:42 5: I2C_TSL2561_Poll: 0.4 s
2015.12.28 03:17:42 5: FRM:<f077390000010300f7
2015.12.28 03:17:42 5: onI2CMessage address: '57', register: '128' data: [3]
2015.12.28 03:17:42 5: Lichtsensor RX register 0, 1 byte: 3
2015.12.28 03:17:42 5: I2C_TSL2561_I2CRcvControl: is enabled
2015.12.28 03:17:42 5: I2C_TSL2561_Poll: start
2015.12.28 03:17:42 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 3
2015.12.28 03:17:42 5: I2C_TSL2561_Poll: 0.403 s
2015.12.28 03:17:42 5: I2C_TSL2561_Poll: start
2015.12.28 03:17:42 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 3
2015.12.28 03:17:42 5: FRM:>f07639082c010200f7
2015.12.28 03:17:42 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:17:42 5: I2C_TSL2561_Poll: start
2015.12.28 03:17:42 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:17:42 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:17:42 5: FRM:<f07739002c0161010000f7
2015.12.28 03:17:42 5: onI2CMessage address: '57', register: '172' data: [225,0]
2015.12.28 03:17:42 5: Lichtsensor RX register 12, 2 byte: 225 0
2015.12.28 03:17:42 5: I2C_TSL2561_I2CRcvChan0 225
2015.12.28 03:17:42 5: I2C_TSL2561_Poll: start
2015.12.28 03:17:42 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 6
2015.12.28 03:17:42 5: FRM:>f07639082e010200f7
2015.12.28 03:17:42 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:17:42 5: I2C_TSL2561_Poll: start
2015.12.28 03:17:42 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:17:42 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:17:42 5: FRM:<f07739002e010e000000f7
2015.12.28 03:17:42 5: onI2CMessage address: '57', register: '174' data: [14,0]
2015.12.28 03:17:42 5: Lichtsensor RX register 14, 2 byte: 14 0
2015.12.28 03:17:42 5: I2C_TSL2561_I2CRcvChan1 14
2015.12.28 03:17:42 5: I2C_TSL2561_Poll: start
2015.12.28 03:17:42 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 7
2015.12.28 03:17:42 5: I2C_TSL2561_Disable: start
2015.12.28 03:17:42 5: FRM:>f076390000010000f7
2015.12.28 03:17:42 5: I2C_TSL2561_Disable: end
2015.12.28 03:17:42 5: I2C_TSL2561_GetLuminosity: calc state 2 acqui state 0
2015.12.28 03:17:42 5: I2C_TSL2561_Poll: 300 s
2015.12.28 03:19:05 5: FRM:>f076770074012e00f7
2015.12.28 03:19:05 5: FRM:>f076770876010200f7
2015.12.28 03:19:05 5: FRM:>f076770074013400f7
2015.12.28 03:19:05 5: FRM:>f076770876010300f7
2015.12.28 03:19:05 5: FRM:<f077770076014f005d00f7
2015.12.28 03:19:05 5: onI2CMessage address: '119', register: '246' data: [79,93]
2015.12.28 03:19:05 5: FRM:<f077770076012a0166010000f7
2015.12.28 03:19:05 5: onI2CMessage address: '119', register: '246' data: [170,230,0]
2015.12.28 03:22:42 5: I2C_TSL2561_Poll: start
2015.12.28 03:22:42 5: I2C_TSL2561_GetLuminosity: calc state 0 acqui state 0
2015.12.28 03:22:42 5: I2C_TSL2561_GetLuminosity: starting new measurement
2015.12.28 03:22:42 5: I2C_TSL2561_Enable: start
2015.12.28 03:22:42 5: FRM:>f076390000010300f7
2015.12.28 03:22:42 5: FRM:>f076390800010100f7
2015.12.28 03:22:42 5: I2C_TSL2561_Enable: end
2015.12.28 03:22:42 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 2
2015.12.28 03:22:42 5: I2C_TSL2561_Poll: 0.4 s
2015.12.28 03:22:42 5: FRM:<f077390000010300f7
2015.12.28 03:22:42 5: onI2CMessage address: '57', register: '128' data: [3]
2015.12.28 03:22:42 5: Lichtsensor RX register 0, 1 byte: 3
2015.12.28 03:22:42 5: I2C_TSL2561_I2CRcvControl: is enabled
2015.12.28 03:22:42 5: I2C_TSL2561_Poll: start
2015.12.28 03:22:42 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 3
2015.12.28 03:22:42 5: I2C_TSL2561_Poll: 0.403 s
2015.12.28 03:22:43 5: I2C_TSL2561_Poll: start
2015.12.28 03:22:43 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 3
2015.12.28 03:22:43 5: FRM:>f07639082c010200f7
2015.12.28 03:22:43 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:22:43 5: FRM:<f07739002c0161010000f7
2015.12.28 03:22:43 5: onI2CMessage address: '57', register: '172' data: [225,0]
2015.12.28 03:22:43 5: Lichtsensor RX register 12, 2 byte: 225 0
2015.12.28 03:22:43 5: I2C_TSL2561_I2CRcvChan0 225
2015.12.28 03:22:43 5: I2C_TSL2561_Poll: start
2015.12.28 03:22:43 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 6
2015.12.28 03:22:43 5: FRM:>f07639082e010200f7
2015.12.28 03:22:43 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:22:43 5: FRM:<f07739002e010e000000f7
2015.12.28 03:22:43 5: onI2CMessage address: '57', register: '174' data: [14,0]
2015.12.28 03:22:43 5: Lichtsensor RX register 14, 2 byte: 14 0
2015.12.28 03:22:43 5: I2C_TSL2561_I2CRcvChan1 14
2015.12.28 03:22:43 5: I2C_TSL2561_Poll: start
2015.12.28 03:22:43 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 7
2015.12.28 03:22:43 5: I2C_TSL2561_Disable: start
2015.12.28 03:22:43 5: FRM:>f076390000010000f7
2015.12.28 03:22:43 5: I2C_TSL2561_Disable: end
2015.12.28 03:22:43 5: I2C_TSL2561_GetLuminosity: calc state 2 acqui state 0
2015.12.28 03:22:43 5: I2C_TSL2561_Poll: 300 s

Bin grad in der Bahn, später mehr...

Grüße,
Stefan

01.01.2016 17:30 Kommentare hinzugefügt...

... noch was anderes:

Kannst Du mal bei Dir folgendes versuchen:

Sensor in Dunkelheit.
Messung 1 auslösen (update)
Licht einschalten
Messung 2 auslösen
Messung 3 auslösen

Wird bei Dir in Messung 2 schon der hellere Wert gemessen, oder erst in Messung 3?

Hallo Stefan,

das Log belegt meine letzten Vermutungen:

Normaler Ablauf:

Zitat
2015.12.28 03:07:38 5: I2C_TSL2561_I2CRcvControl: is enabled
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: start
2015.12.28 03:07:38 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 3
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: 0.403 s
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: start
2015.12.28 03:07:38 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 3
2015.12.28 03:07:38 5: FRM:>f07639082c010200f7
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: start
2015.12.28 03:07:38 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:07:38 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:07:38 5: FRM:<f07739002c0161010000f7
2015.12.28 03:07:38 5: onI2CMessage address: '57', register: '172' data: [225,0]
2015.12.28 03:07:38 5: Lichtsensor RX register 12, 2 byte: 225 0
2015.12.28 03:07:38 5: I2C_TSL2561_I2CRcvChan0 225

Empfangs-Timeout:

Zitat
2015.12.28 03:12:39 5: I2C_TSL2561_I2CRcvControl: is enabled
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 3
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: 0.403 s
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 3
2015.12.28 03:12:39 5: FRM:>f07639082c010200f7
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: 0.03 s
2015.12.28 03:12:39 5: I2C_TSL2561_Poll: start
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 1 acqui state 5
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: state machine stuck, aborting
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: calc state 3 acqui state 5
2015.12.28 03:12:39 5: I2C_TSL2561_GetLuminosity: error, aborting

Im Gut-Ablauf siehst du kurz vor Ende "2015.12.28 03:07:38 5: FRM:<f07739002c0161010000f7", das ist die Antwort auf "2015.12.28 03:07:38 5: FRM:>f07639082c010200f7". Im Fehlerfall fehlt die Antwort und wird auch nicht empfangen, obwohl das I2C_TSL2561-Modul mit "I2C_TSL2561_Poll: 0.03" mehrfach zusätzliche Wartezeiten spendiert.

In einem solchen Fall kann das I2C_TSL2561-Modul nichts mehr machen, als mit Fehler abzubrechen.

Den Test

Zitat
Sensor in Dunkelheit.
Messung 1 auslösen (update)
Licht einschalten
Messung 2 auslösen
Messung 3 auslösen

Wird bei Dir in Messung 2 schon der hellere Wert gemessen, oder erst in Messung 3?

habe ich für die Entwicklung auch verwendet und zwar in beiden Richtungen. Bereits mit der vorletzten vorgestellten Modulversion hat der Test plausible Werte geliefert und zwar sofort mit der nächsten Messung (also hier bei Messung 2).

Du hast definitiv ein Problem im Arduino-Umfeld und nicht im FHEM-Umfeld. Sieh dir bitte meine Hinweise zur Fehlersuche aus http://forum.fhem.de/index.php/topic,40875.msg378768.html#msg378768 (http://forum.fhem.de/index.php/topic,40875.msg378768.html#msg378768) noch einmal an. Es hat wahrscheinlich etwas mit deiner Hardware zu tun. Also überprüfe die Verdrahtung und tausche Komponenten.

In wie weit die Firmata-Firmware eine Rolle spielt, kann ich nicht sicher sagen. StandardFirmataEthernet 2.5 funktioniert auf einem Pro Mini 16 MHz mit W5100-LAN einwandfrei. ConfigurableFirmata 2.8 funktioniert auf einem Pro Mini 16 MHz mit W5100-LAN bzw. auf einem Teensy LC mit mit W5100-LAN oder ENC28J60-LAN problemlos, wenn man dazu FHEM modifiziert (siehe http://forum.fhem.de/index.php/topic,44525.0.html (http://forum.fhem.de/index.php/topic,44525.0.html)). Das ENC28J60-LAN habe ich auf einem Pro Mini nicht ausprobiert, da es mir aufgrund der Ressourcenwarnung des Compilers nicht sinnvoll erschien.

Grüße,
Jens

Hallo Jens,

an was für Verdrahtungsprobleme denkst Du?
Der Sensor liefert ja zu 99% richtige Werte.
Habe wie Du einen BMP180 am I2C-Bus und zwei LEDs 1x PWM und 1x OUT zum Testen.
Wie Du im log siehst werden da die Register ja fehlerfrei ausgelesen.
Allerdings fällt mir gerade ein, dass ich beim BMP180 das Oversampling runterdrehen musste, da es sonst auch zu Fehlern kam.
Auf welchem Wert hast Du das i2c-config im FRM-Device stehen?

Gruß,
Stefan

Zitatan was für Verdrahtungsprobleme denkst Du?

Kabellängen können eine Rolle spielen, aber vielleicht hast du auch ein schwächelndes I2C-Modul. Bitte unbedingt mal alles auseinander nehmen und auf kürzestem Weg nur den TSL2561 anschließen und nur diesen über FHEM abfragen, und, falls dann in Ordnung, schrittweise die anderen Funktionen wieder dazu nehmen. Besser wäre es noch, wenn du Tauschkomponenten hast.

ZitatAuf welchem Wert hast Du das i2c-config im FRM-Device stehen?

Ein Wert von 30000 ermöglicht 3faches Oversampling beim BMP180. Der Wert von i2c-config wirkt sich aber nicht auf das TSL2561 aus.

Grüße,
Jens

Hallo Stefan,

wg. meinen Firmata-Experimenten baue ich mein Breadboard momentan öfter um. Gestern hatte ich auch einen merkwürdigen Effekt mit dem TSL2561. Er war am Bus und hat geantwortet, aber der Messwert war immer Null. Abziehen, Power-Cycle, nichts half - bis ich die Pins am TSL2561-Board noch einmal nachgelötet habe. Allerdings hat es dann nur ein paar Minuten funktioniert, danach war der Messwert wieder nur Null. Wahrscheinlich hat die Wärme durch das Löten das Betriebsverhalten leicht in Richtung gut verschoben.

Versuche jetzt herauszufinden, wo die Ursache liegt. Momentan ändere ich den I2C-Bustakt des Arduino. In I2CFirmat.h hinter "Wire.begin();" "Wire.setClock(50000L); // bitrate, default 100 kHz, max. 400 kHz" einfügen. Schlüssig sind die bisherigen Ergebnisse aber nicht, aber ich habe zumindest wieder Messwerte.

Sollte das nichts bringen, werde ich mir noch mal Modultiming vornehmen. Möglicherweise ist der Jitter bei der Übertragung viel größer als von mir angenommen, dann reichen die vorgesehen Reserven nicht (immer). Vielleicht kannst du ja mal überprüfen, ob deine Null-Messerte z.B. eher bei eine IntegrationTime von 402 ms auftreten und bei 13 ms nie, das wäre ein Indikator.

Grüße und einen Guten Rutsch,
Jens

Hallo Jens,

kannst Du Dir mein log vom 28. nochmal ansehen. Habe es jetzt farblich unterlegt. Mir scheint (bedingt durch Netzwerkverkehr?), dass das Modul doch nicht lange genug auf die Antwort wartet. Schliesst ja mit "Poll: 300 s" einen Vorgang ab, und danach kommen dann trotzdem noch Antworten.
Oder verstehe ich da was falsch?

Wünsche Dir ebenfalls einen Guten Start ins Neue Jahr!

Viele Grüße,
Stefan

p.s. was mir neulich bei den (einfachen) Breadboards aufgefallen ist: die Federn verbiegen recht schnell. Steckt man Bauteile mit unterschiedlichen "Beinchen"-Durchmessern kann's da schon mal 'nen schlechten Kontakt geben. Habe etwas Erfahrung mit dem Löten, kalte Lötstellen kann ich bei mir eigentlich ausschliessen. Meinen Sensor betreibe ich momentan im dunklen Keller, deshalb ist die Integration-Time grundsätzlich im worst-case Bereich 402ms. Werde auch nochmals experimentieren.

Hallo Stefan,

kann im Log nichts neues finden, es fehlen die Antworten - trotz automatisch verlängerten Wartezeiten. Bei mir ist das anders gewesen, da sind die Antworten gekommen aber die Werte waren Null.

Wenn du den türkis markierten Bereich meinst, z.B.:

Zitat2015.12.28 03:19:05 5: FRM:>f076770074012e00f7

dann solltest du folgendes berücksichtigen: ein normales Firmata-Telegramm fängt mit f0 an, dann kommt ein Kommando-Byte, hier 76, und dann bei I2C-Zugriffen die Geräteadresse. 77 ist dein BMP180, während 39 der TSL2561 ist (siehe auch http://firmata.org/wiki/V2.3ProtocolDetails (http://firmata.org/wiki/V2.3ProtocolDetails)). Im türkis markierten Bereich wurde also der BMP180 abgefragt.

Grüße,
Jens

Gutes Neues Jahr, Jens!

habe jetzt nochmals über dem log gebrütet. Schau Dir meine (nicht ganz ernst gemeinten) Kommentare an.
Wenn ich's richtig verstehe, ist die State-Machine über die längere Wartezeit etwas pikiert und reagiert nicht ganz rational.
Das Modul versucht ab da eine Messung beim ausgeschalteten Sensor auszulösen was dann im Chaos endet.
Erst nach der verzögerten Neuinitialisierung gelingt die Messung wieder.

Kannst Du der State-Machine etwas mehr Geduld einräumen?

Grüße,
Stefan

Hallo Stefan,

auch dir ein frohes neues Jahr!

Das ist eine super Logauswertung. Die Abläufe scheinen bei dir z.T. doppelt solange zu brauchen, wie zu erwarten wäre. Natürlich könnte man mehr Wartezeit spendieren - dadurch würde aber die ganze Messung doppelt so lange dauern und davon wären alle Anwender betroffen und nicht nur die mit Firmata. Das ist noch nicht die richtige Lösung. Ein Seitenaspekt ist auch, das die State-Machine nicht gegen Out-Of-Order-Receives geschützt ist - dadurch fängt sie sich nicht ganz so schneller wieder wie theoretisch möglich wäre.

Solange die Ursache für den zusätzlichen Zeitbedarf unbekannt ist, bleibt unklar, welche max. Verzögerung tatsächlich gebraucht wird. Was hast du für einen Arduino und mit welchem Takt arbeitet er? Ist dein Netzwerk am RPi ausgelastet (USB-Ethernet) - oder vielleicht der USB-Port des BCM2835, weil du mehrere USB-Geräte hast, die ständig viel IO machen?

Grüße,
Jens

Hi Jens,

vermute, dass der höhere Zeitbedarf an meiner etwas komplexeren Netzwerkstruktur liegt. Wobei die ganze Schose im Durchschnitt nur zweimal am Tag auftritt (bei Messung alle 5 Minuten ist das bei 0,7% der Messungen). Würde ich auch eher als Out-of-Order-Receive bezeichnen.

Der Sensor hängt momentan an einem original Nano 3.0 (16Mhz) und ist per ENC28J60 am Ethernet angeschlossen. Von dort gehts über eine Powerline-Strecke (100MBit) über drei Stockwerke zum Raspi 2B. An dem hängt ein CUL, ein JeeLink und die Raspi-Kamera ist mit motion-control aktiviert. Der Raspi ist zu ca. 60% (bzw. load 1,5) ausgelastet.

Wobei ich nicht richtig verstehe warum dir ein längerer Timeout Kopfzerbrechen macht. Dies erzeugt ja nicht jedesmal eine längere Messung sondern rettet eher eine verunglückte. Wichtig ist doch nur, dass der Sensor nicht vor Ablauf der IntegrationTime abgefragt wird, ob die Antwort dann 180ms früher oder später eintritt fällt m.E. nicht so sehr ins Gewicht. Du schickst die Messwert-Anfrage ans FRM-Modul, dann kann das TSL-Modul ja die Blockung aufgeben. Aufgerufen wird es doch direkt nach Eintreffen des Messwertes wiederum vom FRM-Modul.
Bin auch der Meinung, dass Du die Chan0- und Chan1-Abfrage direkt hintereinander abschicken kannst, ohne zuerst auf die Antwort vom Chan0 warten zu müssen. Aber da steckst Du wahrscheinlich momentan tiefer drin als ich...

Grüße,
Stefan

Hi Stefan,

du hast bei deiner Bewertung den Firmata-Ablauf vor Augen. Drehe ich einfach nur an der Wartezeit, ändert sich tatsächlich nicht viel für Firmata, denn sobald das Antwort-Telegramm kommt, geht es weiter. Bei den blockenden I2C-APIs ist das aber anders. Da kommt nichts vom I2C-Bus wenn man nicht wieder etwas macht. Also wartet man da solange, bis die max. Wartezeit abgelaufen ist. Habe aber inzwischen eine Idee, wie ich das berücksichtigen kann. Vermeiden möchte ich aber nach Möglichkeit einen Firmata-Timing-Parameter im Modul. Auch was die "gleichzeitige" Abfrage der beiden Register betrifft hast du prinzipiell recht, aber auch da muss ich erst prüfen, wie das im Nicht-Firmata-Fall aussieht.

Melde mich, sobald ich das Modul angepasst habe.

Grüße,
Jens

Hallo,

anbei der Release Candidate 2 mit einer weiteren Optimierung des Timing bei asynchronem I2C-Bus-IO, getestet mit Firmata over LAN. Das Timeout für das Abfragen der Messwerte ist nun um den Faktor 10 höher, um bei stärkeren Telegramm-Laufzeitschwankungen einen Messabbruch zu vermeiden. Außerdem wird aus dem gleichen Grund länger gewartet, bevor nach dem Messstart mit dem Abfragen der Messwerte begonnen wird.

Eine relevante Änderung bei synchronem I2C-Bus-IO (RPII2C, etc.) sollte es nicht geben. Ein Test durch einen freiwilligen Tester wäre wünschenswert.

Im RC2 ist nun auch der Hotfix vom 26.12.2015 enthalten. Dadurch ändern sich die absoluten Helligkeitswerte unter gleichen Bedingungen, wenn floatArithmetics verwendet wird.

Viel Spaß,
Jens

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?

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

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

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

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

Hallo Stefan,

danke fuer die Rueckmeldung, dass ist super :D. 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

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

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

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)?

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

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:

ZitatWohnzimmer[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.

Hallo Stefan,

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

ZitatThe 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

    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

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:

ZitatConverts 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

Habe den Rundungsblock mit
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

Hallo Stefan,

der Source-Kommentar

Zitat... 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

Hallo Jens,

in einer homebridge Diskussion mit justme1968 hat sich eben herausgestellt, das der Wert luminosity der den lux-Wert ausgibt eigentlich (nach SI-Einheiten) nicht richtig bezeichnet ist.
Richtig wäre: illuminance
siehe: https://en.wikipedia.org/wiki/Lux (https://en.wikipedia.org/wiki/Lux)
Was haben die Anwender für Nachteile wenn die Bezeichnung des Readings korrigiert würde?

Gruß,
Stefan

Hallo Stefan,

im Datenblatt vom TSL2561 ist von "illuminance" die Rede und so steht es auch in der Einleitung der Modul-Hilfe.

Eine bloße Umbenennung des Readings wäre trivial und die erforderlichen Anpassungen an meiner eigenen FHEM-Installation wären überschaubar. Das muss aber nicht auf alle Anwender des Moduls zutreffen. Jeder Anwender des Moduls müsste seine Konfiguration anpassen und das steht in keinem Verhältnis zum funktionellen Nutzen.

Ein mögliche Lösung wäre es, ein neues Attribut für die Umschaltung des Reading-Namens einzuführen, das die alte Schreibweise bevorzugt. Dann müsste man aber für die neue Schreibweise bei jedem Erstellen eines Devices dieses Attribut erst setzten. Somit ist auch das noch keine optimale Lösung.

Grüße,
Jens

Zitat von: jensb am 01 Dezember 2016, 21:28:50
Ein mögliche Lösung wäre es, ein neues Attribut für die Umschaltung des Reading-Namens einzuführen, das die alte Schreibweise bevorzugt. Dann müsste man aber für die neue Schreibweise bei jedem Erstellen eines Devices dieses Attribut erst setzten. Somit ist auch das noch keine optimale Lösung.

Es wäre auch möglich, dieses Attribut für die alte Schreibweise zu machen.
In der State Funktion kannst du auf das alte Reading Prüfen und dort automatisch ein Attribut setzen wenn dieses Reading existiert.
Parallel dazu lässt sich eine Info ins Log schreiben.
Das neue Reading kann in diesem Fall auch zusätzlich parallel erscheinen.

Ich hatte so bei einem Portextender Modul eine Änderung gelöst. (später kannst du es dann rausnehmen und nur das neue Reading verwenden)