Tapo CameraTapo摄像头连接

When to Use

Use this skill when the user wants an agent to connect to their own Tapo cameras on a trusted local network, verify camera reachability, take still captures, and inspect the resulting frames without defaulting to cloud workflows.

This skill is for local camera operations, not general surveillance design. Keep it scoped to user-owned cameras, explicit capture requests, and reversible local workflows.

Architecture

Memory lives in ~/tapo-camera/. If ~/tapo-camera/ does not exist, run setup.md. See memory-template.md for structure.

CODEBLOCK0

Only create cameras.md, sessions/, captures/, or incidents.md if the user wants persistent local state.

Quick Reference

Topic	File
Setup and activation behavior	INLINECODE8
Memory schema and status values

memory-template.md | | Camera inventory template | cameras.md | | Incident log template | incidents.md | | Discovery, auth, and capability checks | discovery-and-auth.md | | Local still-capture and review flows | snapshot-workflows.md | | Unofficial API fallback boundary | api-fallback.md | | Failure diagnosis and recovery order | troubleshooting.md | | Local capture helper | tapo-capture.py |

Requirements

• - INLINECODE17
• INLINECODE18 and its kasa CLI for local discovery, device state, and camera module access
• INLINECODE20 for one-frame JPEG capture from RTSP
• A Tapo camera account with RTSP and ONVIF enabled in the Tapo app when the model supports third-party compatibility
• Camera host or IP on the same trusted local network as the agent
• Optional environment variables for the helper: TAPO_CAMERA_USERNAME, TAPO_CAMERA_PASSWORD, or INLINECODE23
• Optional unofficial fallback: a local API library only when RTSP or ONVIF is unavailable and the user approves that narrower path

Treat Tapo credentials and KASA_CREDENTIALS_HASH as secrets. Never paste them into chat, commit them to files, or print them back to the user.

Data Storage

Use local notes only when they improve repeatability:

• - the memory file for activation boundaries, privacy limits, and preferred output paths
• INLINECODE25 for camera labels, hosts, model quirks, and stream capability notes
• dated session notes for capture attempts and the exact path that worked
• INLINECODE26 for recurring auth, RTSP, ONVIF, or firmware regressions
• the captures/ folder for user-approved still images only

Core Rules

1. Prove scope and ownership before touching a camera

• - Confirm the camera belongs to the user and the agent is on the same trusted network segment.
• Start with hostname, model, and whether the camera is a direct device or a hub child.
• Do not scan arbitrary ranges or attempt blind discovery outside the explicit device scope.

2. Prefer maintained local tooling first

• - Use python-kasa and the kasa CLI for discovery, auth validation, and camera capability checks.
• Use RTSP and ONVIF on the local camera only after confirming third-party compatibility is enabled.
• Reach for unofficial APIs only when the maintained local path cannot produce the required capture flow.

3. Separate discovery from capture

• - First prove the device answers and the camera module is present.
• Then derive stream capability and capture a single still to an explicit output path.
• Do not mix auth debugging, network probing, and repeated frame capture in one opaque step.

4. Keep secrets out of chat, disk, and process output

• - Inject camera credentials from a secret manager or ephemeral environment variables.
• Do not store raw passwords, reversible credential blobs, or full authenticated RTSP URLs in local notes.
• The helper may use a live RTSP URL internally for ffmpeg, but it should not print that URL unless the user explicitly asks.

5. Capture the smallest useful artifact

• - Default to one still image, not continuous recording.
• Write captures only to a user-approved local path under ~/tapo-camera/captures/ or another explicit destination.
• Name captures with camera label and timestamp so later inspection stays deterministic.

6. Keep the trust boundary local by default

• - Local Tapo device traffic is allowed only to the camera host on the user's LAN.
• Do not upload frames to cloud vision services, shared drives, or chat surfaces unless the user explicitly requests it.
• If the user wants remote or cloud workflows, stop and restate what data would leave the machine first.

7. Fall back deterministically

• - If kasa cannot expose a camera module or RTSP URL, check model support, privacy mode, and third-party compatibility before changing approach.
• If the camera is a hub child, battery device, or a model with broken RTSP support, use the API fallback playbook and keep that path local-first.
• Record the final working path so the next capture does not repeat the same trial-and-error.

Capture Traps

Trap	Why It Fails	Better Move
Treating every Tapo device like a direct RTSP camera	Hub children and some battery devices do not expose the same local stream surface	Identify device class first, then choose RTSP, ONVIF, or API fallback
Printing the full RTSP URL into logs

That leaks camera credentials into history and shared output | Keep URLs redacted by default and only reveal them on explicit request | | Using cloud login assumptions for local capture | Local device auth and camera account setup are separate in practice | Verify the camera account and third-party compatibility state first | | Jumping straight to repeated frame pulls | Harder to debug and easier to cross privacy boundaries | Prove one still capture before any loop or batch job | | Storing captures and credentials together | Raises the blast radius if the local folder is copied or synced | Keep images and secrets separate, and never persist secrets in ~/tapo-camera/ |

External Endpoints

Endpoint	Data Sent	Purpose
INLINECODE34	local camera authentication and feature queries	local device connection through INLINECODE35
INLINECODE36 or INLINECODE37

local camera credentials and stream request | still capture via ffmpeg from the LAN stream | | http://{camera-host}:2020/onvif/device_service | local device-service requests | ONVIF capability checks when enabled on the camera |

No third-party endpoint is part of the default workflow.

Security & Privacy

Data that may leave your machine:

• - Nothing to third parties by default
• Local-LAN requests to the user's camera host for auth, capability checks, and frame capture

Data that stays local:

• - User-approved notes under INLINECODE40
• Captured stills in a local folder chosen by the user
• Troubleshooting logs and device capability notes

This skill does NOT:

• - store camera passwords, tokens, or reversible credential blobs in plain text
• capture or upload images without explicit user intent
• run undeclared cloud vision or cloud relay workflows
• modify camera firmware, privacy settings, or motor position by default
• access files outside the working directory or ~/tapo-camera/ for memory

Scope

This skill ONLY:

• - connects to user-owned Tapo cameras on a trusted local network
• validates local access with maintained tools
• captures still images to explicit local paths
• documents the minimum fallback needed when RTSP or ONVIF is unavailable

This skill NEVER:

• - brute-force camera credentials or scan arbitrary networks
• enable silent background monitoring
• upload frames to external services by default
• treat hub children, battery devices, and direct cameras as interchangeable
• rewrite the installed skill files

Related Skills

Install with clawhub install <slug> if user confirms:

• - cameras - broader camera capture and review workflows outside the Tapo-specific lane
• INLINECODE44 - deeper frame extraction, transcoding, and media inspection once capture works
• INLINECODE45 - ecosystem-level device coordination and automation planning
• INLINECODE46 - local-device debugging and network-aware connector reasoning
• INLINECODE47 - organize and inspect saved captures after acquisition

Feedback

• - If useful: INLINECODE48
• Stay updated: INLINECODE49