Smart Farm IoT – LoRa Sensor Network & Secure Gateway (Proof of Concept)

The goal for this first version was simple: get a basic smart-farm path working from sensor to backend. LoRa sensor nodes sit on one side, an ESP32 gateway bridges them to Wi-Fi, and a Java/Kafka backend receives and stores the data so it can be processed or visualised later. The system is split into three layers: field nodes that measure soil and climate conditions, a gateway that forwards readings over a TLS-encrypted link, and a backend that checks the messages and streams them into Kafka. DuckDNS and router port forwarding are used so the gateway can reach the server even when it’s not on the same local network.

The hardware is intentionally modest: standard development boards and off-the-shelf sensors wired into a simple but reproducible topology. The emphasis is on a clean split between low-power field nodes and a slightly more capable gateway device.

The software stack spans microcontroller firmware, gateway logic, and a Java server. The goal is to keep each layer simple enough to reason about, while still enforcing basic security on the path from sensor to backend.

The backend is a small, containerised distributed stack used to ingest, process, and visualise sensor data. It runs in Docker on a single development machine and is built around Apache Kafka for event streaming, Apache Spark for batch and stream processing, and Elasticsearch for indexing and search. The architecture was first put together as a separate university project and then adapted to accept the smart-farm data, so this IoT setup is one concrete example of how the stack can be used rather than a full production deployment.

A static web dashboard was built to visualise what the final monitoring interface would look like. The demo includes four pages: a main dashboard with live sensor status, node locations on a map, and quick actions; an analytics page with temperature, humidity, and soil moisture charts over time; a weather forecast page pulling data from the Open-Meteo API; and a solar tracking page showing sun position, panel output, and irradiance curves.

The UI is built with Tailwind CSS, Lucide icons, Chart.js for graphs, and Leaflet.js for the interactive map. All data shown is static or mocked, but the layout and components reflect how a real system would present sensor readings, alerts, and controls. The design uses a dark theme with green accents, card-based layouts, and status indicators that match the overall style of the project.

Key features of the demo:

• Dashboard: Real-time sensor cards, field map with node markers, node status list, recent alerts, and quick action buttons.
• Analytics: Temperature trends across all nodes, humidity and soil moisture charts, RSSI signal strength, and battery status bars.
• Weather: 7-day forecast, hourly breakdown, precipitation chart, and farming recommendations (data via Open-Meteo API).
• Solar & Sun: Sun position arc with sunrise/sunset times adjusted for local terrain (mountain blocks sun after 18:00), solar panel output for a 5×35W array, irradiance chart, and panel controls.

The demo files are located in the project's /demo folder and can be opened directly in a browser.

This project reinforced that even small IoT setups are really about the whole stack, not just one board or sensor. On the hardware side, working with LoRa, ESP32, and basic sensors showed how sensitive long-range radio links are to wiring quality, antennas, and power. A single loose jumper or bad solder joint can easily masquerade as a protocol bug until you track it down. Soldering LoRa modules and sensor connections turned out to be more fragile than expected, and getting the ESP32 reliably into programming mode meant spending a bit of time understanding its boot pins and reset sequence.

On the software side, keeping the firmware simple and well-structured paid off when debugging. Having clear responsibilities for each layer—nodes, gateway, server—made it easier to isolate problems. Running TLS on the ESP32 pushed its memory harder than expected, and adding validation on the server side helped filter out noise and bad readings from the LoRa link.

The distributed backend brought its own set of lessons. Getting Kafka, Spark, and Elasticsearch to work together in Docker required careful version matching—mismatched connector versions caused cryptic errors that took time to debug. Spark jobs needed to be compiled with the right Java version (8, not 11) to run in the container. Elasticsearch 8.x dropped support for document types, which broke older examples. And coordinating service startup order in Docker Compose required custom health checks and delays. The Prometheus integration also showed that not all services expose metrics out of the box; some need dedicated exporters.

Overall, the main takeaway so far is that building a useful smart-farm platform is less about one clever algorithm and more about a lot of small decisions: sensible wiring, clear message formats, basic security, and a backend that can grow a little as the project does.

The design draws heavily on vendor documentation and existing building blocks:

Hardware & Firmware:

• LoRa Alliance documentation and module datasheets for radio settings and range assumptions.
• ESP32 official documentation for Wi-Fi, TLS, and GPIO behaviour.
• Arduino Nano and DHT11 datasheets and community examples for basic sensor integration.

Distributed Backend:

• Apache Kafka documentation for event streaming and topic management.
• Apache Spark documentation for stream and batch processing.
• Elasticsearch official documentation for indexing, search, and Kibana dashboards.
• Confluent Kafka Connect documentation for sink connectors.
• Prometheus and Elasticsearch Exporter documentation for metrics collection.
• Docker and Docker Compose documentation for container orchestration.
• Maven documentation for Java build management.

For the server and gateway, Java/Kafka and Arduino/ESP32 examples were adapted to fit the specific message format and security model used here.