DHT22 Temp readings in the -3200 range

Hi, I recently assembled a NodeMCU board with a DHT22 to read the temp of my deep freeze. For some reason it shows the temp as -3260C inside my freezer. When I remove it from my freezer and hook it to my computer and print out the values using the serial communication, it prints out about 21C which is about right in my house. I assume the freezer is somehow between 0C and -17C, which should be within the supported range.

Basically every 5 minutes I call a thinger endpoint with the temp and texts my phone if it drops below a certain threshold.

Here is my code:

#include <SPI.h>
#include <ESP8266WiFi.h>
#include <ThingerESP8266.h>
#include <DHT.h>

#define USERNAME "****" // Your login name from thiner.io
#define DEVICE_ID "****" // Your device ID from thinger.io
#define DEVICE_CREDENTIAL "*****" // your crefential from thinger.io

#define SSID "*****"
#define SSID_PASSWORD "*****"

#define DHTPIN D1
#define DHTTYPE DHT22
DHT dht(DHTPIN, DHTTYPE);

ThingerESP8266 thing(USERNAME, DEVICE_ID, DEVICE_CREDENTIAL);

unsigned long previousMillis = 0;      // to know when to post the temperature
unsigned int minutes_interval = 5;    // variable in minutes for posting the temperature
int temp_threshold = 32;

void checkTemp() {
  float flTemp = dht.readTemperature();
  int temp = -100;
  digitalWrite(LED_BUILTIN, LOW);
  delay(100);
  pson data;
  data["value1"] = flTemp;  
  thing.call_endpoint("freezer_temp", data);
  digitalWrite(LED_BUILTIN, HIGH);         
}

void setup() {
  dht.begin();
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, HIGH);

  thing.add_wifi(SSID, SSID_PASSWORD);
}

void loop() {
  thing.handle();
  unsigned long currentMillis = millis();
  if(minutes_interval>0 && currentMillis - previousMillis >= minutes_interval * 60000) {
    previousMillis = currentMillis;   
    checkTemp();
  }
}

FWIW I just moved it to my other fridge to see if the temp change made a difference and now it shows at 1C in the other fridge, which is accurate. Its like as soon as it goes negative, it goes to -3260.

Off hand it is looking like somewhere in the mix there is an unsigned number that is getting a signed number passed to it.

One thing you can try for testing is add 100 degrees to the reading while it is still a float. If it reads what you expect just with an extra 100 then look hard at the signed an unsigned. If it is still giving you -3260 then time to consider something passing you an error code that is not being handled. Could be the temp sensor or maybe the module that is texting you.

Thanks for the info! I did a little more digging and got the raw data from the sensor. Sorry ifyou already know this, but just want to explain it clearly.

The temp sensor returns 16 bits to represent the temp, the first bit is the negative sign. On the library it splits these 16 bits up into 2 8-bit entities (data[2] & data[3]). I printed out the 2 8-bit items and this is what I get.

1111 1111 1001 0110

This means the negative bit is working, and I think the last 8 bits are correct. Its those 7 bits in the middle that are skewing my number so bad. Here is the old code and my new code, currently testing it in my freezer.

f = ((word)(data[2] & 0x7F)) << 8 | data[3];
      f *= 0.1;
      if (data[2] & 0x80) {
        f *= -1;
      }
      if (S) {
        f = convertCtoF(f);
      }
f = ((word)(data[2] & 0x00)) << 8 | data[3];
      f *= 0.1;
      if (data[2] & 0x80) {
        f *= -1;
      }
      if (S) {
        f = convertCtoF(f);
      }

I felt like I could do this without much concern because I will never have a temp that is greater than 25.6 C. Basically those left-most 7 digits are worthless to me.

Do you think this is a sensor issue or a library issue?

I have now tried this with 3 different libraries and they all read the same thing. When my freezer is very close to 0F (-18C), it does not give me the correct output bits. I have also tried this with 2 different NodeMCU boards.

This leads me to believe the DHT22 is bad.