WiFi Kit32 v.3 and DHT11 sensor

Ok, I’ve got the OLED and I2C working perfectly now am now stuck on something that should be simple, I want to add a DHT11 sensor for humidity readings. The DHT11 is not I2C so I need to connect it to a GPIO pin, but I cannot find one that works. Here is a simple sketch in which I’ve tried several GPIO pins in line 7 but none have worked. What am I doing wrong?

// Example testing sketch for various DHT humidity/temperature sensors

// Written by ladyada, public domain

// REQUIRES the following Arduino libraries:

// - DHT Sensor Library: https://github.com/adafruit/DHT-sensor-library

// - Adafruit Unified Sensor Lib: https://github.com/adafruit/Adafruit_Sensor

#include "DHT.h"

#define DHTPIN 48 // Digital pin connected to the DHT sensor

// Feather HUZZAH ESP8266 note: use pins 3, 4, 5, 12, 13 or 14 --

// Pin 15 can work but DHT must be disconnected during program upload.

// Uncomment whatever type you're using!

#define DHTTYPE DHT11 // DHT 11

//#define DHTTYPE DHT22 // DHT 22 (AM2302), AM2321

//#define DHTTYPE DHT21 // DHT 21 (AM2301)

// Initialize DHT sensor.

DHT dht(DHTPIN, DHTTYPE);

void setup() {

Serial.begin(115200);

Serial.println(F("DHTxx test!"));

dht.begin();

}

void loop() {

// Wait a few seconds between measurements.

delay(2000);

// Reading temperature or humidity takes about 250 milliseconds!

// Sensor readings may also be up to 2 seconds 'old' (its a very slow sensor)

float h = dht.readHumidity();

// Read temperature as Celsius (the default)

float t = dht.readTemperature();

// Read temperature as Fahrenheit (isFahrenheit = true)

float f = dht.readTemperature(true);

// Check if any reads failed and exit early (to try again).

if (isnan(h) || isnan(t) || isnan(f)) {

Serial.println(F("Failed to read from DHT sensor!"));

return;

}

// Compute heat index in Fahrenheit (the default)

float hif = dht.computeHeatIndex(f, h);

// Compute heat index in Celsius (isFahreheit = false)

float hic = dht.computeHeatIndex(t, h, false);

Serial.print(F("Humidity: "));

Serial.print(h);

Serial.print(F("% Temperature: "));

Serial.print(t);

Serial.print(F("°C "));

Serial.print(f);

Serial.print(F("°F Heat index: "));

Serial.print(hic);

Serial.print(F("°C "));

Serial.print(hif);

Serial.println(F("°F"));

}

World’s worst sensor, both for vagueness of reading and it’s ancient protocol, whereas now you have I2C working, getting an I2C sensor going should be simple.

The alternative is to start with an empty sketch, only add the DHT library and look as the S3 data sheet to find a pin that is only GPIO without any other alternative uses added. GPIO48 is for SPICLK_N and should switch modes but …

Thanks for the info on the DHT11. The point is that this is just a hobby project but I’m frustrated that I can’t seem to find a GPIO pin to use as GPIO. I have ordered some I2C I/O expander boards so I will soon be able to use I2C for most sensors but I would still like to know how to use the GPIO pins on the WiFi Kit32 board, coming from Arduino and ESP32 where this is easy makes me think there must be a way to use the GPIO pins for simple sensors, or leds, or switches etc.

By the way, the sketch above is a simple sketch using only the DHT.h library and GPIO48, but it doesn’t work.

There’s something with DHTs…

GPIO2-7 should be very usable, 38-42 as well but slightly less preferable.

Also, no need to use an I2C expander - I2C can be shared among multiple sensors as long as the sensors have different addresses. And even if there’s an address class, about half of the sensors out there offer a way to change the address to prevent the clash.

Noooooooooooo … I2C expanders require much VooDoo in the co-ordination of which channel is set to which. Only used it on a commercial project once for having 8 x BME680’s and we spent far too much time debugging the multiplexer vs config of BME. And as @BNS says, that’s the whole point of I2C addresses - lots of sensors, just one bus.

Read the datasheets & schematic, look for unencumbered pins, test …

Then become a hero by documenting it all!

I am actually refering to a device to allow non I2C devices to use the I2C protocol rather than a hub. https://www.amazon.de/gp/product/B07DK4WDRW/ref=ox_sc_act_title_1?smid=A3SCFTIO8CSK1X&psc=1

Those are useful enough - some have more pins - just try not to have real time on/off or reads on those as the whole I2C interface isn’t as quick as real GPIO. But good for indicator LEDs and the like.

See my comment to bns regarding the I2Ci/o expander boards, I obviously didn’t explain myself very well.

Regarding becoming a hero, that is not my intention. I just want to be able to use a board I paid €20 for. The documentation for their boards should be done by Heltec, not me. At the moment the docs are full of contradictions and downright false information. I took me week to get the OLED and I2C to work together, with lots of help from you and others here. I am not really prepared to put the same effort into simply getting any GPIO pin to work as a GPIO pin. I think it’s going to be back to an ESP32 with a separate OLED for me. One other thing whilst I’m ranting, you mentioned ChatGPT getting confused about the Heltec pins, suggesting pins that are not even broken out etc. This just shows how bad the Heltec documentation is.

Or consider the phrase, the board you ONLY paid $20 for. An absolutely miracle of economics.

If you wanted it far more gift wrapped & handed on a plate, then go with an Adafruit board, that’s what the price differential is all about.

And in engineering terms, having a requirements list and researching before purchase would uncover some of these issues. Albeit you don’t know what you don’t know until it comes back to bite you.

So you could consider that the $20 is a good investment in your embedded learning. And I do appreciate that this could be a larger investment for some, depending on where in the world they are, but with a Western name talking about $$$, I’d suspect not so much as those from Sub-Saharan Africa that I work with.

You did it with your I2C code snippet. If you collate your pin info you can do it again. This is how we all collaborate on such things to fill the gap between keenly priced sparsely documented hardware and easy of use.

How do we (me, @bns, @UniquePete and others) cope with this? As we reference the docs, we set aside the older / broken materials, we look at the schematic and we look at the Espressif datasheet.

When I need to go on a brute force pin hunt with ESP for ANY vendors hardware, I write code that takes a pin number from the serial port and manually move a jumper one at a time until I’ve tried them all.

Until computing becomes more like civil engineering which is about us all raising our games, this is reality, and yes, it does surely suck.

An ESP32 NodeMCU together with a 0.96" OLED cost less than half the price of the Heltec WiFi Kit32 v3 and works out of the box with full and accurate documentation online and hundreds of examples to learn from. Is it better to learn actual programming rather than the intricacies and foibles of just one board?

Having said that, I am not one to let something beat me. So you will no doubt be hearing from me again :wink:

1 Like

Hi, steve.
In fact, I have been sorting out heltec documents recently. If you have any requirements, please let me know.
My E-mail address is: richard@heltec.cn

Hi Richard, a good start would be if you could tell me what GPIO pins I could use to connect a DHT11 sensor to my Heltec WiFi Kit32 v3 and make the sketch above work.

That’s not really feasible or helpful - should we all list the different sensors available and ask Heltec to provide code for each one for each product. And then when a new product comes out …

Rummaging around the big box of random sensors and found me a DHT11 - can confirm it works fine on pin 48 using the Adafruit library.

So maybe you have a broken one?

This is sort of why the DHT11’s are a bit left field - harder to test unless you have two. Whereas once you have I2C working, debugging is easier.

I have two DHT11, one is brand new and was sealed in a packet and both work fine with my ESP32.

What exactly is the name of the Adafruit library you have successfully used?

I have also tried to use the HC-SR04 sensor with my WiFi Kit32 v3 without success after having it working fine on a ESP32 though I admit I haven’t tried all the possible pin combinations (it needs a Trigger pin and Echo pin). I am not asking for Heltec to provide code for every possible sensor, just to say clearly, without contradiction, which pins are available and with what restrictions.

Dunno what its name is, wasn’t looking, but Google says that there is only one. My code is the same as yours - I opened the example, set the pin to 48 and compiled/downloaded.

This is all detailed in the schematic & the data sheet for the ESP32-S3.

It may not be convenient, but just use pins that are not used for boot mode that aren’t attached to any other component on the schematic - that just routes straight to the pin header.

I’ve got plenty of HC-SR04’s, I can try one out when I’m back in the office.

Heltec are mostly guilty of confusing docs, partly due to naming conventions, probably exacerbated by English as a Second language.

I’d go with Microchip as being the gold standard - made considerably easier as they have English as a Butchered language but I know some of the staff British so that helps.

ST are pretty good with docs, the forum is OK but prone to Italian shrugging. It took a very long time for me to get more than one DS18B20 to work on a pin for reasons that have never really become clear.

Nordic are good with hardware docs but merged their SDK with Zephyr, the most opaque Arduino-esque RTOS in the world ever. And their forum is populated by well meaning but not very can do staff.

At least here you have enthusiasts to call upon!

I know nothing of the companies you mention. I came to Heltec from using Arduinos, ESP8266s, ESP32s and M5Stack, I saw an ESP32 compatible board with a OLED built in and thought “Cool, I could do a lot with that”.