Which LUX sensor

[manjh]

I see that EasyESP supports two LUX sensors: BH170 and TSL2561. Which is the best choice? Based on price the BH1750 is slightly cheamer at $1,03, while TSL2561 is $1,66.
Marginally cheaper, so I would rather choose the best.
Any advice?
Also, is there support for the simple (and no doubt: cheapest) good-old LDR?

[Dylantje]

Perhaps buy this 2....
And try them...

And let us now....

[manjh]

I did that already, was just eager to hear opinions from all experts on this forum...

[ogollemon]

So far I've tried only the BH1750. At least with the BH1750 it is possible to use two sensors on the same bus.

"With the ADDR pin grounded, the address is as you have it 0x23, the other address is 0x5C (a simple bit inversion)."

[Dylantje]

So far I've tried only the BH1750. At least with the BH1750 it is possible to use two sensors on the same bus.

"With the ADDR pin grounded, the address is as you have it 0x23, the other address is 0x5C (a simple bit inversion)."

+


Please tell me how i this is working in the easpeasy?
What module must i select..
and what pin do i need

[ogollemon]

So far I've tried only the BH1750. At least with the BH1750 it is possible to use two sensors on the same bus.

"With the ADDR pin grounded, the address is as you have it 0x23, the other address is 0x5C (a simple bit inversion)."

+


Please tell me how i this is working in the easpeasy?
What module must i select..
and what pin do i need

It is normal i2c bus, so you have to choose the ic2 pins. At the moment you have to alter the source a bit to support the 0x5c address of the bh1750.

[BertB]

I see that EasyESP supports two LUX sensors: BH170 and TSL2561. Which is the best choice? Based on price the BH1750 is slightly cheamer at $1,03, while TSL2561 is $1,66.
Marginally cheaper, so I would rather choose the best.
Any advice?
Also, is there support for the simple (and no doubt: cheapest) good-old LDR?

The spectrum of visible light ranges from 380 nm (violet) to 780 nm (red) (in vacuüm).
In short, the BH1750 just measures that.
The TSL2561 also measures infra red. It has two diodes, one for visible and infra red light and one for infra red light only.
To my opinion, BH1750 fits most requirements, whereas the TSL2561 offers a wider spectrum, more sensitivity and more accuracy.
Regarding the TSL2561, ESPEasy only provides the visible and infra red values.
For more info, also read:
https://e-radionica.com/productdata/BH1750FVI.pdf and
https://cdn-shop.adafruit.com/datasheets/TSL2561.pdf

The good old LDR can be connected to the ADC port via a suitable voltage divider. Some arithmetic could help you to figure out what light intensity is being measures. I prefer the use of the BH1750 or the TSL2561.

[Dylantje]

It is normal i2c bus, so you have to choose the ic2 pins. At the moment you have to alter the source a bit to support the 0x5c address of the bh1750.

Dear...
I am not so smart as you think perhaps...
I do not what the ic2 pins are...
Are this the hardware pins?

ScreenShot225.jpg (32.74 KiB) Viewed 29782 times

[BertB]

correct. SDA is the i2c data line and SDC the i2c clock.
In your case pins 9 and 10.
Which really is not a good idea, since in some cases they are used by the ESP.
Better stick to 4 and 5 instead.

[Dylantje]

mmm China has arrived here....
When i have time ... Give the lux a try...
Is it possible to set a lux and the Uv @ the 2 hardware pins?
Or perhaps 2 lux sensors on these pins...

I need more of then 1 sensor that is using the hardware pins

[manjh]

mmm China has arrived here....
When i have time ... Give the lux a try...
Is it possible to set a lux and the Uv @ the 2 hardware pins?
Or perhaps 2 lux sensors on these pins...

I need more of then 1 sensor that is using the hardware pins

I2C is a bus, so as long as your sensors have different base addresses, I would think they can work attached to the same pins.
Give it a try...

[manjh]

BH1750 sensors arrived this morning. Took me 5 minutes to hook it up to a NodeMCU and get it working.
Not much of a challenge...
Now to find a suitable case for this new unit...

[Dylantje]

Do i need to connect all the wires...
GND VCC and the 2 hardware pins?

[costo]

Do i need to connect all the wires...
GND VCC and the 2 hardware pins?

Sure, if you talk about I2C sensors.

Ground is always common for all sensors/circuits. Vcc is needed because your sensor needs power.
SCL and SDA are needed for the communication.
Do not forget that there must be somewhere on your I2C bus pull_up resistors otherwise the bus may not work properly.
Resistors of 4k7 or 3k3 between Vcc and SDA/SCL will be usually be fine.

[bertrand]

I wanted to use these for my indoor Hydroponic setup, but there is big discrepancy between the two as I'm using Blue & Red LED tubes... that might be out or the scope...








I found this TI "Full spectrum" sensor OPT3002 http://www.ti.com/product/OPT3002... That is even available as a board on tindie. https://www.tindie.com/products/closedc ... al-sensor/

[Ton_vN]

One ESP8266 in operation, with 2*BH1750 and 1*DHT11.

The data sheet for BH1750 tells that at 30 degrees from the Line-of-Sight the sensitivity drops to 80% and at approx. 40 degrees to 60%.
In order to cover in a clean way the full arc of the sun's movement, the 2 sensors have been aimed with a horizontal offset of approx. 30 degrees relative to their platform, and the platform is tilted by approx. 30 degrees from horizon. The platform is looking South.
It means that
- sensor_A points 30 degrees East of South & Up by 30 degrees from horizontal
- sensor_B points 30 degrees West of South & Up by 30 degrees from horizontal
In practise (after a few days of testing) the difference in aiming not (yet) really becomes visible.

But another aspect pops up:
for high light-input the read-out for both sensors blocks at 54612 lux.
Considering that the max. level according to the scaling could be 65535 lux, that is strange [?]

Any similar experience? [and an explanation?]

Also triggers the question at which of the 3 possible resolutions the ESPEasy performs the read-out of these BH1750s?

[grz3]

im using / testing both BH1750 & TLS2561.
- BH1750 gives results in two decimals, TLS2561 gives only whole numbers. (don't understand ms times in setup of TLS2561???)
- results of both sensors are similar - max 0.8 lux diff. (when placed side by side) - in low light or standard daylight/room bulbs
- BH1750 gives option to set i2c addres, so possible to use 2 in one espeasy project, TLS2561 only one i2c addres = total 3lux sensors in project
- TLS2561 arrived from ebay with better delivery time comparing another seller with BH1750 - this got no really value on functionality

[Ton_vN]

TLS2561-breakout-boards also have an address-pin to set I2C-addresses 0x39, 0x29, 0x49, selectable with jumpers:
0x29 = pin to GND
0x39 = floating pin
0x49 = pin to VCC

[costo]

But another aspect pops up:
for high light-input the read-out for both sensors blocks at 54612 lux.
Considering that the max. level according to the scaling could be 65535 lux, that is strange [?]

Any similar experience? [and an explanation?]

I think you are using a version before R129, beginning with R129 reading will go up to 54611 for readings smaller than maximum and jump to 65535 for max reading.

The reason is there is a sort of 'correction-factor' in the _P010_BH1750.ino.
Lux values are divided by 1.2
Full value FFFF = 65535, this value divided by 1.2 gives 54612.5

Code: Select all

          byte b1 = Wire.read();
          byte b2 = Wire.read();
          float val = 0xffff; //pm-cz: Maximum obtainable value
          if (b1 != 0xff || b2 != 0xff) { //pm-cz: Add maximum range check 
            val=((b1<<8)|b2)/1.2;
          }

I am not sure why this divide by 1.2 'correction' is done, to me this seems pretty useless. (maybe we can speak of a bug?)

Maybe Martinus can give a good reason why the output of the BH1750 has to be divided by 1.2

.............................................................
edit , To answer myself:
After reading in the datasheet of BH1750
The divide by 1.2 factor is suggested by the manufacturer to convert the value of the reading into 'real' lux values.

Still the accuracy of this sensor is such that the uncertainty is great.
The sensitivity in the visual spectrum varies between 0.8 and 1.0, depending on the actual color.

Measurement Accuracy S/A (Min.)0.96 // (Typ.) 1.2 // (Max.) 1.44 times Sensor out / Actual lx
EV = 1000 lx ※ 1, ※ 2

So after the divide by 1.2 correction there can still be an error of over 20%. This sensor is not an prefessional measuring device.

Readings in ESPEasy can be interpreted as 'real' lux values up to 54611 Lux and after that ESPEasy will show 65535 meaning there is an intensity overload. (since R129)

[Ton_vN]

Indeed, my 2 ESPs are happily humming at version R120.
Following costo's explanation I will keep them in that state until I see other reasons for an upgrade of the firmware.

To operate the BH1750s more or less within their effective range, it looks that an 'external' attenuation has to be applied to the devices.
In other words: less light should fall on the detector. That calls for grey or black windows, but calibration is then next issue.
Although with the tolerance of 20% due to light-colour as mentioned by costo, is calibration really an critical issue?
Probably better to empirically make an attenuation which brings the peak-illumination just within the operational range of the sensor, and then 'calculatory align' the lux-values from the BH1750 (or comparable device) with the output of an algorithm like published in the Domoticz-Forum under this thread http://www.domoticz.com/forum/viewtopic ... 077#p70949

In another (meteo) forum I have seen configurations with detectors/photodiodes covered by black isolation tape.
Apply that configuration also in my own PWSes: accuracy is 'nil', but the resulting curve has some value as a indication of sun's intensity.

[Mr.ToR]

I have both of these sensors however i haven't played around with the TLS2561 yet.
However, the BH1750 can measure LUX upto 121360 lux.
As far as i know there is only one library that gives interface to control the device in detail however there were no example showing how it's done, so i did the examples myself.
Here is the library
https://github.com/Tonguc-Endem/BH1750FVI/tree/master

And here are my two examples
https://github.com/Tonguc-Endem/BH1750F ... ration.ino
https://github.com/Tonguc-Endem/BH1750F ... output.ino

also i was able to power off and on the BH1750 to save energy, which is necessary especially if used in ESP8266 with battery.
power control is also included in the example function.

hope this helps.

[mvn77]

65535-very very bad! Especially for a greenhouse ...

[Ton_vN]

Indeed a max. measurement for illumination level of approx. 50klux is some limitation.
But on the other hand, what is the practical difference between 'much light' and 'very much light'?
The plants don't care, just the owner .......

If it is not possible to electronically expand the measurement range (or by software), perhaps a mechanical solution is feasible:
put some dark fabric cover over the sensor (or the plastic cover of a deodorant roller), wich results in a reduction factor relative to the uncovered sensor.
Calibration is an issue which could be solved by application of 2 sensors [which is easy with BH1750s => on same I2C-bus, just set them to different address]:
1*BH1750 (A) without cover for the lower light-levels, 1*BH1750 (B) with cover for the higher light levels
With sensors (A) and (B) running parallel, in the lower light levels the attenuation-factor Att of the cover can be calculated:
Att = output(B)/output(A)
To get for sensor (B) the same, correct, practical light level value as measured by sensor (A) you divide the output-value of sensor(B) by the attenuation-factor Att .

In summary & formulas
Outputdata A from Unprotected Sensor (A) ranges from 0 to 54klux
Outputdata B from Covered Sensor (B) for the same lightlevels in practise ranges from 0 to 54klux * Att (in which Att <1)
=> The 'true' practical lightlevel from Sensor(B) is Outputdata C = Outputdata B / Att
Outputdata C derived from Sensor (B) operationally continues till it clips at a practical lightlevel of 54klux / Att.

Not sure that Att is a constant/linear factor over the whole range, but that is a refinement:
for a first implementation you could determine a constant value of Att at the 50klux lightlevel of Sensor (A)