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

npm install

cp .env.example .env

ashaBackend - this is where the the mcp tools live and how the devices are stored and fetched to the LLM

pip install uv

uv sync

cp .env.example .env

uv run main.py

ashaBridge - the ashabridge is the link between a microcontroller and the AI.

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.