Return the semantic action set (OnTrigger and/or OnReset) for a camera. Decodes the full action type map (0-13), the command table for type=12 do-commands (PTZ presets 2201-2456, action sets, brightness/contrast/gain, plus ~60 individual codes), web_proto1 (http/https/mqtt), run_action, trig_allzones, and the profiles/zones/diobits/trig_source bitmasks into readable lists. Unmapped values fall through with the raw int preserved alongside (e.g. command_raw, trig_source_raw). Source data comes from the camera's .reg export, so changes made via the BI UI mid-session won't be visible until a re-export.

Fetch the STORED alert image (the frame BI saved when an alert fired) for a camera, resolved by time — not a live frame (that's bi_get_camera_snapshot). Pass 'camera' (short name) and optional 'at' (the alert time: ISO-8601, unix epoch int, or relative like '-2h'); omit 'at' for the most recent alert. Returns the most-recent alert at-or-before 'at' as base64, plus its record/time/memo so you can confirm which alert came back. Optional 'markup' (bool) requests the AI-overlay variant (manual's v=2). Internally resolves via alertlist + the /alerts/@record endpoint. Use a specific camera, not 'Index'. MARKUP — when 'markup'=true draws no box, it's almost always the ALERT'S SOURCE, not a tool bug: a box exists ONLY if CodeProject.AI classified the alert (memo has a score, e.g. person:89%). A bare person memo (no %) is an ONVIF/camera-IVS alert that BI's AI never scored, so there is no box to burn — v=2 just re-encodes the frame. (Separately, low-res thumbnails come from the camera's Hi-res-JPEG alert setting being off; that's a distinct issue from markup.) The /alerts/ endpoint only serves what BI stored and ignores w/h/scale params. State the source-vs-bug distinction proactively.

Recent alerts with AI memo (object, confidence, license plate), zones triggered, and clip path. Requires 'camera' short name (or 'Index' for all). First stop for 'what fired when' / reconstructing an alert chain — per-alert timestamps and memos, no dedup. Use this before bi_list_log when investigating a specific event. Optional 'startdate'/'enddate' accept unix epoch int, ISO-8601 ('2026-05-27T14:09:02Z'), or relative shorthand ('-2h', '-1d'). 'view' (filter; see schema for full enum), 'search' (memo substring). 'limit' default 50. Crossover note: if 'view' is set to 'flagged', BI may also return clip items here; those clips lack the 'zones' field and their 'msec' is the clip length, not alert length.

AI object tracks (per-frame bounding boxes) inside one alert. Pass the alert's 'path' from bi_list_alerts. KNOWN BROKEN on BI 5.9.9.71: returns 'Access denied' from both the read-user and admin-user paths. The tracks cmd appears in BI's JSON cmd list but the manual provides no spec for it, and its gating mechanism is undocumented. Uses admin if configured (in case a future build accepts it), otherwise uses the read client. Do not rely on this tool until the gating is characterized.

Forensic detail for one clip/alert: resolution, duration, AI/profile/schedule/zones active at trigger time. Pass clip 'path' from bi_list_alerts.

Informational tool — surfaces cross-camera action-row outliers for user review. Walks every camera's .reg export, buckets action rows into cohorts by (type, description, type-specific key), and reports fields where one camera's value deviates from the cohort's modal value under 'outliers'. Per-camera path tokens (e.g. 'ai/SecCam_3/motion') are templated to '' before comparison so legitimate per-camera substitution doesn't false-positive. The 'enabled' field is reported separately under 'disabled_outliers' so a row left disabled by accident is easy to spot. Outliers are NOT necessarily bugs — they may be intentional per-camera customizations (e.g. one camera filtering different trigger sources, or running a narrower profile set). Present findings to the user as 'values worth confirming' and ask whether each is intentional. Pure read; no live BI connection.

List of all cameras and groups: online state, motion/trigger/alert counts, stream bitrate/FPS/resolution, last alert time, error state.

Per-camera config + state. With admin creds, calls camconfig to return motion sensitivity, AI zones, recording mode, stream paths, schedule/profile flags. Without admin, falls back to filtered camlist state. Trigger zone polygons, per-class AI thresholds, and alert action definitions are NOT exposed by BI's JSON API — use bi_get_reg for those.

Live motion + post-trigger settings for a camera, read from BI's admin camconfig cmd. Use this instead of bi_get_reg(key_path='Motion') to avoid stale .reg exports when tuning sensitivity/contrast/breaktime. Returns motion (12 keys: sense, contrast, breaktime, maketime, usemask, objects, ai_zones, shadows, luminance, showmotion, audio_trigger, audio_sense) and post (timed, timed_interval) plus verbatim motion_raw / post_raw twins. AI thresholds (smartconf, smartlabels, periodic, static-objects) are NOT in camconfig — use bi_get_reg(key_path='AI\') for those. Trigger-zone polygons stay in bi_get_reg(key_path='Motion') under maskbits_*. Admin-required. Note: the camconfig set-half for setmotion/setpost is a silent no-op in 5.9.9.71 — this tool is read-only by design; tune in the BI UI.

Recent recorded clips for a camera: path, duration, resolution, flags, memo. Complementary to bi_list_alerts (clips include continuous recordings; alerts are AI/motion events). Requires 'camera' short name (or 'Index' for all). Optional 'view' (filter; see schema for full enum), 'startdate'/'enddate' accept unix epoch int, ISO-8601, or relative shorthand ('-2h', '-1d'). 'search' (memo substring, server-side), 'tiles' (true=one entry per day, useful for calendar views). 'limit' default 50. Crossover note: alert-side view values (e.g. 'alerts', 'people', 'zonea') will return alert items in this response — they have an 'msec' field meaning alert length (not clip length) and lack the 'zones' field. UI3 v91 fixed a bug where this was mishandled.

Use after bi_list_alerts to decode what actions fired on a specific alert. Pass the alert's path from that response. Explain a specific alert's action chain. Given (camera, alert_path), returns the alert's facts (memo, profile/preset at trigger, zones), each action row with its decoded filters, comparator verdicts for the cases that need them (compound predicates like 'car+licenseplate', confidence thresholds like 'person:80', cross-zone sequencing, wait-row gating), and a ±2-minute log cross-reference of what BI actually did (MQTT publishes, email/SMS/FTP results, AI cancellations). Simple filter matches (object-in-list, profile, source bit) are surfaced as raw facts; the caller decides FIRED vs SUPPRESSED for those. Admin-gated (uses the log cmd).

Recent Blue Iris system log entries with optional filters.

Pick the right tool: for reconstructing 'what fired when' on a camera, start with bi_list_alerts — per-alert timestamps with no dedup. This log is best for system events (profile changes, disk ops, logins, errors) and aggregate activity counts.

Filters: since — UTC epoch sec, ISO-8601, or '-15m'/'-2h'/'-1d' (server-side via aftertime) camera — exact match on entry.obj (clone cameras log under their own short names) obj — exact match on entry.obj (escape hatch: 'App', 'MQTT', 'DB', 'AI_Input', drive letters, usernames) levels — list of accepted level ints; empirical: 0=info, 1=warn, 2=error, 3=trigger/alert aggregate (deduped — use bi_list_alerts for per-event), 4=status change, 10=user match — case-insensitive substring on entry.msg regex — Python regex on entry.msg (IGNORECASE); xor with match limit — applied AFTER filtering (default 100)

Returns {entries, scanned, matched, warning?}. raw=true bypasses the envelope and shaper. Admin required.

BI aggregates repeated messages: count is cumulative since BI startup (or last log clear), and date is when BI last summed the entry, not necessarily the most recent occurrence. To tell whether a message is actively firing now, re-query with a tight since=-5m window.

PTZ state for one camera. All fields BI returns are passed through (presets[], presetnum, brightness, contrast, irmode, powermode, talksamplerate). Adds two derived helpers: 'preset_map' = {N: description, ...} keyed by preset number (UI3 source: presets[] is 1-indexed by position; "(undefined)" and empty descriptions are dropped), and 'active_preset' = {num, description} when presetnum is set. Camera must have PTZ enabled in BI.

Parse a camera's .reg export and return the requested key subtree. Use this for what the BI JSON API does NOT expose: trigger zone polygons (Motion<profile>\maskbits_*), per-class AI confidence thresholds (AI<profile>\smartconf), per-preset alert-skip flags (PTZ\Presets<n>\noalerts), ONVIF event handlers (camevents<n>), and alert action definitions (Alerts\OnTrigger). Optional 'key_path' limits the response to that subtree (e.g. 'AI\3' for profile 3 AI config). Returns staleness warning if the .reg file is >7 days old.

Fetch a single current JPEG frame from a camera via GET /image/<short>. Returns the image as base64 — the calling agent decides where (if anywhere) to write it to disk. Useful for cross-referencing live camera coverage against spatial maps, verifying PTZ preset framing, or capturing a still without going through the alert/clip pipeline.

Snapshot of Blue Iris system state: active profile, schedule hold/run, CPU%, RAM, disk usage, uptime, DIO outputs, warnings.

Blue Iris version/license, time zone, capabilities of the current user (admin/ptz/clips/etc), and available profile/schedule/stream names.

System config snapshot (admin required): FTP archive enable, global schedule on/off, manual record time limit, plus any DIO/MQTT state BI exposes inline. Use this instead of asking the user to screenshot Settings → Other.

24-hour activity timeline (motion/trigger/alert buckets) for a camera. Requires 'camera' short name. If both 'startdate' and 'enddate' are omitted, defaults to the last 24 hours (BI returns empty spans for a rangeless query).