feat: Brabble as Clawdis node for distributed voice wake

[steipete]

Summary

Run brabble as a Clawdis node for Star Trek-style "Hello Computer" voice activation anywhere.

Vision

• Deploy brabble on Raspberry Pi 4 (or any device)
• Connects to Clawdis gateway via Tailscale (like iOS/Android nodes)
• Wake word detection triggers → sends audio/text to gateway
• Gateway routes to agent → response back via TTS

Use Cases

• "Hey Clawd, turn down lights in bedroom to 10%" → Home Assistant integration
• "Hey Clawd, what's my schedule tomorrow?" → Calendar queries
• "Hey Clawd, play some jazz" → Audio control
• Distributed voice points throughout home/office

Architecture

[Pi + Brabble] --wake word--> [Gateway] --> [Agent]
                                  ^            |
                                  |            v
                              [Response] <-- [TTS]

Related

• brabble: https://github.com/steipete/brabble
• swabble: macOS 26 native version using Speech.framework
• Could accept hooks and potentially host brabble directly

Discussion

From Discord #general (Jan 3, 2026)

[tiagoefreitas]

home assistant has a framework for this and open hardware, could be a nice addition too

[afalk42]

This would be a fabulous (or "leiwand", as we Austrians say) feature, especially when used with a USB Speakerphone, such as the Jabra Speak 410 connected to the Raspberry Pi! Any timeline for when this might get implemented?

[VarunChopra11]

@steipete

Proposal: Use microWakeWord + whisper.cpp for Pi/Linux Distributed Voice Node

Summary:
Rather than integrating brabble (Go-based full pipeline) directly, I propose an architecture using lightweight microWakeWord (for efficient always-on wake word detection) + whisper.cpp (for on-demand transcription) + a Node.js/bash gateway hook. This aligns with openclaw's current stack and keeps dependencies clean.

---

Advantages

• No new product language runtime: No Go or Python as core dependencies — just a small TFLite binary and C++ for whisper.cpp.
• Ultra-low idle CPU: microWakeWord runs at <5% CPU on the Pi, activating whisper.cpp only after wake trigger.
• Architecture symmetry: Mirrors how Swabble works on macOS/iOS, just with different underlying engines.
• Separation of concerns: Small, replaceable modules for detection/transcription/hook.

Disadvantages

• Slightly more wiring required: Need to glue together microWakeWord and whisper.cpp via scripting.
• Minor maintenance: Two binaries to update instead of one (brabble handles both, but in Go).
• No cross-platform single binary: brabble is more singular, but less "native" to the current ecosystem.

---

Why Not brabble?

• Adds Go as a runtime/dependency, which isn't elsewhere in openclaw's core stack.
• Less resource-efficient: whisper.cpp held warm under brabble uses more CPU/RAM compared to an always-idle microWakeWord.

---

Net:
This approach keeps the main openclaw repo clean, leverages best-fit tools for each job, and gives the lowest possible resource use on Raspberry Pi.

Curious for maintainer thoughts — happy to start prototyping if this direction sounds good!

---

[steipete]

ClawKeeper Triage

Last analysis: 2026-03-07T22:46:22Z
Planned action: comment
Category: needs_review
Confidence: 88%

Promising feature idea, but the current record shows unresolved product and architecture questions around whether this belongs in core, a plugin, or an external node integration.

• The request appears directionally valid, but scope is still broad across node runtime, gateway transport, speech pipeline, and operator setup.
• The current analysis leaves key architecture choices open, especially the node contract, auth/pairing model, and where STT/TTS should run.
• This looks better suited for product/architecture review before implementation work starts.
• A narrower follow-up proposal would help, such as defining the minimal node-to-gateway contract first.
• Keeping the issue open is reasonable until maintainers decide whether this ships as core, an extension, or an external companion project.

[afalk42]

I had this on my "fun project" to-do list for a little while now and finally found time to implement this today, with the help of my OpenClaw agent, of course. This was done as a completely external implementation, so requires no actual PR for code changes in OpenClaw.

This setup uses a Raspberry Pi 5 running as an OpenClaw node with a custom Python voice pipeline script. It connects to the OpenClaw gateway over the LAN and routes voice interactions through the main agent session, giving the voice channel access to every tool the agent has.

Architecture

                    ┌─────────────────────────────────┐
                    │        OpenClaw Gateway         │
                    │   (wss://gateway:18789)         │
                    │                                 │
                    │  ┌──────────┐  ┌──────────────┐ │
                    │  │  Agent   │  │  Tool Engine │ │
                    │  │  (main)  │──│  (HA, email, │ │
                    │  │          │  │   calendar…) │ │
                    │  └────▲─────┘  └──────────────┘ │
                    └───────┼─────────────────────────┘
                            │ chat/completions API
                            │ (SSE streaming)
                            │
              ┌─────────────┼─────────────────┐
              │     Raspberry Pi 5 Node       │
              │                               │
              │  ┌──────────────────────────┐ │
              │  │   voice-pipeline.py      │ │
              │  │                          │ │
              │  │  1. Wake word detection  │ │
              │  │     (Porcupine/Picovoice)│ │
              │  │  2. Record speech        │ │
              │  │  3. STT (OpenAI)         │ │
              │  │  4. → Gateway API        │ │
              │  │  5. Stream response      │ │
              │  │  6. TTS per sentence     │ │
              │  │     (ElevenLabs)         │ │
              │  │  7. Play via Jabra       │ │
              │  └──────────────────────────┘ │
              │                               │
              │  ┌──────────────────────────┐ │
              │  │   OpenClaw Node Service  │ │
              │  │   (system.run, browser)  │ │
              │  └──────────────────────────┘ │
              │                               │
              │  🔊 Jabra SPEAK 410 USB       │
              │  🎙️ (mic + speaker in one)    │
              └───────────────────────────────┘

Key Design Decisions

1. Not a separate agent — The voice pipeline connects to the main agent session via the gateway's /v1/chat/completions endpoint. This means voice has access to every tool: Home Assistant, email, calendar, web search, etc. No reduced-capability voice-only agent.

2. Streaming TTS — Response text is broken into sentence-sized segments and each is sent to TTS immediately as it streams back from the LLM. This means you hear "Sure, let me turn that off" while the tool call is executing, rather than getting all the text dumped at the end.

3. Wake word runs locally — Picovoice Porcupine runs entirely on the Pi's CPU with zero cloud calls. Audio only leaves the device after the wake word triggers and the user speaks a command.

4. Runs as a systemd user service — Auto-starts on boot, auto-restarts on crash, survives SSH disconnects.

For full details and Python code, please see: https://github.com/afalk42/openclaw-pi-voice-node

[VarunChopra11]

@steipete — afalk42's external implementation above is a great reference for the node-to-gateway contract in practice (using /v1/chat/completions + SSE streaming). Would it make sense to formalize that as the minimal node interface spec before considering native integration? Happy to help draft a lightweight ADR or interface doc if that would move this forward.