Use of BH1750 light sensor in low power node

[NeverDie]

@mfalkvidd
Have you considered sleeping your sensors rather than turning them off? I measured the standby current on a BME280 to be 148na using a Dave Jones Microcurrent. I don't know what your light sensor would measure out at though, but you may burn less current sleeping your sensors than going through a higher drain startup, depending on how long you sleep them for.

Have you considered using a simple photo-resistor connected to the ADC on your atmega328?

[Nca78]

@NeverDie said:

@mfalkvidd
Have you considered sleeping your sensors rather than turning them off? I measured the standby current on a BME280 to be 148na using a Dave Jones Microcurrent. I don't know what your light sensor would measure out at though, but you may burn less current sleeping your sensors than going through a higher drain startup, depending on how long you sleep them for.

Have you considered using a simple photo-resistor connected to the ADC on your atmega328?

The idea of using BH1750 is to have precise lux measurement.
Didn't have time to test with another sensor but I will do it soon, maybe that one is just faulty as I see no logical reason for it to behave that way, even in continuous measurement mode and battery powered it's doing the same.

[alexsh1]

You can measure voltage and see if it drops too much during sending. Unfortunately, CR2032 is not a very powerful power source.
Another idea would bee having sensor measurements done desperately. I have several sensors (BH1750 + TSL2561 + VEML6070 UV(coming shortly) MOD-1016 (lightning sensor)) running from a tiny Li-on 3.7v 350mA battery without any issues.

[NeverDie]

It may be a long-shot, but I wonder if in fact your sensor is actually working perfectly and your lighting is the kind that flickers on and off at a very fast rate, tricking your eye into believing that it's continuously on? If your sensor were to sample fast enough, perhaps it is reporting the amount of light that is actually there during each brief sample interval rather than the average that you were expecting.

Incidently, how are you liking Domoticz? I'm looking for something that will log and graph my sensor data, and I like how Domoticz appears to do that for everything by default. Is it easy to learn, or is it a steep learning curve?

[Nca78]

@NeverDie sampling time for measurement is long (>100ms), flicker in lighting that could influence it would be clearly visible with human eye. It also does the sames with natural light which can vary with cloud coverage but not that wildly :)

For Domoticz it's not very difficult to learn I think, but the log for sensor data is not complete. It keeps values at regular intervals (not all values sent): every 5 minutes for the last day by default, it can be increased to 7 days in the configuration but after that it will only keep average and min/max for each day.
I'm also a bit frustrated with the limited interface too, I would like to be able to combine switches/selectors/etc into one block (for example all settings to control an AC) but that is not possible.

[AWI]

@NeverDie we should start a separate thread on controller experiences. But for here, and the way I see it : Domoticz is a do it all, easy to use controller with interface to excellent data handling (influxdb, etc). Works out of the box in most cases. I have recently started to look at mycontroller which is geared to MySensors and is more configurable.

[gerritv]

Not sure if you ever solved the BH1750 problem. I had same issue, the BH1750 library does not correctly handle the case where One Time is configured as mode. The sensor literally powers down after the command is executed. You would need to wake it up again by issuing a Power On command (0x1) according to data sheet.
I switched to using BH1750_CONTINUOUSxxxx but then I am not looking to save the few microA. My attempts to fix the driver library haven't succeeded yet :-( I would prefer it worked properly with BH1750_ONE_TIMExxxx.

[gerritv]

I submitted an issue on the BH1750 library, which was fixed. So OneTime modes now work as expected.
https://github.com/claws/BH1750/issues/17

[4994james]

@gerritv

I am using v1.3.0 of the BH1750 library which I think is the most recent version on github (updated Jan 22).

I had the same issue when using ONE_TIME_HIGH_RES_MODE in that the sensor would return an accurate light level on first power up but then each subsequent read would return the same value regardless of the light level.

Reading through the source code (I think) the measureReady statement is still missing a configure statement to re-power up the module.

So I put a configure statement in the main loop of the sketch which (I think) powers up the module and then a wait for 200ms to allow enough time before reading.

void loop(){
    if (!lightSensor.configure(BH1750::ONE_TIME_HIGH_RES_MODE)){ 
    Serial.println("Could not power up light sensor");
    }
    wait (200);
    if (lightSensor.measurementReady()) {
    uint16_t lux = lightSensor.readLightLevel();// Get Lux value
    #ifdef MY_DEBUG
    Serial.println(lux);
    #endif
    send(msgLight.set(lux, 1));
    }
etc...

My device is a combination temp/hum sensor using a HTU21 and light sensor using BH1750.

I now get accurate light levels each read cycle.

In BH1750 continuous mode the current draw was about 0.15mA between reads. In one time mode it is now reading 0.01mA on my ammeter, i.e. almost too small to read.

[nekitoss]

@gerritv Thank you for pointing the problem. I was updating my code, while library was updated and found that i had funtion, that does not exists in library - i've added it in local copy in library, then it updated and my local patch was gone.
I've investigated previosly mentioned PR - and must admit that later they removed that re-initialisation when reading.
I will try a PR to slightly improve that behaviour, but looks like library is becoming abandoned.

Now look it should work next way: after previous measurement done you must run lightSensor.configure(ONE_TIME_) so it starts measuring - this is shown in their example BH1750onetime.ino. Then we have to wait, but measurementReady() relies on _delay_ms, which (as i remember) won't tick during sleep so you can't sleep. We can sleep but we can't get exact measurement time for current settings. Soto save battery we sleep max time - which, according to library is 180ms. Then we get reading. On next cycle - repeat.

As i understand maximum battery saving code will look like:

void setup() {
  Wire.begin(); // Initialize the I2C bus (BH1750 library doesn't do this automatically)

  lux_init_status = lightMeter.begin(BH1750::ONE_TIME_LOW_RES_MODE); //init ONE_TIME - at same time it will start measuring, but we will ignore this and double-call start measuring
  if (lux_init_status == false) {
    send(deb_msg.set("ErrorInitLux")); //notify us about failure
  }
}

void loop() {
  if (lux_init_status) { //making it fail-safe  - if BH1750 brokes then other sensors will still work
    lightMeter.configure(BH1750::ONE_TIME_LOW_RES_MODE); //this will start measuring, after it sensor will go into power-down mode
    //note, that configure has 10ms sleep built-in
    sleep(180); //this is guarantee time in this library with any config. We can't get that externally as for v1.3.0
    long lux = lightMeter.readLightLevel(); //actually get results
  }
  
  sleep(SLEEP_TIME);//sleep between measurements
}

note that .configure() that is also called by .begin has built-in 10ms delay