Tasmota: tsl2561 i2c sensor is not detected when sht3x sensor connected to the bus

[Dimonix77]

Describe the bug
tsl2561 sensor is not detected when sht3x sensor connected to i2c bus.

_Also, make sure these boxes are checked [x] before submitting your issue - Thank you!_

• [x] _Searched the problem in issues and in the wiki_
• [x] _Hardware used_ : ESP-07 with "generic" module configuration
• [x] _Development/Compiler/Upload tools used_ : atom, platfomio, NodeMCU flasher, OTA
• [x] _If a pre-compiled release or development binary was used, which one?_ : sensors 6.4.0
• [x] _You have tried latest release or development binaries?_ : yes
• [x] _Provide the output of command_status 0 :

10:31:12 RSL: stat/sonoff/STATUS = {"Status":{"Module":18,"FriendlyName":["Sonoff"],"Topic":"sonoff","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}
10:31:12 RSL: stat/sonoff/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://thehackbox.org/tasmota/release/sonoff-sensors.bin","RestartReason":"Software/System restart","Uptime":"0T00:02:45","StartupUTC":"2018-12-17T09:28:27","Sleep":50,"BootCount":7,"SaveCount":17,"SaveAddress":"FB000"}}
10:31:12 RSL: stat/sonoff/STATUS2 = {"StatusFWR":{"Version":"6.4.0(sensors)","BuildDateTime":"2018-12-16T14:35:56","Boot":2,"Core":"2_4_2","SDK":"2.2.1(cfd48f3)"}}
10:31:12 RSL: stat/sonoff/STATUS3 = {"StatusLOG":{"SerialLog":4,"WebLog":2,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["smarthome",""],"TelePeriod":300,"SetOption":["00008009","558180C0","00000000"]}}
10:31:12 RSL: stat/sonoff/STATUS4 = {"StatusMEM":{"ProgramSize":550,"Free":452,"Heap":16,"ProgramFlashSize":1024,"FlashSize":4096,"FlashChipId":"16301C","FlashMode":3,"Features":["00000809","0FDEE794","0003A3A4","B7FFBFCC","0002BBC0"]}}
10:31:12 RSL: stat/sonoff/STATUS5 = {"StatusNET":{"Hostname":"sonoff-3310","IPAddress":"10.2.3.107","Gateway":"10.2.3.1","Subnetmask":"255.255.255.0","DNSServer":"10.2.3.22","Mac":"18:FE:34:FE:0C:EE","Webserver":2,"WifiConfig":4}}
10:31:12 RSL: stat/sonoff/STATUS6 = {"StatusMQT":{"MqttHost":"","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_FE0CEE","MqttUser":"DVES_USER","MqttType":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}}
10:31:12 RSL: stat/sonoff/STATUS7 = {"StatusTIM":{"UTC":"Mon Dec 17 09:31:12 2018","Local":"Mon Dec 17 10:31:12 2018","StartDST":"Sun Mar 25 02:00:00 2018","EndDST":"Sun Oct 28 03:00:00 2018","Timezone":"+01:00","Sunrise":"08:38","Sunset":"16:54"}}
10:31:12 RSL: stat/sonoff/STATUS10 = {"StatusSNS":{"Time":"2018-12-17T10:31:12","ANALOG":{"A0":88},"SHT3X-0x44":{"Temperature":25.5,"Humidity":20.8},"TempUnit":"C"}}
10:31:12 RSL: stat/sonoff/STATUS11 = {"StatusSTS":{"Time":"2018-12-17T10:31:12","Uptime":"0T00:02:45","SleepMode":"Dynamic","Sleep":50,"LoadAvg":36,"Wifi":{"AP":1,"SSId":"smarthome","BSSId":"00:0C:42:39:EF:10","Channel":2,"RSSI":52}}}

To Reproduce
Flash "sensors" version of firmware to esp8266 device, define SDA and SCL pins, restart, connect two sensors tsl2561 and sht3x to i2c bus, see serial log where only sht3x is detected.

Expected behavior
Both tsl2561 and sht3x i2c sensors must be detected by firmware, web page should display temperature, humidity and luminosity.

Screenshots
sht3x at 0x44, tsl2561 at 0x29
00:00:00 SHT: Sensor did not ACK command
00:00:00 I2C: SHT3X found at 0x44
10:55:08 MQT: stat/sonoff/RESULT = {"I2CScan":"Device(s) found at 0x29 0x44"}

tsl2561 at 0x39
00:00:00 SHT: Sensor did not ACK command
00:00:00 I2C: TSL2561 found at 0x39
11:25:20 MQT: stat/sonoff/RESULT = {"I2CScan":"Device(s) found at 0x39"}

sht3x at 0x44, tsl2561 at 0x49
00:00:00 SHT: Sensor did not ACK command
00:00:00 I2C: SHT3X found at 0x44
11:36:09 MQT: stat/sonoff/RESULT = {"I2CScan":"Device(s) found at 0x44 0x49"}

tsl2561 at 0x39, bme280 at 0x76
00:00:00 SHT: Sensor did not ACK command
00:00:00 I2C: BME280 found at 0x76
00:00:00 I2C: TSL2561 found at 0x39
11:41:09 MQT: stat/sonoff/RESULT = {"I2CScan":"Device(s) found at 0x39 0x76"}

sht3x at 0x44, tsl2561 at 0x29, bme280 at 0x76
00:00:00 SHT: Sensor did not ACK command
00:00:00 I2C: BME280 found at 0x76
00:00:00 I2C: SHT3X found at 0x44
10:59:24 MQT: stat/sonoff/RESULT = {"I2CScan":"Device(s) found at 0x29 0x44 0x76"}

Additional context
there is suspicious response "SHT: Sensor did not ACK command".

(Please, remember to close the issue when the problem has been addressed)

[Staars]

Hi,
it is possible, that there is fundamental incompatibility with this hardware combination, but maybe you can do some additional tests, before we give up here.
Can you compile this on your machine and:

• disable Sht and Sht3 (for instance in my_user_config.h)
  -repeat your showings from above.

P.S.: SHT: Sensor did not ACK command is a response from the SHT1x-driver. Theses sensor-1-types do not really conform to the I2C-standard and have to be handled in special way.

[Dimonix77]

Hi,
Now I have only these i2c related lines in my_user_config.h :
`#define USE_I2C // I2C using library wire (+10k code, 0k2 mem, 124 iram)

ifdef USE_I2C

define USE_TSL2561

endif // USE_I2C`

and upload freshly compiled firmware
stat/sonoff/STATUS2 = {"StatusFWR":{"Version":"6.4.0.1(sensors)","BuildDateTime":"2018-12-19T16:19:13","Boot":2,"Core":"2_4_2","SDK":"2.2.1(cfd48f3)"}}
but the serial debug output is the same
00:00:00 Project sonoff Sonoff (Topic sonoff, Fallback DVES_FE0CEE, GroupTopic sonoffs) Version 6.4.0.1(sensors)-2_4_2 00:00:00 SHT: Sensor did not ACK command 00:00:00 I2C: SHT3X found at 0x44 16:21:18 MQT: stat/sonoff/RESULT = {"I2CScan":"Device(s) found at 0x39 0x44"}
It looks like both sht and sht3x drivers are unconditionally compiled in
edit1: sensors are redefined in sonoff_post.h ... next try
edit2: tsl2561 is not detected even with undefined USE_SHT3X and USE_SHT

[Staars]

Depending on your build target, you also have to adjust sonoff_post.h.

[Staars]

An additional question:
Is this 10:55:08 MQT: stat/sonoff/RESULT = {"I2CScan":"Device(s) found at 0x29 0x44"} really 0x29 and not 0x39?

[Dimonix77]

An additional question:
Is this 10:55:08 MQT: stat/sonoff/RESULT = {"I2CScan":"Device(s) found at 0x29 0x44"} really 0x29 and not 0x39?

Yes, I tested tsl2561 with all possible addresses 0x29, 0x39 and 0x49.

[Dimonix77]

I took another set of hardware: esp12 module and two new sensors. Unfortunately the result is the same. I think that it would useful to try sensors at fixed known i2c addresses, without bus scan procedure. Unfortunately, I am not familiar with tasmota code. If someone can give me a hint on how to overcome i2c bus scan and define static addresses for the sensors.

[Staars]

I am not sure, if we talk past each other here, but the usual Tasmota-driver checks the known adresses for its device (mostly 2-3) and checks, if the device responds.
All compiled I2c-drivers get their chance and are searching for their corresponding devices - and will have success or not.

What I wanted to figure out is, if the SHT3 "deactivates" the tsl2561 for fundamental hardware reasons or if the Tasmota-SHT(1or3)-driver does it.
That's why I asked to deactivate these SHT-drivers.

BTW, out of curiosity I just ordered these sensors, but this will take a few (30-50) days ;)

[Dimonix77]

I compiled firmware with i2c driver for tsl2561 only. Unfortunately, the result is still the same. It means that sht/sht3x code doesn't affect tsl2561 sensor. We need somebody's help with logic analyzer to see what is happening at i2c bus level. Sorry, I cannot help with this. I am always ready to verify proposed code changes, if any.

[Staars]

Thank you for this valuable infos!
I agree with your conclusion.

Until I get my hands on these things, I can not do anything. Even then it might be possible, that these incompatibilities will remain.

[digiblur]

To rule out the possible hardware issue/conflict have you tried this with ESPEasy? Not sure if they support these two sensors though.

[Dimonix77]

Thanks for this good hint, @digiblur ! I've completely forgotten about other firmwares to try.
A good one from wifi-iot.com does support both sensors .. and it does work!

[Dimonix77]

ESPEasy also does support and detect both tsl2561 and sht31 correctly.

[Staars]

Okay, then chances are good, that we will achieve this in Tasmota too.
But I will have to wait for the sensors in order to work on it.
Or we find some other volunteer ...

[mike2nl]

I have one tsl2561 from Adafruit Flora but badly no time right now.
Possible in the mean time have to see over xmas.
I'm busy with the MAX31855 and a thermocouple sensor

i could do it with a BME280 and the TLS2561 on a sonoff sv, would this help Staars?
Or i could lean you the TLS sensor.

TLS2561 https://www.adafruit.com/product/1246

[Staars]

My best guess is, that we need a SHT3 in the mix for testing.
I am pretty optimistic, that we get it solved but at least for me, it will take a while to get the (sht)hardware.

[mike2nl]

Ok will look for a SHT sensor. Report later back.

[mike2nl]

Have now orderd all three sensors in a local store for a really good price (xmas price, yeah).
They will be here tomorrow or at least on monday.

So i can help out over xmas.

BTW: need them too for a neighbour. he saw much more in my house now he will spend money, yeah.

[mike2nl]

@Dimonix77

can you do a GPIO on the console for me, please.
And post i here.

[Dimonix77]

Here it is:
00:00:00 SRC: Restart 00:00:00 Project sonoff Sonoff (Topic sonoff, Fallback DVES_FE0CEE, GroupTopic sonoffs) Version 6.4.0(sensors)-2_4_2 00:00:00 SHT: Sensor did not ACK command 00:00:00 I2C: BME280 found at 0x76 00:00:00 I2C: SHT3X found at 0x44 12:05:02 CMD: gpio 12:05:02 RSL: stat/sonoff/RESULT = {"GPIO0":"6 (I2C SDA)","GPIO1":"0 (None)","GPIO2":"5 (I2C SCL)","GPIO3":"0 (None)","GPIO4":"0 (None)","GPIO5":"0 (None)","GPIO12":"0 (None)","GPIO13":"0 (None)","GPIO14":"0 (None)","GPIO15":"0 (None)","GPIO16":"0 (None)"} 12:05:27 CMD: i2cscan 12:05:27 SRC: Serial 12:05:27 RSL: Received Topic /i2cscan, Data Size 0, Data 12:05:27 RSL: Group 0, Index 1, Command I2CSCAN, Data 12:05:27 RSL: stat/sonoff/RESULT = {"I2CScan":"Device(s) found at 0x39 0x44 0x76"}

[mike2nl]

1st Thanks for the fast answer.

Test/Adivse:
It is possible that you change the following?

Set "GPIO0":"6 (I2C SDA)" to "GPIO3":"6 (I2C SDA)"

so that you get:
"GPIO2":"5 (I2C SCL)", "GPIO3":"6 (I2C SDA)"
GPIO 2 = I2C SCL
GPIO 3 = I2C SDA

and then set back GPIO 0 to "GPIO0":"0 (None)"
GPIO 0 = NONE

And then run again some test and check the web ui, status 0 or mqtt for sensor values, please.

[Dimonix77]

gpio3 is in use for serial console Rx. First, I had to disable serial console seriallog 0 . The result was as expected - tsl2561 sensor is not detected.

13:03:36 RSL: stat/sonoff/STATUS8 = {"StatusSNS":{"Time":"2018-12-23T13:03:36","ANALOG":{"A0":98},"BME280":{"Temperature":23.2,"Humidity":22.8,"Pressure":986.4},"SHT3X-0x44":{"Temperature":23.0,"Humidity":24.3},"PressureUnit":"hPa","TempUnit":"C"}}
13:05:21 RSL: stat/sonoff/RESULT = {"GPIO0":"0 (None)","GPIO1":"0 (None)","GPIO2":"5 (I2C SCL)","GPIO3":"6 (I2C SDA)","GPIO4":"0 (None)","GPIO5":"0 (None)","GPIO12":"0 (None)","GPIO13":"0 (None)","GPIO14":"0 (None)","GPIO15":"0 (None)","GPIO16":"0 (None)"}
13:07:25 RSL: stat/sonoff/RESULT = {"I2CScan":"Device(s) found at 0x39 0x44 0x76"}

Since esp8266 doesn't have hw twi controller, all gpios are equal for i2c bit banging.

[mike2nl]

Thanks for your answer @Dimonix77.
I think i have time on 25 or 26 comming days to do it for my self.
Have to search all things togehter, os, sonoff sv and the sensors.
All sensors were delivered yesterday by the friendly postgirl.

Will report when i have done things.

[mike2nl]

So today is the day. have todo some soldering and then test it.
Unfortinally i have no 2.4.2 running right now in Arduino Ide.
I have the 2.5.2 beta 2 running.
Will test first the tls for himself and then compile again with the next sensor until all three are there. I also will change the position in the bus to see is the sht the one who makes trouble.

Looked around about the tls and sht in issues closed along ago and some more younger once.

• https://github.com/arendst/Sonoff-Tasmota/issues/3681
• https://github.com/arendst/Sonoff-Tasmota/issues/2415
• https://github.com/arendst/Sonoff-Tasmota/issues/1314

Looks like the tls and the sht are both are diva's which needs special things.
Will test with breadboard and with the Crowtail - I2C Hub = https://opencircuit.nl/ContentImage/115574/crop/900-600/Crowtail-I2C-Hub.jpg

With the i2c hub i had never an issue about the bus stability and i have a lot laying around.
Got them for 30cent each some month ago.
So let see much later on the day, haha.

[mike2nl]

@Staars

So tests are done and that very fast with help from the I2C Hub.
The TSL2561 is a real diva, that bitch ;-)

here are my data:
..
Hardware: Sonoff SV
Firmware: 6.4.1.1 20181224
Core: 2.5.2
Tool: arduino IDE

..
13:20:29 CMD: gpio
13:20:29 RSL: RESULT = {"GPIO1":"0 (None)","GPIO3":"0 (None)","GPIO4":"5 (I2C SCL)","GPIO5":"6 (I2C SDA)","GPIO14":"0 (None)"}

..
Sensors:
..
BME280
SHT31-D
TSL2561

..
HOW = Sonoff SV <-> Sensor 1 <-> Sensor 2 <-> Sensor 3
..
SV <-> TSL <-> BME <-> SHT = only SHT & BME visible in web ui
..
13:23:46 CMD: i2cscan
13:23:46 RSL: RESULT = {"I2CScan":"Device(s) found at 0x39 0x44 0x76"}
..
SV <-> BME <-> TSL <-> SHT = only SHT & BME visible in web ui
..
13:25:17 CMD: i2cscan
13:25:17 RSL: RESULT = {"I2CScan":"Device(s) found at 0x39 0x44 0x76"}

..
HOW = Sonoff SV <-> Sensor 1 <-> Sensor 2
..
SV <-> SHT <-> TSL = only SHT visible in web ui
..
13:13:56 CMD: i2cscan
13:13:56 RSL: RESULT = {"I2CScan":"Device(s) found at 0x39 0x44"}
..
SV <-> TSL <-> SHT = only SHT visible in web ui
..
13:05:21 CMD: i2cscan
13:05:21 RSL: RESULT = {"I2CScan":"Device(s) found at 0x39 0x44"}

..
HOW = SV <-> SHT <-> BME280 = OK both visible in web ui
..
13:08:16 CMD: i2cscan
13:08:16 RSL: RESULT = {"I2CScan":"Device(s) found at 0x44 0x76"}
..
SV <-> BME280 <-> SHT = OK both visible in web ui
..
13:10:12 CMD: i2cscan
13:10:12 RSL: RESULT = {"I2CScan":"Device(s) found at 0x44 0x76"}

..
HOW = SV <-> TSL <-> BME280 = OK both visible in web ui
..
13:06:57 CMD: i2cscan
13:06:57 RSL: RESULT = {"I2CScan":"Device(s) found at 0x39 0x76"}
..
SV <-> BME280 <-> TSL = OK both visible in web ui
..
00:00:27 CMD: i2cscan
00:00:27 RSL: RESULT = {"I2CScan":"Device(s) found at 0x39 0x76"}

Have checked the TSL sensor breakout board against pull up's but all is ok.
Also had tested to deactivate the BME280 driver, but then it is all the same.
It must be the driver or the timing.
Because when i use my VEML6070 UV Sensor in place of the TSL2561 then all is working.

So what we do now? It can't be the bus timing. I think more a driver issue.
What is the difference in the drivers? I mean at the end of the code, init. call ervery x seconds
and so on. Something with addresses. We need a digi scope but i don't have one, now.

[Dimonix77]

Thank you @mike2nl ! At least my results are reproducible :) and we came to conclusion that we need logic analyzer/digi scope for further investigations.

[mike2nl]

@Dimonix77
yes that too, but we have to investigate the drivers for the SHT and TSL too. There must be something changed. I will look which comapny has libraries for it and then make some test on a Arduino Pro M0.

[mike2nl]

@Staars @Dimonix77 @digiblur @ascillato2
Here all the information, libraries and source i have found about the SHT31-D and the TSL2561.
TSL2561_SHT31-D.zip

Please download it whoever will look into it.
I will delete it in 10 days (today 2018 dec 28) because the size....

[Staars]

I can only make guesses from the outside at the moment.
One of my ideas from some days ago dealt with something like fiddling with the pull-ups on the TSL (page 8/9 in the sparkfun tsl2561 hookup-guide), but then @Dimonix77 reported, that ESP-EASY can work without a problem. So this can not be the explanation.

The next step for me would be, to build a minimal sketch outside of TASMOTA with both sensors, but at the moment I can only cheer :smile (and read through the code).

[mike2nl]

@Staars
that was 100% my idea todo it on a Arduino Pro M0 or a Wemos D1 R1 or R2, not the mini because i don't have them. I would use the different libraries to test is. In all docs i have uploaded there are already small codeed ino's and there i will start to test.

That's all what i can do right now. Still to short on energy and sometimes the crappy lag on motivation.

[ascillato2]

@Dimonix77

Hi,

Can you try again but with latest Tasmota from Today (6.4.1.6)? There are some changes related to I2C.

Thanks.

[Dimonix77]

@ascillato2
Hi, could you provide # of related commits, please?

[mike2nl]

Oh changes in I2C? Did not seen it.

Will do the test tomorrow, Thanks @ascillato2

[ascillato]

@Dimonix77 sorry, my bad. The change in I2C is just for another sensor not related to this one. 8d1dee8929c428045d9b50a56169280771b4d4af

[ascillato]

BTW, any update on this issue?

[mike2nl]

Today i got all sensorss (7) plus oled display running with many different combinations.
But the TSL sensor is steady a diva.
Last but not least i must test it with adafruit libs only on a wemos.
Jesus that thing is more then a diva.

[RaymondMouthaan]

Hai guys,

I like to add the following findings related to TLS2561 aka "The Diva" ;)

I have strange behaviour most probably related to sensor TSL2561, which is connected to 3v3 of a Wemos flashed with custom bin with core 2.3.0, but its also tested with core 2.4.2.
The issue is that tasmota doesn't publishes very teleperiod (10 sec) but much higher (more or less 30 sec), I read about dynamic sleep and tried some values, but the problem remains. From console I noticed a LoadAvg of +/- 90 .
When placing the wemos + tsl in the same room as the AP the publishing gets closer to teleperiod but still not very accurate. Replacing the TLS with a different kind of sensor (in this case a BME680), but with exactly the same firmware doesn't show anything like above.

Logs:

21:42:17 MQT: tele/wemos-11/SENSOR = {"Time":"2019-01-08T21:42:17","TSL2561":{"Illuminance":3.850}}
21:42:45 MQT: tele/wemos-11/STATE = {"Time":"2019-01-08T21:42:45","Uptime":"0T00:26:23","Vcc":2.788,"SleepMode":"Dynamic","Sleep":100,"LoadAvg":15,"Wifi":{"AP":1,"SSId":"indonesia76","BSSId":"C4:04:15:44:64:AA","Channel":8,"RSSI":100}}
21:42:45 MQT: tele/wemos-11/SENSOR = {"Time":"2019-01-08T21:42:45","TSL2561":{"Illuminance":3.850}}
21:43:18 MQT: tele/wemos-11/STATE = {"Time":"2019-01-08T21:43:18","Uptime":"0T00:26:56","Vcc":2.788,"SleepMode":"Dynamic","Sleep":100,"LoadAvg":89,"Wifi":{"AP":1,"SSId":"indonesia76","BSSId":"C4:04:15:44:64:AA","Channel":8,"RSSI":100}}
21:43:18 MQT: tele/wemos-11/SENSOR = {"Time":"2019-01-08T21:43:18","TSL2561":{"Illuminance":3.819}}
21:43:23 CMD: teleperiod 60
21:43:23 MQT: stat/wemos-11/RESULT = {"TelePeriod":"60"}
21:43:24 MQT: tele/wemos-11/STATE = {"Time":"2019-01-08T21:43:24","Uptime":"0T00:27:02","Vcc":2.789,"SleepMode":"Dynamic","Sleep":100,"LoadAvg":246,"Wifi":{"AP":1,"SSId":"indonesia76","BSSId":"C4:04:15:44:64:AA","Channel":8,"RSSI":100}}
21:43:24 MQT: tele/wemos-11/SENSOR = {"Time":"2019-01-08T21:43:24","TSL2561":{"Illuminance":3.819}}
21:46:07 CMD: sleep 50
21:46:07 MQT: stat/wemos-11/RESULT = {"Sleep":"50 (50)"}
21:46:41 MQT: tele/wemos-11/STATE = {"Time":"2019-01-08T21:46:41","Uptime":"0T00:30:19","Vcc":2.788,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":271,"Wifi":{"AP":1,"SSId":"indonesia76","BSSId":"C4:04:15:44:64:AA","Channel":8,"RSSI":100}}
21:46:41 MQT: tele/wemos-11/SENSOR = {"Time":"2019-01-08T21:46:41","TSL2561":{"Illuminance":3.789}}

Status 0:

21:48:47 CMD: status 0
21:48:47 MQT: stat/wemos-11/STATUS = {"Status":{"Module":18,"FriendlyName":["Wemos-11"],"Topic":"wemos-11","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}
21:48:47 MQT: stat/wemos-11/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"wemoss","OtaUrl":"http://tasmoadmin.indonesia:80/data/firmwares/sonoff.bin","RestartReason":"External System","Uptime":"0T00:32:25","StartupUTC":"2019-01-08T20:16:22","Sleep":50,"BootCount":187,"SaveCount":405107,"SaveAddress":"F5000"}}
21:48:47 MQT: stat/wemos-11/STATUS2 = {"StatusFWR":{"Version":"6.4.1.6(sonoff)","BuildDateTime":"2019-01-08T21:09:07","Boot":31,"Core":"2_3_0","SDK":"1.5.3(aec24ac9)"}}
21:48:47 MQT: stat/wemos-11/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["indonesia76",""],"TelePeriod":60,"SetOption":["00008009","558180C0","00000000"]}}
21:48:47 MQT: stat/wemos-11/STATUS4 = {"StatusMEM":{"ProgramSize":511,"Free":492,"Heap":17,"ProgramFlashSize":1024,"FlashSize":4096,"FlashChipId":"1640E0","FlashMode":3,"Features":["00000809","8FDAE394","000383A1","22BE3CCE","00003BC0"]}}
21:48:47 MQT: stat/wemos-11/STATUS5 = {"StatusNET":{"Hostname":"wemos-11","IPAddress":"10.20.1.11","Gateway":"10.0.0.1","Subnetmask":"255.0.0.0","DNSServer":"10.10.1.10","Mac":"5C:CF:7F:0F:C7:9B","Webserver":2,"WifiConfig":5}}
21:48:47 MQT: stat/wemos-11/STATUS6 = {"StatusMQT":{"MqttHost":"mqtt.indonesia","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_0FC79B","MqttUser":"wemos-11","MqttType":4,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}}
21:48:47 MQT: stat/wemos-11/STATUS7 = {"StatusTIM":{"UTC":"Tue Jan 08 20:48:47 2019","Local":"Tue Jan 08 21:48:47 2019","StartDST":"Sun Mar 31 02:00:00 2019","EndDST":"Sun Oct 27 03:00:00 2019","Timezone":99,"Sunrise":"08:42","Sunset":"17:11"}}
21:48:47 MQT: stat/wemos-11/STATUS10 = {"StatusSNS":{"Time":"2019-01-08T21:48:47","TSL2561":{"Illuminance":3.728}}}
21:48:47 MQT: stat/wemos-11/STATUS11 = {"StatusSTS":{"Time":"2019-01-08T21:48:47","Uptime":"0T00:32:25","Vcc":2.788,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":242,"Wifi":{"AP":1,"SSId":"indonesia76","BSSId":"C4:04:15:44:64:AA","Channel":8,"RSSI":100}}}

[mike2nl]

@ascillato2 @Dimonix77 @Staars @digiblur @

Update:
Staars contacted me again today, we are in messages about that issue a while now,
he gave me a hint to test something. And i was possible in the same time frame busy ;-)
with locking at Joba1's github.

There is an issue reported that when the lux value is low a high value is reported (in short)
There can be a loop starting where the drivers hangs it selfs up and the i2c can be blocked (in short)

There is an open PR from himself from 17 Aug 2018.
intended for testing issue # 5 (loop issue)

That i will test firts. It is not the master brunch it is the issue5 brunch.

The idea from Staars will do the same but in the UTIL part of the driver.
So i will test first the issue brunch and when that is not working i will test the hint from Staars
to add _wire.endTransmission(true); in 2 places.

So far the status.

[mike2nl]

@Dimonix77 @Staars @digiblur @ascillato2
Next update an hour later:

Both changes or the single one for itself changes nothing. Tested with the Joba1 library.
Everytime when i connect the SHT31 to the i2c the TSL hangs it up and the TSl is no longer visible.

The changes in the Joba1 lib against high values in darkness works well but is not merged
from Joba right now. That PR is still open. But the code works for that. Will talk with him
what's going on in that case so we can get that included official.

I had checked all addresses so far used in the code but nothing to see. I have no I2C monitor to
check whats going on. That could be one of the next steps.

Next test can be done with the adafruit library in tasmota but therefore the code must be
changed and that is a lot more work.

At the end there must be something in the lib code but did not foind it yet basd on lacl of time
the last two weeks. So more ideas here?

For now i would advise to to tell the users not to use both sensors together until that issue is solved.

[mike2nl]

Wrong part of information here, sorry.
To many tabs opend and that so early in the morning.

[mike2nl]

Had done one more test with the TSL and SHT.

• connected both to i2c
• configured the sonoff sc to I2C, then restart
• after reboot opend the web ui
• the SHT31 was visible
• the TSl was not visible

i2cscan shows both addresses and they are ok.
And now a worst part: don't do that ever

• disconnected the SHT31 sensor while all is running
• web ui shows now nothing - TSL not visible also after refreshing the web ui
• restart the sonoff sc (power down then up again)
• on the web ui the TSL is shown

So far we all have the same. But the moment when i disconnect the SHT sensor
my thought was that the TSL will be shown, so no.

can it be that the INIT of the TSL is not working while a SHT31 is connected?
So as we know it works with all other sensors. Tested now 11 different I2C sesnors.

[mike2nl]

@ascillato2 @Staars @Dimonix77
Staars and me we have talked the past hours about that issue and i have done a lot of tests.
We thought we had found the issue in the ReadSHT about a missing Wire.endTransmission();.

Nope, also that changing with many others had no effect at all.

One more thing i will make a bit more clear:

• I had done the compiling without the SHT31 driver in my_user_config and the TSL was shown
  very wonderfull in the web ui.
• Staars was reading the whole thread again and was the meaning that @Dimonix77 had written
  that this won't even work. But no, it works 100% on two devices (2x sonoff sc).

I have tested now 11 different I2C sensors in different combinations and all are working.
Only when both the TSL and the SHT in one setup it won't.

At the end we need a Logic Analyzer or an I2C Bus Monitor to check whats going on.

By all comparing with other I2C drivers i have seen that everyone is doing his own thing.
Outside of that the I2C driver from Adrian, Andre and/or Jason are ok, ;-).
We have to rewrite or clean up things in a good or better a defined way.
I had talked once with Theo about it. So as with Adrian, Andre and Jason ;-).

[joba-1]

Hi, just wanted to let you know that I am aware of this issue now and ready to help, if I can.
I do not have a SHT and have not seen this problem yet with other sensors though (I mostly use bme280).

I would recommend using my tsl examples (e.g. testing.ino) while having an sht attached to the bus.
They produce much more diagnostic serial output to track problems down.

Another option would be, to add print statements between the tsl method calls in xsns_16_tsl2561.ino to see where it fails.

Maybe something different: I am not convinced, this xsns file does what it should with regards to plug and play sensor handling and retaining a sensor value for some time if the sensor fails. But that could be me not really understanding how that interface is used by tasmota.
Anyways, I currently test this slightly changed code and it does what I expect (plug sensor -> detected on next discover. Unplugged sensor -> last lx value retained for some time, then set to 0, plugged in sensor again -> detected again and displaying new lx values:

/*
  xsns_16_tsl2561.ino - TSL2561 light sensor support for Sonoff-Tasmota

  Copyright (C) 2019  Theo Arends and Joachim Banzhaf

  This program is free software: you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation, either version 3 of the License, or
  (at your option) any later version.

  This program is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  GNU General Public License for more details.

  You should have received a copy of the GNU General Public License
  along with this program.  If not, see <http://www.gnu.org/licenses/>.
*/

#ifdef USE_I2C
#ifdef USE_TSL2561
/*********************************************************************************************\
 * TSL2561 - Light Intensity
 *
 * Using library https://github.com/joba-1/Joba_Tsl2561
 *
 * I2C Addresses: 0x29 (low), 0x39 (float) or 0x49 (high)
\*********************************************************************************************/

#define XSNS_16             16

#include <Tsl2561Util.h>

Tsl2561 Tsl(Wire);

uint8_t tsl2561_valid = 0;
uint32_t tsl2561_milliLux = 0;
char tsl2561_types[] = "TSL2561";

bool Tsl2561Read(void)
{
  // retain last sensor reading for some time even if next read fails
  if (tsl2561_valid) {
    tsl2561_valid--;
  } else {
    tsl2561_milliLux = 0;
  }

  uint8_t id;
  bool gain;
  Tsl2561::exposure_t exposure;
  uint16_t scaledFull, scaledIr;
  uint32_t full, ir;

  if (Tsl.on()) {
    if (Tsl.id(id)
      && Tsl2561Util::autoGain(Tsl, gain, exposure, scaledFull, scaledIr)
      && Tsl2561Util::normalizedLuminosity(gain, exposure, full = scaledFull, ir = scaledIr)
      && Tsl2561Util::milliLux(full, ir, tsl2561_milliLux, Tsl2561::packageCS(id))) {
      tsl2561_valid = SENSOR_MAX_MISS;
    }
  }

  return tsl2561_valid == SENSOR_MAX_MISS;
}

void Tsl2561Detect(void)
{
  if (!Tsl.available()) {
    Tsl.begin();
    if (Tsl.available()) {
      snprintf_P(log_data, sizeof(log_data), S_LOG_I2C_FOUND_AT, tsl2561_types, Tsl.address());
      AddLog(LOG_LEVEL_DEBUG);
    }
  }
}

void Tsl2561EverySecond(void)
{
  if (90 == (uptime %100)) {
    // 1mS
    Tsl2561Detect();
  }
  else if (!(uptime %2)) {  // Update every 2 seconds
    // ?mS - 4Sec (should never take more than 600ms!)
    if (!Tsl2561Read() && tsl2561_milliLux) {
      AddLogMissed(tsl2561_types, tsl2561_valid);
    }
  }
}

#ifdef USE_WEBSERVER
const char HTTP_SNS_TSL2561[] PROGMEM =
  "%s{s}TSL2561 " D_ILLUMINANCE "{m}%u.%03u " D_UNIT_LUX "{e}";  // {s} = <tr><th>, {m} = </th><td>, {e} = </td></tr>
#endif  // USE_WEBSERVER

void Tsl2561Show(boolean json)
{
  if (tsl2561_valid) {
    if (json) {
      snprintf_P(mqtt_data, sizeof(mqtt_data), PSTR("%s,\"TSL2561\":{\"" D_JSON_ILLUMINANCE "\":%u.%03u}"),
        mqtt_data, tsl2561_milliLux / 1000, tsl2561_milliLux % 1000);
#ifdef USE_DOMOTICZ
      if (0 == tele_period) { DomoticzSensor(DZ_ILLUMINANCE, (tsl2561_milliLux + 500) / 1000); }
#endif  // USE_DOMOTICZ
#ifdef USE_WEBSERVER
    } else {
      snprintf_P(mqtt_data, sizeof(mqtt_data), HTTP_SNS_TSL2561, mqtt_data, tsl2561_milliLux / 1000, tsl2561_milliLux % 1000);
#endif  // USE_WEBSERVER
    }
  }
}

/*********************************************************************************************\
 * Interface
\*********************************************************************************************/

boolean Xsns16(byte function)
{
  boolean result = false;

  if (i2c_flg) {
    switch (function) {
      case FUNC_INIT:
        Tsl2561Detect();
        break;
      case FUNC_EVERY_SECOND:
        Tsl2561EverySecond();
        break;
      case FUNC_JSON_APPEND:
        Tsl2561Show(1);
        break;
#ifdef USE_WEBSERVER
      case FUNC_WEB_APPEND:
        Tsl2561Show(0);
        break;
#endif  // USE_WEBSERVER
    }
  }
  return result;
}

#endif  // USE_TSL2561
#endif  // USE_I2C

[mike2nl]

@joba-1
Thanks for the information and i will test it tomorrow morning.
Will report then here.

[mike2nl]

@joba-1
Short report.
I used the latest tasmota from today (fresh dev donwload)
used your xsns_16_tsl2561.ino in place of the original one.
Same issue. The TSL is visible only when the SHT is not connected.
No different debug info output then with the original driver code.
I have tested it on two sonoff sv and eaxch with a TSl and SHT.
So enough hardware to test with.
Jesus it begins me to get crazy with that.

[joba-1]

have you also tested to disconnect the TSL and reconnect it again and see if it is rediscovered in the absence of a SHT, or after you unplug the SHT? That was the main concern of my changes in xsns. Solving the SHT issue would have been a nice side effect. Connecting and disconnecting i2c devices on the fly is generally no big problem, but if you want to play it safe, plug in ground first, then vcc, scl and sda and unplug the other way round, ground last.

[Staars]

22:10:28 RSL: tele/sonoff/SENSOR = {"Time":"2019-01-17T22:10:23","ANALOG":{"A0":0},"SHT3X-0x44":{"Temperature":23.5,"Humidity":48.7},"TSL2561":{"Illuminance":11.430},"TempUnit":"C"}

.... looking good.
I will do some additional tests, but I think we will fix this soon.

[Staars]

Just a short update.
Currently mike2nl and me do some work and meanwhile I am pretty sure, that the problem is really isolated. A PR could be done today or tomorrow.

[mike2nl]

I got the changed code from Staars and will test it when sunday morning comes up in 7 or 8 hours.
When this works Staars can make the PR.

I found missing values and some very little other things in the tsl library. I got the software designer documents two dyas ago (friday) after i asked AMS nicely. I think Joba did not get these one, but that is no issue at all we all are here to help and not all people know that they are exsits. Sometimes the companies don't give them out to the public. And the old company TAOS Inc. is now ams AG. That happend in 2011. So, not all documents where found by ams AG in that time.

That work will be done after the driver is working again so all users can work further in the meantime.
When the addition is done another PR will be given. But that needs a little bit of time to get it done and i will inform Joba about it. Jesus all these testings

[Staars]

The PR is out.
The exact technical reason for this bug remains unclear at the moment, but the good news are, that the most important part of the library is not affected.

When the SHT3x-sensor is co-connected the function: tsl.available() in the driver always returns true. In my setup it even returns true, when I disconnect the tsl2561-sensor.
So in the init-routine the driver gets quite early the false information, that the sensor is already running and so the sensor never really starts.

In the new version I only do a rough check for a device at the known adresses with a built-in Tasmota-function and the rest is more or less the same. I only remove the remaining calls of tsl.available().

[Dimonix77]

Thanks @Staars ! My very first suggestion was exactly the same - use well known static addresses.

[...]
If someone can give me a hint on how to overcome i2c bus scan and define static addresses for the sensors.

[mike2nl]

@Staars @joba-1
in the library i will change somethings but Joba will be informed about it.
So as i told that there are some little things and we will fix that.
Then a 2nd PR will be given.

[joba-1]

hm, can‘t see the pr, so just some generic comments: tsl.available() does just a beginTransmission() at the given address followed by endTransmission() and checking the error code. I think this is the official i2c way to check availability of a i2c device.
Also: tsl.begin() scans for all wellknown tsl addresses. I dont see why coding this again in tasmota will improve matters. If I do one of it wrong (cant see why) it should be fixed in the library.

[Staars]

Yes, this is only a minimal-change-PR and it is already merged.

Thats why mike2nl wrote, that we will further refine the things and then we will remove the unnecessary double address scan. This is not the end of the road.

BTW, I think this thread can be closed, because the further work is on our agenda.

[andrethomas2]

Closing this issue as the PR to fix this bug (PR https://github.com/arendst/Sonoff-Tasmota/pull/4986) has already been merged into development.

Support Information

See Wiki for more information.
See Chat for more user experience.