Git Product home page Git Product logo

bh1750's People

Contributors

beta-tester avatar claws avatar coelner avatar flopp999 avatar goebish avatar ivankravets avatar mike-kiwi avatar moritz89 avatar nutter avatar onno-dirkzwager avatar per1234 avatar schaeferpm avatar syssi avatar wridgers avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

bh1750's Issues

The library works for STM32

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.

How can I set I2C adress?

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.

Compile warning

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

Usage information MTreg

As you can see, I used the MTreg value to capture outdoor light.
bildschirmfoto von 2018-10-11 09-16-16

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:

  1. include in begin() some resetting to the default MTreg
  2. get/set method to manipulate the saved MTreg in the library space
  3. inform the user to take care of this behavior
  4. (find a hidden possibility to get the current MTreg from the sensor itself)

Changing the default pins.

Hi!

Is it possible to change the default A5 and A4 pins (both in Arduino and ESP8266)?

Thanks!

Great lib!!

Hello, the library dont really want to work with my esp32s, anyone?

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

Issue calling readLightLevel immediately after setMTReg

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.

how to send sensor to sleep

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!

Possible arithmetic error evident with larger MTreg

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]

Another Kind of Compile Warning

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?

delete

Sorry, my bad, I've found my issue, you can delete this ^^'

Improve error handling

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

[BH1750] Device is not configured! ESP8266 afterESP.deepSleep

`/*

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 ?

Keep Returning 0 Value

Dear Friend,

I have an issue with your library.
screen shot 2018-01-10 at 17 04 30

It keep returning 0 from sensor value. I copy and paste your code. Also already put your library file in place.

Any advice will be so helpful.

Thank you

Frequent calls to readLightLevel prevents measurement update

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

The Wire.requestFrom() does not need beginTransmission() and endTransmission().

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.

include initial measurement delay

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

BH1750 does not work on ESP32

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

}

Here I show de wiring.
bh1750

Thanks.

Huge difference in readings CONTINUOUS_HIGH_RES_MODE vs CONTINUOUS_HIGH_RES_MODE_2

I get very different readings, which differ by a factor of ~2:

  1. CONTINUOUS_HIGH_RES_MODE gives me: 160 "lx" under a bright LED bulb, but facing the wall.
  2. CONTINUOUS_HIGH_RES_MODE_2 gives me: 320 "lx" in the same environment.

Example:

  1. 161 | 161 | 161 | 161 | 161 | 161 | 161 | 161 | 161 | 161 | 161 | 161 | 161 | 161 | 161 | 161 | 161 | 161 | 161 |
  2. 227 | 234 | 324 | 324 | 324 | 324 | 324 | 324 | 324 | 324 | 324 | 324 | 324 | 324 | 324 | 324 | 324 | 324 | 324 | (at first I was covering the sensor a bit)

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.

Reading light level fails if using the ONETIME modes

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

    ...
}

Debug messages can cause the MCU stuck

Due to possibility that printing of error messages can stuck program flow it is better to add choice to enable or disable this messages according to needs of user/programmer of the library.

obrazek

Begin test

Can you help me with get this working? Especially with first line.

  if (!lightMeter.begin()) {
    lcd.print("Light failed!");
    while (1) {}
  }

delay.h missing

I'm trying to interface the sensor to a nodemcu and compiler warns that util/delay.h is missing. Please help

Trouble using 2 sensors

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

[BH1750] Set address _after_ constructor

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

Arduino Uno R4 minima

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!

[TIP] Device not configured - temporary fix.

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

}

Using 2 sensors from one code

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?

Measurement Time Register function

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.

Update README to capture change to undefined light level value of 65535

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.

References are #26 and #44.

BH1750 readLightLevel() eventually returns 27k value in low light environment

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.

clarification on executing next OneTime measurment and getting delay time

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

Define conversion factor as a constant

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;

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.