An ESP32 can read a sensor and send a message in a few lines of code. That is enough for a bench demo, but it is not enough for a reliable alerting system.
The difference appears when the project runs unattended. Sensors bounce, readings hover around thresholds, Wi-Fi drops, and a fault can generate hundreds of repeated events. If every raw event becomes a notification, the engineer quickly learns to ignore the channel.
A better design treats messaging as the last stage of an event pipeline: detect the condition, decide whether it matters, then notify a person.
Detection answers a machine question: did something change?
Notification answers a human question: does someone need to know about it now?
Those questions should not be handled by the same line of code. A useful pipeline is:
Sensor → ESP32 → Event Filter → State Machine → Backend or API → Messaging Bot → Engineer
This separation gives each layer one job. The sensor provides measurements, the ESP32 creates events, filtering removes noise, and the state machine tracks operating state. A backend can store telemetry, enforce rate limits, and retry failed requests. The messaging service only handles the final human alert.
Figure 1. ESP32 notification pipeline separating sensing, filtering, state management, backend reliability, and human-facing alerts.
Consider a temperature sensor that reports once per second:
27.1°C, 27.3°C, 27.5°C, 27.4°C.
Those readings are useful telemetry, but they are poor notifications. Continuous measurements belong in a database, IoT platform, or dashboard. Human alerts should represent state changes or exceptions.
For example, instead of sending every reading, define a condition such as:
Now the notification channel reports a change in operating condition rather than a stream of numbers.
Real sensors rarely change state cleanly. Mechanical switches bounce. Motion sensors can pulse more than once. Analog values can move back and forth around a threshold.
A simple condition such as temperature > 40 may therefore trigger repeated alerts near 40°C.
Two techniques help.
Debouncing requires a condition to remain valid for a minimum time before accepting it as an event.
Hysteresis uses different thresholds for entering and leaving a state. The system might enter WARNING above 40°C but not return to NORMAL until the reading drops below 35°C.
That five-degree gap prevents a value such as 39.9, 40.1, 39.8, and 40.2°C from creating an alert storm.
A state machine makes the alert logic easier to reason about. For a basic temperature monitor, four states may be enough:
The important rule is that messages follow transitions, not loop iterations.
If the system enters WARNING at 14:02, send one warning. If it remains in WARNING for ten minutes, do not send the same warning every second. If it later enters CRITICAL, send a new alert because the state changed. When it returns to a safe range, send a recovery message.
For teams that already use Telegram-style group messaging, Traditional Chinese-speaking users may also see the platform described as 紙飛機聊天軟體. In an engineering design, however, the messaging client should remain the human-facing endpoint; sensor filtering and control logic belong in the device or backend.
Figure 2. Example temperature-alert state machine using separate thresholds for warning, critical, and recovery transitions.
Telegram bots are software-controlled accounts that communicate through the Telegram Bot API. A bot is normally created through BotFather, which issues an authentication token. That token authorizes API requests, so it must be treated like a credential.
A prototype can send HTTPS requests from the ESP32 directly to the Bot API. A larger deployment often benefits from an intermediate backend:
ESP32 → Backend → Bot API → User or Group
The backend can keep the bot token away from device firmware, write logs, apply rate limits, retry failed deliveries, and route events to several channels. Direct delivery is simpler; a backend gives better central control.
A real bot token should never appear in a public repository, screenshot, forum post, or tutorial sample. Telegram's official bot documentation warns that anyone with the token can control the bot.
Use placeholders in published examples and keep production credentials in an appropriate secrets or configuration mechanism. If a token is exposed, rotate it.
A message such as “Temperature high” forces the receiver to ask several questions. Which device? How high? Where is it? When did it happen?
A better alert carries enough context to support a decision:
| Header 1 | |
|---|---|
| WARNING — Server Room TemperatureDevice: ESP32-04Reading: 43.6°CThreshold: 40°CTime: 14:32 UTC | |
| Header 1 | |
For multi-device projects, add a location or asset identifier. If an alert still requires the engineer to open three other systems just to understand what happened, the message is probably too vague.
A broken sensor can produce more traffic than a healthy sensor. Without rate limiting, a fault may fill the notification channel with hundreds of identical messages and hide a more important event.
A cooldown can limit repeated alerts of the same type. Aggregation can be even better:
Temperature remained above 40°C for 10 minutes. Maximum observed value: 46.8°C.
Do not suppress escalation, though. A move from WARNING to CRITICAL still deserves a new message.
An alert is only half of an incident timeline.
If a system reports that a tank is above its safe level but never reports that the level has returned to normal, an operator may not know whether the problem still exists.
Pair significant alarms with recovery conditions. A useful sequence is:
WARNING → CRITICAL → RECOVERED
This gives the person receiving the notifications a clear start, escalation, and end.
A failed ESP32 cannot always report its own failure. If it loses power, crashes, or drops off the network, it may simply stop sending data.
A heartbeat reverses the logic. The device periodically sends a small “alive” signal to a backend. The backend tracks the last successful heartbeat. If a device that normally reports every five minutes has been silent for fifteen minutes, the backend can issue a DEVICE OFFLINE alert.
This matters because “no alarm” and “no device” are not the same condition.
| Header 1 | ||
|---|---|---|
| Architecture | Strengths | Main limitations |
| ESP32 → Bot API | Fast to prototype, few components, easy to demonstrate | Token may reside on device, limited central logging, tighter platform coupling |
| ESP32 → Backend → Bot API | Centralized secrets, retry logic, event history, rate limiting, easier multi-channel delivery | More infrastructure, another service to maintain |
| Header 1 | ||
For a classroom exercise or home prototype, direct delivery may be enough. For several devices, long-term deployment, or systems that need auditability, a backend usually gives cleaner control.
Wi-Fi and Internet connections fail. A notification system should retry transient failures, but an uncontrolled retry loop can create another problem.
Useful safeguards include:
An event ID is especially useful when a backend receives the same request twice. It can recognize the duplicate instead of sending the alert twice.
Telegram is useful for human notification, but it should not become the monitoring database.
Store continuous measurements in a suitable database, cloud platform, or time-series system. Keep the messaging channel for events, summaries, and operator actions.
The same boundary matters even more in safety-critical environments. A consumer messaging service is not a substitute for a certified alarm system, industrial control platform, SCADA system, emergency shutdown circuit, or other required safety mechanism. Use chat notifications as a supplementary channel unless the project's formal requirements say otherwise.
A useful test plan should include conditions that are easy to miss during a successful bench demonstration.
| Header 1 | |
|---|---|
| Test | Expected behavior |
| Sensor briefly crosses threshold | No alert if debounce requirement is not met |
| Threshold remains exceeded | One warning alert |
| Value reaches critical threshold | One critical alert |
| Fault remains active | No repeated message flood |
| Value returns to safe range | Recovery alert |
| Wi-Fi disconnects | Retry or buffer according to design |
| Device stops sending heartbeats | Backend generates offline alert |
| Bot token is invalid | Error is logged without blocking core monitoring logic |
| Header 1 | |
Run these tests before deployment. A notification pipeline should fail predictably, not just work under ideal conditions.
Before deploying an ESP32 alerting project, check five points:
The goal is not to send the fastest possible message. The goal is to turn noisy machine behavior into a small number of alerts that help a person make the right decision.
JLCPCB – Prototype 10 PCBs for $2 (For Any Color)
China’s Largest PCB Prototype Enterprise, 600,000+ Customers & 10,000+ Online Orders Daily
How to Get PCB Cash Coupon from JLCPCB: https://bit.ly/2GMCH9w