This one grew into a much bigger release than the version number suggests. Highlights: a new supported device, two new voice engines (including a fully local one), music control, Wi-Fi setup over Bluetooth, and a long list of stability fixes.
New device: ThirdReality Voice & Music Assistant
Full support as a voice satellite — pairing, wake word, conversations and music playback.
New Flow trigger for the device’s physical button (single, double, triple and long press).
Tuned microphone gain and a connection keepalive so the link stays stable.
New voice engines
Mistral joins OpenAI and Google Gemini as a voice engine — Voxtral realtime speech recognition and Voxtral voices, with full smart-home tool support.
Custom pipeline — run the assistant on your own hardware, with no cloud required. Mix and match each stage:
Speech-to-text: Whisper, Wyoming faster-whisper (the Home Assistant add-on), Mistral Voxtral (including realtime streaming), or any OpenAI-compatible server.
Language model: Ollama, LM Studio, Mistral, or any OpenAI-compatible server (Groq, OpenRouter, DeepSeek, llama.cpp, vLLM…).
Text-to-speech: Piper, Wyoming Piper, Mistral Voxtral, or any OpenAI-compatible server.
The assistant starts speaking sentence-by-sentence while the language model is still writing, and streaming speech recognition means the transcript is ready the moment you stop talking.
Small local models are protected against context-window overflow, with a configurable context size for Ollama.
OpenAI users are automatically migrated off the deprecated gpt-realtime models.
Wi-Fi setup over Bluetooth
Brand-new devices can now be put on your Wi-Fi directly from the pairing wizard in the Homey app, over Bluetooth (Improv BLE). No Home Assistant, ESPHome tooling or USB cable needed — power the device, pair, enter your Wi-Fi credentials, done. Works for both the Voice PE and the ThirdReality.
New assistant abilities (all optional, off by default)
Music — control Music Assistant by voice on both devices: play artists/albums/playlists, pause, volume, “what’s playing?”. Compatible with Music Assistant 2.9.
Shopping list — manage your Bring! shopping list by voice.
Web search — let the assistant look things up on the web (OpenAI or Brave as search provider).
Settings page redesign
Reorganized into sections with a dropdown, one section per feature.
A live token-budget meter shows what each enabled feature costs in prompt tokens — with a per-feature breakdown and toggles, and a green/amber/red verdict against your local model’s context window.
Per-stage Test buttons for the custom pipeline, so you can verify each server befo
Choose the active wake word, and pick voices per TTS backend (Piper voices, Voxtral voice library, or free-text for OpenAI-compatible servers).
Better audio feedback
The device now plays a welcome sound when it connects after pairing, so you know the link works.
If a reply fails mid-conversation (connection drop, service error) you now hear a short error sound instead of silence.
All spoken feedback clips re-recorded to be provider-neutral (they no longer assume you use OpenAI).
Flows & diagnostics
New Flow triggers “Heard something” (with the transcript) and “Thinking” — han flows around the assistant.
Optional remote logging to your own syslog collector (e.g. VictoriaLogs) for troubleshooting.
Reliability
Two full external code reviews were done on the app, with dozens of fixes landing in this release. The most noticeable ones:
The assistant now recovers automatically if the connection dies right as you wake it.
Speech recognition accuracy improved (dedicated transcription model), and replies are anchored to what was actually transcribed — fewer answers to a mis-heard question.
Fixed very short replies being dropped, reply audio playing out of order, reconnect stseveral rare crashes.
All outbound network calls (weather, geocoding, etc.) now have timeouts, and settings saves are transactional.
As always: feedback, bug reports and feature ideas are very welcome!
Hi, thanks for the app! I wanted to explain something I ran into and ask whether a change might be possible.
I have a ThirdReality Voice & Music speaker — an ESPHome-based device with the native API on port 6053. When I add it through your AI Voice Assistant app and choose “Find it on my network,” the scan runs and then ends with “Timeout after 30000ms” — it never finds the speaker.
After a lot of digging, the cause turned out to be discovery, not the device itself. My Homey Pro is on Wi-Fi only, and the speaker’s mDNS multicast isn’t reaching it — other clients on my network can see the device’s _esphomelib._tcp advertisement fine, but Homey doesn’t receive it. So the app’s network scan finds nothing, even though the speaker is fully reachable. As proof, I was able to add the exact same speaker without any issue in the ESPHome Controller app by simply typing in its IP address — it connected instantly over a direct connection, no discovery involved.
So my question is really whether it would be possible to add an option to enter the device’s IP address manually (with port, and an encryption key if needed), as a fallback for when mDNS discovery doesn’t work. That would let people on Wi-Fi-only Homeys, or on networks where multicast doesn’t propagate well, still add these speakers.
Totally understand if it’s not straightforward — just wanted to flag what’s happening and ask. Happy to help test on my end. Thanks!
Hi Bruno. Thank you for the feedback, adding a device by manually typing in the IP is a good idea. Will look into it A question, do you use encryption on your device? My app doesn’t support that yet.
Could you make versions of the „output as text“, timer and related cards, that can be used via / selected from the app without adressing a specific device?
This would come in handy for more global AI tasks not involving a specific output device.
This update is all about making back-and-forth conversations feel natural.
What’s new:
A “ready” chime — the assistant now plays a short chime every time it’s ready for your follow-up. No more guessing when to speak.
~2 seconds faster follow-ups — after the assistant asks you something, the microphone now opens almost immediately instead of after a long pause.
No more dropped conversations — fixed a bug where the assistant would decide you weren’t going to answer before you even had the chance to open your mouth. Multi-turn conversations (quizzes, follow-up questions) now flow reliably.
Accent fix — non-English voices no longer speak with an English accent (rolled back to an earlier OpenAI voice model while OpenAI fixes this upstream).
Safer lock control — unlocking locks by voice is now off by default. If you want it, enable “Allow unlocking by voice” in the app settings. Locking by voice still works as before.
Plus a handful of stability fixes under the hood (pairing, transcription glitches on silent turns).
As always — feedback welcome, especially on how the new conversation flow feels on your devices!
Good idea! A device-less “ask the AI, get text back” flow card is coming — it’ll use whichever engine you’ve configured and can still control your Homey devices, check weather, search the web etc., no speaker hardware needed.
Timers I’ll keep on the devices: their whole point is the LED-ring countdown and the chime on the satellite in your room. For device-less timing, Homey’s built-in flow delays and timer apps already cover it — and you can combine those with the new text card.
I am looking for a voice assistant to match up with Homey, but previously when I was running HA, with the HA Voice Preview box, it had a hard time actually knowing when I stopped talking and it mistook the TV for me speaking as well.
Compared to Alexa, it was so frustrating to use.
How is this currently and with this integration? I seem to have misplaced my HA Voice Preview thing, so I should be ordering a new one to use it.
End-of-speech detection is much better here, at least with the cloud engines (OpenAI is the default). HA decides “are they done talking” with a simple loudness threshold — OpenAI does it with an actual speech model plus noise reduction, and the app makes sure its own reply audio can’t cut your follow-up short. Day to day it feels a lot closer to Alexa.
The TV: it’s much less likely to confuse the assistant while it’s listening, but nothing can tell your voice apart from clear TV dialogue when the mic is open — Alexa has that problem too. And the wake word runs on the device firmware itself, so if the TV was falsely waking it, that’s the same on any platform.
That said, I just added tuning settings for exactly this: you can raise the speech detection sensitivity if the TV keeps triggering it, and change how long a pause ends your turn if it cuts you off. Defaults work fine for most rooms.
So yes, order the new PE — it pairs straight to Homey, no HA needed. Just skip the local/self-hosted pipeline if speech detection was your pain point; it uses a simpler detector, the cloud engines are the ones that fix your complaint.
this app is looking promising, I have recently ordered a respeaker with a asp32s3 and I asked AI to create a flash guide for me. I will get back when I get the device
The guide:
ReSpeaker XVF3800 + XIAO ESP32S3 — flash guide
(for use with arvebjoe/no.arvebjoe.ai-voice-assistant)
Two separate chips need firmware: the XVF3800 (the audio DSP — 4-mic
array, AEC/beamforming) and the XIAO ESP32-S3 (the microcontroller that
runs ESPHome and talks WiFi). Two different USB-C ports, two different
tools, don’t mix them up.
Before you start
The board has two USB-C ports: one on the XMOS/XVF3800 side (near the
3.5mm jack) and one on the XIAO ESP32S3 side. Phase 1 below uses the
XMOS port, Phase 2 uses the XIAO port.
When downloading .bin files from GitHub, use “Download ZIP” or git clone — Seeed’s own docs warn that right-click → “Save As” on the
GitHub file page corrupts the binary.
Source project status: formatBCE/Respeaker-XVF3800-ESPHome-integration
is explicitly marked by its maintainer as “under development, use on
your own risk” (72 stars, actively used, but not a finished 1.0).
Known limitations from the maintainer’s own README: no physical buttons
(so no way to stop a timer or start listening manually except by
voice), no hardware volume control, LED is I2C-only.
Phase 1 — Flash the XVF3800 (the DSP chip itself)
This step matters even though you’re using the board with the XIAO, not
over USB: the XVF3800 ships in USB mode by default, but the XIAO
needs it in I2S mode — specifically the community “I2S master” build
that works around a real limitation (stock ESPHome can’t generate the
12.288MHz MCLK the chip normally needs, so this firmware makes the
XVF3800 generate its own clock instead).
Install dfu-util:
Windows: download from dfu-util.sourceforge.net, extract, add to your PATH. If dfu-util -l shows a LIBUSB_ERROR_NOT_SUPPORTED error, install the WinUSB driver via Zadig (Options → List All Devices → select “reSpeaker XVF3800 4-Mic Array” → Install WinUSB).
Connect the board via the XMOS USB-C port (near the 3.5mm jack).
Verify it’s detected:
dfu-util -l
You should see two Found DFU: lines (reSpeaker DFU Upgrade / reSpeaker DFU Factory).
Flash it:
dfu-util -R -e -a 1 -D application_xvf3800_inthost-lr48-sqr-i2c-v1.0.7-release.bin
(prefix with sudo on Linux). -R reboots the board automatically
when done.
If anything goes wrong and the board stops responding: power off,
hold the Mute button, power back on while still holding it — the
red LED blinks to confirm you’re in Safe Mode, which accepts a
re-flash over USB DFU regardless of what’s currently on it. This is
your recovery path, so it’s hard to truly brick this board.
Phase 2 — Compile and flash the ESPHome firmware onto the XIAO ESP32-S3
Seeed’s own tutorial does this through Home Assistant’s ESPHome add-on —
skip that entirely, you don’t have HA. The standalone ESPHome CLI does
the same compile step without it.
Install the ESPHome CLI on your own computer (not the Homey — this is a one-time build step):
Check the api: block in the YAML for an encryption: key: line —
with arvebjoe/no.arvebjoe.ai-voice-assistant this is a genuine choice
either way, unlike a plain unencrypted setup: that app supports both
plaintext and Noise-encrypted connections. Leave it out for the
simplest first flash; add a 32-byte base64 key later if you want
encryption; either way you’ll paste the same key into the app’s
pairing wizard (API encryption key field) when adding the device.
Set the device name/hostname somewhere near the top of the YAML to
something per-room (e.g. woonkamer-satellite) — this becomes both
its mDNS name and what shows up during Homey pairing before you
rename it.
Compile and flash in one step, over USB, connected via the XIAO’s
own USB-C port this time (not the XMOS one from Phase 1):
esphome run woonkamer-satellite.yaml
First compile pulls in formatBCE’s custom respeaker_xvf3800 and aic3104 components automatically via git (that’s what the external_components: block with type: git in the YAML does) —
expect the first run to take a few minutes longer than a normal
ESPHome build.
Once it boots and joins WiFi, confirm it’s advertising correctly:
avahi-browse -r _esphomelib._tcp # Linux/macOS
You should see it listed with its hostname and port 6053.
Full YAML walkthrough (what each block does) if you want to understand
or tweak it before flashing: Seeed’s annotated guide.
Phase 3 — Install the Homey app and pair the device
arvebjoe/no.arvebjoe.ai-voice-assistant isn’t (yet) on the Homey App
Store, so you install it from source via the Homey CLI:
homey app install (or homey app run --remote if you want to watch
its logs live while pairing — genuinely useful for the first attempt)
In the Homey app, add a device and pick Home Assistant Voice
Preview Edition — of the three built-in drivers (Voice PE, XiaoZhi
AI, ThirdReality) that’s the one built for stock/generic ESPHome
firmware, the closest match for this custom board.
Pairing runs the same mDNS scan as before — the satellite should show
up by its hostname. If you set an encryption key in Phase 2, it’ll be
listed marked “needs encryption key”; select it and paste the key
into the manual-entry form that opens.
If you want full spoken AI replies (not just command recognition),
the board’s speaker output needs to work over ESPHome too — the aic3104 component in formatBCE’s config is a full audio codec
(input and output), which should cover this, but unlike the mic
capture path, I haven’t specifically verified the speaker/media_player
side against this app’s playback mechanism (it serves replies as a
FLAC file over LAN HTTP for the device to fetch and play).
If pairing doesn’t find it
Re-run avahi-browse — if it’s not there, the ESPHome firmware side
hasn’t come up correctly (check the device’s logs via esphome logs woonkamer-satellite.yaml over USB or WiFi).
If it’s advertising but the scan in Homey times out anyway, that’s
usually mDNS/multicast not reaching a Wi-Fi-only Homey Pro — the app’s
pairing wizard has an “Enter IP address manually” option specifically
for this, per its own README.
If it shows up marked “needs encryption key” but you flashed the
YAML without one, the device has a key set anyway — check the actual api: block in what got flashed (e.g. leftover from an old config, or
a typo where you meant to leave it out).
Nice timing, your post sent me down a rabbit hole. I read through formatBCE’s ESPHome config for that board end to end, and it’s a good fit: essentially a port of the Voice PE’s own YAML, same media player, same FLAC announcement pipeline, on-device wake words, timers. I’ll adapt the app to work with the ReSpeaker, but nothing in that config worries me, so it should work.
Your guide looks solid, the I2S-master reasoning in Phase 1 is exactly right. One thing to change in Phase 3 though: don’t pick the Voice PE driver. The app identifies the model during the handshake and each driver only accepts its own, so the PE driver would find your board and then silently reject it (manual IP too). That’s the bit I need to add.
A warning for your renaming step: I’ll match the board on respeaker / xvf3800 in its name or friendly name, so keep one of those tokens, woonkamer-respeaker rather than woonkamer-satellite.
On your open question about the speaker: should be fine. That config’s media player is a speaker_source with a FLAC announcement pipeline, which is exactly what the app serves it, same mechanism as the Voice PE.
Smaller things: no esp32_improv in that config, so skip any Bluetooth setup and use “Find it on my network” or manual IP. No buttons, so the button pressed flow card won’t fire, say “stop” to interrupt a reply. And leave Microphone gain at 0; the XMOS chip already handles gain and echo cancellation.
I don’t have the hardware, so this is all from reading the config, mic levels and wake-word trimming are what’ll most likely need tuning. Do report back when it arrives. If you can run homey app run --remote during your first pairing attempt and paste the log, that’d tell me almost everything.
This release fixes something important I caught during release testing: in rare cases, when the assistant was listening and you said nothing, the speech-to-text could hallucinate a command out of the silence, and the assistant would act on it. During testing it actually switched off a light in a completely silent room. That class of bug is now fixed: transcripts from silent listening windows are
discarded, listening ends after 10 seconds of silence, and a soft descending chime (the mirror of the “speak now” chime) tells you the microphone has closed.
Also in this release:
New experimental device: Seeed ReSpeaker XVF3800, written from the community ESPHome config; I don’t have the hardware myself, so reports are very welcome!
New advanced settings: per-device microphone gain, and speech-detection (VAD) tuning for the OpenAI engine
Gemini engine: the LED ring now shows the listening phase correctly, and Gemini’s response latency is impressively quick
Dependency/security updates
As always: feedback, bug reports and device requests are appreciated.
Awesome thanks for your response! The device is on backorder and is expected to be delivered around 20th of August.
I have two additional requests:
I have my custom pipeline containers behind a reverse proxy (swag) but the input field only supports entering ip addresses and not https urls, could that be supported?
I was thinking on using the respeaker purely as voice input device and use the say card in the homey sonos app for tts / voice output, would it be possible to add a when card for voice output and have it trigger without a tts container
AI Voice Assistant v1.4.6 — submitted for full release
Hi everyone,
I’ve just submitted version 1.4.6 to the App Store, and with this one I’m going for full release — the app is leaving test status.
What’s new in 1.4.6:
Fix: after a brief internet outage, the “Ask assistant. Output as text” flow card could keep failing until the app was restarted. The assistant now recovers fully on its own once the connection comes
back. Voice conversations were not affected.
Minor cleanup of the app’s error logging.
Behind the scenes this release closes a long verification round: every backend of the Custom pipeline (Whisper, Wyoming, Piper, Ollama, LM Studio, Mistral, and any OpenAI-compatible server) has now been
tested end-to-end — full spoken turns on real hardware, recovery from internet drops, and pairing for all supported devices, including encrypted (Noise) ones.
Note from the submission: “Your app is currently under review. This process may take up to two weeks.” — so please be patient, I’ll post here as soon as it’s live.
As always — feedback, bug reports and ideas are very welcome here.
New device: ThirdReality Voice & Music Assistant
New voice engines
Wi-Fi setup over Bluetooth
New assistant abilities (all optional, off by default)
Settings page redesign
Better audio feedback
Flows & diagnostics
Reliability
A question, do you use encryption on your device? My app doesn’t support that yet.
A “ready” chime — the assistant now plays a short chime every time it’s ready for your follow-up. No more guessing when to speak.
~2 seconds faster follow-ups — after the assistant asks you something, the microphone now opens almost immediately instead of after a long pause.
No more dropped conversations — fixed a bug where the assistant would decide you weren’t going to answer before you even had the chance to open your mouth. Multi-turn conversations (quizzes, follow-up questions) now flow reliably.
Safer lock control — unlocking locks by voice is now off by default. If you want it, enable “Allow unlocking by voice” in the app settings. Locking by voice still works as before.
