Context
HidroPond is a prototype for aquaponics monitoring and limited remote actuator control. The system separates the edge layer into two ESP32 roles:
- A sensor device sends telemetry, online events, and heartbeats.
- An actuator device polls for queued commands and reports execution results.
The active architecture uses HTTPS requests to a FastAPI backend. The backend stores operational records, exposes data to a Next.js dashboard, and maintains a command queue for the actuator device.
Hypothesis
Separate sensor and actuator devices, identified by distinct device IDs, can keep telemetry and actuator operations traceable through an HTTPS-based API without using MQTT as the primary transport.
The hypothesis would fail if the backend could not reliably associate telemetry, presence events, commands, and command results with the intended device and pond.
Method
The prototype defines separate HTTP flows for each device role.
The sensor device sends telemetry containing pH, TDS, water temperature, air temperature, humidity, and surface distance. The backend derives water-level values from surface-distance input and records device presence from telemetry and heartbeat events.
The actuator device polls the backend for pending commands. Commands are created through the backend, stored with status information, and updated when the actuator submits an execution result.
The backend can use Supabase REST or direct PostgreSQL, depending on configuration. The Next.js dashboard reads backend endpoints for current telemetry, history, device status, settings, command history, and insight responses.
Result
The prototype establishes a clear operational path:
Sensor ESP32 → HTTPS telemetry → FastAPI → operational store → dashboard
Dashboard → FastAPI command queue → actuator polling → command resultThe implementation includes backend routes for device presence, telemetry, heartbeats, pending commands, command results, telemetry history, pond settings, and insights.
MQTT is not used in the active device path. This reduces the initial transport scope, but makes actuator responsiveness dependent on the polling interval.
Limitations
The prototype does not establish long-term reliability for sensor hardware, network connectivity, command delivery, or actuator execution.
The polling model does not provide immediate command delivery. A command is retrieved only when the actuator device requests pending work.
The dashboard retains a preview fallback when backend telemetry is unavailable. The data source must remain visible so preview data is not interpreted as live operational telemetry.
The insight feature can use local rules and optional language-model summarisation, but its accuracy and operational value have not been validated against real aquaponics outcomes.
What we learned
Separating sensing from actuation makes the device contract easier to reason about. Sensor telemetry and actuator commands have different timing, payload, and failure characteristics.
HTTPS is sufficient for the current prototype’s periodic telemetry, durable presence tracking, and queued-command flow. The trade-off is explicit: lower integration complexity in exchange for polling-based command latency.
Operational insight should remain a supporting interpretation of validated telemetry and rule checks. The prototype does not support using it as an autonomous control mechanism.
External sources
- Siswanto, B. et al. (2023). A simple dataset of water quality on aquaponic fish ponds based on an internet of things measurement device. Data in Brief
- Udanor, C. N. et al. (2022). An internet of things labelled dataset for aquaponics fish pond water quality monitoring system. Data in Brief
- Espressif. ESP HTTP Client documentation
- FastAPI. Request validation and automatic API documentation
Found this research note useful?