Repository navigation
Introduce two-way audio support for compatible devices #201
Description
Activity
- removed a sub-issue
on Jun 24, 2026 Many also want two-way audio "intercom" support between Linux-Voice-Assistant and Home Assistant Voice Preview Edition devices too! 😉
That way HA Assist users would be able to initiate voice-activated intercoms in between Assist devices similar to "Alexa Drop In" function:
-
https://www.amazon.com/alexa-drop-in-calling-intercom/b?ie=UTF8&node=21393410011
Try saying: "Alexa, drop in on the kitchen." to instantly connect to Alexa-enabled devices in your home.
And Contact Drop In connects you to a two-way conversation through an Alexa-enabled device with an Alexa contact.
-
https://www.amazon.com/gp/help/customer/display.html?nodeId=GS3WRTSRKD2U6MCK
(plus "Group calling" with Alexa lets you connect with multiple people at once if created groups in the Alexa app.).
-
Btw, Assist is also missing related voice-activated announcement functions to send a voice-activated broadcast message, similar to Google Nest / Google Home smart speakers and Alexa Communications functionality:
PS: Off-topic but interestingly Google Nest / Google Home smart speakers is missing direct-intercom functionality like "Alexa Drop In".
PPS: As noted, not in-scope, but FYI, others have asked for two-way video intercoms within a household using Assist devices, but would require LVA (Linux-Voice-Assistant ) devices with both camera and display in more than two rooms in your house:
Reacted by cvroque-
This is an excellent and thoughtful goal, I have already prototyped for 2-way audio and video intercom that works, including video drop-in. No native client or go2rtc server is required, only TLS. The videocall can also work over LTE/5G networks with a TURN server. Check it out https://github.com/markfrancisonly/ha-videocall
After nearly 4-years of failure to enable 2-way audio on any camera/doorbell, I want to sincerely say that this roadmap must include involvement from camera manufacturers, and consider manufacture of a certified Home Assistant brand video doorbell.
2-way audio works in the client already! the problem is the end devices are low-power, flaky firmware, and poor interoperability. Open Home Foundation cannot solve the main failure point in the 2-way audio/video problem with a native client.
Also consider my comment here regarding the companion app home-assistant/android#7141 (comment)
Reacted by Nick B.This is an excellent and thoughtful goal, I have already prototyped for 2-way audio and video intercom that works, including video drop-in. No native client or go2rtc server is required, only TLS. The videocall can also work over LTE/5G networks with a TURN server. Check it out markfrancisonly/ha-videocall
After nearly 4-years of failure to enable 2-way audio on any camera/doorbell, I want to sincerely say that this roadmap must include involvement from camera manufacturers, and consider manufacture of a certified Home Assistant brand video doorbell.
2-way audio works in the client already! the problem is the end devices are low-power, flaky firmware, and poor interoperability. Open Home Foundation cannot solve the main failure point in the 2-way audio/video problem with a native client.
Also consider my comment here regarding the companion app home-assistant/android#7141 (comment)
To clarify why native client is something we talk about here. 2-way audio from within the WebView only works if it uses HTTPS otherwise the WebView cannot request the microphone. The other use case a native client would be needed is a call navigation supports.
HTTPS otherwise the WebView cannot request the microphone
Yes but that limitation is a good requirement. Privacy is good, do you really want to implement unsecured communications on Home Assistant?
Privacy is good, do you really want to implement unsecured communications on Home Assistant?
The restriction also applies to local IP addresses. There is nothing insecure about a HTTP connection to a local IP address in a trusted self-administrated home network.
I shouldn't need to rely on a public domain with a DynDNS setup, or self-generated certificates I need to continuously deploy on every home device, in order to talk to my local door bell.
Yes but that limitation is a good requirement. Privacy is good, do you really want to implement unsecured communications on Home Assistant?
For this statement to be valid in this situation we would have to also not allow home assistant itself to be served over http right?
4 remaining items
I have used this Core PR as base:
home-assistant/core#148282
But had to ask claude to tweak it for me because it was not providing the CameraEntityFeature.TWO_WAY_AUDIO capability for the reolink doorbell that I have.Then drafted this iOS PR:
home-assistant/iOS#4994Just adding my two cents here. This is a function that has a lot of importance in the WWHA program. Our research team have shown that specifically for doorbells, this is an expected function to work locally and securely. I would be reluctant to add any more doorbell cameras to the program without this being in place.
Reacted by Matthias Kerstner, Nick B., Hedda, Michael Keck, oerix, Gary Crye, Particpant and ConorReacted by HeddaReacted by Nick B. and Michael Keck- moved this from Shaping to Awaiting approval in Open Home Foundation Roadmap
on Sep 28, 2026 Here's how we envision two-way audio working given the microphone limitation (
getUserMediarequires a secure contexthttps://).Frontend loaded over HTTPS
Everything goes through the frontend for all clients, browsers and companion apps alike: a singlesendrecvWebRTC session handles both playback and the microphone.Frontend loaded over HTTP
- Browser: two-way audio can't work. The frontend should hide or disable the talk control instead of failing.
- Companion apps: the frontend keeps playing video and audio as usual. Through the external bus, it passes the camera entity to the native side, and the app opens a separate send-only audio session used only to transmit the microphone after asking the permission to the user.
The choice is made at runtime (
window.isSecureContext+ the app advertising the capability over the external bus), not from the configured URLs, since the app switches between internal and external URLs.Points we still need to validate:
- Echo cancellation: playback happens in the WebView and capture in the native stack. This needs testing on a range of devices.
- Delay between the stream: having two stream could have a delay between the two.
- Frontend might want additional controls over the stream like push to talk or mute.
@bgoncal are we aligned?
Reacted by Nick B.Approved the opportunity and marked the priority "high". Note that the app move for iOS has priority over this one any time.
../Frenck
Reacted by Bruno Pantaleão Gonçalves and mrtncodeReacted by Timothy, Nick B., oerix and mrtncode@TimoPtr If product-ux team wants to keep the UI as-is in frontend then we are aligned.
The native part of this like notification call is out of scope of this first opportunity IMO. We need to create another one for anything native that we would like to do IMO.
Reacted by Matthias KerstnerSounds good 👍🏻
I've added the Epic for this to the progress board too for visibility. We can follow up for any other cross-team tasks
Join the discussion on Discord: https://discord.com/channels/330944238910963714/1554752656055210025/1554752656055210025
Thanks for working on this! I’m developing HomeCall, an open-source project that lets users record their own voice in Home Assistant and send it as an announcement to one or more speakers.
A dashboard card handles recording, and a custom integration converts and delivers the audio through existing Home Assistant integrations. Supported targets include Alexa, DLNA, Sonos, Music Assistant, Google Cast and EchoMuse.
@Hedda’s comments about room-to-room intercom and voice broadcasts caught my attention, because HomeCall already addresses the recorded voice announcement side of that use case. It currently provides one-way messages, but live two-way intercom would be an interesting future direction.
I also encounter the microphone restriction discussed here: recording requires HTTPS, even when speaker delivery stays local. Is the planned native microphone capability specific to camera WebRTC sessions, or could it eventually support other uses such as recording voice announcements?
Reacted by Matthias KerstnerReacted by HeddaReacted by HeddaI’m developing HomeCall, an open-source project that lets users record their own voice in Home Assistant and send it as an announcement to one or more speakers. A dashboard card handles recording, and a custom integration converts and delivers the audio through existing Home Assistant integrations. Supported targets include Alexa, DLNA, Sonos, Music Assistant, Google Cast and EchoMuse. @Hedda’s comments about room-to-room intercom and voice broadcasts caught my attention, because HomeCall already addresses the recorded voice announcement side of that use case. It currently provides one-way messages, but live two-way intercom would be an interesting future direction.
Was just about to post a tip seen on Reddit that @thomasgregg made a custom component integration and a matching frontend card called "HomeCall" which could perhaps even be used as a base to build for this UI or else just use for inspiration here? Check out these links for it:
and
While it currently only seems to have one-way support it sounds like it has a announcing/sending part down, so "only" missing receiving part. Could maybe be extended with two-way intercom for room-to-room when using ESPHome, however unsure if two-way intercom could be made possible for room-to-room with third-party like Amazon Echo and Google Nest speakers?
Anyway, the cards looks very nice, and again its interface for the announcement/send part seem well thought out. Screenshots from Reddit:
Thanks @thomasgregg & @Hedda for pointing that out - looks nice!
For scoping purposes - This opportunity here aims for a first step in enabling two-way audio from which to potentially expand further, especially thinking about video door bells and the general UI/UX perspective on that #84
This first step will come with some known limitations - something to refine further (engage here Discord). Since there won't be changes to how the underlying go2rtc is handling connections to the cameras it won't be possible to simultaneously use the vendor app when HA is (audio) streaming. But definitely a first step into the right direction!
Reacted by Nick B.
Problem statement
Home Assistant does not currently support two-way audio, which is a core feature of video doorbells and many security cameras. Users who want this today must fall back to a manufacturer's own app, breaking the local-first and integration promise of Home Assistant. This opportunity is about building two-way audio as a generic, platform-level capability that any integration can build on, not a feature tied to any single brand or implementation.
Home Assistant aims to provide the same user experience regardless of the platform used. Two-way audio will therefore ship with full parity across iOS and Android, enabling users to speak through their phone to any compatible camera or doorbell via the Home Assistant companion app. Two-way audio support via the Home Assistant frontend is included as well.
Previous analysis and community work - most notably the Core PR at home-assistant/core#148282 - surfaces a key constraint: the majority of Home Assistant users run local http connections, and current WebRTC players do not allow microphone access over insecure http. This requires native WebRTC players in the companion apps capable of accessing the microphone over http connections.
Community signals
The primary community thread tracking demand for this feature:
Related Core PR with prior implementation work:
Come join the discussion here:
Scope & Boundaries
In scope
Not in scope
Foreseen solution
Cameras speak many different protocols: RTSP, RTMP, WebRTC, HLS, FFmpeg-processed streams, and so on. The Home Assistant frontend and companion apps can't speak all of these natively.
A proposed solution is outlined here:
Risks & open questions
Open questions
Appetite
Medium - 4-5 weeks
Execution issues
No response
Decision log