Engineering problem
Unify heterogeneous hardware and live telemetry in one reliable product while operating with intermittent connectivity and imperfect device links.
RV Monitor
- Focus
- Full-stack / IoT
- Year
- 2023-2026
- Stack
- Next.js · TypeScript · PostgreSQL · Raspberry Pi · BLE · Docker
My role
Full-stack / Product Engineer. I built the frontend, backend integration, data model, hardware-facing flows and deployment around the vehicle's real systems.
System
BLE and serial devices · Raspberry Pi · local services · PostgreSQL · API layer · Next.js frontend · local-to-cloud synchronisation
Outcome
A working onboard and remote monitoring environment used with live vehicle data rather than idealised mock telemetry.
RV Monitor is a real system I built for an expedition campervan, not a dashboard prototype. It connects onboard power, solar, water, environmental sensors, modem diagnostics, GPS, cameras and controllable devices through a Raspberry Pi-based software stack. The engineering constraint is that the vehicle must remain observable and usable when devices disconnect, telemetry becomes stale or mobile internet disappears.
From hardware to usable telemetry
The data originates in very different devices: battery and solar controllers, water and environmental sensors, ESP32 nodes, BLE devices, a serial GPS receiver, modem diagnostics and camera streams. The edge layer has to collect these sources and turn them into a consistent model the rest of the product can consume.
Raspberry Pi acts as the always-on computer inside the vehicle. Hardware-specific details are kept behind service boundaries so the web application can work with stable states and measurements instead of knowing how each individual device communicates.
Local-first architecture and failure states
The system is designed around local operation first. Data is persisted and served inside the vehicle, while remote access and cloud synchronisation are an additional path rather than a requirement for the dashboard to function.
That changes the software model: a value is not simply present or absent. Components need to distinguish fresh, stale, disconnected, unavailable and recovering states. Device reconnects and missing internet are normal operating conditions, not exceptional edge cases.
Remote access without assuming a stable network
The mobile view prioritises the information that matters away from the vehicle: current power and environmental state, alerts, location and device availability.
The interface treats stale and disconnected data explicitly, so remote monitoring does not present an old reading as if it were current when the vehicle temporarily loses connectivity.
Frontend over live vehicle data
The Next.js/React interface combines live status, historical charts, GPS and route data, modem diagnostics, cameras and direct controls. Reusable cards and data-visualisation patterns share state semantics, so a disconnected battery controller and an unavailable sensor are represented consistently even though their underlying integrations are different.
Deployment in a moving vehicle
The application stack is deployed around the Raspberry Pi environment with Docker and Nginx, and supports both local access in the campervan and remote views when connectivity is available. Building against the installed hardware exposed timing, reconnect and stale-data behaviour that would not appear in a conventional mock-data dashboard.
The result is a software layer for the vehicle itself: one interface for understanding what the campervan is doing now, inspecting history, controlling supported devices and checking the system remotely when away from it.