Motivation & Goals

Status: 🟒 Stable


What this project is really about

This is a personal learning project with a clear, hands-on goal: understand how a weather station works end-to-end, from raw sensor reading to a usable dashboard and simple predictive models.

The motivating use case is intentionally concrete and humble:

Knowing when it actually makes sense to water outdoor plants, based on observed local conditions β€” not guesswork.

The project is not intended to compete with commercial stations, replace a professional meteorological network, or solve large-scale climate problems. It is intended to be educational, achievable, and progressively useful.


Goals

The project has three layers of goals, ordered by priority:

Layer 1 β€” Hardware & firmware (core)

  • Build a reliable, low-power data logger from scratch
  • Understand sensor acquisition, embedded timekeeping, and deep-sleep power management
  • Produce consistent, timestamped, locally-stored data

Layer 2 β€” Data pipeline

  • Understand how to move data from a field device with no permanent internet connection to a server
  • Build a simple backend with data ingestion, storage, and a visual dashboard

Layer 3 β€” Local intelligence

  • Use collected data for practical decisions (plant watering)
  • Explore short-term weather forecasting using machine learning on local sensor data
  • Use data from nearby public weather stations to bootstrap models before enough local data is available

Scope and constraints

The project explicitly accepts the following constraints from day one:

Constraint Rationale
Single station Manageable scope for a personal project
Single user No multi-user, permissions, or security requirements
No permanent internet connection at the station Enables solar/battery operation; forces clean data pipeline design
Learning value over absolute precision Cheap, accessible sensors are acceptable
Incremental approach Each phase must be independently useful

Day-to-day operation

The station has two modes, selected by a physical toggle switch on the board:

Mode What happens
MEASURE Normal operation β€” ESP32 wakes on RTC alarm, reads sensors, appends a CSV row, goes back to deep sleep. No Wi-Fi, no user interaction needed.
SERVER Data retrieval β€” ESP32 starts a Wi-Fi access point. The user connects their phone and downloads log files via a browser, then flips the switch back to MEASURE.

A typical data collection cycle looks like this:

  1. The station runs unattended in the field for days or weeks (MEASURE mode)
  2. The user walks up, flips the switch to SERVER β€” the LED turns solid ON
  3. Phone connects to the station’s Wi-Fi AP; log files are downloaded via a browser
  4. Switch flipped back to MEASURE β€” station returns to deep sleep
  5. Back home on home Wi-Fi, the user opens the server web UI and uploads the CSV file
  6. The backend ingests and stores the data; the dashboard updates

No script, no app, no permanent internet connection at the station β€” only a browser and a physical switch.


What this project is NOT

  • A commercial product
  • A real-time alerting system
  • A replacement for a professional weather API
  • A multi-node sensor network

These are all compatible with the architecture but are explicitly out of scope.