ESP32 + AWS IoT Monitoring
An ESP32 reads temperature and humidity from a DHT22 and publishes JSON over MQTT to AWS IoT Core, authenticated with an X.509 device certificate over TLS. Node-RED subscribes to the topic, applies the data logic, and renders gauges, a 24-hour trend, and threshold alerts on a dashboard that is reachable from anywhere.
- Role
- IoT developer in a project team. Sensor wiring, ESP32 firmware, AWS IoT Core thing, certificate and policy setup, Node-RED flow and dashboard. The presentation is credited to "Tim Proyek IoT".
- Context
- Team project presented to teachers and documented in a 13-slide deck. The firmware and cloud configuration were implemented but never published.
- Period
- 2026-05 → 2026-06 (Related repositories were created in May and June 2026; the presentation is undated.)
- Evidence
- ArchitectureDocumentationTechnical breakdown
01
The Case
Computer labs and server rooms overheat quietly. The project set out to read temperature and humidity continuously, push the readings to the cloud so they can be seen from anywhere, and show them on a dashboard that makes a problem visible at a glance. The deck lists four reasons: energy efficiency (cooling decisions based on real data), device safety (no overheating), cloud accessibility (no geographic limit), and real-time analysis (fast response to sudden changes).
02
Evidence
Project presentation: Sistem IoT Cerdas (13 slides, Indonesian)
document
The dashboard image in the deck is the Node-RED reference dashboard, not a screenshot of this system
note
03
Architecture
Text version of the diagram
Device
AWS
-
AWS IoT Core
AWS IoT Core
Managed MQTT broker; device authenticated with an X.509 certificate.
-
AWS IoT policy
AWS IAM
Restricts the device to connect, publish, and subscribe on specific topics.
Processing and UI
-
Node-RED
Node-RED
Subscribes to the topic, applies data logic, drives the dashboard.
-
Node-RED Dashboard
Node-RED Dashboard
Gauges, 24-hour trend chart, colour alerts above the threshold.
Planned extensions
- Telegram bot alerts Telegram Bot APIplanned
- InfluxDB history InfluxDBplanned
- Relay for AC control Relay moduleplanned
Connections
- DHT22 sensor → ESP32 · digital read
- ESP32 → AWS IoT Core · MQTT publish (MQTT over TLS, X.509)
- AWS IoT policy — AWS IoT Core · authorises
- AWS IoT Core → Node-RED · MQTT subscribe (MQTT)
- Node-RED → Node-RED Dashboard · gauges, charts, alerts
- Node-RED → Telegram bot alerts · planned
- Node-RED → InfluxDB history · planned
- Node-RED → Relay for AC control · planned
04
Technical Breakdown
infrastructure
Hardware: an ESP32 development board (dual-core 240 MHz, Wi-Fi and Bluetooth, low power, TLS capable) and a DHT22 digital sensor (temperature -40 to 80 °C with ±0.5 °C accuracy, humidity 0 to 100% RH with ±2% RH accuracy) on a breadboard with jumper wires. Cloud: an AWS IoT Core thing with a certificate and policy. Processing: a Node-RED instance with the dashboard nodes.
application
Firmware written in the Arduino IDE reads the sensor on a fixed interval and publishes a JSON object with the temperature and humidity to an MQTT topic on the IoT Core endpoint. Node-RED subscribes to that topic, parses the payload, and feeds gauge widgets, a 24-hour line chart, and alert logic that changes colour when the temperature exceeds a threshold such as 30 °C.
security
Device authentication uses an X.509 certificate and TLS end-to-end between the ESP32 and AWS. An AWS IoT policy restricts the device's rights to specific topics. No shared password travels over the network.
05
Key Findings
Engineering decisions
- Data flow sensor, ESP32, Wi-Fi, AWS IoT Core, Node-RED, dashboard, with JSON payloads over MQTT.
- Device authentication with an X.509 certificate and TLS between the ESP32 and AWS IoT Core; an AWS IoT policy restricts the device to its own topics; MQTT QoS covers delivery reliability.
- Dashboard with gauges for instant readings, a 24-hour trend chart, and colour alerts when the temperature passes a threshold such as 30 °C.
- Motivation from the deck: energy efficiency through automatic cooling decisions, protecting computer labs and servers from overheating, cloud access without geographic limits, and real-time analysis.
- Use the managed broker. AWS IoT Core replaces a self-run MQTT server and brings device identity with it: each ESP32 carries its own X.509 certificate and private key, connects over TLS, and is limited by an IoT policy to the topics it needs.
- Keep the device simple. The ESP32 does three things: read the DHT22, connect to Wi-Fi, and publish a small JSON payload. Everything else, from logic to visualisation, lives in Node-RED where it can be changed without reflashing.
- Reliability is a protocol setting. MQTT quality-of-service levels cover delivery guarantees; the deck names QoS as the mechanism that makes messages arrive reliably.
06
Challenges and Solutions
Challenges
- A microcontroller on a school network has to authenticate to a cloud broker without shipping shared passwords.
- Readings must reach a browser dashboard in real time from anywhere, not only on the local network.
Solutions
- Per-device X.509 certificate and private key on the ESP32, TLS to the IoT Core endpoint, and a scoped IoT policy.
- Node-RED subscribed to the IoT Core topic feeds gauges, charts, and alert nodes on the dashboard.
07
Result
The deck reports stable monitoring with a transmission delay under one second on AWS. That figure comes from the presentation; no measurement log was kept, and the dashboard image in the deck is the Node-RED reference dashboard rather than a screenshot of this system. The firmware, cloud configuration, and flow were implemented but not documented beyond the presentation.
Planned extensions, none of them built: Telegram bot notifications, InfluxDB storage for yearly audits, and automatic air-conditioning control through a relay.
Outcomes on record
- The presentation reports stable monitoring with a transmission delay under one second on AWS infrastructure.
- Firmware, the IoT Core thing, certificate, and policy, and the Node-RED flow were implemented but not documented beyond the deck. Implemented in project environment
Planned, not built
- Telegram bot notifications to phones. Planned
- Historical storage in InfluxDB for yearly audits. Planned
- Automatic air-conditioning control through a relay. Planned
08
Stack
Languages
AWS services
Data and analytics
Messaging and streaming
Security
Frontend
IoT hardware and protocols