Domoticz

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?

According to Adafruit it is mainly a UV-index sensor and not a very good light sensor.
You would need the TSL2561 for that.

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 .......

Thinking about a housing as shown in the picture below. Would gauze over the 'hole' offer sufficient protection to keep out occasional raindrops?
Humidity will still penetrate, and requires other protective measures.

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).

@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?

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?

OK, this is still work in progress as I have come up with a few ideas to place some sensors out from the box.
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.

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.

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]

Toulon7559 wrote: - But a good position for the 'sensor-head' means a rather long cable for the I2C-interface

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 glass

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?

I am sure it is the same sensor. The one I have is BH1750FVI

Is this an option?
https://nl.aliexpress.com/item/Free-shi ... 1fa1ed9458

@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.

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.

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?

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 .....

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.

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-window for 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 .......

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.