This line is not correct : "while (! Wire.available());".
After Wire.requestFrom() it is not correct to wait.

• wrong constants in the code.
  void simpleRead(void)
  {
  // Simple data read example. Just read the infrared, fullspecrtrum diode
  // or 'visible' (difference between the two) channels.
  // This can take 100-600 milliseconds! Uncomment whichever of the following you want to read
  uint16_t x = tsl.getLuminosity(TSL2591_VISIBLE);
  //uint16_t x = tsl.getLuminosity(TSL2561_FULLSPECTRUM);
  //uint16_t x = tsl.getLuminosity(TSL2561_INFRARED);

  Serial.print("[ "); Serial.print(millis()); Serial.print(" ms ] ");
  Serial.print("Luminosity: ");
  Serial.println(x, DEC);
  }

currently the library blocks on every reading of the sensor values:

uint32_t Adafruit_TSL2591::getFullLuminosity (void) {
  // ....
  // Wait x ms for ADC to complete
  for (uint8_t d=0; d<=_integration; d++)
  {
    delay(120);
  }
  // ....
}

(all specialized readings are calling the getFullLuminosity function)

this delay is needed because the lib enables the sensor for every interaction and disables it afterwards.
but i think a ~100-600ms blocking delay just for getting a sensor reading is not a nice thing to do..
→ if the sensor is left running you just can read a value and be happy ;-)

if you want to make sure you get a valid reading - first check the Status Register for AVALID.
if the lib needs to make sure it always gets a new conversion value i think
after the read we could disable only the AEN flag (Enable Register) and re enable it directly again.
this should clear the AVALID flag.

i would try and create a pull-request - but i first need a ok/info for how to do this in line with the adafruit goals!

so the fix for this should also fix #12

With the current library and "tsl2591_interrupt.ino" example, the interrupt feature does not work.
This is because in the library the device gets powered on and powered off in every function by the enable() and disable().
To generate interrupts the tsl2591 cannot be in powered off state.
I resolved this by commenting all the enable() and disable() in the library and managing the power states in the Arduino sketch. If the Arduino goes to sleep and I want him to be woken up the the TSL, I call the enable() before the Arduino sleep call. Of course also before initializing the TSL or doing measurement I enable it.
This info should be at least be documented, if the library does not get changed. Also the Adafruit tutorial could be updated that now there is Interrupt function as well.
I used in the enable() function the following settings for the "Enable Register", so that I get only 1 interrupt (not two) from the No Persist Interrupt (and not also from the ALS Interrupt) for when the light level goes as soon as after 1 measurement below the lower threshold or higher than then upper threshold:
write8(TSL2591_COMMAND_BIT | TSL2591_REGISTER_ENABLE, TSL2591_ENABLE_POWERON | TSL2591_ENABLE_AEN | TSL2591_DISABLE_AIEN | TSL2591_ENABLE_NPIEN);
where TSL2591_DISABLE_AIEN must be added in the .h file as:
#define TSL2591_DISABLE_AIEN (0x00)

• Arduino board: Arduino Nano 33 BLE

• Arduino IDE version (found in Arduino -> About Arduino menu): 1.8.11

• List the steps to reproduce the problem below (if possible attach a sketch or
  copy the sketch code in too):
  Select target board and try to compile:

#include <Wire.h>
#include <Adafruit_Sensor.h>
#include "Adafruit_TSL2591.h"

Following error dump will be given:

Alternatives for avr/pgmspace.h: []
ResolveLibrary(avr/pgmspace.h)
C:\Users\Arduino\Documents\Arduino\libraries\Adafruit_TSL2591_Library\Adafruit_TSL2591.cpp:50:12: fatal error: avr/pgmspace.h: No such file or directory
  -> candidates: []

   #include <avr/pgmspace.h>

            ^~~~~~~~~~~~~~~~

compilation terminated.

File is currently located under deprecated-avr-comp:
https://github.com/arduino/ArduinoCore-API/blob/master/api/deprecated-avr-comp/avr/pgmspace.h

Current solution is to make a local copy of this library and copy inn deprecated file.

I tried somewhat correcting the sensor lux calculation for incandescent bulbs based on calculated values. I have mentioned the changes I did here.
Can someone give some feedback on this?

Is there a raspberry pi version available of the tsl2591

Hi,

I just found out that together with the Adafruit Unified Sensor API, this sensor reports back inaccurate data, like a minimum value of 0.0 when it should really be more like 0.000118.

And also the resolution seems to not be correct 🤔

https://forums.adafruit.com/viewtopic.php?f=19&t=124176

https://github.com/adafruit/Adafruit_BusIO

This part of the Adafruit's example code for tsl2591 test does not work correctly:
if (tsl.begin())
{
Serial.println("Found a TSL2591 sensor");
}
else
{
Serial.println("No sensor found ... check your wiring?");
while (1);
}
REASON:
tsl.begin() will hung up if no sensor detected. Expected behavior would be to display a message (no sensor found) the stop running. Instead, it looks like the begin() hungs up.
It looks like I'm not alone with this problem (I have just seen on adafruit's forum.)

Hi,

Adafruit_TSL2591::begin() always returns true instead of returning real status from a function it calls. Looks like a typo. It breaks a few things down the road that rely on begin().

The current algorithms produce a negative lux under certain conditions (especially low light).

Current:
lux1 = ( (float)ch0 - (TSL2591_LUX_COEFB * (float)ch1) ) / cpl;

The fixed value of TSL2591_LUX_COEFB can cause negative values when IR intensity is high. This should be replaced by a dynamically scaling coefficient. A better implementation would be this:

Improved:
lux = ( ((float)ch0 - (float)ch1 )) * (1.0F - ((float)ch1/(float)ch0) ) / cpl;

The raw difference is taken initially and a correction factor of 1-ch1/ch0 is applied to scale down the lux with increasing IR intensity. This ratio represents the amount of IR present within the full spectrum. This should give a better approximation to lux given the 2-channel constraint of the sensor.

It seems that the problem is not yet solved.

In low-lighting conditions (early evening office space, home dining room, etc.), simply waving one's hand at one foot distance (and shorter) produces negative lx values.

According to the TSL2591 datasheet, the chip should consume only 2.3uA (micro-amps) when sleeping. However, using the current master branch version, I am seeing 100uA @ 3.3V when sleeping, which is quite high.

I see that the disable() call successfully reduces the current from about 300uA (when taking measurements) down to 100uA (sensor disabled). However, I think the device may not be in the proper sleep mode, as this is about 45x higher current than the datasheet value.

Is there another call that puts the device in a deeper sleep mode?
Has anyone else experienced this level of current draw during sleep mode?

These measurements are made using the EEVBlog uCurrent, which has been independently tested and verified.

Thank you!

I'm using the current version of the library and the new lux calculation. However I still get the 65535. However, I am unsure if this can be related to another error (where it jumps from 0 to 65535) and the sensor has to be sampled more than 2 times? I've made a check within the calculateLux function to check for negative numbers.

My use-case is a station outside that measures lux with the TSL2591 and UV with Si1145 every 10 minutes (and goes to deep sleep inbetween)

It is configured with:

timing: TSL2591_INTEGRATIONTIME_100MS
gain: TSL2591_GAIN_LOW

• Arduino board: ATMEGA328P-AU (8Mhz 3V3)
• Arduino IDE version (found in Arduino -> About Arduino menu): PlatformIO

Would be nice to have support for the INT (interrupt) possibilities of the TSL2591.

Because i needed it, i started the development of this support last week :-)
Hope to have it ready soon

The TSL2591 is special because it can read to low light level (188microlux). there are a few problems with the Universal sensor definition:
sensor -> resolution = 0.0001 (currently = 1.0)

Also the calculateLux function is set to a uint32_t when it should be a float (currently it tuncates the result to an integer).
even with these changes though event.light still truncates the value to 2 decimal places. I can't seem to figure out why.

Dear dev,
How I'm supposed to read more than 65535 value from a uint16_t type?
All functions returns 16 bit values!

In the example "tsl2591_interrupt.ino" the code

`Serial.print("Interrupt Threshold Window: -");
Serial.print(TLS2591_INT_THRESHOLD_LOWER, DEC);
Serial.print(" to +");

Serial.println(TLS2591_INT_THRESHOLD_LOWER, DEC);
Serial.println("");`
has two minor mistakes:

1. the signs - and + should be removed, because the thresholds are from value X to value Y.
2. The second value printed should be TLS2591_INT_THRESHOLD_UPPER. The current code prints twice the lower threshold.