Climate History: A Small Service for Long-Term Room Data

Why this exists

Short dashboard history is fine for live control, but it does not always explain room trends, sensor behaviour or seasonal change. Climate History is a separate, lightweight collector and dashboard for that job.

The unglamorous hardware bit

Room measurements do not need designer hardware. The retained purchase records show three TH03 Zigbee temperature-and-humidity sensors at £4.20 each (£12.60 for the three), and a SONOFF SNZB-02P sensor bought for £9.70. These are deployed project sensors. The public record deliberately does not tie a receipt to a particular room entity, because that level of mapping is not useful to publish.

What I built

The service separates a resilient periodic collector from a small web interface and stores its data in SQLite. Collection runs on a five-minute cadence, timestamps are stored in UTC and the UI converts time for presentation. Keeping collection, storage and presentation distinct makes restarts and backfills easier to reason about.

The SQLite lesson

The backup design uses a database-aware snapshot rather than assuming that copying an active SQLite file is sufficient. This matters because write-ahead logging can leave recent data outside the main database file until checkpointed.

The documented restore procedure includes the application, service definitions, web configuration and database as one unit. That is a useful reminder that restoring a database alone does not recreate a service.

What has not been tested

The recorded backup inspection found a usable snapshot structure, but it was not a live restore-and-service test. This article therefore describes the architecture and recovery intent, not a proven disaster-recovery outcome.

Why it stays small

For a focused historical service, simplicity is an advantage: one collector, one local database, one small UI and a recovery plan that restores the whole service boundary.