Dashboard cards - cbrightly/hass-aidot-cameras GitHub Wiki

Dashboard cards (fastest live view)

How you put a camera on a dashboard changes how fast it loads - more than any integration setting. This page covers the recommended card, multi-camera walls, and the one host-resource limit to know about.

Using the wrong card makes every live view slow. With the default Picture / Picture Glance card, opening a camera goes through Home Assistant's HLS player (the ~20 s scrubber buffer), so the first frame is several seconds away on every view - even for a warm camera that WebRTC would show in well under a second. If your cameras feel slow to load, this is almost always the cause, not the integration.

The default Picture / Picture Glance card shows a periodically-refreshed thumbnail and only starts a live stream when you click through to the more-info dialog - and that dialog uses Home Assistant's HLS player, so the first frame is several seconds away.

Sound. The cards below carry the camera's own audio, untranscoded. Home Assistant's built-in HLS more-info dialog (what the Picture cards open) has sound too, by default since 2.30.8, through the Audio in HLS and recordings option (Configuration options); it was silent from 2.30.4 to 2.30.7 - see Live view plays in slow motion for why.

Recommended: Advanced Camera Card

For a genuinely fast, always-live tile, use the HACS Advanced Camera Card pointed at the AiDot camera entity. It renders the go2rtc WebRTC live stream inline (low-latency once the camera is connected) instead of the HLS more-info player, lazy-loads cameras that aren't on screen, and can bind the PTZ controls to the same button entities (see PTZ control). In practice this is the single biggest improvement to perceived load speed.

type: custom:advanced-camera-card
cameras:
  - camera_entity: camera.front_door
live:
  # Use the native Home Assistant path. This integration hands HA a go2rtc
  # RTSP source, so the `ha` provider already serves go2rtc WebRTC (low-latency
  # once warm) and triggers the stream start automatically. Do NOT use
  # `provider: go2rtc` here: for a non-Frigate camera the card resolves no
  # stream unless you also set `live.go2rtc.url` and `live.go2rtc.stream`, so a
  # tile pinned to bare `go2rtc` never starts.
  provider: ha
  # show the tile already live instead of a click-to-play thumbnail
  preload: true
  # `[]` (the default) never auto-unloads the stream once it is loaded, so
  # re-views stay warm. The card's older string form (`lazy_unload: never`) was
  # replaced by this list form and is now rejected as invalid.
  lazy_unload: []
dimensions:
  # Fixed tile size. Without this the card sizes to the media and can balloon
  # when a stream (re)connects.
  aspect_ratio_mode: static
  aspect_ratio: "16:9"

The first view of an idle camera still pays the one-time connection handshake (see Cameras overview); the card does not change that. What it removes is the HLS dialog hop on every view after the camera is warm. Pair it with the mains warm-hold option (Configuration options) for instant re-views.

Install it via HACS -> Frontend -> search Advanced Camera Card. Any WebRTC-capable card works (e.g. AlexxIT's WebRTC Camera); the Advanced Camera Card is recommended because it also handles the PTZ overlay.

Multiple cameras on one dashboard

Use live.provider: ha on every card (one camera per card, or a multi-camera card) - that keeps each tile on the native go2rtc WebRTC path. A grid of single-camera cards:

type: custom:advanced-camera-card
cameras:
  - camera_entity: camera.front_door
live:
  provider: ha
  auto_play: [visible]
  auto_unmute: []
dimensions:
  aspect_ratio_mode: static
  aspect_ratio: "16:9"
# ...repeat one card per camera, each with `live.provider: ha`

Host-resource note for big live walls

Mains A000088 cameras stream by decrypting in-process. The concurrent serve cap sizes itself to your camera count automatically (set the AIDOT_MAX_CONCURRENT_STREAMS environment variable to impose a hard ceiling), so a big all-live wall streams every tile out of the box. The practical limit is host CPU - each live A000088 costs a decrypt pipeline. Battery/SDES cameras don't use a slot. See Cameras overview for how the cap interacts with warm-hold.

See also