Howto debug TCS3472 not working

[demJanus]

Hi,

I have a D1 mini running ESP_Easy_mega_20221224_collection_A_ESP8266_4M1M.bin (mega-20221224_35f2ff8)
I connected a TCS3472 breakout board (besides an ADC1115 and I have a custom pcb for my setup with reliable connectors, no breadboard or something, so I2C is working fine)
I added "Color - TCS34725" to Task 12 with the default settings (but played around a bit, no difference).
Unfortunately I do not get any readings, all values are always zero.
When performing an I2C Scan I can see besides my ADC a device on I2C address 0x29, which should be the TCS.
In the tools -> log output there seems to be nothing of any help, actually nothing related to the sensor at all.
How can I track down the issue? Are there any further logs and if so how can I fetch them? Any known issues related to that sensor or anything that I missed here?

edit: also tried latest ESP_Easy_mega_20230508_collection_A_ESP8266_4M1M.bin (mega-20230508) with same results.

Thanks for your support.
Alec

[TD-er]

Is it possible the task will get disabled on its own?
If so, then the device may not respond within its timeout.
On the tools->Advanced page you may want to uncheck "Check I2C devices when enabled" and see if that makes a difference.

Another thing that might cause issues is when you're using boards with those I2C chips mounted.
Most of those boards already have a pull-up resistor present.
But when adding several of those boards to the same I2C bus, you might end up with a rather strong pull-up resistance.
It is possible your TCS-sensor can't handle a strong pull-up.

See if you can remove other boards to check if that makes a difference.
If not, you could try lowering the I2C clock frequency. For example to 100 kHz (hardware tab)

Another option could be to experiment with the "I2C ClockStretchLimit" (also on the Tools->Advanced page)
It requires experimenting to see what value might work for this clock stretch limit.

If you have multiple of those chips available, you might want to try another one on a seperate board to make sure the plugin code should work and rule out any issues when there is for example a new chip revision of those sensors.
Or simply making sure the sensor you're testing isn't broken or maybe needs some other pin connected too to work.
Some chips have multiple power supply pins, like for the digital part and the analog part of the circuit.

[Ath]

Is the device address (0x29) shown when looking at the I2C Scan results? If not it may be a wiring issue.

[demJanus]

Is the device address (0x29) shown when looking at the I2C Scan results? If not it may be a wiring issue.

yes, it is shown there. I am sure that the wiring of the I2C connection is fine. How does the detection of the I2C devies work? If the device address is listed there, does that mean that one can be sure that communication is OK?

[demJanus]

Is it possible the task will get disabled on its own?
If so, then the device may not respond within its timeout.
On the tools->Advanced page you may want to uncheck "Check I2C devices when enabled" and see if that makes a difference.

How can the task get disabled on its own? How does that "Check device" option work exactly? Unchecking the option you mentioned does not make any difference.

Another thing that might cause issues is when you're using boards with those I2C chips mounted.
Most of those boards already have a pull-up resistor present.
But when adding several of those boards to the same I2C bus, you might end up with a rather strong pull-up resistance.
It is possible your TCS-sensor can't handle a strong pull-up.

I did already remove all other board, no difference.

See if you can remove other boards to check if that makes a difference.
If not, you could try lowering the I2C clock frequency. For example to 100 kHz (hardware tab)

Tried already, no effect unfortunately

Another option could be to experiment with the "I2C ClockStretchLimit" (also on the Tools->Advanced page)
It requires experimenting to see what value might work for this clock stretch limit.

What exactly is the effect of that option?

If you have multiple of those chips available, you might want to try another one on a seperate board to make sure the plugin code should work and rule out any issues when there is for example a new chip revision of those sensors.
Or simply making sure the sensor you're testing isn't broken or maybe needs some other pin connected too to work.
Some chips have multiple power supply pins, like for the digital part and the analog part of the circuit.

Unfortunately I don't have another board of that type to try.


But in the meanwhile: Isn't there any other option to dig in deper and for example get some logging on the outcome of the I2C communication?


Thanks for your support.

[TD-er]

Well you know at least that the SDA and SCL are connected correctly.
But to detect it you only send a single request to that address and the I2C device replies to it.
For most other calls you need a lot more signalling over the I2C bus.
So when it is detectable, it doesn't mean communications to the device are very reliable.
For example too strong pull-up resistors on SDA/SDL can cause issues, or long cable on the I2C bus.

Some devices may require a bit more energy to perform a measurement, so voltage stability to the sensor may play a role when actually trying to perform a measurement.

And as I mentioned, I2C devices may use "clock stretching" to actually limit the data rate or need a bit more time to prepare a reply.
What this does is the I2C slave device may pull the SCL line low to stall any communication on the I2C bus until it is ready to answer a request.
This can take too long so ESPEasy may already have reset the I2C bus.
By allowing a bit more time for clock stretching, you essentially increase the timeout to wait till the SCL line is high again.
The clock stretch value is some kind of timeout value, but it isn't expressed in msec.
On ESP32 it is a multiple of 1/80 usec (thus clock ticks at 80 MHz)
I don't know what the unit is on ESP8266, but usually 1000 or 2000 is a good value to test with.

[TD-er]

Is it possible the task will get disabled on its own?
If so, then the device may not respond within its timeout.
On the tools->Advanced page you may want to uncheck "Check I2C devices when enabled" and see if that makes a difference.

How can the task get disabled on its own? How does that "Check device" option work exactly? Unchecking the option you mentioned does not make any difference.

That's pure ESPEasy magic of course

When a task is started in ESPEasy, the plugin function "PLUGIN_INIT" is called.
If this returns "success = false", ESPEasy will disable that task. (With "Check I2C devices when enabled" checked)
Typically on I2C sensors, if the sensor is not found or not responding, it may cause a lot of timeouts when trying to communicate with that not connected or not working I2C device.
This may make it really hard to work with the ESPEasy node and correct any incorrect setting (e.g. wrong address)
So that's why we added this feature.

But on some I2C devices this may effectively render any form of cummunicating with it impossible.
That's why it can be turned off too.

But in the meanwhile: Isn't there any other option to dig in deper and for example get some logging on the outcome of the I2C communication?

We don't have "generic" logging for I2C debugging as it usually works just fine.
Some I2C plugins do have extra debug logs to track down some device specific issues.

Support for this sensor is already quite old, so you could try to install an older version of ESPEasy to see if that might work on your board.
If it does, then at least you know the sensor is working and then we can look into whether something else might be broken in the software.
Either in a newer SDK or perhaps some other (later) added feature can have an effect on just this sensor.

P050 was already added more than 5 years ago, so you could even try much older builds to make sure the SDK differs from what we're now using.

[demJanus]

Support for this sensor is already quite old, so you could try to install an older version of ESPEasy to see if that might work on your board.
If it does, then at least you know the sensor is working and then we can look into whether something else might be broken in the software.
Either in a newer SDK or perhaps some other (later) added feature can have an effect on just this sensor.

Thanks for all your detailed explanation. Very helpful

To test the sensor I just quickly hooked it up to an arduino lying around and uploaded a testsketch (from here: https://electropeak.com/learn/interfaci ... h-arduino/) and the sensor seems working (I did not check the values, just waving a postcard in front of it, but doesn't matter for now).

Code: Select all

Found sensor
Color Temp: 1391 K - Lux: 1 - R: 1 G: 1 B: 0 C: 2  
Color Temp: 5201 K - Lux: 0 - R: 1 G: 1 B: 1 C: 2  
Color Temp: 5201 K - Lux: 0 - R: 1 G: 1 B: 1 C: 2  
Color Temp: 5201 K - Lux: 0 - R: 1 G: 1 B: 1 C: 2  
Color Temp: 5201 K - Lux: 0 - R: 1 G: 1 B: 1 C: 2  
Color Temp: 3931 K - Lux: 0 - R: 3 G: 2 B: 2 C: 7  
Color Temp: 5201 K - Lux: 0 - R: 4 G: 3 B: 4 C: 11  
Color Temp: 4566 K - Lux: 2 - R: 6 G: 5 B: 5 C: 16  
Color Temp: 4656 K - Lux: 1 - R: 7 G: 5 B: 6 C: 18  
Color Temp: 4777 K - Lux: 2 - R: 9 G: 7 B: 8 C: 23  
Color Temp: 4656 K - Lux: 2 - R: 14 G: 10 B: 12 C: 35  
Color Temp: 3677 K - Lux: 0 - R: 5 G: 3 B: 3 C: 11  
Color Temp: 4161 K - Lux: 1 - R: 11 G: 7 B: 8 C: 25  
Color Temp: 4854 K - Lux: 1 - R: 11 G: 8 B: 10 C: 29  
Color Temp: 5201 K - Lux: 3 - R: 13 G: 11 B: 13 C: 37  
Color Temp: 4928 K - Lux: 3 - R: 15 G: 12 B: 14 C: 39  

P050 was already added more than 5 years ago, so you could even try much older builds to make sure the SDK differs from what we're now using.

Can you point me to a version I should give a try that should work from those days by any chance? Then I could give it a try just to see if a defect was introduced somewhen in those recent years. But at least there is some strong evidence that there is something fishy with that P50 module...

[TD-er]

Hmm, an Arduino board is often 5V I/O
Not all I2C chips can handle that well.

About the older builds: https://github.com/letscontrolit/ESPEasy/releases
Just pick some build of beginning 2019 or something, so you will still be using core 2.3.x
That's for sure using a completely different way of addressing I2C signals.

[demJanus]

Hmm, an Arduino board is often 5V I/O
Not all I2C chips can handle that well.

The TCS breakout board has an LDO onboard and some level shifting. I would be running it on 3V, thats how it is documented on various places with the espeasy setup. At least the chip supply voltages in deed look fine with that setup.
However I also ran the board on 5V on the D1mini (assuming the 5V tolerance is there as discussed often, even though not officially confirmed by data sheet). Again no difference. So I don't think the supply voltages make a problem here.

About the older builds: https://github.com/letscontrolit/ESPEasy/releases
Just pick some build of beginning 2019 or something, so you will still be using core 2.3.x
That's for sure using a completely different way of addressing I2C signals.

I might give that a try. Not sure that it is an option to run that long term?
Sadly will not be able to find some spare time to get into the project and/or hook up an oscilloskope to check what's going on.
Would really be sad if I had to abandon that sensor/project.

[TD-er]

I can order the chip myself, but right now I don't think I have it here to test myself

[Ath]

I know I have one here, but I didn't manage to find it yet...