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.
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: 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.
Make the connection timings measured, and consistent across pages
Three pages gave three different answers for the same question. Cameras said
"0.6 - 2.3 s" mains and "~2.5 s cold" SDES; the FAQ repeated that; Known
limitations still said "about 6.7 s cold" for SDES, which is the figure the
cold-start work replaced. A reader comparing them would not know which to
believe, and one of them was a year of optimisation out of date.
All three now carry the same numbers, read from the integration's own log on a
live install: 2.6-2.9 s for mains standard models, 2.5-3.6 s for mains SDES, and
6-9 s for battery, where nearly all of it is the camera waking. These describe
how long the camera takes to start sending video, which is a thing that can be
measured and repeated - what a dashboard adds on top depends on the card, and is
now said rather than folded into the number.
The warm figures are gone rather than restated. "0.2 - 0.9 s warm" could not be
reproduced: the obvious way to time it, camera.record, returns before the
recording finishes, and two attempts that looked like fast warm opens had logged
"Recording failed to capture anything" while returning success. A warm view
starts immediately because the session is already open, which is what the reader
needs and all that can be said honestly.
Verified and deliberately left alone: listing an SD card really does cost 15-21 s
on a mains camera - timed at 18.0 s, with a real cold open in the log behind it.
That one is not stale, because the listing pays an SCTP handshake on top of the
session the cold-start work sped up.
Cold start for SDES cameras is about 2.5 s, not 6.7 s
Update first-view timings and describe the battery wake
Re-measured on the reference fleet after the 2.19.12 / 1.0.0rc7 work: mains
0.6-2.3 s, SDES 0.2-0.9 s warm and about 6.7 s cold, battery 7-13 s from idle.
Adds what the old numbers hid - a battery camera's first view is almost entirely
the camera waking, that wake varies (1 s to 33 s measured on one camera in one
day), and an occasional first view therefore takes considerably longer. The view
now waits it out instead of failing. Also states plainly that nothing wakes a
battery camera unless you are watching it, since that is the question the
numbers invite.
Resolution: record that the control is gone, and why
The select was removed in 2.11.9 and 2.12.0 clears the leftover entity, but the
wiki still documented it as a working control with a caveat. Six pages
referenced it.
The reason also needed correcting. This page said some models ignore the
command; they do not. With the library able to read camera replies, an M3 Pro
acknowledges it within 0.03s and reports the new value back when asked. The
video is simply identical either way - 1280x720 at the same bytes per frame
under both settings, measured with the setting confirmed by read-back first.
The earlier checks had all been made in the SD direction, and SD sends the value
the camera is already on, so they only ever showed that setting a camera to its
current value changes nothing. That is worth stating on the page rather than
quietly rewriting, because it is the kind of measurement error that looks like a
finding.
Use plain ASCII throughout the wiki
Replaces em dashes, en dashes, arrows, smart quotes, ellipses and decorative
symbols with ASCII equivalents across all pages, so the published docs render
identically everywhere and copy/paste cleanly into terminals and issue reports.
Two glyphs needed wording rather than substitution: the HACS kebab-menu icon is
now written as 'the three-dot menu', and the middle-dot separators became
slashes (a pipe would have broken the markdown table cell in Home.md).
Replace stale cold-start figures with measured ones
The 15-21s mains / 25-70s battery figures and the 'sub-second' claims
pre-dated several streaming fixes and were wrong in both directions.
Replaced with times measured end to end through Home Assistant's own
live-view signalling on a seven-camera fleet.
Also rewrites the blank-picture troubleshooting entry: before 2.10.0 the
usual cause for SDES cameras was a go2rtc re-registration bug in the
integration, not the user's network, so the entry now says to update
first and only then investigate VLAN/AP isolation.
docs: correct mains cold-start figure to 15-21 s
Initial wiki: install, config, cameras, PTZ, audio, recordings, automations, troubleshooting, FAQ