DEV Community: voicute

microWakeWord vs an online generator: custom wake words on the ESP32-S3

voicute — Sat, 31 Oct 2026 04:07:39 +0000

microWakeWord vs an online generator: custom wake words on the ESP32-S3

If you want wake-word detection on the device itself — an ESP32-S3, an ESPHome build, a Home Assistant Voice Preview Edition — microWakeWord is the community's answer. It's open source, its preset models are one YAML block away in ESPHome, and its INT8 TFLite models are genuinely tiny.

I run Voicute, an online wake-word generator, so I get asked how it compares. Since microWakeWord keeps coming up alongside openWakeWord as if they were one thing: they're two separate projects by different authors, from the same Home Assistant ecosystem. openWakeWord runs server-side; microWakeWord runs on the microcontroller. This post is only about the microcontroller side.

Where microWakeWord shines

For a supported preset wake word, it's hard to beat:

Official ESPHome micro_wake_word component — detection stays on-device, no audio streamed anywhere
Preset models already tuned for ESP32-S3-class hardware
INT8 TFLite models small enough for flash and RAM budgets on an MCU
An active community around Home Assistant Voice

If one of the preset words works for your product, use it. The rest of this post is about the case where it doesn't — your phrase isn't available, and you need a custom model.

What a custom microWakeWord model actually takes

The framework is open and the training docs are good. But "custom" means you assemble the whole data pipeline yourself:

Generate synthetic positives with the Piper sample generator (free, open TTS)
Collect real hard negatives — confusable phrases, TV, music, room noise from the target space
Write the model config (JSON: features, architecture, quantization) by hand
Train, export INT8 TFLite, flash, and evaluate on the actual microphone
Iterate 1–4 until false accepts and recall both land where you need them

None of this is exotic — it's how wake-word models are built. It's just that every step is yours: every retrain cycle costs an afternoon of notebook-plus-desk time, and the quality ceiling is set by your data recipe.

Two recipe details decide most outcomes. First, synthetic positives only cover what TTS can say — Piper's voices have a recognizable character and a narrow accent range, and the gap between "Piper saying your phrase" and "a human saying it at 2 m through a MEMS mic" is where recall usually dies. Second, the negative set is what teaches rejection; generic background noise rarely contains the specific phrases your word actually gets confused with.

What an online generator changes

Again, full disclosure up front: I built Voicute, and its training platform is closed source. The inference engine and exported models are open (github.com/voicute/onnx-wakeword). Here's the honest side-by-side:

	microWakeWord	Voicute
Code	fully open (framework + runtime)	training closed; engine + models open
Target	ESP32-S3-class MCUs (INT8 TFLite)	ONNX + TFLite — MCU, Python, Android, web, HA
Sample TTS	Piper (free)	commercial neural TTS
Real recordings	DIY — record, rebuild dataset, retrain	upload in browser, retrain is one click
Hard-negative mining	you curate the negative set	re-mined automatically on retrain
Config	model JSON written by hand	none — phrase in, model out
Multi-keyword	one model per phrase, stacked	2–10 words in one model (~128 KB, <5 ms)
Languages	depends on available Piper voices/models	Chinese, English, German, French, Japanese workflows
Time to first model	hours–days (Colab ↔ device loop)	minutes to a testable model

The three differences that matter in practice:

The record→retrain loop is minutes, not days. When the first model fails on real hardware — and a first model often fails — the microWakeWord path means rebuilding the dataset and running the training notebook again. In Voicute you record a small varied set of the real phrase, upload it, and retrain; hard negatives get re-mined for you. That loop speed is usually the difference between "we evaluated custom wake words" and "we shipped one."

Multi-keyword in one model. ESPHome-style runtimes load one model per phrase, so wake word plus a few commands means several models to train, manifest, and manage. Voicute trains 2–10 keywords into a single model, one inference pass, ~128 KB and under 5 ms on an ESP32-S3 — wake word and commands in the same budget as one standalone wake word.

TTS quality as a starting point. Piper is the right choice for a fully open pipeline; Voicute generates its synthetic positives with paid commercial-grade neural TTS instead. It's still synthetic audio — the synthetic-to-real gap exists for everyone — but starting closer to natural speech means fewer retrain cycles before the model survives a real room and a real accent.

When microWakeWord is still the right call

A preset model fits, and you want zero new dependencies — ESPHome makes this a one-block change.
The fully open stack (framework, runtime, training) is a hard requirement.
Your team already has the data pipeline built and enjoys operating it.

When the generator earns its keep

Your phrase isn't available as a preset, and non-English is often exactly this case.
You need wake word + commands in one model on the device.
The deadline is real and the person doing this is a firmware engineer, not an ML person.
You want the first model testable in minutes, then decide whether it needs real recordings.

One thing that doesn't change on either path: the exported model is only half the system. The microphone, gain, enclosure, and feature pipeline decide as much as the weights do — test on the target hardware, measure recall and false accepts per hour, and never trust a single confidence score.

Disclaimer: I'm the creator of Voicute. microWakeWord is a genuinely well-built project and the ESPHome integration is excellent; if I've mischaracterized anything, tell me and I'll correct it.

openWakeWord vs an online wake word generator: two paths to a custom model

voicute — Sat, 31 Oct 2026 03:54:59 +0000

openWakeWord vs an online wake word generator: two paths to a custom model

openWakeWord is the default answer when Home Assistant users want custom wake words, and for good reason: it's free, open source, and ships with a set of official pretrained models. I've used it, and parts of my own product exist because of its limitations.

Because people ask me to compare it with Voicute — the online generator I built — here is an honest breakdown: what openWakeWord's training path actually involves, where it struggles, and what a hosted generator changes. (microWakeWord, the ESP32-side cousin of openWakeWord, gets its own post.)

First, the right mental model

These are not two versions of the same thing. openWakeWord is a pipeline you operate: open-source training notebooks, open weights, open runtime, and you own every step. Voicute is a hosted workflow that operates the pipeline for you — type a phrase, get a model. The training platform is closed source; the inference engine and the exported models are open.

If your decision criterion is "must the training code be open?", this comparison is over — pick openWakeWord and be done. The comparison below is for everyone else.

What custom training on openWakeWord looks like

For the official pretrained models, openWakeWord is excellent — download, load, done. The story changes when your phrase isn't one of them:

Generate synthetic positive samples with the Piper sample generator (free, open TTS)
Assemble negative datasets: background audio, speech, music
Run the training notebook (Colab or local Python)
Export ONNX/tflite, test on the real device, and usually iterate

One structural fact explains most of the pain: the speech embedding backbone is frozen. Custom models are small classifiers on top of a fixed feature space. When your phrase lives in a badly-covered region of that space, no amount of training steps pulls recall up — I've measured swings from roughly 25% to 90% between two words trained with the identical recipe. Lowering the threshold to recover recall buys you false wakes.

Also note the language situation: the official pretrained models are English. The training notebook can synthesize samples in other languages via Piper voices, but you own the entire validation burden — nobody has tuned that path for you.

What the hosted generator does differently

Same goal, different allocation of work:

	openWakeWord	Voicute
Code	fully open (training + runtime)	training closed; engine + models open (GitHub)
Sample TTS	Piper (free)	commercial neural TTS
Architecture	frozen embedding + small classifier head	from-scratch TCN per model
Real recordings	DIY — record, re-run notebook, repeat	upload in browser, retrain is one click
Multi-keyword	one model per word, stacked at runtime	2–10 words in one model (~128 KB, <5 ms)
Languages	English pretrained; others DIY	Chinese, English, German, French, Japanese workflows
Output	ONNX / tflite	ONNX + TFLite, standard formats
Time to first model	hours–days, notebook fluency required	minutes to a testable model

Three of these deserve a paragraph each.

No frozen embedding. Because Voicute trains from scratch per model, the network can shape its feature space around your specific phrase instead of drawing a boundary inside a fixed one. That's the direct answer to the "word-picking" problem above — not magic, just not inheriting someone else's frozen features.

Commercial TTS + real recordings. Piper is impressive for a fully open pipeline, but synthetic samples are the only positive evidence an openWakeWord model ever sees, and Piper's prosody/accent range is narrow. Voicute starts from commercial-grade neural TTS — closer to natural speech, fewer retrain cycles — and, more importantly, treats real recordings as a first-class step: when recall disappoints on real hardware, you record a small varied set of the actual phrase, upload it, and retrain. A small varied set beats hundreds of duplicate takes. All of this is possible in openWakeWord's world too; it's just you, scripts, and an afternoon each time.

Multi-keyword in one model. openWakeWord trains one model per word, and your runtime stacks them. A wake word plus four commands means five models to tune and serve. Voicute trains 2–10 keywords into a single model with one inference pass — ~128 KB and under 5 ms on an ESP32-S3.

When openWakeWord is still the right call

Your phrase is close to an official pretrained model — free, proven, done.
You need the training pipeline itself open and auditable end to end.
You're researching, not shipping, and the notebook loop is part of the fun.

When the generator earns its keep

The phrase is non-English, or English-but-picky (the 25%-recall kind).
Recall must be stable without per-device threshold tuning.
You need wake word + commands in one small model.
The person doing this is a firmware engineer with a deadline, not an ML hobbyist.

That's the whole trade: open pipeline you operate vs hosted workflow that operates it for you, with different TTS, different model architecture, and a real-recording loop measured in minutes. If runtime openness matters to you, note that Voicute's engine and models are on GitHub — measure recall yourself rather than trusting any "90%+" claim, mine included.

Disclaimer: I'm the creator of Voicute. openWakeWord is referenced fairly as far as I can — it's a genuinely good project; if I've mischaracterized anything, tell me and I'll correct it..

What Is ONNX? Where Can a Custom Wake-Word Model Run?

voicute — Wed, 28 Oct 2026 11:57:02 +0000

ONNX is a portable model format. It helps move a trained wake-word model between compatible inference runtimes, but an ONNX file is not a complete voice assistant and it cannot be installed into every consumer device.

ONNX in simple terms

ONNX, or Open Neural Network Exchange, describes a neural network graph, its weights, and its input/output definitions. An inference runtime loads the file and executes the model on a CPU, mobile device, desktop computer, browser, or edge system.

For a custom wake word, the complete pipeline is usually:

Microphone → audio preprocessing → Mel features → ONNX model
           → threshold and false-trigger filtering → application action

The ONNX file only represents the model. Audio capture, feature extraction, thresholds, consecutive-frame confirmation, cooldowns, and device actions belong to the surrounding application.

Wake words are not the same as ASR

Keyword spotting (KWS) answers a narrow question: did one of these fixed phrases occur? Automatic speech recognition (ASR) converts open-ended speech into text.

	KWS / wake word	ASR
Task	Detect fixed phrases	Transcribe speech
Typical size	KB to hundreds of KB	Tens to hundreds of MB
Runtime	Always-on, low latency	Usually starts after wake-up
Use cases	Wake words and fixed commands	Open-ended dictation and conversation

If a product only needs a wake word or a small set of commands, KWS can be much smaller, faster, and easier to keep offline than a full ASR system.

Where can an ONNX wake-word model run?

Platform	Typical runtime	Practical use
Android	ONNX Runtime or TFLite	Local app listening and offline controls
Linux / Raspberry Pi	ONNX Runtime, Python, or C++	Gateways, robots, desktop devices, and local automation
Windows / macOS	ONNX Runtime	Desktop tools and test applications
Web	ONNX Runtime Web with WASM/WebGL	Browser demos and web applications with microphone permission
iPhone	iOS runtime or Core ML integration	Possible inside an app; it does not replace Siri
Home Assistant	Wyoming or an external local service	A custom wake-word path for your own Home Assistant setup

What about ESP32?

ESP32-S3 is an important exception. In practice, you normally do not copy a desktop ONNX file onto the microcontroller and run a full ONNX Runtime. Instead, convert and quantize the model to INT8 TFLite and use TensorFlow Lite Micro or another embedded runtime.

The accurate statement is that one training result can target multiple deployment formats. Android, Linux, and Web may use ONNX, while ESP32-S3 generally uses an INT8 TFLite version.

Can Alexa, Google Home, or Siri use a custom wake word?

Not by installing an ordinary ONNX file. Existing Amazon Echo, Google Home/Nest, and Siri products control their own microphone and wake-word pipeline. A user cannot arbitrarily replace the factory wake word with a custom model.

The model can run in an Android app, a Raspberry Pi gateway, an ESP32-S3 device, or hardware that you control. That external system can then call Home Assistant, SwitchBot, Nature Remo, or another API.

Portable inference and permission to modify a consumer product firmware are two different things.

How to use ONNX as a wake-word model

Define the wake word or fixed commands and generate an ONNX or TFLite model.
Choose the target device and audio-capture path.
Connect the inference runtime and calculate the Mel features expected by the model.
Add thresholds, consecutive-frame confirmation, cooldowns, and false-trigger protection.
Start ASR after the wake word, or map the detected label directly to a fixed action.

The open-source onnx-wakeword project includes examples for Android, Web, Python, desktop, and embedded deployment. Always validate recall and false activations with the final microphone, distance, enclosure, and background noise.

Getting a custom model

Teams with an ML workflow can prepare positive and negative data, train a KWS model, and export the target formats themselves. For faster product validation, Voicute lets you enter a keyword, generate a custom model, and download it for local deployment.

The important distinction is simple: ONNX makes model deployment more portable; it does not make every device installable or every factory wake word customizable.

Generate and test a custom wake-word model at Voicute.

Build a Multi-Keyword Offline Voice Controller with ONNX and TFLite

voicute — Mon, 26 Oct 2026 09:40:12 +0000

Many voice interfaces do not need to transcribe arbitrary speech. A lamp, robot, appliance, kiosk, or media controller may only need a small vocabulary such as:

turn on the light
turn off the light
next
previous
stop

For this kind of product, a multi-keyword model can be a simpler fit than a full cloud ASR pipeline. The model answers a constrained question: which known command, if any, is present in the current audio window?

This article shows the engineering shape of that system, including model metadata, local inference, command callbacks, and the tests that matter before connecting voice input to a real action.

1. KWS is not general speech recognition

Keyword spotting (KWS) detects a known phrase or a small set of known phrases. Automatic speech recognition (ASR) produces a transcript for open-ended speech.

Product requirement	Suitable first tool
Start an interaction with one phrase	Single-keyword KWS
Recognize 2–10 fixed commands	Multi-keyword KWS
Understand arbitrary sentences	ASR plus intent parsing
Verify who is speaking	Speaker verification

A typical two-stage voice controller looks like this:

always-on wake word
        ↓
short command window
        ↓
multi-keyword model
        ↓
command label
        ↓
safe application action

The wake word and the command vocabulary are separate concerns. Keeping the command list fixed makes the application behavior easier to test and keeps the system local.

2. One model, several command labels

A multi-keyword model exposes a fixed output order. For example:

{
  "model_type": "multi_keyword",
  "keywords": ["turn on the light", "turn off the light", "next", "stop"],
  "model_file": "commands.onnx",
  "mel_time": 98,
  "n_mels": 32,
  "cons_frames": 2
}

The keywords array is part of the interface. Its order must stay aligned with the model output:

output[0] → turn on the light
output[1] → turn off the light
output[2] → next
output[3] → stop

The application should map a recognized label to an action instead of embedding business logic inside the model.

3. A minimal application callback

The exact API differs between Python, Android, Web, and embedded runtimes, but the application boundary can remain simple:

def on_keyword(word, probability, info):
    if word == "turn on the light":
        lights.set_power(True)
    elif word == "turn off the light":
        lights.set_power(False)
    elif word == "next":
        player.next()
    elif word == "stop":
        player.stop()

In a real product, add a cooldown and make repeated events safe. Voice detection should not directly bypass authorization or confirmation for destructive actions such as deleting data, unlocking a door, or purchasing something.

4. The local inference pipeline

The model file is only one part of a working detector:

microphone
   ↓
mono PCM audio
   ↓
sample-rate conversion and framing
   ↓
log-Mel feature extraction
   ↓
ONNX or TFLite inference
   ↓
threshold and consecutive-frame logic
   ↓
command callback

The runtime preprocessing must match the training and export configuration. A model can appear correct in one demo and lose recall if the target application changes the sample rate, frame shape, Mel settings, or input normalization.

The open-source onnx-wakeword repository contains the local inference examples. The same general model concept can be delivered as ONNX for desktop, Web, Android, and Python integrations, or as TFLite/TFLite Micro for constrained embedded targets.

5. ONNX and TFLite are deployment choices

Use the runtime that matches the target platform:

Target	Typical format or runtime	Important boundary
Web	ONNX Runtime Web	Browser microphone permission and compatibility still matter
Android	ONNX Runtime in the open demo	The current demo is not an Android TFLite SDK
Python / desktop	ONNX Runtime	Audio device and operating-system setup must be tested
ESP32-S3	INT8 TFLite Micro	The public hardware example is tied to its tested audio board

“The model is portable” does not mean that every audio device or board behaves identically. The final microphone, enclosure, operating system, and power budget need their own test.

6. Testing commands as a group

Testing only one successful utterance per command is not enough. For each command, collect:

positive examples from multiple speakers;
different distances, speeds, and volumes;
similar-sounding phrases;
ordinary conversation and silence;
television, music, fans, and device playback;
the microphone and enclosure intended for the product.

Measure at least:

recall = detected intended utterances / total intended utterances
false accepts per hour = unwanted activations / hours of negative audio

Also check confusion between commands. A model can have good recall for next while incorrectly confusing next with stop in the same environment.

7. When a second training round is useful

If the baseline model triggers on a recurring sound, keep the false-trigger clips as hard negatives for a later training round:

base model
   ↓
scan representative negative audio
   ↓
collect false-trigger clips
   ↓
retrain with hard negatives
   ↓
repeat held-out evaluation

Do not reuse every clip as training data. Keep a separate held-out set so that the second evaluation still measures generalization.

8. Generate before you integrate

The practical workflow for a fixed-command product is:

Define the wake word and command vocabulary.
Generate a Basic model for the target language.
Test the phrases with real voices before downloading.
Download the ONNX or TFLite artifact and its metadata.
Integrate the matching local runtime.
Measure recall, false accepts, latency, memory, and power on the target device.

Voicute supports custom keywords in Chinese, English, Spanish, Japanese, German, French, and Hindi. The online test is a screening step; it is not a production guarantee for every microphone or enclosure.

Conclusion

For a product with a small, known command vocabulary, one multi-keyword model can be cleaner than one detector per command or a full ASR service. The model recognizes the vocabulary; the application owns the action policy; the final device test decides whether the result is ready to ship.

The open inference examples are available in voicute/onnx-wakeword. You can generate and test your own fixed command vocabulary at Voicute.

Disclosure: I am the creator of Voicute. The model-generation service is commercial, while the local inference examples are open source. Results depend on the language, speakers, microphone, environment, and runtime configuration.

How to Get a Wake-Word Model in 2026

voicute — Fri, 23 Oct 2026 09:49:54 +0000

Adding a wake word to a product sounds simple:

microphone → wake-word model → application action

The difficult part begins when the phrase is not one of the pre-trained examples, the language is not English, the microphone is inside a real product, or the model starts triggering on television and normal conversation.

In 2026, there are two practical ways to obtain a custom wake-word model:

Train an open-source pipeline such as openWakeWord yourself.
Use an online or hosted training platform and download the resulting model.

Both approaches can work. The right choice depends on whether your priority is training control or getting to a deployable experiment quickly.

This guide explains both paths and the validation steps that should happen before a model is used in a real device.

First: do you need a wake-word model?

A wake-word model is a small keyword-spotting model. It answers a narrow question:

Is the target phrase present in this short audio window?

It does not transcribe arbitrary speech and it does not understand open-ended requests.

Use a wake-word or keyword-spotting model when the application needs phrases such as:

Hey device
Open the door
Turn on the light
Start recording

Use ASR and intent parsing when the user can say anything, for example:

Set the living-room light to 37 percent and turn it off after ten minutes.

A common product architecture is therefore:

Always-on wake word
          ↓
Short command window
          ↓
Fixed-command KWS or ASR
          ↓
Application action

Keeping these stages separate can reduce compute, latency, network dependency, and accidental microphone uploads.

One model can recognize multiple keywords

The same workflow is useful when the product needs a fixed command set, not only one wake word. Instead of running one model for every command, you can train a multi-keyword model that returns a label for each phrase:

Turn on the light  → LIGHT_ON
Turn off the light → LIGHT_OFF
Pause              → PAUSE
Resume             → RESUME

This is still keyword spotting, not open-ended speech recognition. The vocabulary is defined before training, and the application maps the returned label to an action. A single multi-keyword model can simplify model packaging, feature extraction, threshold management, and updates.

Each keyword still needs separate evaluation. Similar pronunciations may have different recall and false-trigger behavior, so one good result must not be used as a proxy for every class in the model.

What does a custom wake-word model contain?

The model file is only one part of the system. A working detector also needs:

Microphone capture
Sample-rate conversion
Audio framing
Feature extraction, often log-Mel features
Model inference
A detection threshold
Cooldown and repeated-trigger logic
Application callbacks

The same model can behave differently if the audio preprocessing changes. Before comparing training platforms, write down the target runtime requirements:

Item	Example question
Sample rate	Does the runtime expect 16 kHz audio?
Input format	Mono PCM, float32, or int16?
Model format	ONNX, TFLite, or TFLite Micro?
Target device	Browser, Android, Linux, ESP32-S3, or Raspberry Pi?
Trigger policy	How many consecutive frames are required?
Evaluation	Will you measure recall and false accepts per hour?

This prevents a common mistake: training one model and then discovering that the deployment runtime expects a different feature pipeline.

Path 1: train openWakeWord yourself

openWakeWord is an open-source wake-word library with pre-trained models and tools for custom model training. Its documentation includes an automated training utility and a Google Colab workflow.

The self-managed route gives you the most control. You can inspect the data, change the training process, run multiple experiments, and keep the pipeline inside your own infrastructure.

It also means that you are responsible for the complete process.

Step 1: choose a phrase that can be detected

Good wake words are distinctive and easy to pronounce. Avoid phrases that occur frequently in normal conversation or that are too close to common words.

Test several candidate phrases before training a production model. A phrase that looks unique in text may be difficult to distinguish acoustically.

For a multilingual product, test the phrase with native speakers. Pronunciation, tone, syllable boundaries, and speaking speed can change the difficulty significantly.

Step 2: generate positive examples

The positive examples contain the target phrase. A training pipeline may use synthetic speech, real recordings, or a mixture of both.

Synthetic data is useful for quickly covering multiple voices and speaking styles. Real recordings are useful when the final users have a particular accent, microphone, speaking distance, or pronunciation pattern.

At minimum, vary:

Speaker identity
Speaking speed
Volume
Pronunciation
Background noise
Distance from the microphone

Do not put every recording into one large training set without a separate test set. You need held-out examples to measure whether the model generalizes.

Step 3: prepare negative audio

Negative audio does not contain the target phrase. It should represent what the device will hear when it must remain silent:

Normal conversations
Music
Television
Fans and appliances
Similar-sounding words
Silence and room noise
Speech from different speakers

False triggers are often caused by the negative data being too easy. A model that only sees clean speech and clean noise during training may fail in a living room, office, vehicle, or factory.

Step 4: run the official training workflow

The openWakeWord repository provides training documentation and notebooks. Start with the automated workflow if you are learning the process, then move to a more controlled pipeline when you need production-level evaluation.

Keep a record of:

Repository commit or release version
Training configuration
Synthetic voice sources
Positive and negative dataset versions
Number of training steps
Exported model format
Threshold used during evaluation

Without these details, it becomes difficult to reproduce a model or understand why a second training run behaves differently.

Step 5: evaluate the model before deployment

Do not judge a model only by whether it triggers when you say the phrase once.

Measure recall:

recall = detected intended activations / total intended activations

Measure false accepts per hour:

false accepts per hour = unwanted activations / hours of negative audio

Run both tests with the final microphone if possible. A model can perform well on a laptop recording and poorly on a small embedded microphone.

Why self-training can take longer than expected

The first training run is usually not the end. Common problems include:

The phrase is acoustically difficult.
The synthetic voices do not match real speakers.
The negative audio is too clean.
The threshold is too low.
The feature-extraction pipeline is different at runtime.
The enclosure or microphone adds noise.
The phrase is confused with a common word.

The usual improvement loop is:

Train R0
   ↓
Test on real audio
   ↓
Collect false triggers and missed examples
   ↓
Add difficult examples
   ↓
Train R1
   ↓
Test again

This is why “I trained a model” and “I have a reliable product detector” are different milestones.

Path 2: use an online training platform

The online route is useful when you want to validate a phrase without first building a machine-learning environment.

The typical workflow is:

Enter a wake word
      ↓
Choose a language or voice configuration
      ↓
Generate and train the model online
      ↓
Test it with a browser microphone
      ↓
Download the model
      ↓
Validate it on the target device

This does not eliminate testing. It moves the training infrastructure out of your local machine.

What to check before choosing a platform

Do not compare online platforms only by their landing pages. Check:

Supported languages and pronunciations.
Whether the output is ONNX, TFLite, TFLite Micro, or proprietary.
Whether the model can run without an API key or network connection.
Whether commercial redistribution is allowed.
Whether you can test with your own microphone before downloading.
Whether real recordings or hard negatives can be used later.
Whether the runtime includes the required preprocessing.
Whether the model size fits the target hardware.

For ESP32 and ESPHome projects, microWakeWord is an example of a hosted workflow focused on small embedded models. Its API documentation describes INT8 TFLite model delivery and ESPHome integration.

For a hosted openWakeWord-oriented workflow, openwakeword.com provides an online training experience built around the openWakeWord ecosystem. Verify its current model export and license terms before using a generated model commercially.

For a multi-platform workflow, Voicute provides online custom wake-word and keyword-spotting model generation, browser testing, and ONNX/TFLite-oriented deployment paths. The onnx-wakeword repository provides open inference examples.

Voicute also supports multi-keyword models and multilingual training. The current language set is English, Chinese, Spanish, Japanese, German, French, and Hindi. This matters for products that need the same fixed-command architecture across markets instead of building a separate training workflow for every language.

When synthetic or baseline training is not enough for a specific accent, brand pronunciation, or microphone, the workflow can be extended with authorized real recordings:

Base model → upload representative recordings → enhancement training → held-out evaluation

Recordings should cover the target speakers, distance, volume, pronunciation, and acoustic environment. They should not be copied into the evaluation set. Real-voice enhancement can improve the match to a product's users, but it does not remove the need to test the final microphone and background noise.

These services have different goals. A platform optimized for ESP32-S3 is not automatically the best choice for Android or browser deployment. A platform with a simple web form is not automatically the best choice for a regulated or commercial product.

A simple decision guide

Choose self-managed openWakeWord when:

You have Python and machine-learning experience.
You need to inspect or customize the training pipeline.
You can manage datasets and evaluation.
You want to control the infrastructure and model generation process.

Choose an online platform when:

You need to test a phrase quickly.
You do not want to install a GPU training environment.
You need a guided train-and-download workflow.
You are willing to validate the output independently.

Choose an ecosystem-specific platform when:

Your target is already fixed, such as ESP32-S3 and ESPHome.
The platform's model format and license match your product.
You prefer an integrated device workflow over general portability.

Deploy the model locally

After obtaining a model, keep the runtime local during inference whenever possible:

Microphone
   ↓
Audio preprocessing
   ↓
Wake-word inference
   ↓
Threshold and cooldown logic
   ↓
Local application callback

The exported model can be integrated through standard ONNX/TFLite runtimes on ESP32, Raspberry Pi, Android, Web, Windows, macOS, Linux, and Home Assistant. Constrained ESP32 devices commonly use INT8 TFLite/TFLite Micro, while desktop, browser, mobile, Linux, and Raspberry Pi applications can use an ONNX or TFLite runtime. Home Assistant can connect through a local Wyoming-oriented integration.

Before shipping, verify:

The sample rate is correct.
The audio channel layout is correct.
The feature extractor matches the training pipeline.
The output label is mapped correctly.
The threshold is tested with positive and negative audio.
Repeated detections are suppressed.
The application does not perform unsafe actions on a single noisy frame.

An ONNX model can be convenient for Python, desktop, Android, and browser runtimes with compatible ONNX Runtime support. TFLite or TFLite Micro is often more suitable for constrained embedded hardware. The model format should be chosen together with the target runtime, not after training is complete.

A reproducible test plan

Use a small but repeatable test plan for every training route:

Positive test set

At least several speakers
Multiple distances
Quiet and noisy rooms
Different speaking speeds
The final microphone

Negative test set

Normal conversation
Music and television
Similar-sounding phrases
Background appliances
Long periods of room audio

Report these numbers

Recall percentage
False accepts per hour
Model size
RAM and flash usage
Average inference latency
Runtime and operating system
Threshold and cooldown settings

If the test conditions are not recorded, the results are difficult to compare. “It worked on my laptop” is a useful first observation, not a benchmark.

Conclusion

There is no single correct way to obtain a wake-word model in 2026.

Self-training openWakeWord gives you control and teaches you how the pipeline works. An online platform reduces setup time and is often the fastest way to validate a phrase. An ecosystem-specific service can be the most practical option when the hardware and runtime are already fixed.

The safest workflow is:

Choose the phrase
   → choose self-training or hosted training
   → generate the model
   → measure recall and false accepts
   → test the final microphone
   → deploy locally
   → repeat with hard negatives when necessary

The important result is not merely a downloaded model file. It is a model whose behavior is measured on the device and in the environment where it will actually be used.

Disclosure: I am the creator of Voicute. Voicute is mentioned as one online option in this guide. The comparison is not an independent third-party benchmark, and the performance of any wake-word model depends on the phrase, language, training data, threshold, microphone, and deployment environment.

I Turned a Product Name into an Offline Wake Word — What I Had to Test

voicute — Wed, 21 Oct 2026 23:53:20 +0000

Most smart products already have a name. The hard part is making the device hear that name reliably without sending every conversation to the cloud.

This is the product question behind a custom wake word: can a device recognize one short phrase locally, then start the next interaction?

The product name and the wake word are different things

A brand name is designed for people. A wake word is designed for a detector. The same phrase can be a good brand name and a poor wake word if it is too short, too common, or easily confused with normal conversation.

For an example product, imagine a small robot called “Taro”. The desired flow is:

“Hey Taro”       → wake the robot
“Move forward”   → start a fixed action
“Stop”           → stop the motor

The wake phrase and the fixed commands are not the same product requirement.

KWS or ASR?

If the product needs to understand arbitrary sentences, names, numbers, or parameters, it needs speech recognition and intent handling. But if it only needs one wake phrase or a small list of commands, keyword spotting is a more focused option.

Requirement	First option
Wake an assistant	Single-keyword KWS
Detect 2–10 fixed commands	Multi-keyword KWS
Understand open speech	ASR plus intent parsing
Verify the speaker	Speaker verification

KWS does not try to transcribe everything. It asks a narrower question: “did one of the target phrases occur?” That makes a small, local model possible.

What I would test before choosing the name

I would not approve a wake word from the spelling alone. I would test:

Several speakers saying the phrase naturally.
Different speaking speeds and distances.
The target microphone and enclosure.
Background conversation, music, fans, and household noise.
Similar-sounding phrases that should not trigger the product.

The browser is a useful first filter. It can tell us whether a phrase is worth taking to a device. It cannot prove that the same result will hold after the microphone, enclosure, distance, and noise environment change.

The delivery path

The practical flow is:

Product name
    ↓
Train a custom keyword model
    ↓
Test with real voices
    ↓
Export ONNX or TFLite
    ↓
Run locally on the target product

For a product team, the useful deliverable is not only a model file. The team also needs the audio input assumptions, feature extraction path, threshold behavior, cooldown logic, and a way to connect a detection callback to a safe product action.

Where a small custom model fits

For my experiments, I wanted a model that could run offline and fit several possible targets: Python, Web, Android, and embedded hardware. A standard ONNX or TFLite artifact makes that transition easier than a platform-locked runtime.

Voicute is one way to start this process without building the training pipeline first: enter the product name, train a Basic model, test it with real voices, and decide whether the result is good enough to download. Real-voice enhancement can help when the target users have a specific accent or speaking style.

The honest boundary is important: online testing is a screening step, not a production guarantee. The final product still needs measurements for recall, false triggers per hour, latency, memory and power.

A minimal local integration example

The runtime should expose a simple event to the application layer:

def on_keyword(word, probability, info):
    if word == "hey_taro":
        robot.start_interaction()
    elif word == "stop":
        robot.stop()

The application should also implement cooldowns and safe failure behavior. A detector should not repeatedly start an action because the same phrase remains in the audio buffer.

What I would ship with the project

The ONNX or TFLite model;
A reproducible inference example;
The supported sample rate and audio format;
Threshold and cooldown defaults;
A test checklist for the final microphone and enclosure;
Clear limitations instead of a universal accuracy claim.

The open-source runtime and examples are available in onnx-wakeword. If you want to test your own product name, use the Voicute online training page.

Disclosure: Voicute is my project. I am sharing the engineering process and its limitations, not claiming that one wake-word model is best for every language or device.

How to Get a Wake-Word Model in 2026: Train openWakeWord Yourself or Use an Online Platform

voicute — Wed, 21 Oct 2026 03:39:57 +0000

Adding a wake word to a product sounds simple:

microphone → wake-word model → application action

In 2026, there are two practical ways to obtain a custom wake-word model:

Train an open-source pipeline such as openWakeWord yourself.
Use an online or hosted training platform and download the resulting model.

Both approaches can work. The right choice depends on whether your priority is training control or getting to a deployable experiment quickly.

This guide explains both paths and the validation steps that should happen before a model is used in a real device.

First: do you need a wake-word model?

A wake-word model is a small keyword-spotting model. It answers a narrow question:

Is the target phrase present in this short audio window?

It does not transcribe arbitrary speech and it does not understand open-ended requests.

Use a wake-word or keyword-spotting model when the application needs phrases such as:

Hey device
Open the door
Turn on the light
Start recording

Use ASR and intent parsing when the user can say anything, for example:

Set the living-room light to 37 percent and turn it off after ten minutes.

A common product architecture is therefore:

Always-on wake word
          ↓
Short command window
          ↓
Fixed-command KWS or ASR
          ↓
Application action

Keeping these stages separate can reduce compute, latency, network dependency, and accidental microphone uploads.

What does a custom wake-word model contain?

The model file is only one part of the system. A working detector also needs:

Microphone capture
Sample-rate conversion
Audio framing
Feature extraction, often log-Mel features
Model inference
A detection threshold
Cooldown and repeated-trigger logic
Application callbacks

The same model can behave differently if the audio preprocessing changes. Before comparing training platforms, write down the target runtime requirements:

Item	Example question
Sample rate	Does the runtime expect 16 kHz audio?
Input format	Mono PCM, float32, or int16?
Model format	ONNX, TFLite, or TFLite Micro?
Target device	Browser, Android, Linux, ESP32-S3, or Raspberry Pi?
Trigger policy	How many consecutive frames are required?
Evaluation	Will you measure recall and false accepts per hour?

This prevents a common mistake: training one model and then discovering that the deployment runtime expects a different feature pipeline.

Path 1: train openWakeWord yourself

openWakeWord is an open-source wake-word library with pre-trained models and tools for custom model training. Its documentation includes an automated training utility and a Google Colab workflow.

The self-managed route gives you the most control. You can inspect the data, change the training process, run multiple experiments, and keep the pipeline inside your own infrastructure.

It also means that you are responsible for the complete process.

Step 1: choose a phrase that can be detected

Good wake words are distinctive and easy to pronounce. Avoid phrases that occur frequently in normal conversation or that are too close to common words.

Test several candidate phrases before training a production model. A phrase that looks unique in text may be difficult to distinguish acoustically.

For a multilingual product, test the phrase with native speakers. Pronunciation, tone, syllable boundaries, and speaking speed can change the difficulty significantly.

Step 2: generate positive examples

The positive examples contain the target phrase. A training pipeline may use synthetic speech, real recordings, or a mixture of both.

At minimum, vary:

Speaker identity
Speaking speed
Volume
Pronunciation
Background noise
Distance from the microphone

Do not put every recording into one large training set without a separate test set. You need held-out examples to measure whether the model generalizes.

Step 3: prepare negative audio

Negative audio does not contain the target phrase. It should represent what the device will hear when it must remain silent:

Normal conversations
Music
Television
Fans and appliances
Similar-sounding words
Silence and room noise
Speech from different speakers

False triggers are often caused by the negative data being too easy. A model that only sees clean speech and clean noise during training may fail in a living room, office, vehicle, or factory.

Step 4: run the official training workflow

Keep a record of:

Repository commit or release version
Training configuration
Synthetic voice sources
Positive and negative dataset versions
Number of training steps
Exported model format
Threshold used during evaluation

Without these details, it becomes difficult to reproduce a model or understand why a second training run behaves differently.

Step 5: evaluate the model before deployment

Do not judge a model only by whether it triggers when you say the phrase once.

Measure recall:

recall = detected intended activations / total intended activations

Measure false accepts per hour:

false accepts per hour = unwanted activations / hours of negative audio

Run both tests with the final microphone if possible. A model can perform well on a laptop recording and poorly on a small embedded microphone.

Why self-training can take longer than expected

The first training run is usually not the end. Common problems include:

The phrase is acoustically difficult.
The synthetic voices do not match real speakers.
The negative audio is too clean.
The threshold is too low.
The feature-extraction pipeline is different at runtime.
The enclosure or microphone adds noise.
The phrase is confused with a common word.

The usual improvement loop is:

Train R0
   ↓
Test on real audio
   ↓
Collect false triggers and missed examples
   ↓
Add difficult examples
   ↓
Train R1
   ↓
Test again

This is why “I trained a model” and “I have a reliable product detector” are different milestones.

Path 2: use an online training platform

The online route is useful when you want to validate a phrase without first building a machine-learning environment.

The typical workflow is:

Enter a wake word
      ↓
Choose a language or voice configuration
      ↓
Generate and train the model online
      ↓
Test it with a browser microphone
      ↓
Download the model
      ↓
Validate it on the target device

This does not eliminate testing. It moves the training infrastructure out of your local machine.

What to check before choosing a platform

Do not compare online platforms only by their landing pages. Check:

Supported languages and pronunciations.
Whether the output is ONNX, TFLite, TFLite Micro, or proprietary.
Whether the model can run without an API key or network connection.
Whether commercial redistribution is allowed.
Whether you can test with your own microphone before downloading.
Whether real recordings or hard negatives can be used later.
Whether the runtime includes the required preprocessing.
Whether the model size fits the target hardware.

For ESP32 and ESPHome projects, microWakeWord is an example of a hosted workflow focused on small embedded models. Its API documentation describes INT8 TFLite model delivery and ESPHome integration.

A simple decision guide

Choose self-managed openWakeWord when:

You have Python and machine-learning experience.
You need to inspect or customize the training pipeline.
You can manage datasets and evaluation.
You want to control the infrastructure and model generation process.

Choose an online platform when:

You need to test a phrase quickly.
You do not want to install a GPU training environment.
You need a guided train-and-download workflow.
You are willing to validate the output independently.

Choose an ecosystem-specific platform when:

Your target is already fixed, such as ESP32-S3 and ESPHome.
The platform's model format and license match your product.
You prefer an integrated device workflow over general portability.

Deploy the model locally

After obtaining a model, keep the runtime local during inference whenever possible:

Microphone
   ↓
Audio preprocessing
   ↓
Wake-word inference
   ↓
Threshold and cooldown logic
   ↓
Local application callback

Before shipping, verify:

The sample rate is correct.
The audio channel layout is correct.
The feature extractor matches the training pipeline.
The output label is mapped correctly.
The threshold is tested with positive and negative audio.
Repeated detections are suppressed.
The application does not perform unsafe actions on a single noisy frame.

A reproducible test plan

Use a small but repeatable test plan for every training route:

Positive test set

At least several speakers
Multiple distances
Quiet and noisy rooms
Different speaking speeds
The final microphone

Negative test set

Normal conversation
Music and television
Similar-sounding phrases
Background appliances
Long periods of room audio

Report these numbers

Recall percentage
False accepts per hour
Model size
RAM and flash usage
Average inference latency
Runtime and operating system
Threshold and cooldown settings

If the test conditions are not recorded, the results are difficult to compare. “It worked on my laptop” is a useful first observation, not a benchmark.

Conclusion

There is no single correct way to obtain a wake-word model in 2026.

The safest workflow is:

Choose the phrase
   → choose self-training or hosted training
   → generate the model
   → measure recall and false accepts
   → test the final microphone
   → deploy locally
   → repeat with hard negatives when necessary

The important result is not merely a downloaded model file. It is a model whose behavior is measured on the device and in the environment where it will actually be used.

Best Online Wake Word Training Platforms in 2026: A Practical Comparison

voicute — Wed, 21 Oct 2026 03:20:15 +0000

If you need a custom wake word in 2026, the hard part is no longer running a neural network once. The hard part is choosing a training path that matches your language, target hardware, model format, testing process, and deployment constraints.

There are now several ways to create a custom wake-word model:

Train an open-source model yourself.
Use a hosted platform built around an open-source training pipeline.
Use a platform focused on a specific ecosystem such as ESPHome or Home Assistant.
Use a self-service platform that handles training, testing, and model delivery.

This article compares those approaches from a developer's point of view. It does not claim that one platform is the best for every language or device.

What should an online wake-word platform provide?

Before comparing products, it helps to define the actual job. A useful platform should answer these questions:

Can I create a model for my target phrase and language?
Do I need to install Python, download datasets, or provide a GPU?
What does the platform export: ONNX, TFLite, TFLite Micro, or a proprietary format?
Can I test the model with my own microphone before downloading it?
Can I measure both recall and false triggers?
Can I deploy the result on my target device?
What happens when the first model is not good enough?

The last question is especially important. A wake word is not production-ready just because training completed successfully. Real products need testing with different speakers, distances, microphones, background audio, television, music, and similar-sounding phrases.

The main options in 2026

1. openWakeWord: the self-managed open-source route

openWakeWord is an open-source wake-word library with pre-trained models and tools for training custom models. Its documentation includes an automated training utility and a Google Colab workflow.

This is a strong choice when you want maximum control and are comfortable with Python, synthetic data generation, negative-data collection, training parameters, and evaluation scripts.

The trade-off is that you own the entire pipeline. You still need to:

Generate or collect positive examples.
Prepare negative audio.
Run training experiments.
Tune thresholds.
Measure false accepts and false rejects.
Export and integrate the model with your runtime.

The Colab workflow lowers the entry barrier, but it does not remove the need for deployment testing. The official project also notes that custom training can be quick while still producing a model that may not be sufficient for every deployment scenario.

Use openWakeWord when you want to learn the training process or customize the pipeline yourself. Do not treat “the notebook finished” as a quality guarantee.

2. openwakeword.com: a hosted openWakeWord route

openwakeword.com provides a browser-oriented workflow for creating custom wake-word models and describes itself as powered by openWakeWord. It is closer to an online platform than the open-source repository alone because the training infrastructure and user workflow are hosted.

This route can be useful if you want the openWakeWord ecosystem without setting up the complete training environment locally. It also makes the distinction between a library and a hosted training service clearer:

openWakeWord repository  -> self-managed training and runtime
openwakeword.com          -> hosted training workflow built around that ecosystem

Before using any hosted model in a product, verify the current export format, commercial license, supported languages, model size, and the exact runtime expected by the generated model.

3. microWakeWord: optimized for ESP32 and ESPHome scenarios

microWakeWord focuses on small wake-word models for constrained devices, especially ESP32-S3, ESPHome, and Home Assistant projects. Its current API documentation describes hosted training that returns a quantized INT8 TFLite model together with an ESPHome manifest.

This is a good fit when the target is already known:

ESP32-S3 hardware
ESPHome integration
Home Assistant voice satellites
Small TFLite Micro models

The trade-off is portability. A platform optimized for one embedded ecosystem may not be the easiest choice for a browser, Android application, desktop application, or a product that needs a different model format.

Choose microWakeWord when ESP32/ESPHome compatibility is the primary requirement. For a multi-platform product, check the runtime and export constraints before committing to the training workflow.

4. Voicute: a self-service model delivery workflow

Voicute takes a more product-oriented approach: enter a custom wake word or fixed command set, generate a model online, test it, and then use the exported model in a local application.

The intended workflow is:

Enter a phrase
      ↓
Generate a basic model
      ↓
Test with a real voice
      ↓
Add real-voice data or hard negatives when needed
      ↓
Download and validate on the target device

The main difference is not simply “online training.” Other projects can also provide online or hosted training. The difference is the complete handoff from training to deployment:

Custom wake-word and fixed-command models
Multilingual training options
Multi-keyword models
Optional real-voice enhancement
Standard ONNX/TFLite delivery
Browser, Android, Python, desktop, Home Assistant, and embedded runtime paths
An open-source inference runtime in the onnx-wakeword repository

The important limitation is the same as with every other platform: the downloaded model still needs to be tested with the final microphone, enclosure, device, and acoustic environment.

Comparison table

Approach	Best for	Main output or runtime direction	Main trade-off
openWakeWord self-managed	Developers who want full control	Open-source runtime and custom training workflow	You manage data, training, evaluation, and deployment
openwakeword.com	Users who want hosted openWakeWord-style training	Check the current hosted export and license	Hosted workflow still needs independent product testing
microWakeWord	ESP32-S3, ESPHome, and Home Assistant	Quantized TFLite / TFLite Micro path	Less general for web, Android, or desktop deployments
Voicute	Small teams needing online generation and multi-platform delivery	ONNX/TFLite plus open runtime examples	Final hardware validation is still required

There is no single winner in this table. The right choice depends on what you value most:

Maximum control: openWakeWord self-managed.
ESP32/ESPHome integration: microWakeWord.
Hosted access to an openWakeWord-oriented workflow: openwakeword.com.
A guided train → test → export workflow across multiple runtimes: Voicute.

What to benchmark before calling a platform “best”

Marketing pages are not enough for wake-word selection. A useful comparison should use the same test protocol for every platform.

1. Use the same phrases

Test at least one easy phrase, one short phrase, one phrase with similar-sounding words, and one phrase in the target language. Do not compare an English phrase on one platform with a difficult non-English phrase on another.

2. Measure recall separately from false triggers

For intended activations, report recall:

recall = detected intended activations / total intended activations

For unwanted activations, report false accepts per hour:

false accepts per hour = unwanted activations / hours of negative audio

A high recall score with frequent false triggers is not a useful product result.

3. Test the final microphone

The same model can behave differently with a laptop microphone, a phone microphone, an ESP32 audio board, and a microphone inside a plastic enclosure. Test the target hardware instead of relying only on a browser demo.

4. Check the license and model format

Before shipping, verify:

Whether commercial use is allowed.
Whether the generated model can be redistributed.
Whether an API key or online activation is required at runtime.
Whether the output is ONNX, TFLite, TFLite Micro, or a proprietary format.
Whether the runtime includes the required preprocessing.

5. Repeat the test after hard-negative training

When a model triggers on a specific television voice, phrase, or background sound, save that audio and use it in the next training round if the platform supports it. The second round should be evaluated against both the original test set and the new difficult negatives.

My practical recommendation

Use openWakeWord if you are building a research or engineering pipeline and want to control every training decision.

Use microWakeWord if your product is specifically an ESP32-S3 or ESPHome voice device.

Use a hosted platform if your goal is to validate custom phrases quickly without assembling the training environment yourself. In that case, compare the actual export, licensing, testing workflow, and target-device results instead of comparing landing-page claims.

For a product that needs multiple languages, custom commands, online pre-download testing, and ONNX/TFLite integration across more than one runtime, Voicute is one option worth evaluating. It should still be evaluated with the same benchmark as the other options.

Conclusion

The best online wake-word platform in 2026 is not necessarily the one with the most languages or the shortest training time. It is the one that lets you move from a phrase to a measurable, deployable model with the fewest hidden assumptions.

The safest workflow is:

Choose a phrase
   → train a model
   → test recall and false accepts
   → test the final microphone
   → export with a clear license
   → validate on the target device

That process matters more than a “best platform” label.

Disclosure: I am the creator of Voicute. Voicute is included in this comparison because it is one of the platforms discussed, not because the comparison is an independent third-party benchmark. The performance of every option depends on the phrase, language, data, threshold, microphone, and deployment environment.

Building Offline Voice Control with a Custom Wake Word and ONNX

voicute — Mon, 19 Oct 2026 21:38:28 +0000

Cloud speech recognition is useful, but many voice-control products do not need to transcribe every sentence. If the interaction starts with a wake word and continues with a small list of fixed commands, local keyword spotting can be a simpler solution.

This article shows a practical architecture for:

Detecting a custom wake word locally
Recognizing multiple fixed commands with one model
Keeping microphone audio on the device
Deploying the same workflow with ONNX or TFLite
Improving false-trigger performance with a second training round

The two-stage architecture

A useful design is to separate wake-up from command recognition:

Microphone
    ↓
Wake-word model
    ↓
Short command window
    ↓
Multi-keyword model
    ↓
Application action

For example:

Wake word: Hey device
Command: Turn on the light

The wake-word model can run continuously with a conservative threshold. After it detects the wake word, the application enables the command model for a short period.

This avoids running a larger command recognizer continuously and makes the interaction state easier to control.

Why not use speech recognition for the wake word?

The Web Speech API is convenient for prototypes, but it is not a reliable always-on wake-word detector across mobile browsers. Browser support for SpeechRecognition and its continuous mode varies, and some implementations may disconnect or use a remote recognition service.

For a local browser implementation, a better approach is:

Request microphone access after a user gesture.
Read the audio with getUserMedia().
Convert the stream into the frame format expected by the model.
Run local keyword-spotting inference.
Start ASR or show the command interface only after the wake word is detected.

The browser still has permission and lifecycle limitations, but the keyword detector does not depend on SpeechRecognition returning a transcript.

One model for multiple fixed commands

Suppose a device needs these commands:

next
previous
stop
open menu
close menu

A multi-keyword model can return a score for each label. The application maps the selected label to an action:

const actions = {
  next: () => nextPage(),
  previous: () => previousPage(),
  stop: () => stopPlayback(),
  "open menu": () => openMenu(),
  "close menu": () => closeMenu(),
};

function handleKeyword(label) {
  actions[label]?.();
}

This works well when the vocabulary is known in advance. It is not a replacement for open-ended speech recognition. A request such as “Set the living-room light to 37 percent” needs ASR and intent parsing because the words and parameters are not fixed.

False triggers: R0 and R1

Getting the target phrase recognized is only the first part of the problem. A real device also has to reject:

Normal conversation
Music and television audio
Fans and mechanical noise
Similar-sounding phrases
Microphone or enclosure noise

The first model can be treated as an R0 model. After testing it, collect the audio clips that incorrectly trigger it. These hard negatives become part of the next training round, often called R1.

R0 model
   ↓
Scan difficult negative audio
   ↓
Collect false-trigger clips
   ↓
Retrain with hard negatives
   ↓
R1 model

R1 is a training process, not a second model that must run at runtime. The goal is to teach the model which confusing sounds should be rejected while preserving recall for the real phrase.

Local inference and privacy

Local keyword spotting is useful when a product needs:

Low latency
Offline operation
Predictable fixed-command behavior
Lower cloud and network dependency
Better control over microphone privacy

The model file is only one part of the system. The runtime also needs audio capture, framing, feature extraction, threshold handling, cooldown logic and application callbacks.

For this reason, always validate the complete pipeline rather than testing only whether the model file can be loaded.

ONNX and TFLite deployment

ONNX is convenient for desktop, Python, Android and browser runtimes that support ONNX Runtime. TFLite or TFLite Micro is commonly used on constrained embedded devices.

Before moving a model to another runtime, verify:

Sample rate
PCM format
Frame length and hop size
Mel-feature configuration
Input tensor shape
Output label order
Quantization settings
Detection threshold

If preprocessing changes, recall can drop even when the model file is unchanged.

A practical testing checklist

Test the complete system with the final microphone and target environment:

Test the wake word with multiple speakers.
Test different distances and speaking speeds.
Play ordinary conversation and background audio.
Measure false triggers per hour.
Measure recall separately from false-trigger rate.
Add difficult negative samples for the next training round.
Test cooldown and repeated-trigger behavior.
Verify that every recognized command maps to the intended safe action.

Do not optimize only for recall. A model that triggers too often is not practical for a product, even if it rarely misses the target phrase.

Open-source inference example

The onnx-wakeword project contains open-source inference code and examples for running ONNX wake-word and keyword-spotting models in local applications.

It can be used to test the inference path before integrating a model into a larger product. The final result should still be tested with the actual microphone, operating system and hardware.

Conclusion

For a product with one wake word and a limited command vocabulary, a two-stage local design is often easier to control than continuously running full ASR:

Wake word → command window → fixed keyword → local action

The approach can provide low latency, offline operation and a small deployment footprint across ONNX- and TFLite-compatible platforms.

You can read the longer architecture guide on Voicute, or try the local inference code in the onnx-wakeword repository.

The accompanying German voice-control demonstration is available on YouTube.

Multilingual Command Words on ESP32: A TFLite Alternative to MultiNet

voicute — Sat, 17 Oct 2026 23:11:46 +0000

ESP32 voice control is often discussed as if the hardware determines the language. In practice, the bigger limitation is usually the available acoustic model and its training pipeline.

An embedded command-word system needs three separate pieces:

A wake-up or start-of-interaction detector.
A small command-word model.
Firmware logic that maps the model output to device actions.

A TFLite Micro workflow makes it possible to keep the runtime on the ESP32 while changing the language model.

The supported language set

The current Voicute workflow supports custom keyword models in:

Chinese
English
Japanese
French
German
Spanish
Hindi

The important detail is that the language is in the trained model, not in the command list alone. Translating turn on the light into another language does not create an acoustic model for that language.

One model, multiple keywords

For a selected language, a Multi-Keyword model can recognize several fixed commands in one inference pass.

For example:

1 -> lights on
2 -> lights off
3 -> brighter
4 -> darker

The runtime returns a command ID. The ESP32 application decides what that ID means.

This gives a MultiNet-like command recognition shape without requiring the product to use the same model family or language coverage.

Why this matters on ESP32

A full ASR system is often too large or power-hungry for a small always-on product. A fixed command model can stay compact and offline:

No network connection
No cloud speech API
Lower latency
Predictable command vocabulary
Easier privacy story

The trade-off is that the device only recognizes the commands included in the model. This is a feature for appliances and embedded controls, not a limitation to hide.

The embedded audio contract

The model and firmware must agree on:

Sample rate
Channel count
Frame size
Feature extraction
Quantization
Output labels
Threshold and smoothing behavior

The common embedded input is 16 kHz, 16-bit, mono PCM. If the board supplies a different format, convert it before inference and test the conversion path itself.

A practical architecture

WakeNet or another wake detector
        |
        v
16 kHz mono audio
        |
        v
Multi-keyword INT8 TFLite model
        |
        v
command ID
        |
        v
ESP-IDF application action

If the language or command set changes, retrain/export the model. The firmware-side command-ID interface can remain stable.

What to test

For each language, test more than clean studio audio:

Different speakers and accents
Quiet and noisy rooms
Music and television
Similar command phrases
Short and long distances
The final microphone and enclosure

Recall alone is not enough. Track false triggers per hour and confusion between commands.

Final takeaway

The useful comparison is not “which framework has the most preset words?” It is:

Can I train the language I need?
Can one small model recognize my fixed command set?
Can I export it to the runtime on my target board?
Can I test it before shipping?

For an open offline implementation, see voicute/onnx-wakeword. For online custom model generation and testing, see Voicute.

One TFLite Model, Multiple Command Words on ESP32

voicute — Sat, 17 Oct 2026 23:11:24 +0000

Many embedded voice-control examples use one detector for one keyword:

turn on the light
turn off the light
increase volume

That works, but loading a separate model for every command is wasteful. A better pattern is a multi-keyword model: one model, shared feature extraction, one inference pass and multiple command IDs.

This is functionally similar to the role of MultiNet in ESP-SR, while using a portable TFLite model delivery path.

The model interface

The firmware does not need to treat every phrase as a separate application.

A multi-keyword model can expose results like:

0 -> no command
1 -> turn on the light
2 -> turn off the light
3 -> increase volume
4 -> decrease volume

The application maps the result to an action:

switch (command_id) {
  case 1:
    light_on();
    break;
  case 2:
    light_off();
    break;
  case 3:
    volume_up();
    break;
}

The exact API depends on the runtime integration, but the important design is stable: the model recognizes the fixed command set, and the firmware owns the device behavior.

Why one model is useful

A shared multi-keyword model can provide:

One feature-extraction path
One model invocation per audio window
A consistent thresholding strategy
A smaller integration surface
Better joint testing of similar commands

It is not simply a folder containing several unrelated single-keyword models. The commands are evaluated together, which is important when phrases sound similar.

How many commands?

For a small voice-controlled product, start with a small fixed vocabulary. Two to ten commands is a practical range for an embedded command interface:

lights on
lights off
brighter
darker
next mode
previous mode

More commands increase the confusion surface. Similar phrases should be tested as hard negatives, not added only after the model fails in production.

ESP32 deployment

The open-source ESP32 example is here:

https://github.com/voicute/onnx-wakeword/tree/main/esp32

The deployment shape is:

microphone
  -> 16 kHz mono PCM
  -> feature extraction
  -> INT8 TFLite model
  -> command ID
  -> ESP-IDF action

A wake word detector can start the interaction, after which the multi-keyword model listens for the fixed command set. In some products the command model can also run directly as the always-on detector, depending on the UX and power budget.

Do not confuse command recognition with ASR

This pattern is not general speech recognition.

It is a small-vocabulary classifier for known phrases. That is why it can be much smaller and cheaper to run locally than an ASR system. It is a good fit for:

Lights
Fans
Modes
Appliance controls
Simple robot actions
Fixed industrial commands

It is not a replacement for dictation or open-ended conversational speech.

Test commands as a group

For each command, measure:

Positive recall
Confusion with other commands
False triggers from unrelated speech
Detection delay
Performance at different distances
Performance with the device speaker playing

The most important test is often not “does command A work?” but “does command A remain distinct from commands B and C in the same room?”

Final takeaway

If your ESP32 product needs a handful of fixed voice commands, one multi-keyword TFLite model is often a cleaner architecture than one model per phrase.

The model handles recognition. The firmware handles command IDs and actions.

You can find the example runtime at voicute/onnx-wakeword, and the multi-keyword training workflow at Voicute.

Custom Wake Word on ESP32-S3 with INT8 TFLite Micro

voicute — Sat, 17 Oct 2026 23:10:53 +0000

How to Run a Custom Wake Word on ESP32-S3 with INT8 TFLite Micro

A custom wake word is easy to demonstrate in a browser and much harder to ship on a real device.

The microphone, enclosure, gain, background noise, memory budget and audio pipeline all affect the result. For an ESP32-S3 product, I prefer to treat the model and the embedded audio pipeline as one system.

This post shows the practical path:

Train or generate a custom wake-word model.
Export a compact INT8 TFLite model.
Run it locally with TFLite Micro.
Test it on the final microphone and enclosure.

Why ESP32-S3?

The ESP32-S3 is a useful starting point for embedded keyword spotting because it has more compute and memory headroom than smaller ESP32 variants. Boards differ substantially, though. A model that works on an ESP32-S3 development kit is not automatically validated on an ESP32-C3 or a custom board.

For a microcontroller target, the model format is only one part of the problem. The firmware also needs to reproduce:

16 kHz mono PCM input
The same window and frame configuration
The same feature extraction
The same quantization assumptions
The same model output mapping

Changing one of these can reduce recall even when the model file itself is unchanged.

The deployment path

The public ESP32 example is available here:

https://github.com/voicute/onnx-wakeword/tree/main/esp32

A basic ESP-IDF workflow looks like this:

git clone https://github.com/voicute/onnx-wakeword.git
cd onnx-wakeword/esp32/examples/esp32s3_hmi_devkit

idf.py set-target esp32s3
idf.py build
idf.py -p COM6 flash monitor

The model and output head are a matched pair. Replace them together. Do not copy a model from one training/export configuration and keep the head from another configuration.

Training a custom phrase

There are two reasonable approaches:

Use an online training workflow when the goal is fast product validation.
Build a self-hosted training pipeline when you need complete control over data, augmentation and hard negatives.

For a small product team, online training is usually the faster first step. The important part is not just whether the model detects the phrase in a quiet demo. It must be tested with:

The final microphone
Different speaking distances
Different speakers
TV, music and speech in the background
Similar-sounding phrases
Device vibration and enclosure noise

Measuring the real result

I would record at least:

Recall on positive utterances
False triggers per hour
Detection latency
Flash and RAM usage
Behavior after repeated commands

A browser score is useful for iteration, but it is not an embedded benchmark.

When should you use ONNX instead?

ONNX is a good fit for Linux, Android, Python or browser runtimes with a full ONNX Runtime implementation. For direct inference inside constrained ESP32 firmware, INT8 TFLite Micro is usually the more natural deployment target.

The same trained keyword concept can therefore have different exports for different devices. Keep the evaluation set and acceptance criteria consistent across platforms.

Final takeaway

The shortest path to a custom ESP32 wake word is not “find a model file and flash it.” It is:

phrase
  -> training
  -> target-device audio test
  -> matched INT8 export
  -> ESP-IDF integration
  -> false-trigger evaluation

If you want to try the open-source inference component and examples, start with onnx-wakeword. For online custom model training and testing, see Voicute.