Files

T

Dermot Duffy 85d6811761 fix: Release the microphone to the browser when a call ends (#2685 )

The microphone is connected when a call needs it and released the moment
that
call ends, so the browser stops reporting it as in use at hangup rather
than
`disconnect_seconds` later.

Existing configurations are migrated automatically by the visual editor.

 - Closes: #2681 

BREAKING CHANGE: `live.microphone.disconnect_seconds` is removed. The
microphone is released when a call ends, so there is no idle countdown
to
configure. Use `live.microphone.always_connected` to hold it open
instead.

BREAKING CHANGE: The `microphone_connect` and `microphone_disconnect`
actions
are removed. The card owns the microphone lifecycle; `microphone_mute`
and
`microphone_unmute` remain.

BREAKING CHANGE: `call` is removed from `live.microphone.auto_mute`,
whose
default is now `[]`. The microphone is muted when a call ends regardless
of
this option.

BREAKING CHANGE: `microphone_unmute` has no effect outside a call.
Nothing
carries the audio at any other time, so the request is ignored rather
than
opening the microphone.

2026-08-14 16:17:31 -07:00

5.5 KiB

Raw Blame History

2-way Audio

This card supports 2-way audio (e.g. transmitting audio from a microphone to a suitably equipped camera). In general, due to the myriad of different cameras, security requirements and browser limitations getting 2-way to work may be challenging.

Requirements

Environmental requirements

Must have a camera that supports audio out (otherwise what's the point!)
Camera must be supported by go2rtc for 2-way audio (see supported cameras).
Must be accessing your Home Assistant instance over https. The browser will enforce this.

Card requirements

Only Frigate cameras are supported.
Only the go2rtc and go2rtc-experimental live providers are supported.
Only the webrtc mode supports 2-way audio.

If your setup supports 2-way audio but detection is intermittent on load:

Increase cameras[].go2rtc.metadata_fetch_timeout_seconds.
Or force the capability with cameras[].capabilities.force: ['2-way-audio'].

Example configuration

type: custom:advanced-camera-card
cameras:
  - camera_entity: camera.office
    live_provider: go2rtc
    go2rtc:
      modes:
        - webrtc
      # Optional: For slower cameras increase timeout (default: 2)
      metadata_fetch_timeout_seconds: 10

Usage

Two-way audio is driven by the call menu button (a phone icon). It is enabled by default and appears in the live view whenever the selected camera -- or one of its dependencies -- supports 2-way audio.

Tap the call button to start an outbound call. An on-screen overlay appears with controls to mute/unmute the microphone, mute/unmute the inbound audio, and end the call. When more than one 2-way-audio camera is available the button becomes a submenu with one entry per camera.
Inbound calls (started by a view.triggers.actions.trigger: call trigger -- e.g. a doorbell) open the overlay in a ringing state with only two buttons: a red Reject and a green Answer.
The call menu button itself tracks the call state: tap it to start or answer a call and to hang up an active one, and while an inbound call is ringing hold it to reject. This lets you drive the whole call from the menu when the standard call controls are hidden with live.controls.call.enabled: false -- see Driving calls from the menu.
When a call is answered (outbound calls are answered by definition) the inbound audio is unmuted automatically, so the caller can be heard. The microphone stays muted by default (push-to-talk) -- tap the microphone button in the overlay to speak. Both behaviors are configurable via live.microphone.auto_unmute and live.auto_unmute.
The camera will always load without the microphone connected, unless the always_connected microphone option is set to true. On the first call there may be a brief webrtc connection reset to include 2-way audio.
The browser asks for microphone permission when a call needs it. How often it asks depends on the browser: Chrome remembers the choice for the site, Safari asks once per page load, and Firefox asks for every call unless Remember this decision is ticked. Set always_connected to true to be asked once at card load instead.
While a call is in progress the card locks disruptive actions (camera and substream changes, casting, reload, etc.) so an accidental tap, swipe, or button press doesn't cut the call off. Set live.controls.call.lock to false to disable this.
End the call with the overlay's end-call button. When the call ends the microphone and inbound audio are muted again, and the microphone is disconnected. The exception is always_connected, which holds the microphone connected for as long as the card is running.

Calls can also be controlled programmatically with the call_start, call_answer, and call_end actions -- for example, from an automation that fires when a doorbell sensor triggers. The call condition can be used to show or hide elements while a call is in progress.

Call lifecycle

The diagram below traces a call from start to finish:

Talking with a single tap

By default, two taps are needed to speak: start (or answer) the call so you can hear, then unmute the microphone via the in-call overlay so you can be heard. This push-to-talk default keeps the microphone muted until you explicitly choose to speak.

To collapse that to a single tap, unmute the microphone automatically when a call is answered:

live:
  microphone:
    auto_unmute: ['call']

For outbound calls the microphone opens the moment the call starts; for inbound calls it opens the moment you press the green answer button. Leave auto_unmute empty (the default) to always start muted regardless.

5.5 KiB Raw Blame History