Home
ES · Ver en español

Case study

SmartPot

IoT platform that watches hydroponic crops and lets an assistant act on them

ESP32 sensors publish over MQTT with TLS, a Spring Boot API stores and controls each crop, and a FastAPI service diagnoses and forecasts. In September 2026 I rebuilt the platform after production went down.

SmartPot overview with average crop health, crops online, alerts and the assistant's suggested actions for all crops (open the full-size image)
Detail of a virtual crop with the raft illustration, the weather outside, the state of each actuator and six readings compared with their ideal ranges (open the full-size image)
Alert list where the assistant turns on ventilation when heat or humidity rise and warns when the substrate humidity leaves its ideal range (open the full-size image)

The problem

Hydroponic crops fail fast when temperature, pH or nutrients drift, and nobody can watch them all day. SmartPot started as a university project to monitor crops remotely and act on them.

In September 2026 production was down. The API rejected every request after a change in its route prefix, the database container did not exist, the MQTT broker the API expected had never been deployed, and several internal services were reachable from the internet.

Constraints

  • Devices sit on home networks, so the broker has to be reachable from the internet and still authenticate each device.
  • Five students with different schedules and a single server.
  • The demo has to work without real hardware.

What I built

  • One repository per component, each with a hardened image on GHCR, for the API, the web app, the AI service, the broker, the database, the cache, mail, the firmware and the simulator.
  • A versioned MQTT contract (smartpot/v1/{cropId}/…) on Mosquitto 2.1 with dynamic security, TLS 1.2 or newer on port 8883 with its own certificate authority, and WebSockets behind Nginx for the browser.
  • Spring Boot 4 API on Java 21 with MongoDB, Redis and JWT, checking ownership on every crop and device.
  • A FastAPI assistant that combines an expert system, fuzzy logic and scikit-learn models. It forecasts the hours until a variable leaves its range (Theil-Sen), groups crops with the same problem (K-Means) and suggests one action for all of them.
  • A device simulator over MQTT, with a weather mode fed by Open-Meteo, so the demo and the end-to-end checks run without hardware.
  • Deployment from the organization repository, with Docker Compose in production and Kubernetes manifests.

Architecture

From the sensor to the screen

Data moves both ways between neighboring columns, with readings going right and commands coming back.

  1. Field

    • ESP32 firmware in MicroPython
    • Device simulator with live weather

  2. Messaging

    • Mosquitto 2.1 broker
    • TLS on 8883 and WebSockets behind Nginx
    • Credentials per device

  3. Platform

    • Spring Boot 4 API on Java 21
    • MongoDB and Redis
    • FastAPI assistant with scikit-learn

  4. People

    • React 19 PWA
    • Telegram alerts

Delivery

  • Hardened images on GHCR
  • Central deploy with Docker Compose
  • Kubernetes manifests

Decisions and trade-offs

  1. MQTT with credentials per device

    The devices sit on home networks. They send readings, take commands from the API and each one has to authenticate.

  2. The simulator as a real component

    The demo has to work without real hardware.

  3. Expert rules next to the models

    The models need data before they help, and at first there are no readings.

Results

  • Back in production on September 26, 2026, with seven healthy containers and TLS verified on the broker.
  • 139 tests in the API and 35 end-to-end checks.
  • I wrote 2,273 of the 2,446 non-bot commits across the 11 repositories.

Open items

  • Automated database backups before more growers join.
  • Run the Kubernetes manifests on a real cluster.

Stack

Pick a technology to see the projects that use it.

Related