Case Study / Agricultural IoT

Engineering Work

Off-Grid Precision Agriculture — Sensor Hardware & SaaS Platform

Designing solar-powered off-grid sensor nodes for remote agricultural monitoring and the full multi-tenant SaaS platform that aggregated their data — from ultra-low-power embedded firmware to commercial client dashboards in production.

6+ months Autonomous field operation
10+ Commercial client sites served
4 Sensor types per node

Problem

How do you design sensor nodes that measure feed, water, temperature, and CO₂ in remote agricultural locations when there is no grid power, no guaranteed cellular link, and no technician available to reset a failing unit?

This was as much a power-systems problem as an embedded-software problem. Sampling frequency, radio choice, fault recovery, and energy harvesting strategy were all coupled design decisions.

Approach

  • Designed adaptive sleep and wake scheduling based on battery state to extend useful runtime under poor solar conditions.
  • Chose LoRa over GSM as the primary uplink because power draw and range mattered more than familiar tooling.
  • Added local threshold logic so nodes could suppress routine transmissions and spend energy only when events mattered.
  • Integrated maximum power point tracking to recover more solar harvest than a naive charging design.
  • Used watchdog-driven recovery so firmware stalls did not require field intervention.

Outcome

The sensor system demonstrated that unattended, off-grid sensing is reliable when power management, radio topology, and recovery strategy are designed together. Units operated for multiple months without field intervention across Italian vineyard and orchard sites.

Platform

The field sensor network fed into a full multi-tenant SaaS platform built to aggregate, visualise, and alert on the collected data across multiple commercial clients:

  • Chose Kafka over direct MQTT subscription for data ingestion — it decouples ingestion from processing, supports multiple independent consumers per client, and allows historical replay if a processing consumer falls behind.
  • Used MQTT topic namespacing by device identifier and client prefix, so all clients share one broker without ever seeing each other’s data streams.
  • Built a modular Angular dashboard with a drag-and-drop widget system — each client account configures their own layout without code deployment; widget types include time-series charts, threshold gauges, and device status maps.
  • Implemented role-based access control at device level — a user account can be scoped to a specific site or device group, not just a top-level tenant.
  • Used Redis for real-time device last-seen state and session caching; MongoDB as the primary data store for telemetry history and device configurations.

The platform went live serving commercial agricultural clients across Italy and Europe — demonstrating the full vertical from firmware to deployed SaaS in a single engineering effort.

Architecture

System design shown as an operational topology, not a decorative diagram.

The architecture visual is intended to show how edge capture, buffering, transport, event processing, and operator-facing systems fit together under real deployment constraints.

Field Sensor Topology

Off-Grid Precision Agriculture — Sensor Hardware & SaaS Platform

Low-power field capture, gateway relays, and cloud alerts composed for intermittent real-world conditions.

Architecture diagram of an off-grid agriculture monitoring system showing solar-powered STM32 and ESP32 nodes, local threshold logic, LoRa uplinks, gateway aggregation, and cloud dashboards for remote monitoring.
Off-Grid Precision Agriculture — Sensor Hardware & SaaS Platform

What to look for

  • Offline resilience and deterministic recovery are treated as first-class design concerns.
  • Operational visibility is separated from ingestion reliability so reporting never destabilizes capture.
  • Protocol choices reflect topology and failure modes, not just team familiarity.
6+ months Autonomous field operation
10+ Commercial client sites served
4 Sensor types per node

What I Would Do Differently

Implement over-the-air firmware update from day one. Retrieving physical units for bug fixes in month three made clear that remote patchability should have been treated as a core system requirement.

Stack

The implementation choices below reflect the boundary between field reliability, event architecture, and operator-facing systems.

STM32 ESP32 LoRa C++ Power electronics MQTT NestJS Angular Kafka MongoDB Redis Docker