Building a smart greenhouse in the woods: the architectural experiment of DevFest Basilicata - DevF{or}est

_By Maurizio Argoneto and Francesco di Donato @francesco_didonato_d1f65 _

How do you organize a tech conference that isn't just the usual sequence of slides in a dark hotel room? GDG Basilicata answered that question by bringing 66 developers to La Majonica, a forest in the municipality of Tito (PZ, Italy), for the third edition of DevFest — rebranded for the day as "DevForest".

But the real innovation wasn't just the location. The event broke the classic format by introducing a single, fascinating constraint: technical interdependence. Instead of isolated workshops, the entire day had one global goal — build a working smart greenhouse, live, piece by piece, across different teams.

Here's how we merged Botany, IoT, 3D Printing, Cloud computing, and Generative AI into a single, functioning pipeline.

🤝 Talks as "integration contracts"

The morning was dedicated to five 30-minute talks. These weren't just theoretical presentations — they were actual technical contracts: each speaker handed over the exact specifications (JSON formats, endpoints, physical tolerances) that their group had to respect during the afternoon Build Sprint, so the whole system could talk to itself.

The 5 pillars of our ecosystem:

1. Botany (Francesco Albanese) — Biology before code. He defined the plant's vital thresholds (soil moisture, air temperature), which became the conditional logic of our software, and made the case for why IoT actually matters for energy and water conservation.

2. Electronics / IoT (Soumaya Erradi) — The "nervous system". Using an ESP32 microcontroller, a DHT11 sensor, and a capacitive soil sensor, the team wrote the C++ firmware to read environmental data and drive a water pump relay.

3. 3D Fabrication (Luigi Tuccillo) — The "armor". Bare hardware doesn't survive in a greenhouse. Using Tinkercad and AI-assisted modeling, the team designed and printed a PETG case (heat- and moisture-resistant) with tolerances tight enough to properly house the ESP32.

4. Cloud & Data (Gregorio Palamà) — The "brain". A serverless Cloud Function on Firebase evaluated incoming data and made irrigation decisions by querying Gemini.

5. App & Generative AI (Mike Trizio) — The "voice". A dashboard built in Angular to show real-time data and let users ask, by voice, "How is the plant doing?" — and get an empathetic answer read back via text-to-speech.

🏗️ The real architecture (spoiler: not everything went 100% smoothly)

For the Dev.to crowd, here's the juicy part. IoT always looks easy in online tutorials — things change when you're in a forest with limited connectivity.

We ruled out a push model from the Cloud to the ESP32: the device wasn't exposed to the internet, and there was no way to configure NAT/firewall rules out in the woods. So the architecture we actually shipped in the afternoon was built around polling.

The final stack:

ESP32 → Spring Boot API Gateway (Cloud Run) → External Firestore → Angular App

The system handled 4 parallel flows:

1. Telemetry — The ESP32 sent POST requests to the Java gateway, which performed an upsert of the telemetry data (humidity, temperature) into Firestore.

2. Manual command — The user clicked a button on the Angular app, sending a command to the Gateway.

3. Chat with Gemini — The Angular app built a dynamic prompt by injecting live sensor data and sent it to Gemini to generate a conversational response about the plant's health.

4. Scheduled automation — A Firebase Node.js (TypeScript) Function ran every hour. It applied a pre-filter (e.g. soil moisture < 40%), passed 48 hours of historical data to Gemini in a batch, and forced the output to match a structured Zod schema (shouldWater, durationSeconds, reason). If the answer was positive, it queued the command on the Gateway.

The polling trick and the in-memory queue

To get the irrigation command to the physical pump, the ESP32 sent a GET /adjustments request to the Spring Boot Gateway at regular intervals. The Gateway kept an in-memory command queue (a ConcurrentHashMap of ConcurrentLinkedQueue). Once read, the command was removed — exactly-once delivery — and executed by the pump.

🔍 Retrospective: what worked and what "exploded"

The best part of building things live is the evening retrospective — held, literally, around a campfire.

The big wins:

• Separation of concerns. Because the JSON contracts were nailed down in the morning, teams could work in parallel. If the Cloud team got stuck, the IoT team just kept testing against mocked data.

• The dual use of Gemini. Using AI for two completely different jobs — a creative, natural-language response on the frontend, and an algorithmic decision constrained by a Zod schema on the backend — turned out to be a winning combination.

Technical debt (don't repeat this in prod):

• The in-memory queue. A RAM HashMap for the command queue is perfect for a hackathon and disastrous for scalability. If the Cloud Run instance restarted (or scaled out), commands were simply lost. For v2, the plan is to move the queue to a Firestore collection (pendingCommands) or to Cloud Tasks / Pub/Sub.

• Polling latency. Being a pull system, there was a noticeable delay between the AI's decision and the actual pump activation, dictated by the ESP32's polling cycle.

• Tricky IAM permissions. Firestore lived in a different Google Cloud project than Cloud Run. Without explicitly granting the roles/datastore.user role to the service account, the system failed silently with PERMISSION_DENIED errors.

📹 Event coverage & video references

The DevForest experiment caught the attention of both local media and the tech community. Worth a look if you want to see the greenhouse — and the woods — in action: Web site

🎯 Conclusion

As Maurizio Argoneto put it:

"The day was focused on nature and technology — we had the opportunity to experience, through talks and labs, what it means not just to design, but to practically build something real. We did this with 3D-printed elements, sensors capable of reading a plant's vital state, all the way to transforming this data in the cloud and designing an app for monitoring and interaction."

The success of DevFest Basilicata didn't hinge on which libraries were used — it hinged on forcing different teams to depend on each other in an environment with real physical and network constraints. It was the physical embodiment of what it actually means to build and maintain distributed software.

If you want to replicate the project, the entire Spring Boot gateway code is open source, and you can test it with the Firebase CLI and a simple ESP32.

See you at the next DevFest! (Hopefully with a persistent message queue 🚀)