A light turns on and a buzzer sounds when a sensor changes state. That is a useful interaction demonstration. If the prototype is then described as a fire or gas alarm, the claim has changed far more than the circuit has.
For teams exploring an alert interface, simple sensor modules are still valuable. They show how an input condition becomes an audible response and how a user can silence it. On our bench we built this with a PT334 optical module, an MQ-series gas module, a buzzer and a button on RP2040 boards, with MicroPython programs built in BIPES. What it demonstrates is the control path, not protection against a hazard.
First establish what the input actually reports
The PT334 program read GPIO10 as active-low with a 200 ms pause. The module's normal output is high, which is why the condition is inverted. The terminal recorded trigger messages. We did not measure detection range, false alarms, or whether it can tell a flame from other light sources.
The MQ module's switching output has a different physical basis. Winsen describes the MQ-2 as a semiconductor gas sensor, and our notes had wrongly called it electrochemical. The manufacturer's standard test conditions include at least 48 hours of preheating. A brief warm-up before a bench test is not a substitute for those conditions or for calibration.
Our records for the MQ test were also inconsistent: the block program used GPIO19 and a one-second delay, while the saved project and terminal run used GPIO9 and 200 ms. Adjusting the module's threshold potentiometer moves the switching point; it does not turn a digital trigger into a concentration measurement. Reconcile the module, supply and program before treating any of this as a reproducible experiment.
The combined assembly reveals the interaction rule
The assembled alert combined both inputs, a buzzer and a button. The program tested active-low inputs on GPIO27 or GPIO8. Either one enabled 1 kHz PWM on GPIO9 with a duty value of 800. A separate check on a GPIO5 button set the duty to zero, and the loop paused 200 ms.
That is all the program does. There is no alarm-state variable and no rearm delay, even though our written description of the project had promised a fuller behavior. Because the button check comes after the alert check, a press silences the buzzer during that pass. If the input condition is still present, the next pass turns it back on.
That detail matters if the intended user action is "acknowledge and stay quiet." The current code cannot do it.
Define the states before choosing sensors
An alert interface needs explicit states, and each has to be testable:
- Normal. No input active, no output.
- Alerting. Input became active; output on.
- Acknowledged. User pressed the button; output off, while the input may still be active.
- Rearmed. Input returned to normal, so a new event will alert again.
- Fault. An input is missing or invalid; the user needs to know the device is not monitoring.
You can develop and test all of these with a plain switch standing in for the sensor. There is no need to create smoke or release gas to check that acknowledge and rearm behave correctly. A related Arduino forum discussion about combining environmental sensors with a buzzer is about this same integration problem: readings plus feedback.
Keep the claim bounded
A module that switches an output when its threshold is crossed is a prototype input. Qualifying a sensor for a safety function is separate work: defined detection performance, false-alarm behavior, warm-up and aging, power-loss behavior, and the standards that apply to the product category. None of that evidence comes from a bench demonstration like ours.
So build the interaction prototype with a clear label for what it is. Use it to settle what the device shows, how it sounds, how a person silences it and what happens when an input fails. Those decisions carry forward into a real product. The sensor choice and its qualification come after, with their own test plan.