TempMon: A Local-First IoT Environment Monitor for My Baby

TempMon started with a simple personal goal: keep my baby's room comfortable without constantly checking the temperature and humidity.

What began as a small sensor project grew into a local-first automation system with ESP8266 sensor nodes, a Python backend, live dashboard widgets, notification rules, and IR-based AC control.

The problem

Babies cannot tell you when the room is slightly too warm, too cold, or too dry.

I wanted the room to stay inside a comfortable range with minimal manual effort. The system needed to be:

• reliable
• quiet
• local-first
• easy to inspect
• able to act automatically
• flexible enough for future sensors and rules

This was not a place where I wanted a cloud-only dependency.

The system should keep working even if the internet is unavailable.

The architecture

The architecture is intentionally simple:

ESP8266 sensor nodes
  -> local backend
  -> rules and notification engine
  -> dashboard widgets
  -> IR control / integrations

The main parts are:

• ESP8266 devices with DHT22 sensors
• Wi-Fi setup and device ingestion
• Python backend service
• lightweight local storage
• dashboard for live temperature, humidity, and system state
• plugin-style extensions for notifications, widgets, and integrations

The value is not in one device. The value is in the whole feedback loop.

Automation that actually helps

The system can detect when the room drifts outside the expected range and respond through configured actions.

Examples include:

• notifying me only when action is needed
• changing AC settings through an IR blaster
• showing clear dashboard status
• using light-based alerts where sound would be disruptive
• keeping historical logs for troubleshooting

I tried to avoid noisy automation.

If a system alerts too often, people stop trusting it.

The plugin idea

The plugin model keeps the core small.

A plugin can add:

• a dashboard widget
• a notification channel
• a device integration
• a rule or action
• configuration fields

That means the system can grow without turning the main backend into a pile of special cases.

This is the same architecture habit I use in larger products: keep the core stable, then extend around clear contracts.

The AI layer

The AI part is intentionally practical.

I do not need a large model to control a room. What helps is pattern recognition:

• when the room usually heats up
• how humidity changes by time of day
• when AC changes are most effective
• which alerts are useful versus noise

In this kind of system, lightweight heuristics and small models can be more useful than cloud-heavy AI.

The goal is comfort and reliability, not novelty.

Engineering takeaway

TempMon represents a kind of engineering I enjoy: embedded devices, backend services, frontend dashboards, automation, and real-world constraints in one system.

It also reinforces an important product lesson:

The best automation is quiet. It helps without constantly asking for attention.

Related:

• Full-stack developer and solution architect in India
• School management system case study
• Writing archive