claws / bh1750 Goto Github PK
View Code? Open in Web Editor NEWAn Arduino library for the digital light sensor breakout boards containing the BH1750FVI IC
License: MIT License
An Arduino library for the digital light sensor breakout boards containing the BH1750FVI IC
License: MIT License
Hi guys,
First of all sorry for my English. I have a problem with the BH1750, it tells me that it is not well in fact with the i2cdetec, it does not detect it and I no longer know what to do. I have tried everything, pullup resistors as well. I have also tried different BH1750 sensors. I have tested de pins and work. The only thing that I
Here is my code:
#include <Wire.h>
#include <BH1750.h>
#include <i2cdetect.h>
BH1750 lightMeter;
void setup() {
Serial.begin(115200);
// Initialize the I2C bus (BH1750 library doesn't do this automatically)
Wire.begin();
// On esp8266 you can select SCL and SDA pins using Wire.begin(D4, D3);
i2cdetect();
if (lightMeter.begin()) {
Serial.println(F("BH1750 Test begin"));
}
else {
Serial.println(F("BH1750 Initialization FAILED"));
}
}
void loop() {
float lux = lightMeter.readLightLevel();
Serial.print("Light: ");
Serial.print(lux);
Serial.println(" lx");
delay(1000);
}
Thanks.
Dear Wizards/@claws,
Presently, the device address (0x23/0x5C) have to be known/set with the constructor, ie. before the setup() call. This pretty much means that it must be hard-coded in the program.
If the same software is to be used on (slightly) different hardware configurations, then it might be convenient that the address can be set during the setup() phase - presumably after an i2c-scan or whatever, where the available addresses can be probed.
As it is now, I must create two instances of the object, as per eg:
BH1750 lightMeter1((byte) 0x23);
BH1750 lightMeter2((byte) 0x5C);
void setup() {
...
lightMeter1.begin() || Serial.println("LIGHT1 not configured");
lightMeter2.begin() || Serial.println("LIGHT2 not configured");
...
}
Thanks for a good library.
/Bjarne
I'm trying to interface the sensor to a nodemcu and compiler warns that util/delay.h is missing. Please help
Hi
first of all I'm sorry for my english!
I have a ESP 32S board and the three examples in the your library don't work and give me a compile error:
"Compiling library "BH1750-master"
"/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++" -DESP_PLATFORM -DMBEDTLS_CONFIG_FILE="mbedtls/esp_config.h" -DHAVE_CONFIG_H "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/config" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/bluedroid" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/app_trace" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/app_update" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/bootloader_support" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/bt" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/driver" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/esp32" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/esp_adc_cal" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/ethernet" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/fatfs" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/freertos" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/heap" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/jsmn" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/log" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/mdns" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/mbedtls" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/mbedtls_port" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/newlib" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/nvs_flash" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/openssl" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/spi_flash" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/sdmmc" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/spiffs" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/tcpip_adapter" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/ulp" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/vfs" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/wear_levelling" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/xtensa-debug-module" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/coap" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/console" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/expat" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/json" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/lwip" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/newlib" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/nghttp" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/soc" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/tools/sdk/include/wpa_supplicant" -std=gnu++11 -fno-exceptions -Os -g3 -Wpointer-arith -fexceptions -fstack-protector -ffunction-sections -fdata-sections -fstrict-volatile-bitfields -mlongcalls -nostdlib -Wall -Werror=all -Wextra -Wno-error=unused-function -Wno-error=unused-but-set-variable -Wno-error=unused-variable -Wno-error=deprecated-declarations -Wno-unused-parameter -Wno-sign-compare -fno-rtti -MMD -c -DF_CPU=240000000L -DARDUINO=10900 -DARDUINO_ESP32_DEV -DARDUINO_ARCH_ESP32 -DARDUINO_BOARD="ESP32_DEV" -DARDUINO_VARIANT="esp32" -DESP32 -DCORE_DEBUG_LEVEL=0 "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/cores/esp32" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/variants/esp32" "-I/Users/michele/Documents/Arduino/hardware/espressif/esp32/libraries/Wire/src" "-I/Users/michele/Documents/Arduino/libraries/BH1750-master" "/Users/michele/Documents/Arduino/libraries/BH1750-master/BH1750.cpp" -o "/var/folders/gl/m2zph6n55lsdyt5bys669rcr0000gn/T/arduino_build_28944/libraries/BH1750-master/BH1750.cpp.o"
/Users/michele/Documents/Arduino/libraries/BH1750-master/BH1750.cpp: In member function 'uint16_t BH1750::readLightLevel(bool)':
/Users/michele/Documents/Arduino/libraries/BH1750-master/BH1750.cpp:144:21: warning: overflow in implicit constant conversion [-Woverflow]
uint16_t level(NAN);
^
/Users/michele/Documents/Arduino/libraries/BH1750-master/BH1750.cpp:161:10: error: enumeration value 'UNCONFIGURED' not handled in switch [-Werror=switch]
switch (BH1750_MODE) {
^
/Users/michele/Documents/Arduino/libraries/BH1750-master/BH1750.cpp:161:10: error: enumeration value 'CONTINUOUS_HIGH_RES_MODE' not handled in switch [-Werror=switch]
/Users/michele/Documents/Arduino/libraries/BH1750-master/BH1750.cpp:161:10: error: enumeration value 'CONTINUOUS_HIGH_RES_MODE_2' not handled in switch [-Werror=switch]
/Users/michele/Documents/Arduino/libraries/BH1750-master/BH1750.cpp:161:10: error: enumeration value 'CONTINUOUS_LOW_RES_MODE' not handled in switch [-Werror=switch]
cc1plus: some warnings being treated as errors
Using library Wire at version 1.0 in folder: /Users/michele/Documents/Arduino/hardware/espressif/esp32/libraries/Wire
Using library BH1750-master at version 1.1.3 in folder: /Users/michele/Documents/Arduino/libraries/BH1750-master
exit status 1
Error compiling for board ESP32 Dev Module."
I2C scanner give me the address 0x23.
I have tried the same sketch on an ESP8266 board and the sensor work great!
Please, can you help me?
In continuous mode we are getting a zero measurement because we missed the initial measurement delay. Either the user have this in mind and wait the right amount of time or we fix that by adding a specific delay during configure()
.
Hi claws, could you add this library to Arduino Library Manager, then users can install and update this library easily. Thank you!
The readLightLevel
function returns an inconsistent number if it's called right after calling setMTreg
when the mode is ONE_SHOT. setMTreg
has delay_ms
when the mode is CONTINUOUS but not ONE_SHOT, and this inconsistent behavior doesn't happen in CONTINUOUS modes.
This issue was originally raised in #57.
Normally there is Wire.begin(SDA,SCL) at the setup() and you are not allowed to use this method in a library. but most of the libraries do this anyway.
esp8266/Arduino#2607
esp8266/Arduino#2774
this does not compile
In file BH1750.cpp, in the function readLightLevel(), the Wire.requestFrom() is encapsulated by Wire.beginTransmission and Wire.endTransmission(). That is not correct use of the Wire library, since the Wire.beginTransmission and Wire.endTransmission should only be used when writing data.
The Wire.requestFrom() is a complete I2C transaction on its own.
These modes power down the chip after the level is read. The present code does not wake up the chip when reading the value in those modes.
I added a save of mode and changed the code in readLightLevel:
uint16_t BH1750::readLightLevel(void) {
...
// Start transmission to sensor
Wire.beginTransmission(BH1750_I2CADDR);
switch (MODE) {
case BH1750_ONE_TIME_HIGH_RES_MODE:
case BH1750_ONE_TIME_HIGH_RES_MODE_2:
case BH1750_ONE_TIME_LOW_RES_MODE:
__wire_write((uint8_t)MODE);
break;
}
// Read two bytes from sensor
Wire.requestFrom(BH1750_I2CADDR, 2);
...
}
Hi All,
So I've seen people having this issue "device not configured" for me, I know it's not hardware issue because I've been running MicroPython without a problem and the BH1750 sensor is soldered to a custom PCB I've made.
The address in my case is 0x5C I've tried to change it "softly" it didn't work, changed the source files didn't work till I found a fix by looking into one of the advanced examples.
After changing lightMeter.begin() with the following:
lightMeter.begin(BH1750::CONTINUOUS_HIGH_RES_MODE, 0x5C, &Wire);
It fixed my problem, the sensor is working perfectly fine now. I have no idea why as I'm a Python not C or C++ Programmer but would love the author @claws to take a look over it and see if can find the issue.
I've spent about 25 minutes trying to re-solve the problem till I came with this solution, hope it can save some time for others as well that having the same issue as me.
Complete code:
#include <Wire.h>
/*
Example of BH1750 library usage.
This example initialises the BH1750 object using the default high resolution
continuous mode and then makes a light level reading every second.
Connection:
VCC -> 3V3 or 5V
GND -> GND
SCL -> SCL (A5 on Arduino Uno, Leonardo, etc or 21 on Mega and Due, on esp8266 free selectable)
SDA -> SDA (A4 on Arduino Uno, Leonardo, etc or 20 on Mega and Due, on esp8266 free selectable)
ADD -> (not connected) or GND
ADD pin is used to set sensor I2C address. If it has voltage greater or equal to
0.7VCC voltage (e.g. you've connected it to VCC) the sensor address will be
0x5C. In other case (if ADD voltage less than 0.7 * VCC) the sensor address will
be 0x23 (by default).
*/
#include <Wire.h>
#include <BH1750.h>
BH1750 lightMeter(0x5C);
void setup(){
// start serial communication
Serial.begin(115200);
// start I2C on pins 4 and 15
Wire.begin(4,15);
// initialize the bh1750
lightMeter.begin(BH1750::CONTINUOUS_HIGH_RES_MODE, 0x5C, &Wire);
}
void loop() {
float lux = lightMeter.readLightLevel();
Serial.print("Light: ");
Serial.print(lux);
Serial.println(" lx");
delay(3000);
}
Hello. Thank you for your library. I have question.
How can i using 2 sensors by one pair I2C pins? I know that i can setup 2 adress on sensor, by ADD pin, but how i can read data from both sensors wich have 2 diferent adress from code? How init 2 sensors by code?
I use the sensor together with other I2C devices on one arduino and therfore would like to set a unique I2C adress for the sensor.
Update the version of Arduino used in the Travis continuous integration test to be the latest.
Because at some point was removed this fix for auto-start one-time measurement (maybe because it sarted at reading moment)
And because it is not clear from README.md (but still present in example), that you need to start one-time measurement again by calling
lightMeter.configure(BH1750::ONE_TIME_HIGH_RES_MODE);
(and not just use readLightLevel()
)
I suggest clarifiyng that in README.md:35
When the One-Time mode is used your sensor will go into Power Down mode when it completes the measurement and you've read it.
You will need to run `configure()` each time you want to start measuring before you read the results.
and in example BH1750onetime.ino
Serial.println(" lx");
//run new one-time measurement
lightMeter.configure(BH1750::ONE_TIME_HIGH_RES_MODE);
}
Also because my battery-powered device sleeps between the start and end of measurement - I cannot rely on measurementReady()
function, because millis() are "paused" during sleep, if I remember correctly.
So I suggest adding a function, that gives you back delay time, and reusing that function in the beginning of measurementReady()
function.
Here is quick sketch (sorry, if any bad function names or mistakes - i do not program on C++):
/**
* Calculates time needed for measurement
* @param maxWait a boolean if to wait for typical or maximum delay
* @return a number of milliseconds to wait
*/
unsigned long BH1750::getMeasurementTime(bool maxWait) {
switch (BH1750_MODE) {
case BH1750::CONTINUOUS_HIGH_RES_MODE:
case BH1750::CONTINUOUS_HIGH_RES_MODE_2:
case BH1750::ONE_TIME_HIGH_RES_MODE:
case BH1750::ONE_TIME_HIGH_RES_MODE_2:
return maxWait ? delaytime = (180 * BH1750_MTreg / (byte)BH1750_DEFAULT_MTREG)
: delaytime = (120 * BH1750_MTreg / (byte)BH1750_DEFAULT_MTREG);
case BH1750::CONTINUOUS_LOW_RES_MODE:
case BH1750::ONE_TIME_LOW_RES_MODE:
return maxWait ? delaytime = (24 * BH1750_MTreg / (byte)BH1750_DEFAULT_MTREG)
: delaytime = (16 * BH1750_MTreg / (byte)BH1750_DEFAULT_MTREG);
default:
return 180;
}
}
/**
* Checks whether enough time has gone to read a new value
* @param maxWait a boolean if to wait for typical or maximum delay
* @return a boolean if a new measurement is possible
*/
bool BH1750::measurementReady(bool maxWait) {
// Wait for new measurement to be possible.
// Measurements have a maximum measurement time and a typical measurement
// time. The maxWait argument determines which measurement wait time is
// used when a one-time mode is being used. The typical (shorter)
// measurement time is used by default and if maxWait is set to True then
// the maximum measurement time will be used. See data sheet pages 2, 5
// and 7 for more details.
unsigned long currentTimestamp = millis();
if (currentTimestamp - lastReadTimestamp >= getMeasurementTime(maxWait)) {
return true;
} else
return false;
}
I can make a PR if these changes are acceptable (or you can do it by yourself, if it is more comfortable).
Line 156 in a49b085
Shouldn't we keep 5 bits rather than 3 bits?
It seems that in CONTINUOUS modes, frequent calls to readLightLevel prevents the bh1750 module to actually update the measurement. Presumably, the measurement is interrupted by the i2c communication and has to be restarted.
Thus, if I (say) set
lightMeter.configure(BH1750::CONTINUOUS_HIGH_RES_MODE);
and then call readLightLevel with only 100 (or even 120) millis delays, then I keep getting the same value back.
If I increase to, say, 180 millis (max time to make measurement) ,then I get an updated value every time.
If there already is a caveat about this usage, then I apologize for reporting.
I do not see an easy way to circumvent this, except storing (in the object) the previous measurement and time-of-measurement, and not then checking time vs previous time-of-measurement to see if an updated measurement should be ready.
Obviosly, I can avoid the problem by not calling readLightLevel()
often. I was just surprised by the effect, and want to report it.
Best,
/Bjarne
Hello,
I just wanted to say I tested this library for STM32F103C8T6 with the stm32duino SDK and it works perfectly fine. I think the stm32
can be added to supported platforms, to remove the WARNING: library BH1750 claims to run on avr, sam, esp8266, esp32 architecture(s) and may be incompatible with your current board which runs on stm32 architecture(s).
warning.
i am getting this in serial monitor
t: 0 lx
BH1750 Test
[BH1750] Device is not configured!
my code:
#include <Wire.h>
BH1750 lightMeter(0x5C);
void setup() {
// put your setup code here, to run once:
Wire.begin();
Serial.begin(115200);
lightMeter.begin(BH1750::CONTINUOUS_HIGH_RES_MODE);
delay(2000);
}
void loop() {
// put your main code here, to run repeatedly:
uint16_t lux = lightMeter.readLightLevel();
Serial.print("Light level: ");
Serial.println(lux);
delay(5000);
}
The cabling:
D21 -> SDA
D22 -> SCL
GND & ADDR -> gnd
VCC -> 3.3V
After reading a raw value read from the sensor it is converted to lux units by dividing by a conversion factor. This value is typically 1.2. For use in this library where no calibration is being performed the factor is effectively a constant.
The value is currently hard coded in the body of the readLightLevel
function and looks like a magic number.
Perhaps a better alternative (e.g. clean, more maintainable) would be to define it as a constant along with some comments and use the constant. Something like this:
// Correction factor used to calculate lux. Typical value is 1.2 but can range from 0.96 to 1.44.
// See data sheet (p.2, Measurement Accuracy) for more information.
const float BH1750_CONV_FACTOR = 1.2;
and then later when being used:
// Convert raw value to lux
level /= BH1750_CONV_FACTOR;
I'm working with a custom PCB with an ESP32 Wroom and a BH1750 and using this library to make the readings, most of the times it works perfectly, however eventually the readLightLevel function returns 27 thousand lux, even though it's in a very low level light environment, normally 15 lux. This happens when the I2C clock is at 100k, but doesn't happen in 400k, which seems kinda strange to me, usually the problems happen at higher frequencies, so I think it might be a good idea to see what could be the root of the problem. Ideally I would like to use 100k since the I2C cable is reasonably long, 25cm.
Thank you in advance, and congrats on the great library.
`/*
Advanced BH1750 library usage example
This example has some comments about advanced usage features.
Connection:
VCC -> 3V3 or 5V
GND -> GND
SCL -> SCL (A5 on Arduino Uno, Leonardo, etc or 21 on Mega and Due, on esp8266 free selectable)
SDA -> SDA (A4 on Arduino Uno, Leonardo, etc or 20 on Mega and Due, on esp8266 free selectable)
ADD -> (not connected) or GND
ADD pin is used to set sensor I2C address. If it has voltage greater or equal to
0.7VCC voltage (e.g. you've connected it to VCC) the sensor address will be
0x5C. In other case (if ADD voltage less than 0.7 * VCC) the sensor address will
be 0x23 (by default).
*/
#include <Wire.h>
#include <BH1750.h>
#define durationSleep 10
/*
BH1750 can be physically configured to use two I2C addresses:
- 0x23 (most common) (if ADD pin had < 0.7VCC voltage)
- 0x5C (if ADD pin had > 0.7VCC voltage)
Library uses 0x23 address as default, but you can define any other address.
If you had troubles with default value - try to change it to 0x5C.
*/
BH1750 lightMeter(0x23);
void setup() {
Serial.begin(115200);
// Initialize the I2C bus (BH1750 library doesn't do this automatically)
Wire.begin(D7, D8);
// On esp8266 you can select SCL and SDA pins using Wire.begin(D4, D3);
/*
BH1750 has six different measurement modes. They are divided in two groups;
continuous and one-time measurements. In continuous mode, sensor continuously
measures lightness value. In one-time mode the sensor makes only one
measurement and then goes into Power Down mode.
Each mode, has three different precisions:
- Low Resolution Mode - (4 lx precision, 16ms measurement time)
- High Resolution Mode - (1 lx precision, 120ms measurement time)
- High Resolution Mode 2 - (0.5 lx precision, 120ms measurement time)
By default, the library uses Continuous High Resolution Mode, but you can
set any other mode, by passing it to BH1750.begin() or BH1750.configure()
functions.
[!] Remember, if you use One-Time mode, your sensor will go to Power Down
mode each time, when it completes a measurement and you've read it.
Full mode list:
BH1750_CONTINUOUS_LOW_RES_MODE
BH1750_CONTINUOUS_HIGH_RES_MODE (default)
BH1750_CONTINUOUS_HIGH_RES_MODE_2
BH1750_ONE_TIME_LOW_RES_MODE
BH1750_ONE_TIME_HIGH_RES_MODE
BH1750_ONE_TIME_HIGH_RES_MODE_2
*/
// begin returns a boolean that can be used to detect setup problems.
if (lightMeter.begin(BH1750::CONTINUOUS_HIGH_RES_MODE)) {
Serial.println(F("BH1750 Advanced begin"));
}
else {
Serial.println(F("Error initialising BH1750"));
}
float lux = lightMeter.readLightLevel();
Serial.print("Light: ");
Serial.print(lux);
Serial.println(" lx");
delay(1000);
ESP.deepSleep(durationSleep * 1000000);
}
void loop() {
}`
Any ideas why deepSleep breaks the library ?
Hi, it does not work with this board:
WARNING: library BH1750 claims to run on avr, sam, esp8266, esp32, stm32 architecture(s) and may be incompatible with your current board which runs on renesas_uno architecture(s).
[BH1750] Device is not configured!
A simple patch to get this library working.
bh1750.patch.txt
the sensor has the option to change the measurement time (pg 11) to adapt optical windows influence.
If we implement that, we need a function to write the register over i2c, a private value to save the selected value and patch the readLightLevel() function.
Sorry, my bad, I've found my issue, you can delete this ^^'
I ran three readings with varying MTreg values (31, default, 200).
Across a range of light levels (in the 100-500 lux range), the lux value computed for MTreg=200 was wildly different to the other cases.
This makes me suspect that there is a bug, probably involving incorrect data types and/or integer division. This could be in the calculation of the time interval (this is tentatively confirmed by injecting my own time delay).
[version 1.3.0 used on ESP8266 arduino platform]
Can you help me with get this working? Especially with first line.
if (!lightMeter.begin()) {
lcd.print("Light failed!");
while (1) {}
}
Hi, using this code:
#include<Arduino.h>
#include <Wire.h>
#include <BH1750.h>
BH1750 lightMeter1(0x23);
BH1750 lightMeter2(0x5C);
void setup(){
Serial.begin(9600);
Wire.begin(D1, D2);
lightMeter1.begin(BH1750::CONTINUOUS_HIGH_RES_MODE_2);
lightMeter2.begin(BH1750::CONTINUOUS_HIGH_RES_MODE_2);
Serial.println(F("BH1750 Test"));
}
void loop() {
uint16_t lux1 = lightMeter1.readLightLevel();
uint16_t lux2 = lightMeter2.readLightLevel();
Serial.print("Light1: ");
Serial.print(lux1);
Serial.print(" lx. Light2: ");
Serial.print(lux2);
Serial.println(" lx.");
delay(1000);
}
in a nodeMCU, like sugested in #25 but the output is the same for both, only reads from 0x23
For HIGH_RES_MODE_2 modes the correct formula is:
level = (level / 1.2) / 2
The problem highlighted in this issue is pretty unlikely and has never been reported before so is likely very low priority.
When reading a light value there is a possibility that the data read is not the expected 2 bytes. The implementation assumes that 2 bytes are read, even if they are not, and continues progressing through the function which could then use garbage data in the uninitialised level
variable.
Only a happy path is really accommodated for in the implementation and Arduino does not seem to really support error handling (e.g. exceptions). Perhaps we could consider returning a negative number to signal an error - though the existing return value type does not support that. Perhaps in this condition it could return 65535 which is well above the maximum possible lux value (which is raw/1.2 = 54612).
When reading a light value there is a possibility that the data read is not the expected 2 bytes. The implementation assumes that 2 bytes are read, even if they are not, and continues progressing through the function which could then use garbage data in the uninitialised level variable.
After applying pull request #44 the maximum light level value has been changed from NAN to 65535. This value is well above the maximum possible lux value (which is raw/1.2 = 54612).
The README documentation should be updated to inform the user that a value above 54612 indicates an error or undefined scenario.
Hi!
Is it possible to change the default A5 and A4 pins (both in Arduino and ESP8266)?
Thanks!
Great lib!!
Hi,
How to send sensor properly to sleep ? Before I changed write8 as public and it did the trick. But new version cannot figure out how to do.
public:
BH1750();
void begin(uint8_t mode = BH1750_CONTINUOUS_HIGH_RES_MODE);
void configure(uint8_t mode);
uint16_t readLightLevel(void);
//private:
void write8(uint8_t data);
};
in the actual code I did put this:
lightMeter.write8(BH1750_POWER_DOWN);
it was working.
Lib is great, thanks!
Hi, thanks for that library, I like it :)
Except one warning when I compile it, for ESP32 on PlatformIO :
BH1750.cpp:144:21: warning: overflow in implicit constant conversion [-Woverflow]
uint16_t level(NAN);
As you can see, I used the MTreg value to capture outdoor light.
It reveals an error. The esp8266 is in deep sleep, therefore it restart completely and the saved MTreg value in the library get lost. But the sensor itself uses another MTreg value. I have no idea how to solve the problem in a nice way, but some thoughts:
begin()
some resetting to the default MTregI get very different readings, which differ by a factor of ~2:
CONTINUOUS_HIGH_RES_MODE
gives me: 160 "lx" under a bright LED bulb, but facing the wall.CONTINUOUS_HIGH_RES_MODE_2
gives me: 320 "lx" in the same environment.Example:
Which one of these readings is correct and what went wrong with the other one? Sadly I cannot really guess which one is correct because I cant really put them in perspective, i.e. I have no idea what to expect. My question is not, which of these readings is correct for my particular scenario, rather which one is correctly calculated / measured.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.