Firmata mit TSL2561

Begonnen von eitschdie, 09 September 2015, 15:54:56

Vorheriges Thema - Nächstes Thema

thymjan

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,

klausw

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

thymjan

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.

thymjan

Noch weitere Anpassungen. Problem mit uninitialisierten Variablen behoben.

thymjan

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?

jensb

@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 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
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

thymjan

@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

klausw

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.

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

jensb

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
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

jensb

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.
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

klausw

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

thymjan

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.

jensb

@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  ;)
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

jensb

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
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

thymjan

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.