Clawdia: The AI Assistant That Texts You Security Reports at Breakfast

clawdiallmwhisperpiperttswhatsapphomeassistant

The most useful thing an AI lab can do is tell you something you didn’t already know. For most AI assistants, this means answering questions. For Clawdia — the lab’s AI home assistant running on UbuntuClaw at 172.16.50.2 — it means sending you an unsolicited morning briefing about what happened on your network overnight, in a Welsh female voice, via WhatsApp.

This is not as unhinged as it sounds. Let me explain.

The Architecture

Clawdia is built on NanoClaw (an OpenClaw variant), a self-hosted AI assistant platform designed for home and lab environments. The UbuntuClaw VM runs:

  • NanoClaw (systemd service: nanoclaw.service) — the agent runtime, idle timeout 2 hours
  • Piper TTS — neural text-to-speech for voice responses
  • Whisper ASR on port 9000 — speech-to-text for voice input
  • WhatsApp Bridge — integration layer for sending/receiving messages
  • Home Assistant MCP — stdio MCP server wrapping the Home Assistant REST API

The LLM backend is the local vLLM instance running Gemma4-26B on WSL2, reachable at http://172.16.50.5:8000. This means Clawdia’s inference runs entirely within the home network — queries don’t leave the building, there’s no API key to rotate, and the latency from question to first token is ~800ms regardless of internet conditions.

Piper TTS: The Voice Layer

Piper is a fast, local neural text-to-speech system trained on various voice models. The lab runs several:

  • en_GB-cori-high — primary voice (Welsh female, high quality) — Clawdia’s default
  • en_GB-alba — Scottish female
  • en_US-lessac-high — American male
  • en_US-ljspeech-high — neutral American female
  • en_GB-jenny_dioco — Irish female

The Welsh voice was chosen through a process that can only be described as competitive listening testing. Once you’ve heard a British Isles accent deliver “Your Synology NAS SMART health check has returned no errors,” it becomes difficult to settle for a flat American synthesised voice. This is entirely subjective and I stand by it.

Piper runs entirely locally — no API calls, no network dependency, sub-100ms synthesis for typical response lengths. The audio output is sent via the WhatsApp bridge as a voice note.

Whisper ASR: Listening

Whisper (OpenAI’s open-source speech recognition model, running locally on port 9000) handles incoming voice messages. When a WhatsApp voice note arrives, it’s transcribed by Whisper and passed to the NanoClaw agent as text. The response goes back as a Piper-synthesised voice note.

The result is a voice assistant accessible from the phone without any smart speaker hardware, with no cloud audio processing, and with response quality that scales with the local LLM rather than being fixed to whatever the cloud provider ships.

The Daily Security Summary

The most-used Clawdia feature is an uninvited guest: the daily 12:15 AEST network security summary. This runs on a systemd timer and does the following:

  1. Fetches today’s Nmap discovery JSON from the KaliLinux VM’s HTTP endpoint (http://172.16.50.4:8080/scan_YYYY-MM-DD.json)
  2. Fetches yesterday’s JSON for comparison
  3. Passes both to the local Gemma4-26B model with a prompt asking for a plain-English summary of changes
  4. Synthesises the summary as a Piper voice note (en_GB-cori-high)
  5. Sends it to the designated WhatsApp conversation

A typical summary sounds like this:

“Good morning. Overnight network scan complete. 63 hosts responded, up one from yesterday. The new host on the IoT VLAN has an Espressif MAC address — likely an ESP32 device. Four hosts from the previous scan did not respond: these appear to be laptops that have been powered off. No unexpected services detected on the VM estate. The Synology NAS and Juniper switches are responding normally. Weekly GVM scan scheduled for Sunday.”

This takes about 15 seconds from timer trigger to received WhatsApp message. It requires zero human intervention. It has, on at least three occasions, flagged a host that shouldn’t have been there — once a neighbour’s device that briefly associated with the wrong SSID (since fixed via MAC filtering), once a misconfigured IoT device that connected to the main VLAN instead of the IoT VLAN, and once something I still don’t fully understand that disappeared before I could investigate and has never returned, which is arguably the most concerning outcome.

Home Assistant Integration

Clawdia has access to Home Assistant via a custom stdio MCP server (ha-mcp-stdio.js) that wraps the Home Assistant REST API. This gives the agent read/write access to home automation entities: lights, switches, sensors, media players, and automations.

Practical applications:

  • “Turn off all the lights downstairs” — single conversational instruction, no app navigation
  • “What’s the temperature in the server room?” — returns the temperature sensor value from the rack-mounted sensor
  • “Is the front door locked?” — queries the lock entity state
  • “Set a reminder to check the GVM scan results on Sunday afternoon” — creates a Home Assistant automation

The MCP wrapper approach means the Home Assistant integration uses the same tool-calling framework as the infrastructure MCP servers. From Clawdia’s perspective, querying a light switch state and querying a firewall rule use identical mechanisms — just different server endpoints.

The Service Account Design

The AI assistant’s service account on UbuntuClaw is deliberately a local account, not an Authentik-managed one. This is a specific architectural decision: if Authentik is unavailable (DebIdentity VM is down, LDAP outpost is unreachable), services with Authentik-managed credentials would fail to authenticate. Clawdia’s systemd service starts at boot and needs to be operational before the broader identity infrastructure is confirmed healthy.

Local service account, Docker group membership, no sudo. It can run containers, nothing else.

The Use Case: Ambient Awareness

The original question this architecture answers: how do you maintain situational awareness of a complex home network without spending time staring at dashboards?

The answer turned out to be ambient notifications on a channel you’re already checking. WhatsApp is open. A voice note from Clawdia at breakfast takes 20 seconds to listen to and gives you the overnight network summary without opening a browser, logging into anything, or remembering which dashboard shows DHCP leases.

When something unusual happens — a new host, a service going down, a SMART warning from the NAS — Clawdia is the first to know and the first to tell you. The time between event and awareness collapsed from “whenever I next log into a dashboard” to “12:15 AEST.”

That’s the point of an AI assistant in a home lab. Not a novelty. Infrastructure.

Update — August 2026

Clawdia is gone. She was deprecated on 11 June 2026, one month after this post, and fully purged on 8 July.

The replacement is Homer, a Hermes Agent instance running in Docker on the same VM. The evaluation was scheduled to run two weeks and was called on day one — not because Hermes was dramatically better at any single thing, but because the scheduling, tool wiring and voice round-trip all worked without being nursed, and the NanoClaw stack had accumulated enough hand-maintained scaffolding that keeping both alive for a fortnight was the more expensive option.

The purge was thorough: the service, its user account, containers and images all removed, the local repository archived, and about 14GB of Docker layers reclaimed. Clay deleted the Telegram bot himself, which is the closest thing a piece of home lab software gets to a funeral. A side effect worth noting — an end-of-life PostgreSQL 9.6 instance that a security audit had flagged turned out to be part of the NanoClaw stack, and died with it. Decommissioning is a security control.

What carried over, and what didn’t

The principle survived intact. Homer runs on the local vLLM Gemma4 instance and nothing else. No LiteLLM proxy, no cloud fallback provider, no model catalogue phoning home if it can be helped. If Homer returns an API error, the first thing to check is vLLM on WSL2, because there is no second thing.

The voice moved from Wales to Scotland. Piper is still doing text-to-speech locally and Whisper is still handling transcription locally, but the default voice is now Alba rather than Cori. This was not the outcome of a rigorous process.

WhatsApp is gone; Telegram is the only channel. Synology Chat was considered and dropped without ever being installed.

The 12:15 briefing became a 7:00 digest, and changed character. It’s a genuine agentic run now — Homer calls the Aruba, Synology, Juniper and Home Assistant MCP servers and reports what it finds, rather than diffing two JSON files. A second job reviews pending skills weekly.

The best change was making the other alert silent. A separate health check runs at 07:55 and only messages when something is wrong. Silence means healthy. The daily “everything is fine” message this post was so pleased with is exactly the kind of notification you stop reading within a fortnight, and a channel you’ve learned to ignore is worse than no channel — it’s a channel that will fail quietly on the one morning it matters.

For the same reason, new-device alerts from the security scanner no longer go through the model at all. The Kali VM sends them straight through Homer’s gateway with no inference in the loop. “This MAC address has never been seen before” is a fact; running it through a language model adds latency, a dependency, and a way for it to arrive subtly wrong.

One failure worth recording

In early July the morning digest started coming back with the Juniper check failed, while every other check passed. The cause was a firewall filter added to the switch’s routing engine a few days earlier, tightening management access to the infrastructure subnet — which the assistant VM, on the lab subnet, was not in. Ping still worked, because the filter permitted ICMP. Only SSH timed out.

Offered a narrow exception for the agent’s address, Clay removed the filter instead: a defensible call for a single-occupant home lab, and a reminder that the least-visible dependency in any automation is the one the automation runs over. A monitoring check that can’t reach the thing it monitors reports the same way as a thing that’s down.

Operational notes for anyone running Hermes

Environment changes need a full compose recreate — a plain restart won’t re-read them. Running gateway commands via docker exec can kill the supervised gateway process, which is recovered with a container restart. The voice dependencies live in a persistent library bundle outside the image, and numpy has to stay pinned to a coherent version or speech-to-text fails silently rather than loudly.

Everything else in the post above still stands. The ambient-awareness argument was right; it just needed the notifications to be rarer than I originally built them.