💬 Air Humidity Sensor - DHT

[jwosnick]

I've made a bit of an unusual observation in relationship to this script. I am running a fairly stripped-down version of it, but with the "standard" (not MySensors-customized) DHT library and its associated functions.

Here is the code:

// 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_NODE_ID 47

#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 5

// 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 = 10000;

#define CHILD_ID_HUM 0
#define CHILD_ID_TEMP 1

bool metric = true;

MyMessage msgHum(CHILD_ID_HUM, V_HUM);
MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);
DHT dht(DHT_DATA_PIN, DHT22);
float temperature;
float humidity;

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()
{
  delay(100);
}


void loop()      
{  
  
  // Get temperature from DHT library
  temperature = dht.readTemperature();
  if (isnan(temperature))
  {
    Serial.println("Failed reading temperature from DHT!");
  }
    
  else
  {
    send(msgTemp.set(temperature,0));
    #ifdef MY_DEBUG
    Serial.print("T: ");
    Serial.println(temperature);
    #endif
  }  

  // Get humidity from DHT library
  
  humidity = dht.readHumidity();
  if (isnan(humidity))
  {
    Serial.println("Failed reading humidity from DHT!");
  }
    
  else 
  {
    send(msgHum.set(humidity,1));
    #ifdef MY_DEBUG
    Serial.print("H: ");
    Serial.println(humidity);
    #endif
  }

  // Sleep for a while to save energy
  sleep(UPDATE_INTERVAL); 
}

I find that if I leave the last line as
sleep(UPDATE_INTERVAL);
then the sensor node ends up sending the same temperature and humidity values, over and over again, even if the actual humidity and temperature change.

However, if I change the last line to
delay(UPDATE_INTERVAL);
then everything works as expected.

This is with known good DHT22 units, so I suspect there is something funny about the sleep() function and the operation of the standard (not customized) DHT library.

It took a lot of poking around to discover this, but is this in fact the reason why the MySensors customized DHT library is required for this script? Is that library necessary to make sleep() and DHT temperature measurements play nicely together?

[gohan]

What libraries versions are you using?

[mfalkvidd]

@jwosnick the example sketch has this:

  // Force reading sensor, so it works also after sleep()
dht.readSensor(true);

which is missing in your sketch. The comment suggests that it might be relevant.

[jwosnick]

@mfalkvidd

Yes, absolutely. But it appears that the dht.readSensor() function is not actually part of the standard DHT library, but rather something that only appears in the MySensors-customized version of it. I'm trying to get a handle on why there is a need for a customized library.

[mfalkvidd]

@jwosnick seems like the most recent version of the original library calls readSensor when getTemperature is called.

Maybe the most recent version can be used if the MySensors example sketch is rewritten to just use getTemperature? Would it be possible for you to test this? It would be great if we could get rid of the MySensors-custimized version of the library and just let people install the standard DHT library.

[jwosnick]

@mfalkvidd said in 💬 Air Humidity Sensor:

@jwosnick seems like the most recent version of the original library calls readSensor when getTemperature is called.

Yes, it does... but somehow that function is not "exposed" to the outside world. With a standard DHT test sketch (nothing to do with MySensors) calling readSensor throws an error.

[mfalkvidd]

@jwosnick yes. But since readSensor is called inside getTemperature, there should be no need to call it manually.

[avgays]

@jwosnick

As your set sensor model

DHT dht(DHT_DATA_PIN, DHT22);

it looks like you use "Adafruit DHT-sensor-library".
It's need dht.begin(); in setup(){ } which is missing in your sketch

[jwosnick]

@avgays
Good catch -- thanks. Yes, that is the library I am using.

Despite omitting that line, the script above works fine as long as the last line is a delay() function and not sleep(). If I use sleep(), it in fact appears to work, but sends the same temperature and humidity over and over again. So it is something about the sleep() function.

I will add in the dht.begin() and then put sleep() back in and see what happens.

[jwosnick]

@avgays Confirmed that even with dht.begin(); the script still sends the same temp and humidity info, over and over again, as long as the sleep() function is in there. As soon as sleep() is replaced by delay() it all works properly.

So I conclude from this that the MySensors-customized version of the DHT library must have something in it to make sleep() play nicely with the DHT unit. I wish I knew what that was. It would be ideal if this sensor (and the Dallas Semiconductor one) could be used with the MySensors system with their standard libraries.

[avgays]

@jwosnick
Very strange as in my case this library work well with sleep() on battery-powered node.

Look like it's nessesary to add delay(2000); before or after sleep() as sleep mode stops all timers, so
currenttime - _lastreadtime =0
and function returns with no new measurements.

[Digdogger]

Hi,
I would like to use this example and reduce power consumtion by removing the regulator on the mini Pro and the power led.
If we remove the regulator, we can power the board with 3V on Vcc. It will be OK for the mini pro and the NRF but the DHT22 needs 3.3V minimum. The solution will consist to use a step up boost module. What is the current consumtion of the step up boost?

[gohan]

I don't know about DHT22, but NRF24 can work down to 1.8 or 1.9V so you can connect it directly to battery (take a look ad EasyPCB)

[AWI]

@Digdogger it's better to get rid of the DHT and use something more reliable and operating at lower voltages. Like si7021, sht21 or Bme280

[Digdogger]

Thanx for your answers. @AWI, the BME280 looks great and not expansive i will replace the DHT by this one. Thank you.

[jwosnick]

@Digdogger
Out of curiosity, do you expect there to be a big savings in power consumption by removing the regulator and power LED? I've never used the Mini Pro (the smallest I get to is the Nano) but I understand it already is very efficient with power usage.

[Digdogger]

@jwosnick: please take a look here: http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/.
You'll see that the current saving is significant (almost 40% saving)

[gohan]

@jwosnick
Arduino is efficient for a live node, but for a battery powered sleeping node voltage regulators have a small drain on battery; led also consumes some power. The Nano has also the usb chip that is powered but not used that also increases battery drain. So, as rule of thumb, everything that is not really used/necessary will drain some battery over time.

[mfalkvidd]

@jwosnick with the led and regulator, battery life on 2xAA is about three weeks. Removing them will usually give you 2-5 years.

[jwosnick]

@mfalkvidd

Thank you. I didn't realize the differences were so stark.

I have some Pro Mini 3.3V units on order and hope to convert my sensors to that platform, when they arrive.