**Note** from Bead: Axis Cameras · [canonical source](https://redfish.acequia.io/guerin/.agents/d718e68a-cb63-49c5-9d53-e162adf7440c/2026-06-20/notes/00-axis-cameras-orientation.md) · session 2026-06-20 · discussion: Talk: Axis Cameras
**Read first.** This note bootstraps a denovo agent picking up the `axis-cameras` thread.
## What this bead is for Onboarding and managing **Axis network cameras as `realtime.earth` domains**. Axis cameras are not web servers; they expose the **VAPIX HTTP API** (digest auth, *not* basic) and run embedded Linux with the **ACAP** app platform. Each camera is modelled as a site folder `<name>.realtime.earth/` whose `.site` file declares the device, the VAPIX route, and a credential reference; the secret itself lives in `.credentials/`.
## The methodological frame (camera-as-resource) A camera is a **resource** in the URI sense: a path that resolves not to a file but to a device with a verb vocabulary (snapshot, stream, PTZ, list-accounts, list-params, ACAP deploy). The `.site` file is the binding from a `realtime.earth` domain name to that resource and its route. This is the same agent-as-file / resource duck-typing pattern that runs through the ecology — a `realtime.earth` subdomain *is* the camera.
## The canonical reference vs this workshop - **Canonical:** [`.ai/axis-cameras.md`](c:/Users/steph/Documents/sites/.ai/axis-cameras.md) — VAPIX endpoint quick-reference, per-camera account tables (retrieved 2026-04-17), and a full ACAP deployment guide (C/shell/Python, `.eap` packaging, `applications/*.cgi`). - **Workshop:** this bead — experiments, per-onboarding notes, VAPIX/ACAP tools as `skills/`. - **Rule:** durable conventions discovered here are promoted *back* into `.ai/axis-cameras.md`.
## VAPIX cheat sheet (digest auth) ``` curl --digest -u user:pass http://<host>/axis-cgi/jpg/image.cgi # snapshot curl --digest -u user:pass http://<host>/axis-cgi/mjpg/video.cgi # MJPEG stream curl --digest -u user:pass "http://<host>/axis-cgi/pwdgrp.cgi?action=get" # accounts/roles curl --digest -u user:pass "http://<host>/axis-cgi/param.cgi?action=list" # device params curl --digest -u user:pass http://<host>/axis-cgi/com/ptz.cgi # PTZ control ``` Roles: **admin** (full config), **operator** (PTZ + streaming), **viewer** (read-only), **ptz** (movement). VAPIX passwords are **not** retrievable via the API.
## Current cameras (sites) | Site | Device | Route | Credential | |------|--------|-------|------------| | `simtable1.realtime.earth` | Axis **Q6075** PTZ dome, **firewatch** (outdoor, Los Alamos SALA) | `http://santafetreehouse.dyndns.org` (digest) | `.credentials/santafetreehouse.dyndns.org.json` (user `simtable`) | | `sala.realtime.earth` | Axis camera (indoor, Los Alamos SALA) | `http://67.133.86.244:5901` (digest) | `.credentials/sala-axis.json` |
## What happened this session (2026-06-20) Stephen asked to "create site `http://santafetreehouse.dyndns.org/`" for an **Axis 6075 firewatch camera** for `realtime.earth`, expecting to supply credentials later, and to start this bead. On survey, that hostname was **already** the VAPIX route for the existing `simtable1.realtime.earth` site, with **working credentials already on disk** (user `simtable`, retrieved 2026-04-17). I surfaced the overlap. Stephen confirmed the Q6075 **is that same physical device** and to **keep `simtable1`**. So the work was an *enrichment*, not a new site: - `simtable1.realtime.earth/.site`: `model` → `Axis Q6075 (PTZ network dome)`, added `role: firewatch`. - `.ai/axis-cameras.md`: same model/role update + noted the credential works. - No new credentials needed; the "later" creds were moot.
## Starting orientations for the next move 1. **Verify connectivity** — the camera is reachable via a dyndns hostname that may be stale. A `snapshot`/`accounts` VAPIX call (digest) confirms the device + creds are live *before* building anything on top. 2. **Snapshot/PTZ skill** — a small dep-free helper that reads `<domain>/.site` + the referenced credential and runs the VAPIX verbs would be the first reusable `skill/`. 3. **Firewatch framing** — "firewatch" is a role, not yet a behavior. Open question: does the firewatch role imply scheduled snapshots, an ACAP analytics app (smoke/fire detection), or a feed into `realtime.earth`'s incident tooling? Not yet specified. 4. **Account audit** — re-pull `pwdgrp.cgi?action=get` to refresh the 2026-04-17 account table in `.ai/axis-cameras.md` if accounts may have changed.
## Open questions (carry forward) - Is the dyndns hostname still the right route, or should the camera get a stable `realtime.earth`-native reverse proxy / tunnel instead of `santafetreehouse.dyndns.org`? - What does "firewatch" require operationally (snapshots / ACAP detection / incident feed)? - Q6075 specifics (PTZ presets, ranges, guard tours) — none captured yet.
## Do not - Write into Stephen's global `guerin/` spaces or any site folder without instruction. - Put credentials in the bead tree. - Treat this note as authority over the chat log — if they disagree, the chat log wins.