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:
- The station runs unattended in the field for days or weeks (MEASURE mode)
- The user walks up, flips the switch to SERVER β the LED turns solid ON
- Phone connects to the stationβs Wi-Fi AP; log files are downloaded via a browser
- Switch flipped back to MEASURE β station returns to deep sleep
- Back home on home Wi-Fi, the user opens the server web UI and uploads the CSV file
- 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.