Known limitations

• There is no resolution control. Cameras accept the stream-quality command and report the new value back, but encode the same picture whichever setting is sent - measured across every setting the command defines and the extra one the AiDot app uses for Auto. The select was removed in 2.11.9 rather than left reporting a setting with no effect; 2.12.0 clears the leftover entity. If the AiDot app's own switch looks like it works, see Resolution - it changes its label, not the stream.

• PTZ commands require an active stream. The camera must be streaming for PTZ to reach it - open the live camera card first, then retry. Two-way audio does NOT: the aidot.talk service opens its own session when no live view is running, and reuses the live one when there is. Verified against a live install on 2026-08-11.

• Cloud recordings require a subscription. The Media Browser integration for recorded clips only works when the camera has an active AiDot cloud storage plan. Recordings on the camera's own SD card need no plan, but are listed only - see On-device recordings.

• On-device recordings cannot be played. Pulling video off the SD card is a protocol this integration has not exercised, so those entries are a listing.

• Some models never report their SD card contents. Fixed in library 1.0.0b34, which the integration picks up automatically. This was ours, not the camera's. Cameras on the SDES transport send the listing as several fragments, and the integration parsed each fragment as though it were a whole reply - so the first was discarded and the rest read as noise, and the folder said the camera had not answered while the reply was sitting on the wire. The earlier measurement ("five requests, all unanswered") was accurate about what we received and wrong about why. An A001064 now returns its full listing.

• Listing the SD card costs a camera connection. 15-21 s on a mains camera, up to 70 s on battery, and it wakes the camera - so browsing the folder never refreshes it. The list is taken when a connection is already open for another reason, or when you press the per-camera Refresh button.

• Off-LAN streaming uses STUN/TURN. When Home Assistant and the camera are on different networks, media is relayed through the AiDot cloud TURN servers. Latency and reliability depend on the relay; LAN-direct is always preferable.

• Battery cameras skip local control. The optional LAN-direct discovery uses a UDP subnet sweep that battery cameras do not respond to, so they fall back to cloud-only control even when local control is enabled.

• Motion event delivery can lag. Motion is cloud-polled roughly every 30 seconds, so an event can arrive up to ~30 seconds after the camera detects movement.

• DTLS camera connections are retried automatically. Connections to DTLS-mode cameras are probabilistic per attempt; the integration retries silently, so a brief delay before a stream loads is normal.

• First view of an idle camera has a connection delay. The proprietary handshake runs before video appears - the camera starts sending in about 2.4-3.3 s on a mains standard model, 2.3-2.8 s on a mains SDES model, and 3-6 s on a battery (L2) model. A warm view starts immediately. Once connected the stream is low-latency over go2rtc WebRTC; subsequent views, and motion-pre-warmed views of mains cameras, are quicker. The mains warm-hold option keeps recently-viewed mains cameras warm. See Cameras.

• A battery camera's wake time varies, and an occasional first view is slow. Nearly all of a battery camera's first view is the camera waking; measured on one camera in one day it announced itself anywhere from 1 s to 33 s after the request. The view waits it out - showing Connecting and then Buffering - instead of failing, and gives up after about a minute if the camera really is unreachable. There is no setting that makes a sleeping camera wake faster.

• Recordings and HLS can fail on a COLD camera while the live view works. They are different paths with very different budgets: the live view waits up to 75 s for the camera, but Home Assistant caps camera.record and HLS at 10 s, and a camera that has to be woken and handshaked cannot always beat that. Warm, the same camera records fine. Open the camera's live view first, then record.

  Battery cameras are always cold, so they meet this most often. A mains camera meets it too if you have given it a warm-hold window (see Configuration options): once that window expires the next view is a cold start like any other. Measured 2026-09-20 on a standard mains camera left idle past its window, the first two HLS opens failed and the third succeeded, while the live view was fine throughout. The default warm-hold of 0 keeps mains cameras warm and avoids this entirely.

• One live viewer per camera (AiDot-app contention). Each camera serves a single live session at a time; the AiDot app and Home Assistant cannot both hold the live view. Recorded clips and snapshots are unaffected.

• H.265 sessions take the slower path, and the default asks for H.264. The cameras offer both codecs. A session that answers in H.265 is served through the ffmpeg path rather than published straight into go2rtc, and cannot feed the in-sync recording stream. The Pin camera video to H.264 option (on by default since 2.35.0) asks every camera to stay on H.264, because H.265 breaks players that use Media Source Extensions - the Home Assistant iOS app among them shows about one frame per keyframe. The PTZ model (A001064) still answers H.265 roughly one open in seven despite the pin; since library 1.0.0rc42 (integration 2.33) such a session is abandoned and re-opened, up to twice. See Troubleshooting.

• Hardware video decoding may not make anything faster. Where a machine has decoding hardware that genuinely works it is used, but plenty of machines either have none that ffmpeg can drive, or have some that is slower than simply decoding in software. Both cases are detected by measurement and fall back to software. Note also that live viewing and recording pass the video through without decoding it at all, so they are unaffected either way.

• Lights, plugs and switches on a shared home may not be controllable. These non-camera devices are controlled on the local network only, and that login belongs to the upstream integration this one is forked from. On the account that owns the devices it works normally. An account the home has merely been shared with can be refused that local login by the device itself; those entities then read as unknown and a command returns a clear error rather than pretending it was delivered. The devices still work from the AiDot app, and cameras are unaffected -- they do not use that path. This is upstream behaviour and is deliberately left alone rather than worked around.

  The same applies to local camera control ("Local camera control"): devices accept a local login only from the account that owns them, and refuse a shared-home member with a code that varies by model. Verified across ten devices in four model families - all ten accept the owning account and refuse a shared member:

  Model	What the device answers
  LK.light.A001493	400 not equal abort user id or password
  LK.light.A001497, LK.plug.A001535	4354 fail
  LK.IPC.A000088 cameras	4352 fail

  The first is the honest message: it is the user id that does not match, not the password. Camera live view is unaffected either way - it is WebRTC signalled over cloud MQTT and does not use this path.

• Sound detection is not reported by battery cameras. They are asleep between views and answer nothing, so no sound-detection switches are created for them. This is deliberate: a row of switched-off detectors would claim a state the camera never reported. See Supported devices.

• SD-card size sensors have no unit. The camera reports bare numbers and does not say what they count, so they are shown exactly as reported rather than labelled bytes. See Supported devices.

• WebRTC can fail for every camera when Home Assistant's go2rtc: url: points at the go2rtc the AiDot cameras publish into, if that go2rtc is 1.9.13 or newer (the go2rtc add-on, Frigate's, or a standalone one). Home Assistant's go2rtc client reads the whole stream list on every WebRTC offer and cannot read a stream a camera publishes into (the publisher has no source URL), so offers fail with a Field "url" / Producer traceback while an AiDot camera is publishing there. The WebRTC Camera integration's own go2rtc (1.9.9) is too old for Home Assistant, so pointing url: at it sends every camera to HLS instead. Installs without a url: line are not affected. From 2.37.5 the integration detects this and does not publish there: standard cameras are pulled instead, SDES cameras are not streamed, and Settings -> Repairs says so. To get every camera back on Home Assistant OS or Container: remove the url: line and restart. On Home Assistant Core, where url: is required: run a second go2rtc for the cameras and point AIDOT_GO2RTC_API at it. (2.37.0 and 2.37.1 caused the same failure on installs with only Home Assistant's built-in go2rtc; 2.37.2 fixed that by no longer publishing there.)