blink

Files (3)

• SKILL.md
• blink.cjs
• logo.webp

SKILL.md (first lines)

# Blink

Use this skill for Blink camera, video doorbell, network arm-state, motion
event, and clip-metadata workflows. Blink does not publish an official public
API; this skill follows the bounded community API surface used by BlinkPy,
BlinkMonitorProtocol, and Home Assistant. Treat endpoint behavior as
best-effort and stop on the first authentication or verification failure.

## Core Contract

- Build and run all Blink API calls with `skills/blink/blink.cjs`; do not handcraft Blink URLs, auth headers, or JSON bodies when the helper supports the operation.
- Use `run` for live Blink calls. The helper sends its own request objects through the gateway `/api/http/request` path, so the model does not reconstruct endpoint details.
- Use `http-request` only as dry-run JSON for inspection or fallback direct `http_request` execution when helper live execution is unavailable. Pass emitted `httpRequest` fields as structured JSON; do not stringify nested fields such as `captureResponseFields` or `secretHeaders`.
- Never call `http_request` against guessed Blink hosts or paths. Use only the exact structured request emitted by the helper in this turn. If the helper lacks an operation, say the skill does not support that operation instead of probing.
- For ordinary operator requests, do not read or grep `skills/blink/blink.cjs` to debug the helper. Trust the helper output. Source inspection is for maintainers changing this skill, not for listing devices.
- Helper operations use subject-verb names (`devices-list`, `account-login`, `camera-motion-set`). Legacy aliases are accepted, but prefer the canonical names shown below.
- Credentials and tokens must stay in the SecretRef-backed runtime secret store; never ask the operator to paste `BLINK_PASSWORD` or `BLINK_AUTH_TOKEN` into chat, and never include either value in prose.
- Do not run `hybridclaw secret get`, call `/api/secret`, inspect `env`, or use `curl`/ad hoc scripts to fetch Blink secrets. If the helper reports missing session secrets such as `BLINK_TIER`, run `run account-refresh` once, then `run account-login` if refresh cannot recover the session; email/password may already be stored.
- `account-login` is implemented as OAuth v2 Authorization Code + PKCE in the helper. Run `node skills/blink/blink.cjs --format json run account-login`; do not call old password login endpoints and do not web-search or endpoint-probe inside the user task.
- The Blink-specific implementation lives under `skills/blink/`; the gateway pieces this skill relies on are generic `http_request` primitives for nested response capture, explicit token bind-domain capture, secret-backed headers, manual redirect inspection, and response-body suppression.
- The helper owns all Blink host and path selection; arbitrary host/path passthrough is not supported.
- Clip downloads must go through the gateway artifact path; return artifact handles or metadata only, and rely on the helper-emitted `suppressResponseBody: true` so raw video bytes do not enter model context.
- Live-view requests are red and operator-UI-only; the helper emits `suppressResponseBody: true`, and RTSP/HLS/session handles must not be copied into chat even after approval.
- Stop after the first 401, invalid-credentials, or verification-required response; do not retry, poll, or fan out more Blink calls until credentials or the PIN handover are resolved.
- Stop after a 426 `app update is required` response or OAuth `unsupported_grant_type`. Do not probe alternate Blink endpoints, try new User-Agents, or attempt OAuth `grant_type=password`; use the helper's OAuth v2 Authorization Code + PKCE path with cookie and redirect handling outside model context.

## Setup

Set the initial secrets in this order:

1. Browser admin: open the active HybridClaw admin URL ending in `/admin/secrets` and set
   `BLINK_EMAIL` and `BLINK_PASSWORD`.
2. Browser `/chat` or TUI fallback:

```text
/secret set BLINK_EMAIL "<account email>"
/secret set BLINK_PASSWORD "<account password>"
```

3. Local console fallback:

```bash
hybridclaw secret set BLINK_EMAIL "<account email>"
hybridclaw secret set BLINK_PASSWORD "<account password>"
```

`BLINK_DEVICE_ID` and `BLINK_CLIENT_NAME` are not secrets. The helper generates a stable OAuth hardware id automatically; `BLINK_DEVICE_ID` is only an optional advanced override. `BLINK_CLIENT_NAME` is retained as a non-secret compatibility label and is not sent to Blink OAuth v2.

```bash
node skills/blink/blink.cjs --format json run account-login
```

Successful OAuth v2 login captures:

`BLINK_AUTH_TOKEN`, `BLINK_REFRESH_TOKEN`, `BLINK_TIER`, `BLINK_ACCOUNT_ID`,
and `BLINK_CLIENT_ID`. Do not ask the operator to set these manually after
login; the gateway writes them to the secret store automatically.

If Blink marks the client as unverified, it sends an email/SMS PIN. Use F14
durable handover to receive that PIN from the operator, then run the
login helper with the PIN:

```bash
node skills/blink/blink.cjs --format json run account-login --pin "<code>"
```

The PIN can appear in helper arguments because it is a short-lived operator
handover code; the password and auth token must never appear there.

## Helper Commands

Use this command surface directly:

```text
node skills/blink/blink.cjs [--format json|pretty] http-request <operation> [flags]
node skills/blink/blink.cjs [--format json|pretty] run <operation> [flags]
node skills/blink/blink.cjs [--format json|pretty] plan <operation> [flags]

run account-login [--pin <code>]
run account-refresh
run devices-list

http-request account-login
http-request account-refresh
http-request pin-verify --pin <code>
http-request devices-list
http-request networks-list
http-request network-status-read --network <network-id>
http-request sync-modules-list --network <network-id>
http-request cameras-list --network <network-id>
http-request camera-config-read --network <network-id> --camera <camera-id>
http-request camera-signals-read --network <network-id> --camera <camera-id>
http-request doorbells-list --network <network-id>
http-request motion-events-list --network <network-id> --since 2026-05-26T00:00:00Z
http-request clips-list [--network <network-id>] --since 2026-05-26T00:00:00Z --page 0 --max 50
http-request clip-download --path /api/v2/accounts/<account-id>/media/clip/<file.mp4> [--filename clip.mp4]
http-request thumbnail-download --path /api/v3/media/accounts/<account-id>/networks/<network-id>/<camera-type>/<camera-id>/thumbnail/thumbnail.jpg?ts=<ts>&ext= [--filename camera.jpg]

plan network-arm --network <network-id>
plan network-disarm --network <network-id>
plan camera-motion-set --network <network-id> --camera <camera-id> --enable true
plan camera-thumbnail-refresh --network <network-id> --camera <camera-id> [--camera-type default|mini|doorbell] [--filename camera.jpg]
plan clip-watched-mark --clip <clip-id>
plan clip-delete --clip <clip-id>
plan camera-live-view-start --network <network-id> --camera <camera-id> [--camera-type default|mini|doorbell]
```

Blink clip listing uses the account-scoped `media/changed` API. `clips-list --network <id>` is accepted for the issue-contract command shape, but the helper still calls the account-scoped endpoint and marks the requested network in metadata; filter returned clip metadata by that network before summarizing or choosing a clip path for `clip-download`.
For a current still image, produce a `camera-thumbnail-refresh` plan and, after operator approval, run the plan's `approvedHelperCommandText`. Do not manually stitch together refresh, `devices-list`, and `thumbnail-download`; the approved live helper command owns that full workflow, polls Blink command status, downloads the thumbnail as a gateway artifact only after a successful command, and returns `result.freshness` plus `result.display`. Do not call the image fresh unless `result.freshness.ok` is true. Only display or link the image artifact when `result.display.shouldDisplayArtifact` is true. If `result.freshness.reason` is `command-not-completed` or `command-failed`, report the Blink command status fields and do not download, display, or link any thumbnail. If `result.freshness.thumbnailPathChanged` is false, `result.freshness.sameAsPrevious` is true, `result.display.shouldDisplayArtifact` is false, or a freshness warning is present, say Blink accepted the refresh command but returned the same thumbnail instead of calling it a fresh screenshot. Do not speculate about Wi-Fi, camera hardware, firmware, reachability, or Blink service state unless a separate live Blink response explicitly says so. Do not rewrite thumbnail paths or construct media URLs by hand; the helper routes authenticated requests and stores fresh images as artifacts instead of exposing bytes in model context.

When `camera-thumbnail-refresh` returns `result.failureReportContract`, follow
it exactly. In particular, do not write a "possible reasons" list for a stale
or failed thumbnail. Do not say the camera is offline unless the same successful
live Blink response marks that exact camera offline. Do not use homescreen
`app_updates`, code `105`, or an account-level app-update warning as the cause
of a thumbnail failure unless the refresh or live-view request itself returned
HTTP 426. Do not treat camera `status: "done"`, `updated_at`, or an unchanged
thumbnail timestamp as evidence that the camera has not responded since that
time. A failed thumbnail report should be limited to: camera name/id if known,

From HybridAIOne/hybridclaw, MIT.

More from HybridAIOne/hybridclaw