[APP][Pro] AI Voice Assistant

Apps
, , ,
61

oke here we go, the hardware device seems to be in a “Beam lock released” loop due to a “Home Assistant event ‘esphome.tts_uri’ dropped; client has not subscribed to actions (yet)”

app logging:

2026-08-06T18:32:01.574Z [log] [APIHELPER] - ApiHelper initialized
2026-08-06T18:32:01.662Z [log] [APIHELPER] - API devices connected
2026-08-06T18:32:01.810Z [log] [APP] - AI voice assistant initialized successfully
2026-08-06T18:32:02.430Z [log] [CONVO][MIC] - Settings saved — context cleared, next turn starts fresh
2026-08-06T18:32:26.341Z [log] [CONVO][MIC] - Turn started (wake word / button / flow), listening…
2026-08-06T18:32:26.374Z [log] [CONVO][MIC] - User started speaking (local VAD)
2026-08-06T18:32:28.561Z [log] [CONVO][MIC] - User stopped speaking (local VAD) — mic closed
2026-08-06T18:32:29.489Z [log] [CONVO][STT] - Heard: "Wat voor weer is vandaag?"
2026-08-06T18:32:33.431Z [log] [CONVO][TTS] - Speaking reply (announce)
2026-08-06T18:32:47.704Z [log] [CONVO][END] - Turn complete — conversation closed
2026-08-06T18:32:48.854Z [log] [CONVO][TTS] - Speaking reply (announce)

esp32 logging:

[20:31:08.294][I][respeaker_xvf3800:528]: Version request successful: 1.0.7
[20:31:58.293][W][api.connection:2532]: ai-voice-assistant (192.168.1.107): Reading failed CONNECTION_CLOSED errno=128
[20:31:58.293][W][component:342]: api set Warning flag: waiting for client connection
[20:32:02.470][W][component:365]: api cleared Warning flag
[20:32:02.475][W][api.connection:1751]: 'ai-voice-assistant' using outdated API 1.6, update to 1.14+
[20:32:02.638][W][micro_wake_word:365]: Wake word detection is already running
[20:32:26.032][W][api:437]: Home Assistant event 'esphome.wake_word_detected' dropped; client has not subscribed to actions (yet)
[20:32:26.922][I][esp-idf:000][md_decoder]: D (813246) micro_decoder.decoder_source: Decode finished
[20:32:28.600][I][respeaker_xvf3800:483]: Beam lock released
[20:32:29.509][W][voice_assistant:794]: No text in STT_END event
[20:32:33.458][W][voice_assistant:851]: No text in TTS_START event
[20:32:33.460][W][api:437]: Home Assistant event 'esphome.tts_uri' dropped; client has not subscribed to actions (yet)
[20:32:33.461][I][respeaker_xvf3800:483]: Beam lock released
[20:32:35.469][W][script:081]: Script 'activate_stop_word_once' is already running! (mode: single)
[20:32:35.470][W][api:437]: Home Assistant event 'esphome.tts_uri' dropped; client has not subscribed to actions (yet)
[20:32:35.472][I][respeaker_xvf3800:483]: Beam lock released
[20:32:37.479][W][api:437]: Home Assistant event 'esphome.tts_uri' dropped; client has not subscribed to actions (yet)
[20:32:37.481][I][respeaker_xvf3800:483]: Beam lock released
[20:32:38.465][I][esp-idf:000][md_reader]: E (824790) esp-tls: [sock=58] select() timeout
[20:32:38.467][I][esp-idf:000][md_reader]: E (824790) transport_base: Failed to open a new connection: 32774
[20:32:38.469][I][esp-idf:000][md_reader]: E (824790) HTTP_CLIENT: Connection failed, sock < 0
[20:32:38.470][I][esp-idf:000][md_reader]: E (824790) micro_decoder.http_client: Failed to open URL: ESP_ERR_HTTP_CONNECT
[20:32:38.473][I][esp-idf:000][md_reader]: E (824790) micro_decoder.audio_reader: Failed to connect to URL: http://172.17.0.2/app/no.arvebjoe.ai-voice-assistant/userdata/audio/tx_4cd9574e-4a59-4a96-9ad9-0b91947bd5c8.flac
[20:32:38.474][I][esp-idf:000][md_reader]: E (824791) micro_decoder.decoder_source: Reader failed to open URL
[20:32:39.496][W][script:081]: Script 'activate_stop_word_once' is already running! (mode: single)
[20:32:39.498][W][api:437]: Home Assistant event 'esphome.tts_uri' dropped; client has not subscribed to actions (yet)
[20:32:39.499][I][respeaker_xvf3800:483]: Beam lock released
[20:32:41.532][W][script:081]: Script 'activate_stop_word_once' is already running! (mode: single)
[20:32:41.533][W][api:437]: Home Assistant event 'esphome.tts_uri' dropped; client has not subscribed to actions (yet)
[20:32:41.535][I][respeaker_xvf3800:483]: Beam lock released
[20:32:43.540][W][api:437]: Home Assistant event 'esphome.tts_uri' dropped; client has not subscribed to actions (yet)
[20:32:43.541][I][respeaker_xvf3800:483]: Beam lock released
[20:32:45.610][W][script:081]: Script 'activate_stop_word_once' is already running! (mode: single)
[20:32:45.612][W][api:437]: Home Assistant event 'esphome.tts_uri' dropped; client has not subscribed to actions (yet)
[20:32:45.613][I][respeaker_xvf3800:483]: Beam lock released
[20:32:47.709][W][voice_assistant:877]: No url in TTS_END event
[20:32:47.711][I][respeaker_xvf3800:483]: Beam lock released
[20:32:48.861][W][script:081]: Script 'activate_stop_word_once' is already running! (mode: single)
[20:32:48.862][W][api:437]: Home Assistant event 'esphome.tts_uri' dropped; client has not subscribed to actions (yet)
[20:32:48.864][I][respeaker_xvf3800:483]: Beam lock released
[20:32:50.878][W][script:081]: Script 'activate_stop_word_once' is already running! (mode: single)
[20:32:50.879][W][api:437]: Home Assistant event 'esphome.tts_uri' dropped; client has not subscribed to actions (yet)
[20:32:50.881][I][respeaker_xvf3800:483]: Beam lock released
[20:32:52.951][W][script:081]: Script 'activate_stop_word_once' is already running! (mode: single)
[20:32:52.953][W][api:437]: Home Assistant event 'esphome.tts_uri' dropped; client has not subscribed to actions (yet)
[20:32:52.955][I][respeaker_xvf3800:483]: Beam lock released
[20:32:55.062][W][script:081]: Script 'activate_stop_word_once' is already running! (mode: single)
[20:32:55.064][W][api:437]: Home Assistant event 'esphome.tts_uri' dropped; client has not subscribed to actions (yet)
[20:32:55.065][I][respeaker_xvf3800:483]: Beam lock released
[20:32:57.144][W][script:081]: Script 'activate_stop_word_once' is already running! (mode: single)
[20:32:57.146][W][api:437]: Home Assistant event 'esphome.tts_uri' dropped; client has not subscribed to actions (yet)
[20:32:57.147][I][respeaker_xvf3800:483]: Beam lock released
[20:32:59.242][W][script:081]: Script 'activate_stop_word_once' is already running! (mode: single)

....here be a logging loop.....

[20:35:00.879][I][respeaker_xvf3800:483]: Beam lock released
[20:35:03.016][W][voice_assistant:877]: No url in TTS_END event
[20:35:03.018][I][respeaker_xvf3800:483]: Beam lock released
[20:35:08.297][I][respeaker_xvf3800:528]: Version request successful: 1.0.7

and my esp config is just the example one with a different device name Respeaker-XVF3800-ESPHome-integration/config/respeaker-xvf-satellite-example.yaml at main · formatBCE/Respeaker-XVF3800-ESPHome-integration · GitHub

oke scratch that, this all seems to be related to using a custom pipeline

oke next question
I now have a hook that outputs the text to my sonos device

Scherm­afbeelding 2026-08-06 om 20.57.17
Scherm­afbeelding 2026-08-06 om 20.57.172156×394 37.7 KB

But the default voice to sonos is not very nice, but I can also play a url on sonos, would it be possible to have the output available as a url?

and there seems to be a issue where if you ask something and then want to ask another thing the device doesnt react

[21:09:08.305][I][respeaker_xvf3800:528]: Version request successful: 1.0.7
[21:10:27.091][W][api:437]: Home Assistant event 'esphome.wake_word_detected' dropped; client has not subscribed to actions (yet)
[21:10:27.956][I][esp-idf:000][md_decoder]: D (3094281) micro_decoder.decoder_source: Decode finished
[21:10:30.509][I][respeaker_xvf3800:483]: Beam lock released
[21:10:30.588][W][voice_assistant:794]: No text in STT_END event
[21:10:33.045][W][voice_assistant:851]: No text in TTS_START event
[21:10:33.047][W][api:437]: Home Assistant event 'esphome.tts_uri' dropped; client has not subscribed to actions (yet)
[21:10:33.048][I][respeaker_xvf3800:483]: Beam lock released
[21:10:33.119][I][esp-idf:000][md_reader]: D (3099443) micro_decoder.http_client: Connected: status=200 content-type='audio/x-flac'
[21:10:33.120][I][esp-idf:000][md_reader]: I (3099444) micro_decoder.audio_reader: Streaming http://192.168.1.107/app/no.arvebjoe.ai-voice-assistant/userdata/audio/tx_79e63413-01bf-49a9-9783-ba8bdaf0ac1e.flac (FLAC)
[21:10:33.337][I][esp-idf:000][md_reader]: D (3099662) micro_decoder.audio_reader: HTTP read complete
[21:10:33.339][I][esp-idf:000][md_reader]: D (3099664) micro_decoder.decoder_source: Reader finished
[21:10:40.889][I][esp-idf:000][md_decoder]: D (3107215) micro_decoder.decoder_source: Decode finished
[21:10:40.933][W][voice_assistant:877]: No url in TTS_END event
[21:10:41.036][W][api:437]: Home Assistant event 'esphome.tts_uri' dropped; client has not subscribed to actions (yet)
[21:10:41.038][I][respeaker_xvf3800:483]: Beam lock released
[21:10:41.040][I][respeaker_xvf3800:483]: Beam lock released
[21:10:41.375][I][esp-idf:000][md_reader]: D (3107699) micro_decoder.http_client: Connected: status=200 content-type='audio/x-flac'
[21:10:41.378][I][esp-idf:000][md_reader]: I (3107700) micro_decoder.audio_reader: Streaming http://192.168.1.107/app/no.arvebjoe.ai-voice-assistant/userdata/audio/listening_chime.flac (FLAC)
[21:10:41.380][I][esp-idf:000][md_reader]: D (3107700) micro_decoder.audio_reader: HTTP read complete
[21:10:41.380][I][esp-idf:000][md_reader]: D (3107702) micro_decoder.decoder_source: Reader finished
[21:10:41.530][I][esp-idf:000][md_decoder]: D (3107848) micro_decoder.decoder_source: Decode finished
[21:10:45.550][W][api:437]: Home Assistant event 'esphome.wake_word_detected' dropped; client has not subscribed to actions (yet)
[21:10:47.657][W][api:437]: Home Assistant event 'esphome.wake_word_detected' dropped; client has not subscribed to actions (yet)
[21:10:48.575][I][esp-idf:000][md_decoder]: D (3114900) micro_decoder.decoder_source: Decode finished
[21:10:52.360][W][api:437]: Home Assistant event 'esphome.wake_word_detected' dropped; client has not subscribed to actions (yet)
[21:10:58.678][W][api:437]: Home Assistant event 'esphome.wake_word_detected' dropped; client has not subscribed to actions (yet)
[21:10:59.545][I][esp-idf:000][md_decoder]: D (3125870) micro_decoder.decoder_source: Decode finished
62

I´ve never tested this in HA, so can´t compare. But this app uses an AI large language model, and those are pretty capable out of the box, and you can also ask the AI to do a web search. I´ve had some good results with this so far.

Weather lookup is also implemented, but only for where you Homey is (at home), you can´t ask what the weather is like some other place.

63

You will need some kind of physical hardware, and i recommend the Home Assistant Voice: Preview Edition (PE) or the ThirdReality Voice & Music Assistant. You can read more about them here:

64

Thanks — glad you’re enjoying it!

A “Stop processing” card unfortunately can’t work. “Heard something” fires and the pipeline continues in the same breath, so there’s nothing left to brake; and on the cloud engines the model starts answering when you stop talking, not when the transcript lands — the reply is already on its way. Only the custom pipeline is sequential enough for a gate to even be possible.

But what you’re actually after now exists, from a different angle: the custom pipeline’s LLM backend can be set to None. The turn then stops after speech-to-text — what you said goes out on Heard something, and your Flow decides everything from there, including speaking an answer back with the Say card, which still uses your speech backend. No model in the middle, no processing to stop. Its sibling, TTS backend → None, does the mirror image: the assistant still answers but nothing is spoken, so a Flow can send the reply text to a Sonos or wherever you like.

Fair warning on the None LLM route: follow-up questions and every built-in skill (device control, weather, timers, shopping list, music) go with it — your Flow is the assistant now — plus the Flow round trip on top of the latency you already predicted.

Which is why, given your edit, I’d still point you the other way. Set the LLM backend to OpenAI-compatible and aim it at your bridge: your skill becomes the model, and you keep the LED ring, streaming speech that starts before the full answer exists, follow-ups, and my built-in tools alongside your own — one hop less latency than going through Flow. Both paths work; that one costs you nothing.

Both land in the next test build. Do report back on how the latency feels with a heavy skill behind it.

65

Thank you for the detailed reply. That opens so many possibilities!

Should the app cards be coming one day, I think this app will be the most poweful and versatile Homey AI integration out there! :+1:

66

New test version (v 1.4.10) is now available with the none-LLM and none-TTS implementation.

67

Hi Sre,

Your logs cracked it — thanks. Fixed in 1.4.11, plus the feature you asked for.

Test version:

Reply audio as a URL. Device settings now have a Reply audio dropdown — set it to “Send to a Flow as a URL” and a new trigger card, “Reply audio is ready”, fires with Audio URL, Text and Duration tokens. Feed the URL to your Sonos “Play URL” action and you get the assistant’s own voice instead of the Sonos TTS voice. The link expires after a couple of minutes, so play it immediately, and in this mode a follow-up needs the wake word again (the app can’t know when your Sonos finished speaking). The file is a 48 kHz mono FLAC — if Sonos refuses it, tell me and I’ll switch to WAV.

The Beam lock released loop wasn’t your pipeline. The app was advertising audio URLs on 172.17.0.2, a Docker-internal address your device couldn’t reach — hence the ESP_ERR_HTTP_CONNECT timeouts. The firmware then treats the failed announce as finished, the app queues the next segment, and round it goes. Intermittent because it depended on which network interface came up first at app start. It now takes the address from the connection your device makes to it, so it’s right by construction. Affected every device type, not just yours.

Also fixed: the client has not subscribed to actions spam, and No text in STT_END event (that one was already fixed — your build just predated it).

Still open, and I need you here. Your device going deaf to follow-up wake words I have not solved — detection fires, but the device never asks the app to start a turn. It may clear up as a side effect of the URL fix, since that was leaving it in a retry loop. Please check whether it still happens, and if it does, a DEBUG-level device log covering one good turn plus one ignored wake word would let me pin it down rather than guess.

Handy while testing: Settings → Debug now lists every voice device seen on your network and can record what the microphone actually captured, so you can tell a mic problem from a speech-recognition one. Off by default.

If you get a chance: how does the mic behave with Microphone gain at 0, what name does the device show when pairing, does the mute switch work, and does your unit have an API encryption key?

Thanks again.

69

I just created a PR that fixes two things:

70

Hi Arve,

Same symptom as reported a few days ago in this thread (Beam lock released loop / esphome.tts_uri event not subscribed).

Setup:

  • Device: Home Assistant Voice PE, firmware 26.6.0 (ESPHome 2026.6.0), no encryption configured
  • Homey Pro (Early 2023), app v1.4.11
  • BLE pairing + WiFi provisioning: successful
  • Network: confirmed reachable (port 6053 open, tested via SSH from another host on the same LAN)
  • mDNS discovery: works, Debug tab shows device as “usable voice satellite”, “paired”, probe “accessible”
  • Device tile in Homey: stuck on “Unavailable”
  • Debug tab detail: “Connected: no”

For comparison, I temporarily ran a local Home Assistant Core instance (Docker) and the same device connected and worked correctly via native ESPHome integration — confirms the device itself, WiFi, and network path are fine. The issue appears isolated to the Homey app’s connection/event-subscription handling for this device/firmware combo.

Happy to provide app logs or test a debug build if useful.

Thanks for the great app, looking forward to a fix!

71

v1.4.12 — spoken replies on a Sonos, and the app’s own sounds too

This one is mostly about the Reply audio is ready Flow trigger — the option that hands the assistant’s spoken answer to a Flow as an audio link instead of playing it on the device (device settings → Reply
audio → Send to a Flow as a URL). Handy when your voice device has no speaker, or when there’s simply a better speaker in the room.

What’s new:

  • The audio is now MP3 instead of FLAC, so far more speakers will actually play it — a Sonos in particular.
  • The app’s own sounds come through the same trigger now: a short cue when the device starts listening, plus the error sound, the “no API key” sound and the greeting after pairing. On a device without its
    own speaker those were simply silent before.
  • A new “Is a sound effect” tag on the trigger, so a Flow can tell a spoken reply from a cue — play the cue quietly, or ignore effects entirely with a condition card.
  • Fixed: the audio link could point at an address your speaker couldn’t reach, so nothing played.

Also fixed: on newer ESPHome firmware the volume and mute controls, and playing music on the device, could quietly stop working.

All of the reply-audio work above was written by Stefan Renne (@stefanrenne on GitHub) — a properly thorough pull request, tests and documentation included. Thank you! :folded_hands:

72

Hi Arve,

Following up on my earlier report (Voice PE stuck “Unavailable” despite successful pairing) — after 3+ hours of debugging with the help of Claude AI, we found the root cause.

The bug: In esp-voice-assistant-client.mts, discovery probes intentionally skip SubscribeVoiceAssistantRequest (to avoid stealing the subscription of an already-paired device — the comment in the code explains this well). However, recent firmwares (25.12.4, 26.4.0, 26.6.0 all tested) only reply to VoiceAssistantConfigurationRequest if the client is subscribed. Older firmwares answered without a subscription — which is why pairing works for users on older firmware and silently times out (8s) on recent ones.

How we found it: ran the app locally via homey app run, re-enabled the internal ESP client logger (it’s hardcoded disabled: createLogger('ESP', true)), and the logs showed the exact spot: TCP connect OK → Hello OK → DeviceInfoResponse OK → VoiceAssistantConfigurationRequest sent → total silence → timeout.

Confirmed fix: patching the probe to always subscribe makes pairing succeed instantly. A cleaner fix on your side might be to subscribe temporarily during the probe and unsubscribe right after, or to skip the VA-config check when the device already identified itself via DeviceInfoResponse (projectName already says “Home Assistant Voice PE”).

Happy to test a fix build. Thanks for the great app!

Setup: Voice PE fw 26.4.0, Homey Pro Early 2023, app v1.4.12 (patched from source v1.4.7 on GitHub — note the repo seems behind the store version).

FRANÇAIS

Bonjour Arve,

Suite à mon signalement précédent (Voice PE bloqué “Indisponible” malgré un pairing réussi) — après plus de 3 heures de débogage avec l’aide de Claude AI, nous avons trouvé la cause racine.

Le bug : dans esp-voice-assistant-client.mts, les probes de découverte sautent volontairement SubscribeVoiceAssistantRequest (pour ne pas voler l’abonnement d’un appareil déjà appairé — le commentaire dans le code l’explique bien). Cependant, les firmwares récents (25.12.4, 26.4.0, 26.6.0, tous testés) ne répondent à VoiceAssistantConfigurationRequest que si le client est abonné. Les anciens firmwares répondaient sans abonnement — c’est pourquoi le pairing fonctionne chez les utilisateurs en ancien firmware et expire silencieusement (8s) sur les récents.

Comment on l’a trouvé : appli lancée en local via homey app run, réactivation du logger interne du client ESP (désactivé en dur : createLogger('ESP', true)), et les logs ont montré le point exact : connexion TCP OK → Hello OK → DeviceInfoResponse OK → envoi de VoiceAssistantConfigurationRequest → silence total → timeout.

Correctif confirmé : en patchant le probe pour toujours s’abonner, le pairing réussit instantanément. Un correctif plus propre de votre côté pourrait être de s’abonner temporairement pendant le probe puis se désabonner juste après, ou de sauter la vérification VA-config quand l’appareil s’est déjà identifié via DeviceInfoResponse (le projectName dit déjà “Home Assistant Voice PE”).

Disponible pour tester un build correctif. Merci pour cette super appli !

Config : Voice PE fw 26.4.0, Homey Pro Early 2023, appli v1.4.12 (patchée depuis les sources v1.4.7 sur GitHub — à noter que le dépôt semble en retard sur la version du store).

73

v1.5.0 is live :tada: — it auto-updates, so you are probably on it already.

New

  • Claude (Anthropic) as a language model in the Custom pipeline, with the model picked from a live dropdown.
  • The cloud services for the pipeline’s speech and text stages (OpenAI, Groq, OpenRouter, DeepSeek…) are now a Server dropdown that fills in the address and a working model for you.
  • The Custom pipeline settings are reorganised into one card per stage.

Fixes

  • Adding a device could reboot your satellite. The pairing probe asked for something that crashes ESPHome 2025.8–2026.5, which looked like pairing timing out or a device stuck Unavailable. Fixed and verified on a real Voice PE across three firmwares.
  • An unavailable device now says which side is down — the device or the voice engine — and the Debug page shows the two separately. A missing API key used to look exactly like a network problem.
  • New Verbose logging switch in Settings → Debug, for when you need to send in a log.
  • Wi-Fi setup over Bluetooth notices a dropped link right away; deleting a device no longer crashes; and the Voice PE now trims the wake word off the start of a command by default.

Please re-check your issue :folded_hands: A lot has changed across 1.4.9 → 1.5.0 in just a few weeks, and I think some of you are sitting on something that has quietly been fixed. Update, try it again, and say either way — I would rather hear “still broken” than leave it untested.

If it is still broken: turn on Verbose logging, reproduce it, send a diagnostic report and post the id here, plus which voice engine you use and what Device connected / Engine connected say in Settings → Debug.

74

Thank you, Arve! Now it works. Sorry for the late replay! :slightly_smiling_face:

75

Ho Arve, Can you take a look at this. Set up everthing. No errors but it doesnot work.

87154194-92b4-4345-9a59-b714913be5c8

76

AI Voice Assistant 1.5.2 — Dump log, and a fix for “Heard nothing”

Hi all,

First an apology: I’ve seen the different problems several of you have posted, and I haven’t had the time to look properly at all of them. Sorry about that. Part of the reason is that most of the logs I’ve received couldn’t actually answer the question — Homey’s built-in diagnostics report only carries the last few lines, and they’re rarely the ones that matter. 1.5.2 is mainly about fixing that.

New: Dump log (app Settings → Debug → Dump log)
It writes the app’s recent log — including the detailed satellite connection and voice engine lines that were never in the normal log — to a file on your Homey and shows you a link. Open the link on your phone or computer (same network) and attach the file to your post here, or use Copy log to clipboard. The file starts with a summary of your setup — which satellites you have, their firmware, whether each is connected, and which voice engine you use — so you don’t need to describe any of that.

Privacy: your API keys, everything you said and everything the assistant answered are removed before the file is written. Your local network addresses are kept, because they help you (and me) see which device the app can’t reach. The file is deleted again after 30 minutes.

From now on, when you post a problem, please:

  1. Reproduce it once.
  2. Settings → Debug → Dump log, open the link, and attach the file (or paste it in a spoiler/code block).

That gives me everything I need in one go, and I can actually work through the backlog instead of asking everyone for more details.

Also fixed in 1.5.2
Quiet but clear speech on the ThirdReality satellite could end the turn with “Heard nothing” after about 8 seconds. Fittingly, the Dump log is what found it — the voice detector now picks up softer speech and, when in doubt, sends what it heard to speech recognition instead of giving up.

Thanks for your patience.
Arve

77

AI Voice Assistant 1.5.3 is out — blinds, curtains and awnings by voice, plus a big thank-you

This release is mostly the work of a contributor, so let me start there: a huge thanks to Stefan (stefanrenne on GitHub), who didn’t just ask for window-covering support but built it, tested it on his own hardware, and then went several rounds of code review with me over a week — fixing everything that came up and finding two more bugs along the way. Two pull requests, both merged. This is exactly what makes an open-source Homey app better than one person could manage alone. Thank you, Stefan! :folded_hands:

What’s new in 1.5.3

  • Blinds, curtains and awnings can now be controlled by voice — open, close, stop, or set a position (“open the sunshade halfway”). Yes, the assistant knows an awning is “open” when it’s rolled out.
  • “Nothing here” fallback: if the room you’re in has none of what you asked for, but exactly one other room does, the assistant acts there and tells you which room. (Off switch under Settings → Smart home control, if you’d rather it didn’t.)
  • Faster wake cue when replies are sent to a Flow as a URL (e.g. to a Sonos) — the sound clips are prepared at startup instead of on the first wake.
  • Fix: with the Gemini engine, a short command could be transcribed in the wrong language (Dutch heard as German) even though the spoken reply was right.
  • Fix: tools could occasionally answer from a slightly outdated device list.
  • Fix: a satellite whose speaker never starts playing (seen on the M5Stack AtomS3R) no longer leaves the assistant stuck with the ring lit — the turn ends by itself.

Full details on GitHub as always. If something misbehaves, Settings → Debug → Dump log gives you a file you can attach here or in an issue — it’s the quickest way for me to see what happened.

78

You are more then welcome :slight_smile:
Best regards Stefan

79

v1.5.4 released — fix for “the ring lights up, but nothing ever happens” (OpenAI)

Peter_de_Vos sent in a diagnostics report where the app looked completely dead: wake word worked, the LED ring lit up, but no answer ever came — and the Say flow card lit the ring without playing any sound. No errors anywhere.

The cause turned out to be on the OpenAI side: model access is a per-project setting in the OpenAI dashboard, and a project can be allowed the realtime model while being denied the speech-recognition or text-to-speech models the app also uses. When that happened, the app silently got nothing back — every command hung, and Say played nothing.

With v1.5.4:

  • If your OpenAI project can’t use one of the models, the app automatically falls back to another one, so your command is still answered.
  • You get a Homey notification telling you exactly which model was refused and where to allow it (OpenAI dashboard → your project → Limits → Model usage).
  • The Say card now reports a proper error instead of playing silence.

If your setup has been showing these symptoms, just update — it should start answering immediately, and the notification will tell you what to fix on the OpenAI side for the best quality.

As always: if something misbehaves, the Dump log button under app settings → Debug gives you a full log you can share here.

80

First of all - to the developer of this app … thanks :folded_hands: glad you’re focusing on something that Atom should prioritize.

I’m having problems though … I use ThirdReality and it is installed.

If I switch language to English, it works somewhat great - it can understand what I’m saying, but gives me wrong answers. Like if all lights are on in the living room, it says no lights are on.

But my primary language is danish - and changing language to danish does not work … it misunderstands everything.

I’ve tried setting debug “What did I just say” to on, but it never speaks back - it just times out.

Any idea anybody?

Thanks and keep up the good work :clap::smiley:

81

Hi Mojo.

What AI provider do you use?

And could you send me the log dump? Ask something in Danish → Then click Configure → Debug → Dump log → Open the link in another browser window. Then send the content here or as a PM. That will help me debug what’s going on.

PS: you can also listen to what you said in: Configure → Debug → What did i just say (has to be on) → Click on recoding links below to listen.

PS2: And yes, I’m surprised Atom didn’t include a mic in their new Homey Portal. So I’m looking at an ESP32 solution that has all the stuff the Portal has, plus AI :wink: