Cinderella is in Good Hands — Building an Agentic IoT System with Gemma 4 and ASHA

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 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(); } Enter fullscreen mode Exit fullscreen mode 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 Enter fullscreen mode Exit fullscreen mode 2. Set up environment variables Copy .env.example to .env and fill in your keys: cp .env.example .env Enter fullscreen mode Exit fullscreen mode 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 Enter fullscreen mode Exit fullscreen mode Setup Clone the repo and install dependencies: uv sync Enter fullscreen mode Exit fullscreen mode Copy .env.example to .env and fill in your values: cp .env.example .env Enter fullscreen mode Exit fullscreen mode 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 Enter fullscreen mode Exit fullscreen mode 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… Enter fullscreen mode Exit fullscreen mode 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.