An environmental prototype can show a plausible temperature even when its program has not obtained a fresh reading. If you are preparing a device for someone else to try, the first question is whether the displayed value comes from a successful measurement and describes the place you care about.
An Arduino forum project combining a DHT11, light sensing, a display and a buzzer shows how quickly that simple reading becomes part of a larger decision. On our bench we isolated the acquisition path first: a DHT11 module on an RP2040 board, with a MicroPython program built in BIPES, before adding any display or alert behavior.
Keep initialization, measurement and reading in order
DHT sensors work in three steps: set up the sensor object on a data pin, ask it to take a measurement, then read the temperature and humidity it returned. The block palette keeps those steps separate, and the separation matters. Reading a property without a new measurement returns the last stored value.
Our working program selected DHT11 on GPIO7. An initialization template in the editor carried a placeholder pin; that pin was not our connection, and leaving it in place is an easy way to read nothing. The program called the measurement, then read and printed temperature and humidity, with a two-second pause between cycles.
import dht, time
from machine import Pin
sensor = dht.DHT11(Pin(7))
while True:
sensor.measure()
print(sensor.temperature(), sensor.humidity())
time.sleep(2)
The DHT driver section of MicroPython's ESP32 quick reference shows the same measure-then-read pattern. Its example pin belongs to a different board, and DHT11 and DHT22 differ in capability and in how often they can be sampled, so check the part you actually fitted.
What one reading shows
A sample from our log read 24 degrees Celsius and 62% relative humidity. That is a recorded output from this setup. We did not compare it with a reference instrument or log it over a long period, so it is not an accuracy result.
Put the result where it stays meaningful
The next version of the program should tell a fresh value apart from a failed measurement. measure() can raise an error when the sensor does not answer; the code should catch that specific failure and report it, not hide it.
Keeping the last good reading can be useful if its age is visible. Silently presenting it as current is not. A missing sample also should not become zero degrees just because zero fits the display. A display line such as "24 C (12 s ago)" or "sensor not responding" tells the person trying the device what is actually known.
Placement is its own question
A sensor next to a warm regulator inside a closed case may describe that local space rather than the room. Our test used an open arrangement on the bench, which says nothing about the sensor's location in a finished enclosure.
For a first user trial, decide what the temperature should answer:
- showing a room condition to the user;
- comparing two locations;
- triggering a local demonstration when a threshold is crossed.
Then record where the sensor sits, what is near it, and how the enclosure is vented. Watch how the reading changes after the device has been powered for a while, after it is moved, and with the case open and closed. These are checks still to run, not results from this test.
The short list before a trial
- Data pin, sensor type and sample interval match the hardware actually fitted.
- Each displayed value comes from a measurement that succeeded, and failures are visible.
- The age of the last good reading is known.
- The sensor position inside the enclosure has been tested with the device running.
That is a small amount of work, and it prevents the most common complaint about a first environmental prototype: a number on the screen that nobody can explain.