This is a submission for the Gemma 4 Challenge: Build with Gemma 4
Google's AI story is usually told from the top of the stack.
Bigger models. Better reasoning. More multimodal demos. More cloud endpoints.
That is useful. But there is a different question that kept nagging at me:
What happens when the person who needs the AI is not sitting in a perfect cloud environment? What happens when they are on a farm, the internet is weak, the data is local, and the decision is not abstract at all?
That is why I built SoilSense AI.
What I Built
SoilSense AI is an offline-first farm intelligence app powered by Gemma 4. It runs on a PC, phone, tablet, or Raspberry Pi hub. It connects farm profiles, live soil sensor readings, plant analysis, chat history, and local memory into one app — and it works without a cloud account.
The core problem it solves: most AI agriculture demos skip the boring part. They show a nice chat box, the farmer asks a question, the model gives a confident answer. But real farms are not a single prompt.
A farmer may have one field for vegetables, another for flowers, another for fruit. Each has different crops, soil conditions, irrigation patterns, and disease risks. If those readings get mixed together, the AI advice becomes worse than useless. It becomes confidently wrong.
There is also the connectivity problem. A system that only works when the cloud is reachable is not good enough for many rural environments.
So SoilSense is built on a different assumption: the farm is the source of truth. Gemma 4 is the reasoning layer.
What the app includes:
- Multi-farm profiles — fruit farms, flower farms, vegetable farms, greenhouses, and field zones
- Farm-scoped sensor feeds, so each farm only sees its own pH, moisture, temperature, and NPK readings
- A local bridge that receives sensor packets over HTTP, stores readings locally, and streams live updates over WebSocket
- Gemma 4 analysis that receives the active farm profile, current sensor snapshot, sensor freshness, node identity, prior verdicts, chat memory, and an optional plant image
- Persistent local memory — analyses and chats are stored per farm, not lost after one session
- Three deployment paths: API mode (internet), phone-local Gemma (supported Android devices), or a PC/Pi hub over LAN
- Judge Mode for reproducible demos when physical hardware is not available
The important part is not just that Gemma answers farm questions. It is that Gemma answers with the farm's context already in front of it.
Demo
Demo video: https://youtu.be/EJ6397EinNw?si=a9Ei3Fxmsh_UHHjV
GitHub: https://github.com/ogMaverick12/soilsense-ai/tree/beta
The demo flow:
- First launch and farm profile setup
- Gemma setup — API, phone-local, or PC/Pi hub
- Sensor pairing via QR payload
- Judge Mode replay — 9 sensor packets across 3 farms
- Switching between fruit, flower, and vegetable farms while watching sensor readings change
- Running Gemma 4 analysis using live farm context
- Viewing saved history and local memory
- About, Terms & Conditions, and Gemma 4 Hackathon links in the app footer
One honest note: I do not currently have physical sensor hardware connected for the submission demo. The demo uses Judge Mode — it replays sensor packets through the same local bridge endpoints that real ESP32 and Raspberry Pi nodes use. It proves the ingestion and routing pipeline, but it is replayed data, not live hardware.
Code
Tech stack:
- React + Vite for the UI
- Express local bridge (
bridge/server.mjs) - WebSocket for live sensor streaming
- Farm-scoped HTTP sensor API with
farmIdandsensorNodeIdon every reading - QR pairing payloads for hardware sensor nodes
- Electron for Windows desktop packaging
- Capacitor for Android wrapping
- Ollama/OpenAI-compatible local bridge for Gemma-family models
The project structure keeps concerns clean: src/ has the React app and app logic, bridge/ has the local hub, desktop/ has the Electron shell, android/ has the Capacitor project, and scripts/ has Pi and Windows launchers. Docs cover setup, mobile deployment, Raspberry Pi use, sensor integration, and packaging.
How I Used Gemma 4
SoilSense is intentionally Gemma-only. The UI and local bridge both reject non-Gemma model tags. That matters because I did not want the submission to quietly become a generic model-switcher wrapper. The point is to show Gemma 4 as the reasoning engine for a local-first farm workflow, not as one option among many.
Model strategy is hardware-aware:
-
gemma4:e2b— preferred for Raspberry Pi and weak edge devices -
gemma4:e4b— the balanced local desktop path (detected and tested on my machine through Ollama) -
google/gemma-4-31b-it— the API path for stronger disease reasoning when internet is available - Phone-local Android mode — available on devices that support the Google on-device GenAI runtime; unsupported phones are guided toward PC/Pi hub mode
For analysis, Gemma receives structured context:
- Active farm profile and crop selection
- Current sensor snapshot (pH, moisture, temperature, N/P/K)
- Sensor freshness and latency
- Sensor node identity
- Previous analysis history
- Recent chat memory
- Optional plant image
The output is also structured. SoilSense prompts Gemma for a JSON response covering health status, primary issue, urgency, confidence, disease evidence, soil interpretation, sensor correlation, memory used, spoken alert, and next actions. That lets the UI show a practical verdict instead of dumping raw prose into a chat window.
Gemma also powers a free-form farm chat mode. Even there, the selected farm's local memory is passed as context — so chat answers are grounded in that farm's history, not a blank slate.
Local evidence from my test machine (Windows x64, 8 CPU threads, 15.8 GB RAM, gemma4:e4b via Ollama):
| Capability | Result | Honesty note |
|---|---|---|
| TypeScript check | Passed (npm run typecheck) |
Static check only, not a full end-to-end test |
| Production build | Passed (npm run build) |
dist/ is generated output, not committed |
| Windows installer | Built (SoilSense AI Setup 0.1.0.exe) |
Attached to GitHub Releases, not the repo |
| Android debug APK | Built via Capacitor + Gradle | Debug build unless signed release is created |
| Setup health endpoint | Passed: app, LAN, sensor, node, and model checks | Depends on local machine and network |
| Judge Mode replay | Accepted 9 packets across 3 farms | Replayed packets, not physical hardware |
| Farm-scoped sensor route | Returned orchard readings for judge-fruit-orchard
|
Proves routing by farmId through the bridge |
| Local Gemma detection | Detected gemma4:e4b through Ollama |
Recommendation changes by hardware and installed models |
| Local Gemma smoke test | Returned a response in ~70 seconds | Latency depends heavily on hardware and model warm state |
That last number is not a universal benchmark. Local inference speed depends on hardware, model size, and warm state. But it proves the local path is wired end to end on my machine.
Where I Would Push Back On My Own Project
SoilSense does not prove field-grade sensor calibration. Low-cost pH and NPK sensors can be noisy. A real deployment needs calibration records, placement guidance, and local agronomy validation.
It does not prove every Android phone can run local Gemma. Phone-local support depends on the Android on-device GenAI runtime and device capability — which is exactly why the PC/Pi hub mode exists as the fallback.
It is also not a replacement for local experts, lab tests, pesticide labels, or official agricultural guidance. SoilSense is decision support. It is not a magic agronomist in a box.
I think that honesty makes the project stronger. The architecture is built for the real constraint: use local data, keep the farmer in control, and let Gemma reason over context instead of isolated prompts.
Final Take
The most exciting AI apps are not always the ones with the largest model call.
Sometimes the real product is the boring glue around the model — local data, memory, sensor routing, setup flows, privacy boundaries, and a UI that someone can actually use on a farm with weak internet.
That is what SoilSense AI is trying to be.
Not just "Gemma, answer a farm question."
Gemma 4 with the farm profile, the sensor feed, the history, the crop, and the constraints in front of it.
That is the difference between a chatbot and a tool. And for farmers working with local hardware and unreliable connectivity, that difference matters.
Top comments (0)