Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Read Blink camera and video-doorbell state, list motion clips, and prepare guarded home-security control requests without exposing Blink credentials.
user-invocable
true
requires
{"bins":["node"]}
credentials
[{"id":"blink-email","kind":"api_key","required":true,"secret_ref":{"source":"store","id":"BLINK_EMAIL"},"scope":"Blink account email for OAuth v2 login","how_to_obtain":"Set `BLINK_EMAIL` through browser admin at the active `/admin/secrets` route; if browser admin is unavailable, use `/secret set BLINK_EMAIL \"<account email>\"` in browser `/chat` or TUI; local console fallback: `hybridclaw secret set BLINK_EMAIL \"<account email>\"`."},{"id":"blink-password","kind":"api_key","required":true,"secret_ref":{"source":"store","id":"BLINK_PASSWORD"},"scope":"Blink account password for OAuth v2 login","how_to_obtain":"Set `BLINK_PASSWORD` through browser admin at the active `/admin/secrets` route; if browser admin is unavailable, use `/secret set BLINK_PASSWORD \"<account password>\"` in browser `/chat` or TUI; local console fallback: `hybridclaw secret set BLINK_PASSWORD \"<account password>\"`."},{"id":"blink-auth-token","kind":"bearer","required":false,"secret_ref":{"source":"store","id":"BLINK_AUTH_TOKEN"},"scope":"Blink OAuth bearer token captured after login or refresh","how_to_obtain":"Captured by `node skills/blink/blink.cjs --format json run account-login`."},{"id":"blink-refresh-token","kind":"bearer","required":false,"secret_ref":{"source":"store","id":"BLINK_REFRESH_TOKEN"},"scope":"Blink OAuth refresh token captured after login","how_to_obtain":"Captured by `node skills/blink/blink.cjs --format json run account-login`."}]
metadata
{"hybridclaw":{"category":"home-automation","short_description":"Blink camera, video doorbell, motion clip, and guarded privacy-control workflows.","logo_path":"logo.webp","tags":["blink","camera","video-doorbell","home-security","smart-home"],"stakes_tiers":{"green":"[Truncated]","amber":"[Truncated]","red":"[Truncated]"},"escalation":{"writes":"confirm-each","route":"f14"},"cost_measurement":{"system":"UsageTotals","sub_limit_key":"blink"}}}
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 ; do not call old password login endpoints and do not web-search or endpoint-probe inside the user task.
node skills/blink/blink.cjs --format json run account-login
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:
Browser admin: open the active HybridClaw admin URL ending in /admin/secrets and set
BLINK_EMAIL and BLINK_PASSWORD.
Browser /chat or TUI fallback:
/secret set BLINK_EMAIL "<account email>"
/secret set BLINK_PASSWORD "<account password>"
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.
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
Use devices-list first for a compact account overview; it includes networks, sync modules, cameras, and doorbell-like devices on current Blink accounts.
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.
If refresh cannot recover the session, run node skills/blink/blink.cjs --format json run account-login once.
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.
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.
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.
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.
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.
