tapo-camera（塔波相机）

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.

~/tapo-camera/
├── memory.md               # activation boundaries, preferred capture defaults, and trust limits
├── cameras.md              # hostnames, labels, model notes, and stream capabilities
├── sessions/
│   └── YYYY-MM-DD.md       # capture attempts, failures, and what worked
├── captures/
│   └── ...                 # user-approved local stills only
└── incidents.md            # auth, network, RTSP, and model-specific failure notes

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

Quick Reference

Requirements

• python3
• python-kasa and its kasa CLI for local discovery, device state, and camera module access
• ffmpeg 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 KASA_CREDENTIALS_HASH
• 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
• cameras.md for camera labels, hosts, model quirks, and stream capability notes
• dated session notes for capture attempts and the exact path that worked
• incidents.md 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

External Endpoints

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 ~/tapo-camera/
• 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
• ffmpeg - deeper frame extraction, transcoding, and media inspection once capture works
• smart-home - ecosystem-level device coordination and automation planning
• iot - local-device debugging and network-aware connector reasoning
• photos - organize and inspect saved captures after acquisition

Feedback

• If useful: clawhub star tapo-camera
• Stay updated: clawhub sync