Imported from HybridAIOne/hybridclaw (skills/blink/SKILL.md). Install upstream with npx skills add HybridAIOne/hybridclaw --skill blink. Copyright stays with the author.

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:

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

3. Local console fallback:

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.

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:

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:

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, command id if known, command status fields, freshness/display guidance, and the fact that no fresh image was verified.

If camera-thumbnail-refresh returns result.freshness.reason: "system-busy", say Blink returned a busy response before accepting the thumbnail command and suggest retrying later. Do not describe this as Blink server overload, rate limiting, repeated-snapshot throttling, or proof for or against a camera problem unless the same response explicitly says so.

plan emits no live side effect. It returns approvalText, approvedHelperCommandText, the exact target host/path/method, and the bounded httpRequest shape. Stop after producing the plan. Only after the operator confirms that exact network/camera/clip/action through F8/F14, run the approved helper command exactly.

Read Workflow

1. Use devices-list first for a compact account overview; it includes networks, sync modules, cameras, and doorbell-like devices on current Blink accounts.
2. If devices-list returns blink-login-required or fails because BLINK_AUTH_TOKEN, BLINK_REFRESH_TOKEN, BLINK_TIER, or BLINK_ACCOUNT_ID is missing or stale, run node skills/blink/blink.cjs --format json run account-refresh once before account-login. Do not tell the operator all Blink credentials are missing just because token/tier/account session secrets are not set yet.
3. If refresh cannot recover the session, run node skills/blink/blink.cjs --format json run account-login once.
4. If login returns handover-required, ask for the Blink PIN via F14. When the operator provides the PIN, run exactly node skills/blink/blink.cjs --format json run account-login --pin <code>, then immediately run node skills/blink/blink.cjs --format json run devices-list if login succeeds. Do not read source, inspect secrets, call http_request, or try direct gateway/curl calls between those two helper commands.
5. If login or the PIN resume fails, report the helper error and stop. Do not guess alternate endpoints, read tokens, or retry a fresh login unless the helper explicitly returns another handover-required.
6. If login reports invalid credentials, app update, unsupported grant, or verification failure, stop immediately; do not try guessed API versions, OAuth password-grant, or User-Agent variants.
7. Use the narrower list commands when the operator asks for a specific network or device class; use camera-config-read for motion/video/illuminator settings and camera-signals-read for camera battery, Wi-Fi/sync signal, and temperature telemetry when the homescreen response is not enough.
8. For incident-card summaries, report concrete device ids/names, network ids, offline duration, low battery, poor signal, temperature, and motion bursts only from successful live Blink responses.

Guarded Writes

Network arm/disarm, per-camera motion detection, thumbnail snapshots, clip-state changes, deletion, and live view all affect privacy or retention. They are amber/red and require exact F8/F14 approval with the target network, camera, clip, and action in the approval text.

The bounded Blink API surface used by this skill does not expose camera or sync module reboot/restart commands. Do not claim a remote reboot is available and do not probe for reboot, restart, reset, firmware, or maintenance endpoints.

Do not perform destructive maintenance, account changes, password changes, notification setting changes, or firmware actions through this skill.

References

• BlinkPy: https://github.com/fronzbot/blinkpy
• BlinkMonitorProtocol: https://github.com/MattTW/BlinkMonitorProtocol
• Home Assistant Blink integration: https://www.home-assistant.io/integrations/blink/