Connected product & dashboard
Environmental Monitor
A weather station and the web application behind it: device firmware, ingest API, and the dashboard people actually read, built as one piece rather than three.
- Year
- 2023
- Our role
- Product, firmware, API, dashboard
- Stack
- Next.js, TypeScript, Python, PostgreSQL, Raspberry Pi
The problem
Consumer weather hardware is built on an assumption that does not survive contact with a real site: that the network is always there. Put one somewhere with marginal Wi-Fi and it does not degrade gracefully, it just stops, and the gaps land during exactly the weather you wanted the data for.
The other half of the problem was software. A stream of readings is not a product. Someone has to be able to open a page, see whether anything is wrong, and get told when it is.
How we built it
The device writes every reading to local storage first and treats sending as a separate, retryable step. When the connection comes back it replays the backlog in order, and the ingest endpoint is idempotent, so a device that reconnects twice produces a no-op rather than a duplicated record.
The dashboard is a Next.js application on the shared platform above, which meant accounts, teams, and permissions were already done. The work went into the part that was specific: charting that stays readable across a week or a year, and threshold alerts a non-technical user can set up without calling us.
Where it landed
The record stays continuous across outages instead of having holes in it, which is the difference between data you can trend and data you can only glance at.
The ingest contract was reused unchanged for the water quality product, which is what made that second build fast.
Have something similar in mind? The first call is free.
Start a project