This is a submission for the Gemma 4 Challenge: Build with Gemma 4
What I Built
Most IoT systems are rigid. You configure them once, they do one thing for the rest of their lives, and changing anything requires rewriting code or a touching dashboard. Adding AI usually means expensive cloud inference with unpredictable latency and cost(or you have to fight between engineering cost vs api cost).
ASHA is a project I have been building that tries to fix this. An ecosystem that gives AI models a natural language interface to the physical world. For this hackathon, I wanted to answer one question: can Gemma 4(a small open weight model) actually run an IoT system?
The subject: Cinderella. My house plant.
The hardware setup was deliberately cheap. An ESP32 WROOM (520KB RAM, 4MB flash), a water level sensor, a PWM light strip, and a buzzer. Total cost: under $25. The ASHA library registers all of this with the agent in about 15 lines of code:
#include <ASHA.h>
ASHA asha;
void setup() {
asha.asha_wifi.begin("mywifi", "mypassword");
asha.asha_devices.addDevice(
asha.genericDev(DeviceCategory::Sensor, "Cinderella's water sensor", BusType::Analog), 34);
asha.asha_devices.addDevice(
asha.genericDev(DeviceCategory::Actuator, "Cinderella's Light", BusType::PWM), 18);
asha.asha_devices.addDevice(
asha.genericDev(DeviceCategory::Actuator, "Cinderella's buzzer", BusType::PWM), 23);
asha.init("myashaID");
}
void loop() {
asha.run();
}
From there, Gemma 4 should know what hardware exists and can call it as tools. ASHA handles the translation layer. More details in the repo below.
The interface: WhatsApp. No app, no dashboard, no configuration file. Just a conversation.
I can tell Cinderella's agent to turn on her light, check her water level, play a song on her buzzer, or set up a full autonomous care schedule, all from a single message. When I am away, the agent holds the fort and can even create realtimed embedded task.
The most surprising moment came when I deliberately shut down the microcontroller and asked for a sensor reading. The model did not hallucinate a result. It correctly interpreted the tool timeout as an error and reported it honestly. For a small parameter model handling real hardware, that matters a lot.
The experience was something else. Watching a free open model understand "Cinderella is sensitive, dim her light to 30% at noon to save electricity" and then actually do it felt like something you'd see in sci-fi.
Demo
Code
Stass client- this allows you to connect Gemma4 to an mcp server and communicate over whatsapp
stass_client 2.0
An unofficial WhatsApp client that lets you connect MCP (Model Context Protocol) tools to an LLM and interact with it over WhatsApp.
The difference between 1.0 and 2.0 is that 2.0 has explicit support for MCP clients, while 1.0 relied on the LLM provider's built-in MCP server support. This version also handles MCP OAuth authentication.
Getting Started
1. Install dependencies
npm install
2. Set up environment variables
Copy .env.example to .env and fill in your keys:
cp .env.example .env
3. Configure your allowed WhatsApp number
In main.ts, replace "exampleID@lid" with your own WhatsApp ID. Every incoming message prints its ID to the console, so you can just copy it from there. You can also remove the if check entirely to allow anyone to use the bot — just be careful about costs if you're on a paid model.
4. Set your MCP server URL
Set MCP_URL in…
ashaBackend - this is where the the mcp tools live and how the devices are stored and fetched to the LLM
this project is in the development phase and not ready for production yet
Asha Backend
The backend for Asha — a framework that lets your hardware talk to AI.
Asha connects IoT devices and LLM via MQTT, exposing an MCP (Model Context Protocol) server so an AI agent can directly control and monitor your hardware through natural conversation.
Prerequisites
Make sure you have uv installed:
pip install uv
Setup
- Clone the repo and install dependencies:
uv sync
- Copy
.env.exampleto.envand fill in your values:
cp .env.example .env
Required environment variables:
| Variable | Description |
|---|---|
MONGO_URL |
MongoDB connection string |
JWT_SECRET_KEY |
Secret for signing JWT tokens |
JWT_ALGORITHM |
JWT algorithm (e.g. HS256) |
ACCESS_TOKEN_EXPIRE_MINUTES |
Token expiry duration |
FRONTEND_URL |
CORS origin (default: http://localhost:3000) |
ENV |
Set to development to enable Swagger docs |
Running
Full server (REST API + MCP agent)
uv run main.py
Starts the FastAPI backend and MCP server together on port 8080…
ashaBridge - the ashabridge is the link between a microcontroller and the AI.
ASHABridge
ASHABridge is a microcontroller firmware library that connects IoT hardware to an AI agent via MQTT. The agent can control pins, run batch sequences, and execute real-time Lua scripts on the device — all without reflashing.
Development Phase Notice
This project is actively under development. It works for most common use cases (digital control, PWM, analog sensing, I2C, SPI, UART, Lua scripting), but some features are still in progress. You are welcome to test it, open issues, and contribute. See the To-Do section for what is planned next.
Platform Support
| Platform | Status |
|---|---|
| ESP32 | Supported |
| Raspberry Pi | In progress |
| Arduino | In progress |
Quick Start
1. Install dependencies
This project uses PlatformIO. Dependencies are declared in platformio.ini and installed automatically on first build.
2. Configure credentials
Before building, open the following files and replace the placeholder values:
src/main.cpp — your WiFi credentials and ASHA device ID:
const char* ssid…How I Used Gemma 4
The reason Gemma 4 matters for IoT is simple. It is an open weight model that can handle agentic tasks . For embedded systems running 24/7, API costs are not just inconvenient, they are a dealbreaker. Gemma 4 can remove this entirely.
I started with Gemma 4 E2B running locally on my laptop. 16GB RAM, 1.6GHz CPU, no GPU. The model ran. A command like "turn on Cinderella's light" took almost 2 minutes to execute. Slow, but not useless. If you tell an agent to turn on a light at 6am and it turns on at 6:02am, nobody is upset. For scheduled and automated tasks, local inference on commodity hardware is already viable. This completely eliminates API costs and with appropriate hardware, the latency shrinks to near zero.
I then switched to Gemma 4 26B and 31B via OpenRouter's free tier. Both performed well. They followed the system prompt, called the right tools in the right order, held context across long conversations, and adapted their conversation style to match how the user was speaking. That last one was interesting. Nobody programmed that behavior. The models just picked it up naturally.
How ASHA connects to Gemma 4 technically
ASHA exposes hardware ports as MCP tools. Each device registers its GPIO pin, bus type (Analog, PWM, I2C, UART) and a natural language description(check code example above). Gemma 4 reads the tool descriptions and decides which one to call and when.
For example, given the command "read her water level", Gemma executes the publish tool on the ASHA server with the correct parameters. Under the hood ASHA uses MQTT to execute the command on the ESP32 and sends the response back to Gemma. Gemma 4 26B and 31B consistently confirmed the bus type before calling a tool, every single time.
I also never taught Gemma how to interpret sensor results. It figured that out by itself, correctly mapping raw analog readings to real world plant states. That tells you something about how well these models understand physical systems, a near perfect fit for IoT solutions. You probably don't need to finetune.
Proactiveness
Gemma 4 31B stood out here. When I told it I was leaving and asked for its plan, it did not wait for instructions. It proposed a full care schedule, identified that it had no way to water Cinderella directly, and suggested using the buzzer to alert someone nearby as a workaround. The model found a solution within its hardware constraints without being asked. For IoT that is huge. When a device is out of reach or a component is faulty, you want an agent that adapts, not one that fails silently.
Scheduled workflows and real time conditions
When given time based instructions, Gemma 4 always got the timing right. It understood real time constraints, calculated durations correctly ("it is currently 5:43pm, so the light turns on in 2 minutes"), and executed tasks the way an engineer would think about them. Not just executing commands but reasoning about when and why.
What this unlocks
This combination of Gemma 4 and ASHA proves something important. You can isolate an IoT device, give it a Gemma 4 brain, and ask it to run forever. It will manage itself, notify you only when something is beyond its capabilities, and handle everything else autonomously. No rigid rule sets. No hardcoded edge cases. Just a model that understands the physical world and acts on it.
The applications are not small. Farm monitoring, hospital equipment, power plants, smart homes, industrial systems, drones. Anywhere an embedded IoT solution is needed, this stack can go. And it is already here.
Top comments (0)