Imagine a small device on a workshop shelf that tells someone to check the room. Showing temperature and humidity is easy to describe. Deciding when the device should interrupt a person, and what that person should do next, takes more thought.
We built this in two steps on our bench. First, a DHT11 temperature and humidity sensor beside a small SSD1306 OLED display. Then a second build that adds a light-sensing module, an LED and a buzzer. Both ran on a Raspberry Pi Pico-based controller board, programmed with blocks in BIPES, a browser-based editor for MicroPython. Together they show how a set of readings becomes a rule, while leaving the choice of a useful rule open.
Combining these parts is a familiar problem: a February 2016 forum post asks for review of a similar mix of sensors, display and buzzer assembled from several sketches.
Establish the reading before the warning
The first program initializes the DHT11 and the display, takes a measurement, writes humidity and temperature, and waits two seconds before the next cycle. H labels humidity and T labels temperature. MicroPython's DHT documentation describes calling measure() before reading the values; humidity is relative humidity in percent and temperature is in degrees Celsius.
The display is a useful first checkpoint. Can the intended reader tell which number is which? For a version other people will use, add visible units and a clear indication when a fresh reading could not be obtained. Our first build did neither.
Pin assignments drifted between our program versions: one block version selected GPIO7 for the DHT11, a separate code version used Pin(6), and the combined project used GPIO9. Keep each program with its own connection record instead of treating the versions as interchangeable instructions.
Add the question the alert should answer
The combined build puts more modules around the same controller. It shows a light value as well as temperature and humidity, then drives an LED and a buzzer. That is a good arrangement for discussing an alert, because a person can compare the feedback with the displayed inputs.
The rule we programmed was specific: temperature above 28 or below 20, or humidity above 60 or below 30, entered the alert branch. Those were placeholder settings for the experiment, not established comfort or health limits. The light value was displayed but was not part of the alert condition.
The light value came from this expression:
light = int((39000 - adc_reading) / 39)
It is a transformed input count. Nothing in the build calibrates it to lux, and giving it a familiar unit would make the display look more authoritative without making it more informative.
We also found an ordering problem: the block sequence stored the DHT values before its measure block ran, so each alert decision used the previous measurement. In a revised program, take a fresh measurement before storing the values that drive the alert, following the driver's documented order, and note the correction in the revision record.
One more caution about our records: a screenshot of the simpler temperature-and-display loop was easy to mistake for the combined program. It does not show that the light input and the alarm ran together. Keep the display-only and combined programs as separate files.
Decide what a person should do when it sounds
For a workshop reminder, a useful trial asks whether the sound prompts the intended action or just sends someone looking for a mute button. Choose a reason for the reminder, then compare the displayed reading with the condition that caused it. A general room measurement is not automatically a reason to interrupt someone.
Next, plan what happens near a boundary. If the reading crosses back and forth, should the alert change each time, wait for a sustained change, or stay on until someone acknowledges it? Our on/off branches do not answer that; it is a design choice to make and then test.
A useful next prototype pairs three things:
- a corrected acquisition sequence, measuring before deciding;
- a written alert rule, including what happens near the threshold and when no reading is available;
- a small set of observed trials with real people in the real room.
With those in hand, choosing the enclosure, mounting position and type of feedback becomes a question with an answer, rather than a guess about what the device is for.