Tapo Camera

Connect to Tapo cameras, verify local access, capture snapshots, and inspect frames with local-first RTSP workflows and safe fallbacks.

Security Scan

The skill is largely coherent for local Tapo camera snapshot tasks, but there are a few inconsistencies and a small but real credential-exposure risk (ffmpeg invocation) that you should understand before installing.

Purpose & Capability

The name, description, docs, and code all align: discovery with python-kasa, then a one-frame capture via RTSP and ffmpeg. Required binaries (python3, ffmpeg, kasa) and the ~/tapo-camera/ config path make sense for the stated local-first camera workflow. One minor mismatch: the registry-level install spec only lists a brew formula for ffmpeg, while the skill metadata and docs also expect python-kasa (pip) and the kasa CLI; the installer info may be incomplete.

Instruction Scope

Runtime instructions and the script stay focused on user-owned local cameras and explicitly avoid cloud exfiltration. However, the helper passes the full RTSP URL (which can contain credentials) directly to ffmpeg as a command argument; on many systems that can expose credentials via process listings to other local users. The script redacts output by default and only prints the full RTSP URL when --show-rtsp is used, but it does not mitigate process-argument exposure.

Install Mechanism

The only explicit registry install step shown is brew install ffmpeg (reasonable). The SKILL.md metadata lists a pip install for python-kasa in its internal 'install' section, but the registry metadata did not surface that as an install action — installation instructions are mixed between locations. No downloads from untrusted URLs are present.

Credentials

No required secrets are declared; only optional environment variables (TAPO_CAMERA_USERNAME, TAPO_CAMERA_PASSWORD, KASA_CREDENTIALS_HASH) are used, which are appropriate for camera authentication. The single required config path (~/tapo-camera/) is proportionate to the skill's local persistence goals.

Persistence & Privilege

The skill is not always-enabled and does not request unusual platform privileges. It writes only to its own ~/tapo-camera/ area and documents consent before creating files. Autonomous invocation is allowed (default) but not combined with elevated privileges or cross-skill config changes.

What to consider before installing

This skill appears to do what it says (local discovery and one-frame RTSP captures), but consider these before installing: - Confirm install steps: make sure python-kasa (pip) / the kasa CLI will be installed or available, since the registry install spec only showed ffmpeg. The skill needs both python-kasa and the kasa CLI to function. - Avoid revealing credentials: the tool uses RTSP URLs that may embed usernames/passwords. Do not use --show-rtsp unless you understand the risk, and do not paste RTSP URLs or credentials into chat or shared logs. - Be aware of local exposure: passing the RTSP URL to ffmpeg as a command argument can expose credentials to other local users via process lists on some systems. If this is a concern, run captures on a single-user machine, or modify the capture logic to use a secured input method (e.g., ffmpeg reading from a file descriptor or authenticated local proxy). - Review the code (tapo-capture.py) yourself if possible and test on an isolated trusted network first. If you need automated installs, ensure the pip step for python-kasa is explicitly performed by your environment or installer. - If you want stricter guarantees, ask the skill to avoid writing any captures or memory files unless you explicitly approve each write.

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

Topic	File
Setup and activation behavior	setup.md
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

• 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

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
https://{camera-host}	local camera authentication and feature queries	local device connection through python-kasa
rtsp://{camera-host}:554/stream1 or stream2	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 ~/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