Battery issue with whispernode

  • Hello all,

    I recently created a simple temp/humidity sensor using whisper node. Obviously the drive is to power it up using a battery.
    I am using a cr123a battery at 3v and i was hoping this will last at least 6 months. I am measuring 20-30uA at standby using a multimeter so I thought this should be good. But the battery lasts 3 weeks (tried several batteries to be sure)
    So I suspect something on my code maybe makes it draw awfully lots of current during normal operation (not standby) but I am not sure. The code is below. As you can see I am using a dht22 and I am powering it up via a PIN A3 so that I can shut it down completely during standby. Could that be a problem ? Maybe the delays I introduce during power on ? The node reports temp/humidity just fine it is just that the battery does not last long

    // Enable debug prints
    //#define MY_DEBUG
    // Enable and select radio type attached 
    //#define MY_RADIO_NRF24
    //#define MY_RADIO_RFM69
    //#define MY_RS485
    #define MY_RADIO_RFM69
    //#define MY_IS_RFM69HW
    #define RFM69_868MH
    #define MY_RFM69_NEW_DRIVER
    // ******* CUSTOM ENTRY *******
    // ***Set the node ID to 4*****
    // ****************************
    #define MY_NODE_ID 4
    #include <SPI.h>
    #include <MySensors.h>  
    #include <DHT.h>
    // Set this to the pin you connected the DHT's data pin to
    #define DHT_DATA_PIN A1
    #define DHT_PWR_PIN A3
    // Set this offset if the sensor has a permanent small offset to the real temperatures
    #define SENSOR_TEMP_OFFSET 0
    // Sleep time between sensor updates (in milliseconds)
    // Must be >1000ms for DHT22 and >2000ms for DHT11
    static const uint64_t UPDATE_INTERVAL = 60000;
    // Force sending an update of the temperature after n sensor reads, so a controller showing the
    // timestamp of the last update doesn't show something like 3 hours in the unlikely case, that
    // the value didn't change since;
    // i.e. the sensor would force sending an update every UPDATE_INTERVAL*FORCE_UPDATE_N_READS [ms]
    static const uint8_t FORCE_UPDATE_N_READS = 10;
    #define CHILD_ID_HUM 0
    #define CHILD_ID_TEMP 1
    float lastTemp;
    float lastHum;
    uint8_t nNoUpdatesTemp;
    uint8_t nNoUpdatesHum;
    bool metric = true;
    MyMessage msgHum(CHILD_ID_HUM, V_HUM);
    MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);
    DHT dht;
    void presentation()  
      // Send the sketch version information to the gateway
      sendSketchInfo("TemperatureAndHumidity", "1.1");
      // Register all sensors to gw (they will be created as child devices)
      present(CHILD_ID_HUM, S_HUM);
      present(CHILD_ID_TEMP, S_TEMP);
      metric = getControllerConfig().isMetric;
    void setup() {
      // put your setup code here, to run once:
     //Serial.print("Delay 4 ");
     //Serial.print("Delay 5 ");
     dht.setup(DHT_DATA_PIN); // set data pin of DHT sensor
     if (UPDATE_INTERVAL <= dht.getMinimumSamplingPeriod()) {
      //  Serial.println("Warning: UPDATE_INTERVAL is smaller than supported by the sensor!");
      // Sleep for the time of the minimum sampling period to give the sensor time to power up
      // (otherwise, timeout errors might occure for the first reading)
    void loop() {
        //Serial.print("Delay 1 ");
        //Serial.print("Delay 2");
      // put your main code here, to run repeatedly:
      // Force reading sensor, so it works also after sleep()
      // Get temperature from DHT library
      float temperature = dht.getTemperature();
      if (isnan(temperature)) {
      //  Serial.println("Failed reading temperature from DHT!");
      } else if (abs(temperature - lastTemp) > 0.9 || nNoUpdatesTemp == FORCE_UPDATE_N_READS) {
        // Only send temperature if it changed since the last measurement or if we didn't send an update for n times
        lastTemp = temperature;
        if (!metric) {
          temperature = dht.toFahrenheit(temperature);
        // Reset no updates counter
        nNoUpdatesTemp = 0;
        temperature += SENSOR_TEMP_OFFSET;
        send(msgTemp.set(temperature, 1));
        #ifdef MY_DEBUG
        Serial.print("T: ");
      } else {
        // Increase no update counter if the temperature stayed the same
      // Get humidity from DHT library
      float humidity = dht.getHumidity();
      if (isnan(humidity)) {
        // Serial.println("Failed reading humidity from DHT");
      } else if (abs(humidity - lastHum > 0.9) || nNoUpdatesHum == FORCE_UPDATE_N_READS) {
        // Only send humidity if it changed since the last measurement or if we didn't send an update for n times
        lastHum = humidity;
        // Reset no updates counter
        nNoUpdatesHum = 0;
        send(msgHum.set(humidity, 1));
        #ifdef MY_DEBUG
        Serial.print("H: ");
      } else {
        // Increase no update counter if the humidity stayed the same
      // Sleep for a while to save energy

    Can anybody see if there is something in the code that results in draining the battery ?

    Many thanks!

  • Mod

    @cgeo well, your node wakes every 60 seconds and you delay for 1 second after enabling power to the dht sensor. This means the node is awake at least 1/60th of the time and drawing relatively large current.
    The ratio between awake and sleep is normally much smaller for sleeping nodes. That certainly could cause your battery to deplete in a few weeks.
    Try increasing the sleep time to wake only once every hour or so (increase 60 fold of sleep time) and see if your battery lasts significantly longer.

    Another option would be to replace the dht sensor by eg a bme280. These consume very little in sleep mode, so you don't need to toggle its power, and are immediately available after wakeup.

  • Mod

    I get 5 or 6 uA from my node but I use I2C sensor. Did you time how long does it take to run a full loop? In addition you are sleeping just 1 minute... I'd change that to 5 minutes at least and also I'd consider a better quality sensor too that doesn't require to be switched off and is more accurate

  • Many thanks guys. I thought that waking up every minute is quite usual for battery sensors but probably I was wrong. I am forced to use the delays as you know the dht22 is not the fastest in the market. If there is nothing else wrong I will play with the wake up timer

  • @cgeo there is no need to check temperature every minute. Many plug and play devices measuring temperature have a sleep time of 10-15mins. Unless you are doing some research that requires one minute readings, I do not see a reason why you need such frequent measurements.
    Needless to say that it has a negative effect on the battery life

  • @cgeo I also use Whisper Nodes, and currently have two on 2xAA alkaline cells which have been tracking gas and water consumption pulses since early last November, which currently report 3.04 and 3.03 volts respectively. On the Gas Node that equates to 21,160 radio updates to the Gateway....
    Given that the format of this design will suck almost 99% of energy from the cells, 3 weeks duration is truly bizarre.
    One of the sketch modifications you might make is as suggested above (send every 15 minutes - more than adequate) but also to only send a temperature in if it has changed since the last one sent, another is to use WAIT instead of DELAY.
    Perhaps it might be worth monitoring consumption to establish just how much power is used and for how long, just in case you have a faulty device....

  • Mod

    @zboblamont if the node is not meant to receive messages, using wait or delay doesn't make much of difference. It is worth checking temperature difference before sending, but over 15 minutes it will change anyway and also using a DHT sensor is not helping in keeping temperature reading stable 😄

  • @gohan Fair enough, understood it to be better practice to SLEEP or WAIT rather than DELAY.
    I have seen the DS18 string here not report for well over 2 hours in some rooms as they are stable, so it is not a given 15 minutes will see change.
    I still have a DHT22 in the parts box unused, and I suspect it may never be... 😉

  • Mod

    Well, it is all down to how many decimals you are measuring.

  • @gohan 😂 It is now 20.26, and the Lounge is currently reading 21.5 with a precision of 0.1 and has not updated since 17.07....

Log in to reply

Suggested Topics