Menu icons sit visibly high inside their round buttons in the iOS
companion app, and one pixel high everywhere else. The card's icon
wrapper (`advanced-camera-card-icon`) is slotted into `ha-icon-button`,
whose label renders slotted content inside a plain `<span>`. The wrapper
is an `inline-block`, so it rides the text baseline and leaves the
font's descender space underneath it: the span grows taller than the
icon (measured: 24.5px around a 22.5px icon under Roboto), the button's
flex layout centers the *span*, and the icon lands high by half the
descent.
That descent is a property of the active font, which is why the offset
differs per platform: about 1px under Roboto, and about 2px when the
font stack resolves to a system font, as on iOS, where it is clearly
visible inside the round menu button background. Slotted Home Assistant
icons do not show this because they are laid out block-level via
`--ha-icon-display`, which the card already sets; the card's own wrapper
element reintroduces the inline-block one level up.
**Change:** lay the wrapper out block-level wherever it is slotted into
`ha-icon-button` (`button.scss`, which also covers the submenu and
next/previous controls). Block layout has no baseline, so the label span
shrinks to exactly the icon and the icon centers.
**Verification:**
- The structure (flex button, label span, slotted icon) rebuilt
standalone in Playwright Chromium and WebKit: with an inline-block icon
the offset is 1px under Roboto and 1.75 to 2px under system fonts, in
both engines; with a block icon it is 0.0px in every engine, font, and
button size tried.
- Measured on a live HA 2026.8.3 dashboard (45px menu buttons): before,
every menu icon center sat 1px above its button center; after, 0.0px for
both a standard menu button and a conditional
`advanced-camera-card-menu-icon` element.
- `yarn run test`, `yarn run test:browser` (chromium), `yarn run lint`,
`yarn run typecheck` pass.
---------
Co-authored-by: dermotduffy <dermot.duffy@gmail.com>
## Summary
- add optional microphone constraints for echo cancellation, noise
suppression, automatic gain control, and channel count
- request configured values as non-mandatory `ideal` constraints
- expose privacy-safe microphone capabilities, requested constraints,
and applied settings in card diagnostics
- document the new configuration and add schema, microphone manager, and
diagnostics tests
## Motivation
The card currently calls `getUserMedia()` with `audio: true`. This
leaves echo cancellation, noise suppression, automatic gain control, and
channel count implicit.
Browser and device behavior differs. Explicit processing defaults can
regress microphone gain or amplify noise on some devices. This change
therefore keeps all processing constraints optional and configurable.
## Configuration
```yaml
live:
microphone:
constraints:
echo_cancellation: true
noise_suppression: true
auto_gain_control: false
channel_count: 1
```
Configured values use `ideal` constraints. A browser can ignore
unsupported values. Card diagnostics show the browser capabilities, the
requested constraints, and the reported applied settings.
## Backward compatibility
- existing configurations still use `audio: true`
- no audio-processing defaults are added
- explicit `false` values are preserved
- diagnostic output excludes device and group identifiers
## Validation
- focused microphone, schema, and diagnostics tests: 46 passed
- full test suite: 7,177 passed
- lint passed
- format check passed
- typecheck passed
- unused-code check passed
- production build passed
The optional constraints were also tested successfully with an iOS Home
Assistant Companion client and a go2rtc-based full-duplex intercom. This
is a client microphone-processing change only. It does not add backend
audio denoise.
---------
Co-authored-by: dermotduffy <dermot.duffy@gmail.com>
The card claimed a camera's ONVIF audio backchannel in two places that
had
nothing to do with a call: the capability probe at camera init
(`µphone`),
and a pre-armed `sendonly` audio transceiver on every live WebRTC offer.
Merely
looking at a dashboard occupied the camera's speaker line. Outbound
audio now
travels on its own audio-only WebRTC connection, opened when a call is
answered
and closed when it ends.
- The backchannel is claimed only for the duration of a call. Idle
viewing
claims nothing.
- Two-way audio now works in `mse`, `mp4` and `mjpeg` modes (note: the
outbound
audio still traverses WebRTC).
- No renegotiation and no video blink at call start or end.
- A call that cannot carry audio now reports it and ends, instead of
showing a
live microphone that goes nowhere.
- `live.microphone.always_connected` is now purely about the browser
microphone
permission prompt.
- Call setup measured at 66ms (LAN) and ~260ms (cellular) for ICE and
DTLS, plus
~300ms for `go2rtc` to open an RTSP backchannel.
Verified against a live Frigate + `go2rtc` instance, and by unit tests
at 100%
coverage.
- Closes#2691
- Closes#2039
- Closes#2178
Ref #2299 -- the probe no longer opens a backchannel, but it still runs
per
camera on every load and reconnect, and still dials the camera on the
direct-`go2rtc` path. Caching remains to be done.
Ref AlexxIT/go2rtc#1860 -- once a call has opened a backchannel,
`go2rtc` keeps
that media set up on the camera's RTSP session for the life of the
producer.
Diagnoses #2678
- Closes: #2679
BREAKING CHANGE: `selected` and `unselected` are removed from
`live.microphone.auto_unmute` / `auto_mute`. A camera change ends any
call and the microphone only carries audio during a call, so neither
were useful.
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.
This is a high risk change: every byte the card ships is emitted by a
different bundler, minified by a different minifier, and every
stylesheet is compiled by a different sass. The intent is that the
card's behaviour is unchanged.
**Significant development win**: Build time drops from 24s to 1.1s 🎉
Also adds a test suite ('dist') that runs against the built bundle.
Mounts the card from `dist/` the way Home Assistant does, by URL with a
HACS tag, and asserts the entry stays a facade, that no chunk imports
it, that the browser is served the file unmodified, and that the card
starts up and fetches a language chunk lazily.
Runs in Chromium, Firefox and WebKit, so a change of bundler or minifier
is checked against every engine.
The `initialized` state (used in conditions/triggers) was written once
and never cleared, so it meant "has this card ever been initialized"
while everything reading it took it as "is this card usable now". Home
Assistant takes a card off the page and puts it back whenever its
dashboard tab is left and returned to, so the card initialized again
while the state claimed it was initialized throughout: `trigger:
initialized` fired once per card rather than once per startup, and
automations were dropped in between.
The card lifecycle is now an explicit state machine (`SessionManager`),
the only writer of `initialized`, which separates a card that is
starting up from one initializing part of itself again while it runs. A
new `ever` parameter (conditions/triggers) selects the old latched
behaviour.
`remote_control` uses that parameter to keep its two camera priorities
correct under repeated starts. With `camera_priority: entity` the card
now re-reads the entity every time it starts, so a camera selected while
the card was away is picked up on return. With `camera_priority: card`
the card writes the entity on its first start only, unchanged, since
repeating that write would overwrite a camera the user had selected.
Closes: #2642
BREAKING CHANGE: `condition: initialized` is now `false` whenever the
card is not usable, and `trigger: initialized` fires each time the card
starts up rather than only the first time. Set `ever: true` on either to
keep the previous behaviour.
Dermot Duffy