v0.8.29

Live playback samples name the browser's decoder and count its freezes

• The card's browser samples in the integration's diagnostics download add the
  browser's decoder name (video_decoder, a product string such as FFmpeg
  or ExternalDecoder, kept only within 64 characters of a fixed character
  set), whether the browser calls that decoder power efficient
  (video_decoder_power_efficient), and the inbound video counters
  freezeCount, totalFreezesDuration, pauseCount, totalPausesDuration,
  totalDecodeTime, totalProcessingDelay,
  framesAssembledFromMultiplePackets and totalAssemblyTime as
  video_freezes, video_freeze_ms, video_pauses, video_pause_ms,
  video_decode_ms, video_processing_ms, video_assembled and
  video_assembly_ms, durations in whole milliseconds. Missing values stay
  absent and the integration accepts only these bounded scalars, as for the
  existing fields. See live diagnostics.
• Why: the 2026-09-20 run on #94 (integration 0.8.28, bridge 0.8.23, NVIDIA
  T600, Google Chrome 153 on Windows) reached the 1800-second cap but dropped
  to the JPEG fallback at 54.6 s with zero packet loss, a jitter-buffer wait
  per frame growing from 54 ms to 914 ms, 68 dropped frames and eight PLI.
  The four samples could not tell an H.264 stream the browser's decoder
  rejects from decoding or timing on the PC. With these fields the next
  download can. Refs #94, #106.
• Nothing else changes: the five sample stages, the last eight attempts, the
  retention window, the bridge and the card's playback behaviour are the same.

Upgrade and rollback

Update the integration to 0.8.29 in HACS, restart Home Assistant and refresh
the dashboard. The bridge stays at 0.8.23. To roll back, restore integration
0.8.28 from your backup.

Source commit: fed52c72b444d5d3a3157290acd8c55bdefd8c8e

Validation: Integration and card 0.8.29, bridge unchanged at 0.8.23. Diagnostics only: every browser sample of a live WebRTC attempt adds the browser's decoder name and power-efficient flag and its freeze, pause, decode, processing and assembly counters, bounded scalars projected by the same allowlist as the existing fields. No change to playback, the sample stages, retention, the bridge, device commands or media paths, so no new hardware test is needed. Evidence: CI on the merged commit (ruff, mypy, pytest at 96.9 percent coverage, card build matching the committed bundle, Playwright card suite with go2rtc). Motivation: the 2026-09-20 run on issue 94 dropped from WebRTC to the JPEG fallback at 54.6 s with zero packet loss and a growing jitter-buffer wait, and its samples could not separate a rejected NVENC stream from decoding in the browser. Reported hardware evidence stays reported, not independently reproduced.

Download checksums and exact component versions are included in the release assets.

v0.8.28

Diagnostics keep a long live session, and the mains cap is verified

• Fix: the integration's diagnostics download dropped a live playback report
  fifteen minutes after its attempt started, and the bridge left a live audio
  row out of its support report after the same fifteen minutes. With
  live_max_seconds_mains at 1800 a session that ran to its cap was already
  gone from a download taken right after its end, which the reporter of #94
  found on 2026-09-19: live_playback: [] and
  recent_live_playback_not_recorded after a 30-minute session. Bridge 0.8.23
  and integration 0.8.28 keep both for the bridge's configured cap plus
  fifteen minutes, so a session at any cap stays downloadable for fifteen
  minutes after its end. The last eight attempts, the 3600000 ms elapsed time
  bounds and everything else in the download are unchanged. A bridge before
  0.8.22 that reports no cap keeps 120 seconds plus fifteen minutes.
• The 0.8.26 candidate option live_max_seconds_mains is verified on mains
  powered hardware. On 2026-09-19 the reporter of #94 ran one mains powered
  T8425 (firmware 1.6.4.6, no battery value) behind a T8030 HomeBase 3
  (firmware 3.8.5.2) with an NVIDIA T600, bridge 0.8.22, integration 0.8.27
  and live_max_seconds_mains: 1800 for one session: it ended at 1800.156 s
  with camera_timeout, stream_failure and session_end, the stop was
  device-confirmed 27 ms after the stop request without a retry, two guard
  mode changes from Home Assistant applied during the session without
  interrupting it, no recovery and nothing quarantined, and the GPU returned
  to idle. The session switched to the JPEG fallback at 18.4 s
  (fallback_playback_timeout), so a long WebRTC session on that hardware is
  not verified. See compatibility.
• Nothing else changes: the caps, the 10-second lease, the 20-second startup
  timeout, the card's no-restart rule and the per-HomeBase limit are the same.

Upgrade and rollback

Update the bridge to 0.8.23 and the integration to 0.8.28, restart Home
Assistant and refresh the dashboard. The bridge's private data is compatible in
both directions. To roll back, restore bridge 0.8.22 and integration 0.8.27
from your backup.

Source commit: 25f87b22e9862439285aba833dd29fb150e16a25

Validation: Diagnostics window change only (integration download and bridge support report keep live evidence for the configured cap plus 15 minutes), no device command, protocol or media path change, so no new hardware test is needed. The mains cap evidence recorded in docs/COMPATIBILITY.md is the tester run on #94 (comment of 2026-09-19 21:14 UTC): one mains powered T8425 behind a HomeBase 3 ran 1800.156 s to camera_timeout with a device-confirmed stop and guard mode applied during the session. Rehearsal run 35507397139 and main CI run 35507061401 on 25f87b2.

Download checksums and exact component versions are included in the release assets.

v0.8.27

The live relay follows the bridge's session cap

• Fix: the integration's live relay ended every session after 125 seconds, on
  the JPEG path and on the WebRTC path, whatever the bridge's cap for the
  camera. With live_max_seconds_mains set, a camera without a battery value
  lost its Home Assistant viewer at about 125 seconds, the bridge saw
  no_viewers and ended the session long before its own bound. Reported on
  #94 with bridge 0.8.22 and integration 0.8.26 on a mains powered T8425
  behind a HomeBase 3: two attempts ended at 125.0 seconds with no_viewers
  and session_end, without camera_timeout, while /v1/state reported
  live_max_seconds_mains: 1800.
• The relay now bounds itself by the bridge's cap for that camera plus five
  seconds: 125 seconds for a battery camera or a camera missing from the
  inventory, and live_max_seconds_mains plus five seconds for a camera the
  inventory reports without a battery value. The state's
  live_max_seconds_mains is validated at the boundary as a whole number from
  120 to 3600, and a bridge before 0.8.22 that does not report it keeps 120.
  The bridge still ends the session at its cap and closes the socket. HA's
  bound only catches a bridge socket that neither sends nor closes.
• Nothing else changes: the 10-second lease, the 20-second startup timeout,
  the card's no-restart rule and the per-HomeBase limit are unchanged. The
  bridge stays at 0.8.22.

Upgrade and rollback

Update the integration to 0.8.27 and restart Home Assistant, then refresh the
dashboard. The bridge stays at 0.8.22. To roll back, restore integration
0.8.26 from your backup.

Source commit: a2dae1aded9ebb1d59bc7d5c4b5f89191a1334ac

Validation: Integration-only fix of the Home Assistant relay bound, bridge unchanged at 0.8.22. Cause and effect are established by the reporter's diagnostics on #94 with bridge 0.8.22, integration 0.8.26 and a mains powered T8425 behind a HomeBase 3: two sessions ended at 125.0 s with no_viewers and session_end, without camera_timeout, while /v1/state reported live_max_seconds_mains 1800, matching the fixed 125-second relay timeout that both relay paths carried. Unit tests cover the state parsing, the per-camera rule and a relay that ends at its own bound on both transports (254 tests, 96.9 percent coverage). Installed on the maintainer's HA OS bench (integration 0.8.27 with bridge 0.8.21, battery cameras): the integration loads, serves the 0.8.27 card and shows no errors. No device command, media or bridge behaviour changed, so no new physical test was run. The 30 to 60 minute observation on a mains powered camera on #94 follows this release.

Download checksums and exact component versions are included in the release assets.

v0.8.26

Longer live sessions for mains powered cameras, candidate

• Bridge 0.8.22 includes client 0.14.0. Its per-start live bound and its free
  primary session are the library side of
  keesmod/eufy-mega-client#163.
• Add the optional app option live_max_seconds_mains (Docker:
  EUFY_LIVE_MAX_SECONDS_MAINS, a whole number of seconds from 120 to 3600,
  default 120). It raises the absolute live session cap only for cameras the
  inventory reports without a battery value. Battery cameras keep the
  120-second cap in every case, and the default keeps 120 seconds for every
  camera. The bridge passes the bound per start to the client, the client
  sends the STOP at the bound, and the bridge's own watchdog uses the same
  value, so a session still ends without any help from the viewer.
• With live_max_streams_per_station above 1 the client now keeps the
  HomeBase's primary session free, so guard mode commands and snapshots work
  while cameras are live. Recording playback still waits until no camera on
  that HomeBase is live.
• The 10-second viewer lease, the 20-second startup timeout and the card's
  no-restart rule are unchanged. A session that reaches the cap still ends
  with camera_timeout, stream_failure and session_end and needs a new
  start. The bridge's state reports the configured value as
  live_max_seconds_mains.
• Diagnostics: the bridge's live audio report and the integration's filter
  keep elapsed times up to 3600000 ms, so long sessions keep their rows.

Evidence and limits

The library evidence is one T8030 HomeBase 3 (firmware 3.8.7.4) with one
eufyCam 3 on the maintainer's bench: a ten-minute stream at a flat rate,
control on the idle primary session while a stream ran on its own session,
and a 180-second stream ended by the client's bound with a device-confirmed
STOP, see the
library research note.
The bridge's hub and backend tests cover the per-camera cap, the pass-through
of the bound and the battery rule. No mains powered camera has run through
this bridge with a raised cap yet. That observation belongs to the reporter
of #94 with three mains powered cameras: one camera for 30 to 60 minutes with
diagnostics: true, the stream_metrics from /v1/state before and after,
the integration's diagnostics download, GPU load and the final confirmed
stop. Until then the option is a candidate and installations that leave it
unset are unchanged.

Upgrade and rollback

Update the bridge to 0.8.22 and the integration to 0.8.26, restart Home
Assistant and refresh the dashboard. Leave live_max_seconds_mains unset
unless you take part in the observation. To roll back, restore bridge 0.8.21
and integration 0.8.25 from your backup. The bridge's private data is
compatible in both directions.

Source commit: 81f8c5234d296afdee8f8f59bc4a5f778bc2f2e6

Validation: Candidate for the mains powered observation of keesmod/eufy-mega-client#163. Client 0.14.0 is verified on the maintainer's bench, one T8030 HomeBase 3 (firmware 3.8.7.4) with one eufyCam 3: a ten-minute stream at a flat rate, control on the idle primary session while a stream ran on its own session, and a 180-second stream ended by the client's bound with a device-confirmed STOP (https://github.com/keesmod/eufy-mega-client/blob/main/docs/research/LIVE_BOUND_2026-09-19.md). No mains powered camera has run through this bridge with a raised cap yet. The new option live_max_seconds_mains defaults to 120 seconds, so installations that leave it unset are unchanged. Bridge and integration tests cover the per-camera cap, the battery rule, the pass-through of the bound and the diagnostics bounds.

Download checksums and exact component versions are included in the release assets.

v0.8.25

Autostart cards stay live while scrolled out of view

• An inline card with live_autostart: true keeps its live session while it
  is scrolled out of view and keeps acknowledging frames, so scrolling a long
  dashboard no longer stops and restarts its cameras. A card that scrolls back
  into view is still the same session. Reported on #94 from a mobile
  dashboard with three autostart cards in one column, where every scroll cost
  a device-confirmed stop and a fresh start of several seconds.
• Autostart still starts when the card first comes into view after the view
  opens, so a card below the fold starts the first time you scroll to it, and
  again when the page becomes visible again. Scrolling back into view is no
  longer a trigger of its own. The two-minute cap still ends the session, and
  the session still stops on close, pause, stop, page hide, navigation, card
  removal and disconnection, each confirmed by the bridge. A session that
  ended never restarts by itself, scrolling included, and opening the view
  again applies autostart again. The focus return to the snapshot after a stop
  no longer scrolls the page, so a session that ends while its card is out of
  view leaves the page where it is.
• Inline cards without autostart and the popup keep stopping when the card
  scrolls out of view. No new card option, the editor is unchanged. The bridge
  stays at 0.8.21.

Evidence and limits

Playwright covers an autostart card that keeps its session and its
acknowledgement counter while scrolled out of view on the JPEG path and on the
WebRTC tick path, no second session when it scrolls back, the cap ending an
out-of-view session without a restart on scroll, a manual inline card and the
popup still stopping on scroll out, an autostart card scrolled out of view
still stopping on hidden page, pagehide, disconnection and removal with the
next trigger waiting until it is in view, and three autostart cards in one
narrow column that stay live while the page scrolls between them and all stop
when the page hides or the cards are removed. In headless Chromium both
acknowledgement paths ran at the same rate for a video element 4000 pixels
below the viewport as in view. The reporter's mobile dashboard has not
confirmed this release yet.

Upgrade and rollback

Integration-only release, the bridge stays at 0.8.21. Update the integration,
restart Home Assistant and refresh the dashboard. Coming from 0.8.23, this
update also brings the 0.8.24 toolbar below the video on narrow cards. To roll
back, restore the previous integration version from your backup and reload the
dashboard.

Source commit: 555d12b64502271ad520875229ec8419b119ce19

Validation: Integration-only release, bridge unchanged at 0.8.21 with client 0.13.0. Card changes only: inline live controls move below the video on cards narrower than 500 px (#95, PR #97) and an inline card with live_autostart keeps its session while scrolled out of view (#96, PR #99). No protocol, device command or media path change, so no new hardware test is required. Evidence: Playwright card suite 51 cases including bounding-box layout checks at 360 and 700 px and out-of-view acknowledgement on the JPEG and WebRTC tick paths, real go2rtc cases in CI, Home Assistant checks at 97 percent coverage, main CI green on 555d12b. Concurrent live record of 2026-09-19 (PR #98): three eufyCam 3 on one HomeBase 3 verified through the bridge path with device-confirmed stops. Confirmation on the reporter's phone dashboard is still open in #95 and #96.

Download checksums and exact component versions are included in the release assets.

v0.8.23

Optional automatic live start for inline cards

• New card option live_autostart: true, default false and only valid with
  live_mode: inline. The card starts its live view without a tap when it is
  attached in view: when the view opens, when the card scrolls back into view
  or when the page becomes visible again. Each trigger starts at most one
  session per card, up to the bridge's live_max_streams_per_station. A card
  refused at the limit shows "Another camera on this HomeBase is live",
  returns to its snapshot and does not retry by itself. The visual card editor
  offers the switch for inline cards.
• Pause, resume and stop per card, next to the existing sound and close
  controls. Pause releases the lease and shows the snapshot with a resume
  control, which starts a new session with a fresh lease. Stop ends the session
  and disables autostart for that card until the view is opened again.
• Every rule holds: one lease per card with the frame acknowledgement loop,
  the two-minute cap, and a device-confirmed stop on close, page hide,
  navigation, card removal, disconnection or when the card scrolls out of
  view. When the bridge ends a session, at the cap or for any other reason,
  the card returns to its snapshot and does not restart by itself. Opening the
  view again applies autostart again. There is no retry loop and no
  keep-alive. The default stays the explicit start by tap.

Evidence and limits

Playwright covers autostart on attach, on the page becoming visible again and
on the card scrolling back into view, no autostart in the dialog mode or
without the option, pause, resume, stop from the live bar and from the paused
bar, three autostart cards with the third refused at the limit and no retry,
an end at the cap without restart, cleanup on hidden page, pagehide,
disconnection and removal, the card editor, and real decoded WebRTC media that
starts inline without a tap. On 2026-09-18 four autostart cards on one
HomeBase 3 (T8030, firmware 3.8.7.4) with the bridge option at 3 started
without a tap in Chromium in two rounds: two cameras played through WebRTC
with late audio each time, the fourth card was refused at the limit and did
not retry, pause, resume and stop worked per card, a session that reached the
two-minute cap stayed on its snapshot, and leaving the view stopped the
remaining session with a device-confirmed stop, see
the test record.
The third admitted camera timed out at startup in both rounds, so three
concurrent streams remain unverified and two was the number that played at
the same time on that bench.

Upgrade and rollback

Integration-only release, the bridge stays at 0.8.21. Update the integration,
restart Home Assistant and refresh the dashboard. If you update from 0.8.20,
the 0.8.22 and 0.8.21 notes below apply as well. Existing cards keep their
behaviour until you set live_autostart: true. To roll back, restore the
previous integration version from your backup and reload the dashboard.

Source commit: 3f3a72d2ca3399b78acc3b451833acdbec399ae9

Validation: Tested on 2026-09-18 on one Home Assistant OS installation with a HomeBase 3 (T8030, firmware 3.8.7.4), three eufyCam 3 (T8160, firmware 3.4.3.0) and one T8213: two cameras of one HomeBase live at the same time through the bridge and in Chromium through WebRTC with late audio and device-confirmed stops, a third camera refused at the limit, inline cards with and without automatic start, pause, resume and stop per card, the two-minute cap without a restart, and confirmed stops when leaving the view. Three admitted cameras did not all play, the third timed out at startup, tracked in #94. Sanitized record: https://github.com/keesmod/ha-eufy-cam/blob/main/docs/CONCURRENT_LIVE_2026-09-18.md

Download checksums and exact component versions are included in the release assets.

v0.8.20

Live audio whenever the camera starts sending it

The reporter's T8134 cameras behind a HomeBase 3 send their first AAC frame
four to five seconds after the first video frame on a cold start and 40 ms
after it on a warm start. The library's three-second startup deadline excluded
audio on every cold start, and admitted audio was muxed into the video encoder,
which emits nothing until its first audio frame and holds video for the length
of every audio gap.

• The bridge never muxes audio into the live video stream. Every session starts
  a video-only encoder and delivers AAC on the existing late-audio route as soon
  as its first complete frame arrives, whether that is 40 ms or 5 s after video.
  ready always reports audio: false; an audio transport error ends only the
  audio feed. The library's startup classification remains as observational
  audio_supported/audio_absent marks.
• Home Assistant never ends a live session for an audio_ready it cannot use
  (video setup failed or was downgraded, an older bridge reporting audio: true)
  or for a repeated announcement. Older bridges keep their joint audio source.
• Diagnostics record the late-audio stage and end reason per attempt, include
  the late-audio go2rtc stream's counters in relay rows, report the card's audio
  peer state, and assess the new states. audio_expected now only mirrors the
  bridge's initial classification.

Bounded live encoder and arrival-time stamps

• The live WebRTC encoder is capped with a VBV window (default 4M, add-on
  option live_max_bitrate, Docker EUFY_LIVE_MAX_BITRATE). The reporter's
  relay counters measured 9.8-12.4 Mbit/s unbounded output with 300-500 KB
  keyframe bursts alongside stalled decoding. Those counters alone do not
  establish the cause of the reporter's playback failure.
• Frames are stamped with their arrival time instead of being counted at the
  camera's announced rate. A HomeBase delivering 16-17.5 frames per second
  against a 15 fps header made the browser's jitter-buffer delay grow steadily.

Upgrade and rollback

Update both the integration and bridge to 0.8.20, restart Home Assistant and
refresh the dashboard. Back up both components with their private data first
and restore the previous versions together to roll back. The bundled client
remains 0.12.3. The card makes one late-audio attempt per live view; close and
reopen the view to retry audio.

Scope and known limits

References #10. Bridge tests cover the arrival-time stamping and the bounded
output with real FFmpeg; HA and card tests cover warm and cold audio ordering.
Exact T8134 hardware acceptance still needs the reporter's local retest. A
dashboard proxy does not carry the separate WebRTC media connection. When no
direct media route is available, use reachable TURN or routed LAN/VPN access.

Source commit: dadfecd3274400e8ccd02d6223222536d6c29b82

Validation: Validation and limits: #83 . The local test handoff reports eight T8160/T8213 sessions on T8030, including cold/warm doorbell and HEVC on FFmpeg 5.1.9, with continuous decoded video, nonzero decoded audio energy and confirmed stop. Independent live read-back confirms healthy inventory, authentication and push, with no active or quarantined streams. All 245 HA, 150 bridge and 89 browser tests pass, including real WebRTC/TURN and built-container media checks. Physical audibility and the exact T8134 local/external routes remain unconfirmed in issue #10. This release makes no new hardware-support claim.

Download checksums and exact component versions are included in the release assets.

v0.8.19

More useful playback reports

One diagnostic download now connects the stages of a failed recording, reducing
the separate logs and repeat attempts needed to investigate an issue.

• Extend the existing diagnostic download with recent recording preparation,
  processing, limits, cancellation and cleanup. Anonymous attempt references
  connect bridge and Home Assistant observations. Reports retain at most eight
  attempts for fifteen minutes and exclude identifiers, addresses and media.
• Add a bounded diagnostic download action at relevant player errors, using
  Home Assistant's existing administrator permissions. Report loaded card and
  component versions, observed failure stages and missing or stale evidence.

Stronger regression checks

• Cover concurrent recording readers, close/expiry/unload, interrupted reads
  and reopening after fallback or closure before late audio. The new scenarios
  preserve existing playback behavior and improve the synthetic test fixture.

Simpler device maintenance

• Include client 0.12.3 with one registry for all 51 existing device profiles
  and separate snapshot, live and recording policies. Existing model/type,
  owner and firmware admission remains unchanged. Preserve the released
  late-audio and Home Assistant STUN/TURN behavior.
• Give maintainers one place to add and review profiles within supported device
  families, backed by automatic admission checks. A new protocol or an untested
  model still needs its own implementation and hardware evidence.

Upgrade and rollback

Update both the integration and bridge to 0.8.19, restart Home Assistant and
refresh the dashboard. Back up the integration and bridge with its private
data first. Restore their previous files or versions together to roll back,
preserving credentials and entity identities. Older bridges remain usable but
cannot provide the added recording evidence. Download diagnostics before a
restart or the fifteen-minute retention window expires.

Scope and known limits

References #76, #77 and #78, with
client #139.
This batch adds no model or hardware support claim. Exact external T8134
acceptance remains in #10. The known Home Assistant cryptography dependency
limitation remains open in #30. No security finding is suppressed or fixed by
this update.

Source commit: 9133f18aa941b2a9a6932b9b36faeb76bb44528b

Validation: Combined playback diagnostics and lifecycle validation. The candidate passes
226 Home Assistant tests, 148 bridge tests and 86 browser tests, including real
FFmpeg/go2rtc direct and relay WebRTC, delayed audio, fallback, close/reopen and
concurrent recording readers. A representative existing Home Assistant
installation verified loaded 0.8.19 component/card versions with client 0.12.3,
recording preparation, Safari playback/seek, cancellation and cleanup. A bounded
T8160/T8030 session decoded video and audio with confirmed stop. This is scoped
software and local acceptance, not proof of physical audibility or the reporter's
external T8134 route. No new device support is claimed. Existing obligations in
issues #10 and #30 remain open.

Download checksums and exact component versions are included in the release assets.

v0.8.18

• Use Home Assistant's configured and provider-supplied STUN/TURN servers for
  both live video and optional late audio, on the browser and managed go2rtc.
  Resolve fresh credentials for each peer without changing HA network settings.
• Send ICE candidates as they arrive so an unreachable STUN server does not
  prevent direct local playback. Existing startup, fallback and cleanup limits
  still apply. If HA cannot supply ICE configuration, try direct connectivity.
• Add bounded candidate-type, pair-state and ICE-error counters for failed
  connection attempts. Diagnostics exclude addresses, candidate strings, SDP,
  server URLs and relay credentials.

Back up Home Assistant, update the HACS integration, restart Home Assistant and
refresh the dashboard. Bridge 0.8.17 and client 0.12.2 remain unchanged. Restore
the backed-up integration to roll back.
References #10. The reporter's external T8134 route still needs acceptance.
A dashboard proxy alone does not provide a WebRTC media relay.
See the validation method and acceptance boundary.

Source commit: 61f72292b016d82b296ae0b5ca3a9663d9e17a33

Validation: PR #74, #74, adds Home Assistant's existing ICE configuration to both browser peers and both managed-go2rtc offers. Its 209 HA, 143 bridge and 77 browser tests pass, including video and late audio with a required browser relay, direct playback with unreachable STUN, and JPEG fallback with missing or incorrect relay configuration. The relay fixture uses Chromium, go2rtc 1.9.14, coturn and synthetic media. It does not reproduce the reporter's external network.

Integration 0.8.18 is already installed on HA 2026.9.2 after backup and a successful HA configuration check. All 32 installed integration files and the served card match the tested source. A T8160 FW3.4.3.0 behind T8030 FW3.8.7.4 session through HA and managed go2rtc ran for about 18 seconds and decoded 140 video frames and 483 audio frames with nonzero samples and 69 playback acknowledgements. HA supplied STUN configuration with no TURN provider. One camera start and one confirmed stop left no active viewers, cameras, recordings or converters. Four cameras, 15 available Eufy entities, settings and identities were preserved. This covers local initial A/V, not late audio or external playback on the reporter's T8134.

PR #75 changes release documentation only. Bridge 0.8.17 and client 0.12.2 remain unchanged. The external T8134 route remains open in #10. A working direct media route or TURN provider may still be needed. The existing HA-owned Python dependency limitation in #30 remains open and is not remediated by this release.

Main CI https://github.com/keesmod/ha-eufy-cam/actions/runs/34963618129 and rehearsal https://github.com/keesmod/ha-eufy-cam/actions/runs/34964180611 passed on 61f7229. All five downloaded rehearsal assets match the independently built and verified local artifacts byte for byte.

Download checksums and exact component versions are included in the release assets.

v0.8.17

• Add AAC audio that arrives after a live session started without an audio track.
  Video keeps its existing encoder and connection. The same camera owner supplies
  complete AAC frames to an optional audio-only WebRTC connection. Failed audio
  setup does not interrupt video or extend the camera's viewing deadline.
• Keep initial A/V, video-only cameras, JPEG fallback, recordings, GPU settings,
  credentials and entity identities unchanged. Audio readers use the existing
  per-viewer grant and close with their owner. Older cards and integrations do
  not receive the new audio control events unless they opt in.
• Record audio_late when actual AAC becomes available, with browser audio
  negotiation and decoding counters covering the added track. No audio payload
  is retained in diagnostics.

Update both the bridge and HACS integration to 0.8.17, reload the integration or
restart Home Assistant, and refresh the dashboard. The published client remains
0.12.2. Back up both components before installation. Restore their previous files
or versions together to roll back, preserving app data and login state.

References #10. Tests confirm late-audio delivery and continued video. Exact
T8134 reporter acceptance remains pending. This release makes the change
available for testing. An external WebRTC connection that cannot establish ICE
still uses video-only JPEG fallback and needs reachable media connectivity.

Source commit: 70bd684216b0304d2f603195f7838b5fa7cd3372

Validation: Late-audio delivery and lifecycle coverage are in PR #72, #72. Its 143 bridge, 204 HA and 70 browser tests passed, including late AAC with continued video, audio setup failure, ordinary A/V, JPEG fallback and recording playback. Integration and bridge 0.8.17 are already installed on HA 2026.9.2 with backups and a successful HA configuration check. Installed files and the served card match the tested runtime. A bounded T8160 test through HA and managed go2rtc decoded 228 video frames and 758 audio frames over about 18 seconds with nonzero audio samples, 88 video-progress acknowledgements, one camera start and one confirmed stop. This covers ordinary audio present at startup. Four cameras, one HomeBase, push and 15 Eufy entities recovered with unchanged identities and settings, and no active or quarantined streams or retained media processes. PR #73 changes release documentation only. Exact T8134 reporter acceptance and external WebRTC connectivity remain open in #10. This release makes the late-audio change available through the normal update channels for reporter testing. Main CI https://github.com/keesmod/ha-eufy-cam/actions/runs/34951030193 and rehearsal https://github.com/keesmod/ha-eufy-cam/actions/runs/34951103849 passed on 70bd684. The downloaded rehearsal assets match the independently built and verified local artifacts byte for byte.

Download checksums and exact component versions are included in the release assets.