Measurement of light/radiation
Moderator: leecollings
-
- Posts: 848
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Measurement of light/radiation
My configuration for meteo-sensors lacks a reasonably accurate component for measurement of light and UV.
Adafruit offers its sensor SI1145, which could fill that gap. It interfaces by I2C and I have seen that software is available for Arduino and for Raspberry/Python. See https://www.kiwi-electronics.nl/si1145- ... ght-sensor
Anybody experience with the latter combination?
Additionally interested related to a housing which provides weatherprotection without spoiling the transmission to the sensors and not limiting the open aperture.
Those characteristics are important if you want 'true' values from sunrise till sunset.
Which length of the interfacecable is the limit for a practical setup with the sensorhead outside and the computer inhouse?
Adafruit offers its sensor SI1145, which could fill that gap. It interfaces by I2C and I have seen that software is available for Arduino and for Raspberry/Python. See https://www.kiwi-electronics.nl/si1145- ... ght-sensor
Anybody experience with the latter combination?
Additionally interested related to a housing which provides weatherprotection without spoiling the transmission to the sensors and not limiting the open aperture.
Those characteristics are important if you want 'true' values from sunrise till sunset.
Which length of the interfacecable is the limit for a practical setup with the sensorhead outside and the computer inhouse?
Last edited by Toulon7559 on Friday 06 March 2020 19:44, edited 3 times in total.
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
- bbqkees
- Posts: 407
- Joined: Sunday 17 August 2014 21:01
- Target OS: Linux
- Domoticz version: 4.1x
- Location: The Netherlands
- Contact:
Re: Measurement of light/radiation
According to Adafruit it is mainly a UV-index sensor and not a very good light sensor.
You would need the TSL2561 for that.
You would need the TSL2561 for that.
Bosch / Nefit / Buderus / Junkers / Worcester / Sieger EMS bus Wi-Fi MQTT Gateway and interface boards: https://bbqkees-electronics.nl/
-
- Posts: 848
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Measurement of light/radiation
Probably the TSL2561 (as described at https://www.kiwi-electronics.nl/tsl2561 ... ght-sensor ) is also for other technical reasons the better choice:
- with only 1 sensor it is difficult to cover the whole azimuth arc (= angular range) of the sun's movement over the day.
Effectively 1 sensor = peak-measurement in 1 direction over an angle of approx. 90 degrees.
- with 2 or 3 sensors which are angularly spaced you have better azimuth coverage (e.g. aimed at 135 degrees and 225 degrees relative to North, respectively aimed at 130 degrees, 180 degrees and 230 degrees relative to North, with an elevation according to your latitude). The aperture of the 2 or 3 sensors will overlap, resulting in a wider and more constant, cumulative azimuth coverage.
Then you need 2 or 3 selectable I2C-adresses to individually call the sensors, and only TSL2561 has that facility, not SI1145, nor TSL2591.
Bonus points for TSL2561 are also that it is the cheapest of the 3 candidates, and other people already thought about implementation resulting in scripts, such as https://github.com/janheise/TSL2561
Regardless of that 'positioning' aspect, the layout of the housing is critical, because in principle UV and IR heavily suffer when glass or plastic is applied as protecting window, and light measurement is also affected if the window is not 100% transparant.
An accurate sensor only has value if the transmissionpath to it is OK, otherwise it (again) only provides an indication ......
Nice puzzle/ challenge .......
- with only 1 sensor it is difficult to cover the whole azimuth arc (= angular range) of the sun's movement over the day.
Effectively 1 sensor = peak-measurement in 1 direction over an angle of approx. 90 degrees.
- with 2 or 3 sensors which are angularly spaced you have better azimuth coverage (e.g. aimed at 135 degrees and 225 degrees relative to North, respectively aimed at 130 degrees, 180 degrees and 230 degrees relative to North, with an elevation according to your latitude). The aperture of the 2 or 3 sensors will overlap, resulting in a wider and more constant, cumulative azimuth coverage.
Then you need 2 or 3 selectable I2C-adresses to individually call the sensors, and only TSL2561 has that facility, not SI1145, nor TSL2591.

Regardless of that 'positioning' aspect, the layout of the housing is critical, because in principle UV and IR heavily suffer when glass or plastic is applied as protecting window, and light measurement is also affected if the window is not 100% transparant.


Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
- Posts: 848
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Measurement of light/radiation
Thinking about a housing as shown in the picture below.
Humidity will still penetrate, and requires other protective measures.
Would gauze over the 'hole' offer sufficient protection to keep out occasional raindrops?Humidity will still penetrate, and requires other protective measures.
Last edited by Toulon7559 on Tuesday 02 August 2016 21:31, edited 1 time in total.
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
- Posts: 169
- Joined: Wednesday 30 September 2015 11:50
- Target OS: Raspberry Pi / ODroid
- Domoticz version: v3.8975
- Location: United Kingdom
- Contact:
Re: Measurement of light/radiation
Hi,
I suggest you have a look at the following:
https://forum.mysensors.org/topic/2086/ ... eech-board
I have the BH1750, TSL2561 and UVI i2c board
I am using this enclosure:
http://www.aliexpress.com/item/3-8W-Ult ... .16.qDgEFu
this is a solar panel (battery backed up) driven project.
Additionally, I have a LUA script to get the sun radiation, azimuth and altitude (check out wiki for the script).
I suggest you have a look at the following:
https://forum.mysensors.org/topic/2086/ ... eech-board
I have the BH1750, TSL2561 and UVI i2c board
I am using this enclosure:
http://www.aliexpress.com/item/3-8W-Ult ... .16.qDgEFu
this is a solar panel (battery backed up) driven project.
Additionally, I have a LUA script to get the sun radiation, azimuth and altitude (check out wiki for the script).
-
- Posts: 848
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Measurement of light/radiation
@alexsh1
BH1750FVI is sensor for 'normal' light, TSL2561 is for 'normal' light and for IR.
Questions for understanding the performance of the sensors:
1) With the enslosure closed, what do you read from the IR-part of TSL2561?
2) Which type of board do you apply for UVI?
2a) What values do you read for UV with that device, while in the closed enslosure?
BH1750FVI is sensor for 'normal' light, TSL2561 is for 'normal' light and for IR.
Questions for understanding the performance of the sensors:
1) With the enslosure closed, what do you read from the IR-part of TSL2561?
2) Which type of board do you apply for UVI?
2a) What values do you read for UV with that device, while in the closed enslosure?
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
- Posts: 169
- Joined: Wednesday 30 September 2015 11:50
- Target OS: Raspberry Pi / ODroid
- Domoticz version: v3.8975
- Location: United Kingdom
- Contact:
Re: Measurement of light/radiation
OK, this is still work in progress as I have come up with a few ideas to place some sensors out from the box.Toulon7559 wrote:@alexsh1
BH1750FVI is sensor for 'normal' light, TSL2561 is for 'normal' light and for IR.
Questions for understanding the performance of the sensors:
1) With the enslosure closed, what do you read from the IR-part of TSL2561?
2) Which type of board do you apply for UVI?
2a) What values do you read for UV with that device, while in the closed enslosure?
Currently, I have the following sensors:
1/ BMP180
2/ HTU21D
3/ TSL2561
4/ BH1750FVI
5/ ML8511 (UV Sensor)
5/ Rain module raindrop
6/ Possible PIR
All of them (apart from PIR) will be connected via i2c.
I am currently at the stage we I am connecting individual sensors in the breadboard and will be eliminating a few. 1/ and 2/ will be there as they are soldered to the main board. For the light I currently have 3/ 4/ 5/ I am currently looking at BH1750FVI as soon as I am at TSL261 I'll let you know more, but the idea is that the rain sensor will be sticking out anyway, I have come up with a 3D printed small add-on to the current case to expose ML8511.
-
- Posts: 169
- Joined: Wednesday 30 September 2015 11:50
- Target OS: Raspberry Pi / ODroid
- Domoticz version: v3.8975
- Location: United Kingdom
- Contact:
Re: Measurement of light/radiation
Concerning ML8511, it has to be connected the following way
3.3V = 3.3V
OUT = A0
GND = GND
EN = 3.3V
3.3V = A1
Unfortunately, I cannot connect it to my ESP8266 as I need an analogue-digital converter.
I'll hook it up to my Nano on the breadboard to check.
3.3V = 3.3V
OUT = A0
GND = GND
EN = 3.3V
3.3V = A1
Unfortunately, I cannot connect it to my ESP8266 as I need an analogue-digital converter.
I'll hook it up to my Nano on the breadboard to check.
-
- Posts: 848
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Measurement of light/radiation
Kind of struggling with the same problem:
- planning to use 1*SI1145 for UV+Light+IR and 2*TSL2561 for Light+IR to get
1) reasonably calibrated measurements for UV+light+IR
2) good angular coverage for UV measuring in southerly direction for the 'hot' period of the day, accepting that in early morning and in late afternoon the input is down at the 'slope' of the angular coverage
3) almost seamless angular coverage for light+IR over the whole day from east to west by overlapping azimuth coverage from 2*TSL2561
(like I now have [uncalibrated] with 2* Photodiode BPW34 hooked to the modified Thermosensor of my TFA_Nexus_PWS)
- But a good position for the 'sensor-head' means a rather long cable for the I2C-interface
- An ESP8266 as 'interface-station' would provide more freedom for installation of the sensorhead
[if I knew how to attach those 3 breakoutboards to an ESP8266 in such way that I get an easy read-out at the Raspberry]
- planning to use 1*SI1145 for UV+Light+IR and 2*TSL2561 for Light+IR to get
1) reasonably calibrated measurements for UV+light+IR
2) good angular coverage for UV measuring in southerly direction for the 'hot' period of the day, accepting that in early morning and in late afternoon the input is down at the 'slope' of the angular coverage
3) almost seamless angular coverage for light+IR over the whole day from east to west by overlapping azimuth coverage from 2*TSL2561
(like I now have [uncalibrated] with 2* Photodiode BPW34 hooked to the modified Thermosensor of my TFA_Nexus_PWS)
- But a good position for the 'sensor-head' means a rather long cable for the I2C-interface
- An ESP8266 as 'interface-station' would provide more freedom for installation of the sensorhead
[if I knew how to attach those 3 breakoutboards to an ESP8266 in such way that I get an easy read-out at the Raspberry]
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
- Posts: 169
- Joined: Wednesday 30 September 2015 11:50
- Target OS: Raspberry Pi / ODroid
- Domoticz version: v3.8975
- Location: United Kingdom
- Contact:
Re: Measurement of light/radiation
No necessary - you need to have the outside module with nrf24l01+ or esp8266. The only problem I have right now is to make it water tight given than I cannot cover the head with the glassToulon7559 wrote: - But a good position for the 'sensor-head' means a rather long cable for the I2C-interface
-
- Posts: 848
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Measurement of light/radiation
Question just for understanding/derisking:
Is there a difference in handling of bh1750 vs bh1750fvi?
Can the same software be used? Any differences in results?
Is there a difference in handling of bh1750 vs bh1750fvi?
Can the same software be used? Any differences in results?
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
- Posts: 169
- Joined: Wednesday 30 September 2015 11:50
- Target OS: Raspberry Pi / ODroid
- Domoticz version: v3.8975
- Location: United Kingdom
- Contact:
Re: Measurement of light/radiation
I am sure it is the same sensor. The one I have is BH1750FVI
- Domosapiens
- Posts: 232
- Joined: Wednesday 20 August 2014 12:08
- Target OS: Windows
- Domoticz version: V3.5981
- Location: NL
- Contact:
Re: Measurement of light/radiation
Is this an option?
https://nl.aliexpress.com/item/Free-shi ... 1fa1ed9458
https://nl.aliexpress.com/item/Free-shi ... 1fa1ed9458
Win Vista&7; 1#Aeon Z-Stick S2; 1#Aeotec Z-Sick Gen5, 6#Fib.FGBS001; 24#DS18B20; 8#Everspr.AN158-2; 3#Philio PAN04; 1#Philio PAN06, 1#YouLess El; 1#Fib.FGWPE; 1#ZME_RC2; 2#FAK_ZWS230, 2#Quib.ZMNHCDx, 1#Quib.ZMNHDD1, 7#EM6555
-
- Posts: 848
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Measurement of light/radiation
@Domosapiens
Good find!
In this configuration nicely packed for outdoor application as a simple zenith-scanner:
just put it on a vertical pvc-pipe of 32mm crosssection, and extend the cable for your needs.
Good find!
In this configuration nicely packed for outdoor application as a simple zenith-scanner:
just put it on a vertical pvc-pipe of 32mm crosssection, and extend the cable for your needs.
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
- Posts: 848
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Measurement of light/radiation
For a light-sensor a protective window is not really an issue: glass, perspex or simple plastic is OK, although perhaps causing some minor loss of lux.
To get a protective window which is transparant for IR and for UV is another story:
- plastic sheet material may be suitable if thin enough
- gauze is an alternative
Loss for measured radiation is an unavoidable negative aspect for both sheet and gauze, as well as limited lifetime of the 'window' as effect of the environmental conditions.
To get a protective window which is transparant for IR and for UV is another story:
- plastic sheet material may be suitable if thin enough
- gauze is an alternative
Loss for measured radiation is an unavoidable negative aspect for both sheet and gauze, as well as limited lifetime of the 'window' as effect of the environmental conditions.
Last edited by Toulon7559 on Sunday 23 October 2016 18:09, edited 1 time in total.
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
- Posts: 848
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Measurement of light/radiation
Testing an ESP8266 with 2*BH1750
I have a luxury problem with today's sunny, bright weather:
the BH1750s 'hit the roof' with readings clipping at 54612 lux. At noon far exceeding the values calculated by the script at viewtopic.php?f=23&t=10077 , while (contrary) at sunset or during cloudy conditions with much lower values.
Scratching of head to find a pragmatic/realistic solution for alignment.
Smells as if I have to develop a kind of calbration-curve of 'measurement vs. algorithm'.
Somebody invented yet?

the BH1750s 'hit the roof' with readings clipping at 54612 lux. At noon far exceeding the values calculated by the script at viewtopic.php?f=23&t=10077 , while (contrary) at sunset or during cloudy conditions with much lower values.

Smells as if I have to develop a kind of calbration-curve of 'measurement vs. algorithm'.
Somebody invented yet?
Last edited by Toulon7559 on Monday 08 April 2019 10:01, edited 1 time in total.
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
- Posts: 848
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Measurement of light/radiation
In the setup with 2*BH1750 with an ESP8266 I installed the 2 sensors with an angular offset relative to the mounting platform:
approx 30 degrees from south towards west respectively towards east, and both approx. 30 degrees up from horizon.
The idea is that in that way they should better cover the sun's movement over the day, and with bright, cloudless sky in the measurements you should see that the sun moves from east to west.
But especially when the sky has distinct & changing clouds you get 'interesting effects' due to async measurement and due to light from different directions:
- simple subtraction of the 2 measured values makes the result jump from very negative to very positive
- calculation of combined peak-value only indicates the max. light-input from any direction (which then also may have significant variation)
Conclusion:
looking with 2 offset sensors is OK, because it better covers the whole sun's arc over the day,
but just consider the outcome as an 'indication' for actual/cumulative peak-value, not as an 'absolute' information for light-level from the sun's position.
At most places you have sky with clouds, and therefore the effect mentioned above probably is 'usual'.
In fact, (in my opinion) under those conditions as a general indication a measurement with only 1 sensor pointing south or pointing to zenith is as good as measurement with multiple sensors .....
approx 30 degrees from south towards west respectively towards east, and both approx. 30 degrees up from horizon.
The idea is that in that way they should better cover the sun's movement over the day, and with bright, cloudless sky in the measurements you should see that the sun moves from east to west.
But especially when the sky has distinct & changing clouds you get 'interesting effects' due to async measurement and due to light from different directions:
- simple subtraction of the 2 measured values makes the result jump from very negative to very positive
- calculation of combined peak-value only indicates the max. light-input from any direction (which then also may have significant variation)
Conclusion:

but just consider the outcome as an 'indication' for actual/cumulative peak-value, not as an 'absolute' information for light-level from the sun's position.
At most places you have sky with clouds, and therefore the effect mentioned above probably is 'usual'.
In fact, (in my opinion) under those conditions as a general indication a measurement with only 1 sensor pointing south or pointing to zenith is as good as measurement with multiple sensors .....
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
- Posts: 848
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Measurement of light/radiation
It took some time, but now have 2 other setups under test, which combine
1* BH1750 lightsensor as zenithscanner under dome
2* TSL2561 lightsensors looking sidsouth with sideways offset to cover wider angle in azimuth
1*ML8511 looking south for UV-detection
1*ESP8266 [WEMOS&ESPEasy] to control that group and to report to Domoticz
For physical layout see http://www.vannwnhzn.nl/Weerhuisjebouwen.html#08
The setup at this moment is installed indoors behind a window-pane, looking south, with power from mains.
Another ESP8266 [WEMOS&ESPEasy] deals with
1* GUVA-S12SD looking south for UV-detection
Positive results, but the setup needs some further refinement before it can become operational for 'real' meteo-application.
As expected the sensor-outputs need mutual alignment/ calibration, because the readings from the BH1750-zenitscanner are way lower than the readings from the TSL2561s: perhaps because the zenith-scanner at the present indoor location is not fully exposed to the sun.
On the other hand, the luminosity values from the TSL2561s are reasonably close to a comparable experimental setup with 2*BH1750.
ESPEasy (version 147-Mega) with the present menu for the devices does not read the IR-values from the TSL2561s:
somebody having a method to get those IR-values?
Was surprised to see that the GUVA-PCB has a LED showing that the GUVA-print is powered:
IMHO, not really appropriate if you want to apply the circuit for meteo-sensing, because it might cause stray illumination on nearby sensors.
When positioned outdoors probably the light of that LED raises the neighbours' curiousity what you are doing, and therefore covering foreseen.
The LED would be unnecessary drain for a battery-powersupply: the GUVA in-PCB has meanwhile been replaced by an ML8511.
The GUVA-PCB shifted to another application as gapfiller, secondary UV-zenith-scanner, to help cover the somewhat problematic location for my meteo-setup.
Part of the testing was to see how much effect of the covering windows towards the sensors fitted in the body of the 'meteo-hut':
- the TSL2561s do not seem to mind a plastic shield on their housing and a plastic&gauze outer window => OK!
- for the GUVA expected negative effects from glass window-pane, plastic shield and gauzes, but the GUVA still reports rising VU-signals in relation to sunny environment.
- some extended testing required to collect measuring data for mutal alignment and for calibration.
1* BH1750 lightsensor as zenithscanner under dome
2* TSL2561 lightsensors looking sidsouth with sideways offset to cover wider angle in azimuth
1*ML8511 looking south for UV-detection
1*ESP8266 [WEMOS&ESPEasy] to control that group and to report to Domoticz
For physical layout see http://www.vannwnhzn.nl/Weerhuisjebouwen.html#08
The setup at this moment is installed indoors behind a window-pane, looking south, with power from mains.
Another ESP8266 [WEMOS&ESPEasy] deals with
1* GUVA-S12SD looking south for UV-detection
Positive results, but the setup needs some further refinement before it can become operational for 'real' meteo-application.
As expected the sensor-outputs need mutual alignment/ calibration, because the readings from the BH1750-zenitscanner are way lower than the readings from the TSL2561s: perhaps because the zenith-scanner at the present indoor location is not fully exposed to the sun.
On the other hand, the luminosity values from the TSL2561s are reasonably close to a comparable experimental setup with 2*BH1750.
ESPEasy (version 147-Mega) with the present menu for the devices does not read the IR-values from the TSL2561s:
somebody having a method to get those IR-values?
Was surprised to see that the GUVA-PCB has a LED showing that the GUVA-print is powered:


The LED would be unnecessary drain for a battery-powersupply: the GUVA in-PCB has meanwhile been replaced by an ML8511.
The GUVA-PCB shifted to another application as gapfiller, secondary UV-zenith-scanner, to help cover the somewhat problematic location for my meteo-setup.
Part of the testing was to see how much effect of the covering windows towards the sensors fitted in the body of the 'meteo-hut':
- the TSL2561s do not seem to mind a plastic shield on their housing and a plastic&gauze outer window => OK!
- for the GUVA expected negative effects from glass window-pane, plastic shield and gauzes, but the GUVA still reports rising VU-signals in relation to sunny environment.
- some extended testing required to collect measuring data for mutal alignment and for calibration.
Last edited by Toulon7559 on Sunday 08 March 2020 13:51, edited 3 times in total.
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
- Posts: 848
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Measurement of light/radiation
Another set of lightsensors already in operation, but an available Raspberry0W and that inactive SI1145 'challenge' (although now partially for fun).
Setting & testing the I2C-interface itself is not the problem:
enabling of the I2C-interface using and testing on presence by either or reports the SI1145 at address 60, as expected,
Software is another matter.
Looked at http://www.pibits.net/code/raspberry-pi ... xample.php
but stuck at the setting up of the SI1145-driver from Adafruit located at https://github.com/THP-JOE/Python_SI1145
When following the github-instructions (using python2.7), the report is that the Adafruit module for SI1145 is missing.
A few other people have the same problem: see https://forums.adafruit.com/viewtopic.php?f=8&t=135617
However, the instruction in the last code-windowfor me ends in an error report which starts with telling "Works best with python 2.7"
Using Python2.7 via seems successful: termination without error report ......
The consequence of my setup-trials with both versions of Python however is [?] that the driver is now installed at 2 locations, for python2.7 respectively python3.
Test-running with both versions of python, the example-program simpletest.py stops with error report:
- If running with python2.7, it tells missing module SI1145 as mentioned above
- If running with python3, then module Adafruit_GPIO is reported missing.
Considering the errorreport for missing module Adadfruit_GPIO undocumentedly I ran
My suspicion that the (undocumented) location of the modules is critical, was supported after 'fiddling' with the setup-location for file SI1445.py.
After some more try&error [the print-lines in the script needed enclosing ( ) ] the file simpletest.py as python2.7-application now generates the expected results .......
Setting & testing the I2C-interface itself is not the problem:
enabling of the I2C-interface using
Code: Select all
sudo raspi-config
Code: Select all
sudo i2ctest -y 1
Code: Select all
sudo i2cdetect -y 1
Software is another matter.
Looked at http://www.pibits.net/code/raspberry-pi ... xample.php
but stuck at the setting up of the SI1145-driver from Adafruit located at https://github.com/THP-JOE/Python_SI1145
When following the github-instructions (using python2.7), the report is that the Adafruit module for SI1145 is missing.
A few other people have the same problem: see https://forums.adafruit.com/viewtopic.php?f=8&t=135617
However, the instruction in the last code-window
Code: Select all
sudo python3 setup.py install
Using Python2.7 via
Code: Select all
sudo python setup.py install
The consequence of my setup-trials with both versions of Python however is [?] that the driver is now installed at 2 locations, for python2.7 respectively python3.
Test-running with both versions of python, the example-program simpletest.py stops with error report:
- If running with python2.7, it tells missing module SI1145 as mentioned above
- If running with python3, then module Adafruit_GPIO is reported missing.
Considering the errorreport for missing module Adadfruit_GPIO undocumentedly I ran
Code: Select all
pip install Adafruit-GPIO
After some more try&error [the print-lines in the script needed enclosing ( ) ] the file simpletest.py as python2.7-application now generates the expected results .......
Last edited by Toulon7559 on Wednesday 17 January 2024 18:45, edited 4 times in total.
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
- Posts: 848
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Measurement of light/radiation
Once read-out is working, next step to be planned & realised is implementation of SI1145 in Domoticz etc.
Because the measured data do not look 'real' values like reported by BH1750 and TLS2561, corrections have to be applied prior to upload to Domoticz.
These corrections have to get rid of the observed bias and have to scale the remaining levels to 'practical' values.
In other words: calibration required ......
Running a few days & nights without the corrections, the darkness & peak levels can be found.
Darkness level => bias
Day peak level => scaling above the bias
Not very scientific, just empirical correction, best by comparison with better calibrated devices.
Subsequently the upload to related virtual devices in Domoticz [Light = type LUX, IR = type Customer, UVI = type UV] for further applications.
Because the measured data do not look 'real' values like reported by BH1750 and TLS2561, corrections have to be applied prior to upload to Domoticz.
These corrections have to get rid of the observed bias and have to scale the remaining levels to 'practical' values.
In other words: calibration required ......
Running a few days & nights without the corrections, the darkness & peak levels can be found.
Darkness level => bias
Day peak level => scaling above the bias
Not very scientific, just empirical correction, best by comparison with better calibrated devices.
Subsequently the upload to related virtual devices in Domoticz [Light = type LUX, IR = type Customer, UVI = type UV] for further applications.
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Who is online
Users browsing this forum: No registered users and 1 guest