home-assistant
2024.10 breaks VOIP integration
The problem
I’ve been using VOIP to speak to my Home Assistant via a Grandstream Handytone HT801 box and a cordless phone, as on the page World's most private voice assistant - Home Assistant.
This worked fine up to and including 2024.9.3. I’ve now found that installing 2024.10.1 or 10.2 breaks it, even if I don’t apply the repair which is recommended because binary_sensor.192_xx_xx_xx_call_in_progress is now deprecated. The message about this says the call will work until 2025.4.
After updating to any Home Assistant version from 2024.10.1 I hear the two tone notification (to indicate “call in progress”?) when I press the phone button. However, speaking into the phone doesn’t then give any response - the tone just repeats every few seconds until I hang up. The only way I’ve found to fix the problem is to revert to my backup of 2024.9.3, which means I’m effectively stuck on that version.
I would have included a log extract for VOIP here but can’t find a log.
I’m running HAOS on an Intel NUC and have reverted back to Core 2024.9.3, Supervisor 2024.10.0, Operating System 13.1, Frontend 20240909.1.
Any idea what's going wrong? Thanks.
What version of Home Assistant Core has the issue?
2024.10.2
What was the last working version of Home Assistant Core?
2024.9.3
What type of installation are you running?
Home Assistant OS
Integration causing the issue
VOIP
Link to integration documentation on our website
https://www.home-assistant.io/voice_control/worlds-most-private-voice-assistant
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
Hey there @balloob, @synesthesiam, mind taking a look at this issue as it has been labeled with an integration (voip) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of voip can trigger bot actions by commenting:
@home-assistant closeCloses the issue.@home-assistant rename Awesome new titleRenames the issue.@home-assistant reopenReopen the issue.@home-assistant unassign voipRemoves the current integration label and assignees on the issue, add the integration domain after the command.@home-assistant add-label needs-more-informationAdd a label (needs-more-information, problem in dependency, problem in custom component) to the issue.@home-assistant remove-label needs-more-informationRemove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.
(message by CodeOwnersMention)
voip documentation voip source (message by IssueLinks)
![home-assistant[bot] avatar](https://avatars.githubusercontent.com/in/97978?v=4 "Published by a pub.dev verified publisher"){kind=small}
Same for me.
The phone does seem to listen, and commands are executed, but no beeps/feedback.
After a restart of home-assistant it will work once, subsequent calls don't work anymore.
I got the following related entries:
Logger: homeassistant.components.voip.assist_satellite
Bron: components/voip/assist_satellite.py:242
integratie: Voice over IP (documentatie, problemen)
Eerst voorgekomen: 13 oktober 2024 om 22:02:46 (4 gebeurtenissen)
Laatst gelogd: 15:55:00
PipelineEvent(type=<PipelineEventType.ERROR: 'error'>, data={'code': 'stt-no-text-recognized', 'message': 'No text recognized'}, timestamp='2024-10-13T20:02:46.801795+00:00')
PipelineEvent(type=<PipelineEventType.ERROR: 'error'>, data={'code': 'stt-no-text-recognized', 'message': 'No text recognized'}, timestamp='2024-10-13T20:02:52.555435+00:00')
PipelineEvent(type=<PipelineEventType.ERROR: 'error'>, data={'code': 'stt-no-text-recognized', 'message': 'No text recognized'}, timestamp='2024-10-13T20:04:09.823681+00:00')
PipelineEvent(type=<PipelineEventType.ERROR: 'error'>, data={'code': 'stt-no-text-recognized', 'message': 'No text recognized'}, timestamp='2024-10-14T13:55:00.110173+00:00')\
\
Logger: homeassistant
Bron: /usr/src/homeassistant/homeassistant/runner.py:147
Eerst voorgekomen: 07:15:00 (2 gebeurtenissen)
Laatst gelogd: 14:23:18
Error doing job: Exception in callback None() (None)
Traceback (most recent call last):
File "/usr/local/lib/python3.12/asyncio/events.py", line 88, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.12/asyncio/selector_events.py", line 1238, in _read_ready
self._protocol.datagram_received(data, addr)
File "/usr/local/lib/python3.12/site-packages/voip_utils/voip.py", line 193, in datagram_received
raise err
File "/usr/local/lib/python3.12/site-packages/voip_utils/voip.py", line 183, in datagram_received
audio_bytes = self._rtp_input.process_packet(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/voip_utils/rtp_audio.py", line 61, in process_packet
raise RtpError(
voip_utils.error.RtpError: Expected payload type 107, got 101
Same issue here.
I have a Grandstream HT802 setup according to The World's Most Private Voice Assistant. After a recent update, the phone began to behave as described in the OP. It plays the "listening" two tone chime, If you speak, it just plays the same chime again and again. If you don't speak, you get the "Doh" error noise, then the "listening" chime again.
I checked the whisper logs, and it is receiving the text from the phone and then throwing an error.
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
INFO:faster_whisper:Processing audio with duration 00:06.080
INFO:wyoming_faster_whisper.handler: Turn off the lights in the living room.
ERROR:asyncio:Task exception was never retrieved
future: <Task finished name='wyoming event handler' coro=<AsyncEventHandler.run() done, defined at /usr/local/lib/python3.9/dist-packages/wyoming/server.py:31> exception=ConnectionResetError('Connection lost')>
Traceback (most recent call last):
File "/usr/local/lib/python3.9/dist-packages/wyoming/server.py", line 41, in run
if not (await self.handle_event(event)):
File "/usr/local/lib/python3.9/dist-packages/wyoming_faster_whisper/handler.py", line 79, in handle_event
await self.write_event(Transcript(text=text).event())
File "/usr/local/lib/python3.9/dist-packages/wyoming/server.py", line 29, in write_event
await async_write_event(event, self.writer)
File "/usr/local/lib/python3.9/dist-packages/wyoming/event.py", line 131, in async_write_event
await writer.drain()
File "/usr/lib/python3.9/asyncio/streams.py", line 387, in drain
await self._protocol._drain_helper()
File "/usr/lib/python3.9/asyncio/streams.py", line 190, in _drain_helper
raise ConnectionResetError('Connection lost')
ConnectionResetError: Connection lost
INFO:faster_whisper:Processing audio with duration 00:05.320
INFO:wyoming_faster_whisper.handler: Turn off the lights in the living room.
ERROR:asyncio:Task exception was never retrieved
future: <Task finished name='wyoming event handler' coro=<AsyncEventHandler.run() done, defined at /usr/local/lib/python3.9/dist-packages/wyoming/server.py:31> exception=ConnectionResetError('Connection lost')>
Traceback (most recent call last):
File "/usr/local/lib/python3.9/dist-packages/wyoming/server.py", line 41, in run
if not (await self.handle_event(event)):
File "/usr/local/lib/python3.9/dist-packages/wyoming_faster_whisper/handler.py", line 79, in handle_event
await self.write_event(Transcript(text=text).event())
File "/usr/local/lib/python3.9/dist-packages/wyoming/server.py", line 29, in write_event
await async_write_event(event, self.writer)
File "/usr/local/lib/python3.9/dist-packages/wyoming/event.py", line 131, in async_write_event
await writer.drain()
File "/usr/lib/python3.9/asyncio/streams.py", line 387, in drain
await self._protocol._drain_helper()
File "/usr/lib/python3.9/asyncio/streams.py", line 190, in _drain_helper
raise ConnectionResetError('Connection lost')
ConnectionResetError: Connection lost
INFO:faster_whisper:Processing audio with duration 00:02.790
INFO:wyoming_faster_whisper.handler:
INFO:faster_whisper:Processing audio with duration 00:05.190
INFO:wyoming_faster_whisper.handler:
INFO:faster_whisper:Processing audio with duration 00:05.060
INFO:wyoming_faster_whisper.handler: Turn off the lights in the living room.
ERROR:asyncio:Task exception was never retrieved
future: <Task finished name='wyoming event handler' coro=<AsyncEventHandler.run() done, defined at /usr/local/lib/python3.9/dist-packages/wyoming/server.py:31> exception=ConnectionResetError('Connection lost')>
Traceback (most recent call last):
File "/usr/local/lib/python3.9/dist-packages/wyoming/server.py", line 41, in run
if not (await self.handle_event(event)):
File "/usr/local/lib/python3.9/dist-packages/wyoming_faster_whisper/handler.py", line 79, in handle_event
await self.write_event(Transcript(text=text).event())
File "/usr/local/lib/python3.9/dist-packages/wyoming/server.py", line 29, in write_event
await async_write_event(event, self.writer)
File "/usr/local/lib/python3.9/dist-packages/wyoming/event.py", line 131, in async_write_event
await writer.drain()
File "/usr/lib/python3.9/asyncio/streams.py", line 387, in drain
await self._protocol._drain_helper()
File "/usr/lib/python3.9/asyncio/streams.py", line 190, in _drain_helper
raise ConnectionResetError('Connection lost')
ConnectionResetError: Connection lost
Same exact issue as OP here. tried with latest CORE 2024.11.0. VOIP is broken with assist. Looking at the "debug" from the assist pipeline :
STT always works fine, it seems it always get stuck at the "Natural Language Processing" part. It's not a Assist issue as when I use my smartphone or the browser the pipeline works well. Any idea ?
As expected (as I haven't read of a fix), this issue still exists for me in 2024.11.0. I tried voice access both via the Grandstream box and the Home Assistant Android app. The former failed in the same way as it did previously but the latter still worked, which would seem to narrow it down to the VoIP module (which I don't think the app uses).
We're told that "VoIP in progress binary sensors are deprecated" but that this should work until 2025.4. We're also told "Migrate your configuration to use the corresponding assist_satellite entry" but this doesn't help those of us who are not technically adept enough to know how to do that.
Thanks.
I have used this integration for my poject at the university. (It is about AI and voice control in a smart home environment) And next week I have to submit my work, but I will not be able to demonstrate this at the evaluation. I was hoping to get a fix in the 2024.11.x release as the previous one broke this functionality and this is a major bug for me.
Also observing the issue
Have these versions running:
Core 2024.11.2 Supervisor 2024.11.3 Operating System 13.2 Frontend 20241106.2
The Whisper logs have the same content as above:
INFO:faster_whisper:Processing audio with duration 00:04.690
INFO:wyoming_faster_whisper.handler: Licht draußen aus.
ERROR:asyncio:Task exception was never retrieved
future: <Task finished name='wyoming event handler' coro=<AsyncEventHandler.run() done, defined at /usr/local/lib/python3.9/dist-packages/wyoming/server.py:31> exception=ConnectionResetError('Connection lost')>
Traceback (most recent call last):
File "/usr/local/lib/python3.9/dist-packages/wyoming/server.py", line 41, in run
if not (await self.handle_event(event)):
File "/usr/local/lib/python3.9/dist-packages/wyoming_faster_whisper/handler.py", line 79, in handle_event
await self.write_event(Transcript(text=text).event())
File "/usr/local/lib/python3.9/dist-packages/wyoming/server.py", line 29, in write_event
await async_write_event(event, self.writer)
File "/usr/local/lib/python3.9/dist-packages/wyoming/event.py", line 131, in async_write_event
await writer.drain()
File "/usr/lib/python3.9/asyncio/streams.py", line 387, in drain
await self._protocol._drain_helper()
File "/usr/lib/python3.9/asyncio/streams.py", line 190, in _drain_helper
raise ConnectionResetError('Connection lost')
ConnectionResetError: Connection lost
It seems to only affect the VOIP satellites with the Grandstream based setup as in the tutorial.
I also found these logs via "Settings / System / Protocols", I guess these are related due to the filename components/voip/assist_satellite:
Logger: homeassistant.components.voip.assist_satellite
Quelle: components/voip/assist_satellite.py:240
Integration: Voice over IP (Dokumentation, Probleme)
Erstmals aufgetreten: 13:20:40 (8 Vorkommnisse)
Zuletzt protokolliert: 13:35:39
PipelineEvent(type=<PipelineEventType.ERROR: 'error'>, data={'code': 'stt-stream-failed', 'message': 'speech-to-text failed'}, timestamp='2024-11-16T12:31:39.207714+00:00')
PipelineEvent(type=<PipelineEventType.ERROR: 'error'>, data={'code': 'stt-stream-failed', 'message': 'speech-to-text failed'}, timestamp='2024-11-16T12:33:00.212168+00:00')
PipelineEvent(type=<PipelineEventType.ERROR: 'error'>, data={'code': 'stt-stream-failed', 'message': 'speech-to-text failed'}, timestamp='2024-11-16T12:33:25.177220+00:00')
PipelineEvent(type=<PipelineEventType.ERROR: 'error'>, data={'code': 'stt-stream-failed', 'message': 'speech-to-text failed'}, timestamp='2024-11-16T12:33:38.909185+00:00')
PipelineEvent(type=<PipelineEventType.ERROR: 'error'>, data={'code': 'stt-stream-failed', 'message': 'speech-to-text failed'}, timestamp='2024-11-16T12:35:39.409005+00:00')
The last bit which I found is an entry related to Whisper:
Logger: homeassistant.components.wyoming.stt
Quelle: components/wyoming/stt.py:106
Integration: Wyoming Protocol (Dokumentation, Probleme)
Erstmals aufgetreten: 13:20:40 (8 Vorkommnisse)
Zuletzt protokolliert: 13:35:39
Error processing audio stream
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/voip/assist_satellite.py", line 179, in stt_stream
chunk = await self._audio_queue.get()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/asyncio/queues.py", line 158, in get
await getter
asyncio.exceptions.CancelledError
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/wyoming/stt.py", line 106, in async_process_audio_stream
async for audio_bytes in stream:
File "/usr/src/homeassistant/homeassistant/components/assist_pipeline/pipeline.py", line 953, in _speech_to_text_stream
async for chunk in audio_stream:
File "/usr/src/homeassistant/homeassistant/components/assist_pipeline/pipeline.py", line 1235, in process_enhance_audio
async for dirty_samples in audio_stream:
File "/usr/src/homeassistant/homeassistant/components/voip/assist_satellite.py", line 178, in stt_stream
async with asyncio.timeout(self._audio_chunk_timeout):
File "/usr/local/lib/python3.12/asyncio/timeouts.py", line 115, in __aexit__
raise TimeoutError from exc_val
TimeoutError
If your responses are being processed, it means that STT (Whisper/HA Cloud) is working fine. If responses are not playing, it means that this stage is failing. VoIP indicates what format the TTS audio needs to be, and I wonder if a mismatch there can cause a response failed to play.
For each person reporting the issue, we need to know:
- Do you have the grandstream connected directly to Home Assistant, as per our tutorial.
- What TTS systems are you using?
Okay, so my user experience after a reboot: I dial up HA and it picks up the phone. I can however only hear the "listening" chime constantly repeating. In subsequent calls I can hear nothing.
From this symptom I suspect, that something fails even before the STT component. As far as I know he STT would get the entire recording and transcribe it. I think it has something to do with the end of speech detection, because the chimes are so close to eachother.
My setup (It is quite different from the description): I'm using asterisk (astlinux) as a PBX and making the calls from my cisco SPA5XX series phones. They definitely don't use the same codec as HA. HA only supports the OPUS codec and IP phones support a-law, u-law. I used my asterisk to convert between these formats (so no direct call can be made from these phones and the voip integration can only see the IP of asterisk). The main point is, that it worked for more than a year now. And I can still hear the chimes trough the phone, so I guess the codec conversion works just fine. For stt and tts I'm using the built-in piper and whisper in HA.
One thing is sure: the AI receives nothing from the transcription. In fact it receives no requests from HA so the pipeline fails before the API call.
My setup is based on the tutorial with the grandstream being configured so that it does the direct IP dialing as described in the tutorial.
When I pick up the phone I do hear the "ready to listen" sound. The voice command which I enter seems also to be recognized, at least that's what I think based on the logs here:
INFO:faster_whisper:Processing audio with duration 00:04.690
INFO:wyoming_faster_whisper.handler: Licht draußen aus.
"Licht draußen aus." is the voice command which I spoke into the phone. Up to this point everything seems to work quite ok.
The TTS component which I use is Piper.
I've also set up two voice satellites based on the S3 box, those work as expected. That's why I suspect that it is somehow related to the VOIP implementation.
I am unfortunately not yet too deep into the codebase. Think the issue which I saw in the logs happens around this line here: https://github.com/home-assistant/core/blob/dev/homeassistant/components/voip/assist_satellite.py#L178
In the commit history I've found the following commit which could be related: https://github.com/home-assistant/core/commit/86f8901c9667fc75323a38e87cae98f3603fe5b5#diff-276a218693487049d7cf9d6bb37a1c147aadaf5cb6bc14f957ad10fea8bfc836
It seems to do a change around the code which is causing the issue. Given that some people report to have the problem since a specific version, maybe that's helping to spot the cause.
I'll try if I can manage to create a dev-setup to investigate this. If there is anything I could do to help find the cause of the problem please let me know.
My setup is also based on the tutorial, with a Grandstream HT801 connected directly to my cable modem, feeding to an Intel NUC box running HAOS (reverted to Core 2024.9.3, supervisor 2024.11.3, Operating System 13.2, Frontend 20240909.1). (I reverted to this core because I still want to use the Grandstream.) My conversation agent is Home Assistant, language English, Speech-to-text faster-whisper, language English, Text-to-speech piper, language en_GB, voice northern english male (medium) - although this is only used for system prompts such as "Done"; I couldn't work out how to use it for speech responses to automations etc, which are spoken in the voice from my original setup - alan (low).
My setup without Grandstream HT801 using an android app only (mizudroid) and voice over ip integration.
The call is established but i do not get any sound and the error message:
Logger: homeassistant
Quelle: /usr/src/homeassistant/homeassistant/runner.py:147
Erstmals aufgetreten: 14:04:17 (2 Vorkommnisse)
Zuletzt protokolliert: 14:14:07
Error doing job: Exception in callback None() (None)
Traceback (most recent call last):
File "/usr/local/lib/python3.12/asyncio/events.py", line 88, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.12/asyncio/selector_events.py", line 1238, in _read_ready
self._protocol.datagram_received(data, addr)
File "/usr/local/lib/python3.12/site-packages/voip_utils/voip.py", line 193, in datagram_received
raise err
File "/usr/local/lib/python3.12/site-packages/voip_utils/voip.py", line 183, in datagram_received
audio_bytes = self._rtp_input.process_packet(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/voip_utils/rtp_audio.py", line 70, in process_packet
audio_bytes = opuslib.api.decoder.decode(
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/opuslib/api/decoder.py", line 246, in decode
raise opuslib.exceptions.OpusError(result)
opuslib.exceptions.OpusError: b'buffer too small'
I am new to homeassistant and never had this setup working so this error could have another root cause.
Setup
## System Information
version | core-2024.11.2
-- | --
installation_type | Home Assistant OS
dev | false
hassio | true
docker | true
user | root
virtualenv | false
python_version | 3.12.4
os_name | Linux
os_version | 6.6.31-haos-raspi
arch | aarch64
timezone | Europe/Berlin
config_dir | /config
<details><summary>Home Assistant Community Store</summary>
GitHub API | ok
-- | --
GitHub Content | ok
GitHub Web | ok
HACS Data | ok
GitHub API Calls Remaining | 4824
Installed Version | 2.0.1
Stage | running
Available Repositories | 1461
Downloaded Repositories | 4
</details>
<details><summary>Home Assistant Cloud</summary>
logged_in | false
-- | --
can_reach_cert_server | ok
can_reach_cloud_auth | ok
can_reach_cloud | ok
</details>
<details><summary>Home Assistant Supervisor</summary>
host_os | Home Assistant OS 13.2
-- | --
update_channel | stable
supervisor_version | supervisor-2024.11.2
agent_version | 1.6.0
docker_version | 27.2.0
disk_total | 13.9 GB
disk_used | 7.2 GB
healthy | true
supported | true
host_connectivity | true
supervisor_connectivity | true
ntp_synchronized | true
virtualization |
board | rpi4-64
supervisor_api | ok
version_api | ok
installed_addons | Mosquitto broker (6.4.1), Whisper (2.2.0), Advanced SSH & Web Terminal (19.0.0), rtl_433 MQTT Auto Discovery (0.8.2), Get HACS (1.3.1), Piper (1.5.2), openWakeWord (1.10.0)
</details>
<details><summary>Dashboards</summary>
dashboards | 2
-- | --
resources | 0
views | 0
mode | storage
</details>
<details><summary>Recorder</summary>
oldest_recorder_run | 9. November 2024 um 13:04
-- | --
current_recorder_run | 17. November 2024 um 15:11
estimated_db_size | 25.36 MiB
database_engine | sqlite
database_version | 3.45.3
</details>
I've managed to get a local dev-setup up and running with Whisper, Piper and openWakeWord running in docker containers.
When I comment the following line it starts to work:
async def stt_stream():
while True:
# async with asyncio.timeout(self._audio_chunk_timeout):
chunk = await self._audio_queue.get()
if not chunk:
break
yield chunk
Code pointer: https://github.com/home-assistant/core/blob/dev/homeassistant/components/voip/assist_satellite.py#L178
Compare the pointers from my previous comment https://github.com/home-assistant/core/issues/128372#issuecomment-2480734886
Did the test on the commit tagged as 2024.11.2.
Also did a test run of the tag 2024.9.3 and this one did work out of the box.
Did another experiment. Increasing the timeout also made it work:
async def stt_stream():
while True:
# TODO: Why does it work if I add one second to the timeout?
async with asyncio.timeout(self._audio_chunk_timeout + 1.0):
chunk = await self._audio_queue.get()
if not chunk:
break
yield chunk
Did not yet manage to understand how this plays together with the rest of the code. Hope this observation might be helpful to find the cause of the issue.
I also got this working by changing the timeout back to _PIPELINE_TIMEOUT_SEC, which appears to have been setting it to 30s previously. It definitely seems like the code change referenced by @johbo (https://github.com/home-assistant/core/commit/86f8901c9667fc75323a38e87cae98f3603fe5b5#diff-276a218693487049d7cf9d6bb37a1c147aadaf5cb6bc14f957ad10fea8bfc836) had some unintended consequences. I'm still trying to wrap my head around how that _run_pipeline method is supposed to be working though.
I can confirm this is an issue with 2024.11.x and I reverted to 2024.9.3 to fix it.
No progress on a fix for this? There have been a few hints in this thread but we less "techie" users are probably best off not trying to amend the source code for ourselves even if we could figure out how.
I'm using all the hardware and steps as described in the main tutorial (ht801, an old analog phone, etc). I'm not sure i understand the relation with the asterisk issue. I updated to 2024.12.3 this morning with no luck. Can someone tell us if the main tuto with latest version of HA is working for them/anyone ? Or is it only us with this issue?
i just updated as well, still only get tts voice prompts on the FIRST call only after restarting the voip integration (im running bare metal hassos and also freepbx on a separate machine on the network)
I'm experiencing the same issue. I've got Asterisk running on a virtulal host running my home phones. I've configured an extension to reach HA using the OPUS codec. But currently I get beeps indicating listening but no voice on the first call, then nothing on successive calls. Rolling back to 24.9.1 fixes the issue indicating that my VoIP system and Asterisk configuration is solid.
Literally checking on this daily since I'm really wanting this to work and there appears to be code fixes ready to go in the comments of this thread.
do we know if this is being worked on at all? this is kinda one of the core features with the new 'voice assistant' stuff.. and its kinda sad to see it not working.. just updated to 2024.12.5 and still have same issue.. the FIRST call generates the tones and voice responses.. after that, calling is COMPLETE silence.. if you manage to say the commands at the right time they still work.. but no tones or voice feedback at all
I just saw a video from a youtuber about 3CX. He is doing a full setup and all, praising home assistant for the AI phone implementation, but also talking about the bug ! https://youtu.be/fdM1V98iIQI?feature=shared @34:14. Not surprising as his video was likely filmed in november... He also talks about a solution within HA where he implement an automation that restart VoIP each time (?) not tested on my side so I don't know if it really works. Anyway interresting to see that even a former phone engineer has the same problem.
I'm facing the same issue. I promised my son that he could turn on the Christmas lights using a phone, but it seems he'll have to wait a bit longer. :)
Is it possible to develop a custom component with the necessary fixes while we await the official solution? I'm currently working on this, but I keep encountering a Config flow could not be loaded: {"message":"Invalid handler specified"} error, with no logs available to assist.
Using latest Homeassistant OS on a VM with Homeassistant Core 2024.12.5 here, with the following setup at the local hackerspace @IT-Syndikat. Trying to debug this with @Xiretza.
- STT: Wyoming-faster-whisper (on external VM)
- TTS: Wyoming-piper (on external VM)
- Ollama (on external VM)
- All GPU accelerated using a Nvidia Tesla P40 (assistant responses are reasonably fast)
- Grandstream HT802 V1 (with the old Web UI)
- Auto off-hook-dialing
- Dialing via custom Asterisk extension, Direct IP calling would not work in our case
- An old analog WWII Bunker telephone attached via RJ11
I've managed to get a local dev-setup up and running with Whisper, Piper and openWakeWord running in docker containers.
When I comment the following line it starts to work:
async def stt_stream(): while True: # async with asyncio.timeout(self._audio_chunk_timeout): chunk = await self._audio_queue.get() if not chunk: break yield chunkCode pointer: https://github.com/home-assistant/core/blob/dev/homeassistant/components/voip/assist_satellite.py#L178
Compare the pointers from my previous comment #128372 (comment)
Did the test on the commit tagged as
2024.11.2.Also did a test run of the tag
2024.9.3and this one did work out of the box.
I tried this hotfix on the latest version 2024.12.5 with a Grandstream HT802 (V1) and it seems to (mostly) fix the issue with repeating "listening" sounds for us for now. Thanks @johbo
However this is no permanent solution, as the change is gone as soon as the container is freshly created (e.g. on updates).
I can only second @njfberg, a custom_component until the integration is fixed would be a cleaner hotfix - or even better, can we fix the affected line in a merge request for the next Home Assistant version? What's missing here?
As the VoIP integration was advertised in multiple posts during the "Year of the Voice" with previews and tutorials for the Grandstream HT801/HT802 hardware, I would assume, that someone at Homeassistant would care about this integration. This bug has been open since October, what is blocking this? @balloob, @synesthesiam
I haven't been able to reproduce the problem on my side. I can test the hotfix, but I need to make sure the integration can still detect when the caller hangs up (which is the reason for the chunk timeout).
My comments are not really a fix, more like an indicator that something related to those lines seems to cause this. Or, that the problem becomes visible in those lines. 😬
If you cannot reproduce it @synesthesiam , then maybe we can help with the reproduction of the issue? Or maybe we have something different in our setups which does affect the timing so that this code triggers. I am currently heads down into xmas preparation, might find some time in the coming days to bring up my old experiment and share insights if there is a chance that this might be helpful.
I wonder if the problem is related to this line: https://github.com/home-assistant/core/blob/dev/homeassistant%2Fcomponents%2Fvoip%2Fassist_satellite.py#L168
Maybe I shouldn't use the nowait version of put here. I wonder if the stt stream task is just getting starved due to incoming chunks from UDP always taking priority.
It seems unlikely the issue is being caused by the use of put_nowait, that should only cause different behavior in the event that the audio queue was full and since the queue is being created without a max size that should never be happening.
It seems much more likely that the issue is somehow being caused by the timeout in the stt_stream coroutine since I have been able to reliably reproduce the issue of not having commands processed with the 2.0 sec timeout, but raising that timeout to 10.0 sec causes commands to be processed successfully. I can't really explain why that is working though, because I tried putting a try/except around it to catch the TimeoutError but it isn't caught until I eventually hang up the phone after several cycles of commands failing to be processed.