docs: the library floor is 1.0.0rc60 (2.37.16); refreshing HACS, not restarting, picks up an update
docs: SDES cameras need a separate go2rtc; correct PTZ entity ids and the library floor Home Assistant's built-in go2rtc is not an add-on and cannot take a published stream, so the SDES cameras (L2 battery, A001064 PTZ) are not streamed without the go2rtc add-on, the WebRTC Camera integration or AIDOT_GO2RTC_API, and Repairs says so. Say that on every page that described go2rtc as bundled with a plain HLS fallback. Also: the library floor is >=1.0.0rc59 (2.37.15); the health line's DTLS frame figures; the PTZ buttons are button.<camera>_move_left and so on, not _ptz_left; camera.turn_on does not start a stream; list the dog-bark switch, the Reload button and Refresh on-device recordings.
Troubleshooting: the library floor is 1.0.0rc54 (2.37.12)
2.37.10: library floor rc52, the health line, the audio gain trim after the normalizer
Troubleshooting: the library floor is 1.0.0rc48 (2.37.8)
Troubleshooting: the library floor is 1.0.0rc47 (2.37.7)
Known limitations: from 2.37.5 the go2rtc url: conflict is detected and handled
Known limitations: restore the go2rtc: url: words
Known limitations: the go2rtc url: failure needs go2rtc 1.9.13+ (WebRTC Camera's 1.9.9 is refused instead); Core workaround
Troubleshooting: the library floor is 1.0.0rc46 (2.37.4)
Lights: the off-network repair's address can be the cloud's last-known one; check the light is powered
Known limitations: WebRTC fails while a camera publishes into a go2rtc that Home Assistant's own go2rtc points at; 2.37.2 note
2.36.0: battery cameras are not warmed on motion (two leftover lines); library floor is 1.0.0rc45
2.36.0: battery cameras sleep after a view closes and are not warmed on motion; option labels without defaults; the off-network light repair; unclaimed devices in Diagnostics
Supported devices: a BLE hub on the account is listed but gets no device or entities
Bring the wiki up to 2.35.0: four option pages, the defaults that are on, HLS audio, go2rtc repair; talk needs no live view Configuration options lists the four pages and every option with its current label and default (Pin camera video to H.264, Direct publish into go2rtc, Audio in HLS and recordings and In-sync audio for recordings are on; Open the clip inside the Home Assistant app is off). The HLS dialog has sound by default since 2.30.8. Cameras publish straight into go2rtc. Troubleshooting gains the duplicate-key repair issue, the pinned camera that answers H.265, the stale cached stream fixed in 2.30.6 and the clip that lost its first seconds. aidot.talk opens its own session when no live view is running; PTZ buttons follow what the camera advertises (the reference model pans only). The IR-light switch and the hub row are gone; the integration is listed as AiDot Cameras; the library floor is rc40.
Document the slow-motion live view and that the HLS dialog is now silent Integration 2.30.4 stopped registering an AAC transcoding source with go2rtc. On affected go2rtc builds that transcode carried timestamps stamped on a 90 kHz clock while advertising MPEG4-GENERIC/8000, so audio arrived stretched about elevenfold and every player that syncs to audio crawled to match. - Troubleshooting: new section for the symptom, with the two-capture check that tells it apart from the existing "buffers like HLS" entry. - Configuration options: the direct-publish row no longer promises the HLS fallback carries sound, because it no longer does. - Dashboard cards: note that sound lives on the WebRTC path. - Cameras: normalise non-ASCII punctuation.
docs: correct the cold-open times, which were a superseded measurement Three pages quoted 2.6-2.9 / 2.5-3.6 / 6-9 s from a small read on 2026-09-07. A later and much larger measurement - the middle 80% of about 300 cold opens on 2026-09-15 to 16, which the README already carried - puts them at 2.4-3.3 / 2.3-2.8 / 3-6 s. Battery was the one that mattered: the wiki was telling people to expect 6-9 s when it is 3-6 s. Each figure now carries its sample and date, the superseded battery number is named as superseded rather than quietly dropped, and the Cameras page says the table describes the DEFAULT path - direct publish measures a different quantity and does not belong as a row in it.
docs: give the exposure page the URL form and the measured auth behaviour It said go2rtc could be made to authenticate and left it there. It can, the URL is the ordinary rtsp://user:pass@host/stream, and the config for it is two blocks - so the page now shows both rather than pointing at the idea. Verified on go2rtc 1.9.14 with a live publisher: from another machine, no or wrong credentials are refused 401 and the right ones play. Loopback is exempt from the check, which is worth stating: tested on the go2rtc host itself an unauthenticated request succeeds either way, so a check from there proves nothing. Also says plainly that the cameras have no RTSP server of their own, since rtsp://user:pass@camera is the shape people reasonably expect to find.
docs: say what registering a camera with go2rtc exposes It is how the WebRTC live view has always worked, and it means anything that can reach go2rtc can pull any camera as plain RTSP with no Home Assistant login. Verified on a live install from another machine with no credentials. Written as both halves: it is genuinely useful for Frigate/NVR/VLC and costs the camera nothing extra, and it is the whole exposure, whose reach is go2rtc*s configuration rather than this integration*s.
docs: document the two undocumented streaming options, widen the HLS limit The options page never listed "Pin camera video to H.264" or "Direct publish into go2rtc", both of which are in the streaming step people actually see. The HLS/record limitation was written as battery-only. It is not: a mains camera with a warm-hold window set is cold once that window expires, and meets the same 10 s cap. Measured on a standard mains camera left idle past its window - the first two HLS opens failed, the third succeeded, live view fine throughout. Also replaced a real camera entity id in the card examples with the placeholder the rest of the wiki uses.
SD entries: say tapping points to the AiDot app, matching the new message
Document the owner-vs-member account limit for events and recordings The cloud event and recording lists are only populated for the account that owns the home; a member the home is shared to reads empty lists, so motion events, notifications and cloud recordings all silently produce nothing while the owner's app shows them. It is an AiDot account-role limit, not an integration fault. Add it under 'Motion events are not firing', give cloud recordings a 'Nothing shows up' section, and point the notifications config note at it.
Note that HA notifications are an independent path from the app's Almost every control mirrors a device setting the app shares; notifications do not. HA polls the cloud event list, the app uses its own push channel, and neither toggle affects the other. State it in the notifications section, with the caveat that the events feeding it are still gated by the camera's own (mirrored) detection settings.
Describe how clip links are actually protected, and that they survive a restart
Note that recordings can fail on a cold battery camera while live view works
Add the light-behavior control, and correct why it was missing
The app's Behavior control works; ours is the one at fault
Correct which cameras get the duration control
Rewrap the controls list