TerraGuard: Teaching a Local Gemma 4 to Read a Hillside

Description and use

TerraGuard prototype integrates ESP32 sensors, FastAPI, local Gemma 4 12B, and React to provide autonomous hillside monitoring, risk assessment, and alerts without external LLM APIs.

Problem

Integrating multimodal sensor data with a local LLM to provide structured risk assessments and alerts for hillside monitoring without relying on external APIs.

Outcome

A working prototype demonstrates end‑to‑end hillside monitoring, local LLM assessment, alerting, investigation, and daily reporting, all without external LLM APIs.

Workflow

• 1. Observe: ESP32 reads sensors and records data quality flags.
• 2. Interpret: FastAPI builds an evidence packet with current readings, history, deltas, and flags, then calls local Gemma 4 12B via Ollama.
• 3. Validate: Backend checks JSON schema, risk labels, and applies fallback rules.
• 4. Alert: Severity states (SAFE→WATCH→WARNING→CRITICAL) trigger overlays and sirens.
• 5. Investigate: Operators query past events; answers are grounded in stored records.
• 6. Report: Daily evidence‑based report with timeline, stats, narrative, and PDF is generated.

Evidence

A physical ESP32 sensor node feeds a FastAPI backend, and the backend hands an evidence packet to Gemma 4 12B running locally through Ollama.

Source

Gemma 4 12B is central, not decorative. We run gemma4:12b, the 12B Unified model. Per Google's official model card, it is an open‑weight model under Apache 2.0 that accepts text, image and audio input and documents a context window of up to 256K tokens.

Source

The backend controls which evidence the model sees. Gemma has no access to the sensors, the database or the browser.

Source

We report a working physical prototype where the monitoring, Gemma assessment, alert, report and preparedness workflows run in the current project configuration.

Source