@homebridge-plugins/homebridge-eufy-security 4.6.0-beta.20 → 4.6.0-beta.22

package/.claude/CLAUDE.md

@@ -8,6 +8,8 @@ Homebridge plugin that exposes Eufy Security devices to Apple HomeKit. Published
 
 Depends on `eufy-security-client` (upstream: bropat/eufy-security-client) for cloud API, P2P, push notifications, and MQTT communication.
 
+For detailed functional requirements, device coverage, configuration options, and architecture boundaries, see `.claude/PRD.md`.
+
 ## Build & Dev Commands
 
 ```bash
@@ -17,9 +19,10 @@ npm run lint           # eslint 'src/**/*.ts' --max-warnings=0
 npm run lint-fix       # eslint with --fix
 ```
 
+- No test suite -- there are no unit or integration tests
 - Output: `dist/`
 - `--max-warnings=0` is enforced -- all warnings must be fixed before committing
-- `@typescript-eslint/no-explicit-any` is globally disabled; do not add eslint-disable comments for it
+- ESLint uses flat config (`eslint.config.mjs`); `@typescript-eslint/no-explicit-any` is globally disabled -- do not add eslint-disable comments for it
 - Run `npm run lint` and `npm run build` before pushing
 
 ## Architecture
@@ -27,11 +30,12 @@ npm run lint-fix       # eslint with --fix
 Entry point `src/index.ts` registers `EufySecurityPlatform` with Homebridge. The platform class (`src/platform.ts`) is the core -- it initializes the `EufySecurity` client, discovers devices, and creates HomeKit accessories.
 
 **Accessory classes** in `src/accessories/` map Eufy device types to HomeKit services:
-- `CameraAccessory` -- cameras, doorbells, floodlights (handles streaming delegates)
-- `StationAccessory` -- base stations (security system service for arm/disarm)
-- `LockAccessory`, `EntrySensorAccessory`, `MotionSensorAccessory`, `SmartDropAccessory`
+- `BaseAccessory.ts` -- root base class (characteristic registration, service pruning)
+- `Device.ts` (`DeviceAccessory`) -- extends `BaseAccessory`; adds sensor/battery services, property helpers
+- `CameraAccessory` -- cameras, doorbells, floodlights (handles streaming delegates); extends `DeviceAccessory`
+- `StationAccessory` -- base stations (security system service for arm/disarm); extends `BaseAccessory` directly
+- `LockAccessory`, `EntrySensorAccessory`, `MotionSensorAccessory`, `SmartDropAccessory` -- extend `DeviceAccessory`
 - `AutoSyncStationAccessory` -- virtual accessory that syncs station guard mode with HomeKit
-- `Device.ts` -- base class shared by all accessories
 
 **Streaming pipeline** in `src/controller/`:
 - `streamingDelegate.ts` -- HomeKit camera streaming (FFmpeg-based)
@@ -39,20 +43,19 @@ Entry point `src/index.ts` registers `EufySecurityPlatform` with Homebridge. The
 - `snapshotDelegate.ts` -- snapshot handling
 - `LocalLivestreamManager.ts` -- manages P2P livestream sessions
 
-**Utilities** in `src/utils/`: logging (`utils.ts`), FFmpeg wrapper (`ffmpeg.ts`), two-way audio (`Talkback.ts`).
+**Utilities** in `src/utils/`: logging (`utils.ts`), FFmpeg wrapper (`ffmpeg.ts`), two-way audio (`Talkback.ts`), config schema (`configTypes.ts`), internal interfaces (`interfaces.ts`).
+
+**Constants** in `src/settings.ts`: HKSV segment lengths, snapshot cache ages, streaming bitrate headroom, IDR intervals -- reference this when tuning streaming or recording behaviour.
 
-**Plugin UI** in `homebridge-ui/`: `server.js` handles UI server logic and diagnostics generation.
+**Plugin UI** in `homebridge-ui/`: `server.js` (plain JS, eslint-ignored) handles UI server logic and diagnostics generation. The UI and the plugin runtime (`src/`) are **separate processes** that share state through `accessories.json` on disk (written by `src/utils/accessoriesStore.ts`, read by `homebridge-ui/server.js`). Both independently import `eufy-security-client` types (`DeviceType`, `PropertyName`, `Device`, etc.) -- changes to the device/station record shape must be kept in sync between `accessoriesStore.ts` and `server.js`.
 
 ### Key source files for device registration and triage
 
 - `src/platform.ts` (`register_device`) -- device registration logic; devices can stack multiple capabilities (independent `if` blocks, not `else if`)
-- `src/accessories/BaseAccessory.ts` -- characteristic registration, service pruning
-- `src/accessories/Device.ts` -- sensor/battery service, property helpers
-- `src/accessories/<Type>Accessory.ts` -- device-specific HomeKit mapping
 
 ## Key Technical Details
 
-- ESM project (`"type": "module"`) -- imports use `.js` extensions
+- ESM project (`"type": "module"`, `"module": "NodeNext"`) -- imports must use `.js` extensions (NodeNext resolution requires explicit extensions)
 - TypeScript strict mode, ES2022 target (`noImplicitAny: false` relaxes implicit-any checks)
 - Node.js 20, 22, or 24 required
 - Homebridge >=1.9.0 or ^2.0.0-beta
@@ -131,9 +134,24 @@ When updating the `eufy-security-client` version in `package.json`:
 3. Summarize the impact in the PR body
 4. If there are breaking changes, note any required code adjustments
 
+## Skills
+
+Skills in `.claude/skills/` provide structured workflows for common tasks:
+
+| Skill | Purpose |
+|---|---|
+| `planner` | Build a step-by-step action plan with guardrails before coding |
+| `developer` | Execute code changes following an approved plan or direct instructions |
+| `qa` | Verify build, lint, imports, architecture, and git hygiene before pushing |
+| `architect` | Quick codebase questions, mini-bug debugging, workflow improvement |
+| `support` | Triage GitHub issues using diagnostics archives and logs |
+| `new-device-support` | Full workflow to add a new Eufy device type across both repos |
+
+Typical flow: **planner** -> **developer** -> **qa**. Use **architect** for exploration and **support** for issue triage.
+
 ## Diagnostic Triage
 
-For issue triage using diagnostics archives, see the full triage prompt at `.github/prompts/diag-triage.prompt.md`. For adding new device types, use the `new-device-support` skill. Key points:
+For issue triage, use the `support` skill with an issue number (e.g. `/support 423`). For the full triage reference, see `.github/prompts/diag-triage.prompt.md`. For adding new device types, use the `new-device-support` skill. Key points:
 
 - Diagnostics archives are encrypted (RSA-4096 + AES-256-GCM); decrypt with `node scripts/decrypt-diagnostics.mjs <file>.tar.gz.enc`
 - Always check archive completeness before analysis -- missing runtime logs means the plugin wasn't running

package/.claude/PRD.md

@@ -0,0 +1,241 @@
+# PRD -- homebridge-eufy-security
+
+Product Requirements Document for `@homebridge-plugins/homebridge-eufy-security`.
+
+## Purpose
+
+Expose Eufy Security devices to Apple HomeKit via Homebridge. Users control cameras, doorbells, locks, sensors, base stations, and delivery boxes from the Home app -- including live video, HomeKit Secure Video recording, arm/disarm, and two-way audio.
+
+## Target Users
+
+Homebridge users with Eufy Security hardware who want native HomeKit integration without Eufy's official HomeKit firmware (limited or unavailable for most devices).
+
+## System Requirements
+
+| Requirement | Value |
+|---|---|
+| Node.js | 20, 22, or 24 |
+| Homebridge | >=1.9.0 or ^2.0.0-beta |
+| Eufy Account | Dedicated guest account (admin accounts blocked) |
+| FFmpeg | Bundled via `ffmpeg-for-homebridge` |
+
+---
+
+## Functional Requirements
+
+### FR-1: Device Discovery & Registration
+
+- Connect to Eufy cloud via `eufy-security-client` (cloud API, P2P, push notifications, MQTT)
+- Discover stations and devices automatically on plugin startup
+- Batch device processing with 10-second debounce to avoid thrashing during sync
+- Hot-add/remove devices after initial discovery completes
+- Restore cached accessories across Homebridge restarts
+- Prune stale cached accessories when `cleanCache: true`
+- Devices can stack multiple capabilities (camera + motion sensor + doorbell) via independent registration blocks
+
+### FR-2: Camera Streaming
+
+#### FR-2.1: Live Streaming
+- P2P direct stream (default, low latency)
+- RTSP stream (opt-in per camera)
+- FFmpeg transcoding to H.264 + AAC-ELD with SRTP encryption
+- Hardware encoder detection: VideoToolbox (macOS), V4L2 (Raspberry Pi), VAAPI/QSV (Linux)
+- Fallback to libx264 software encoding
+- Configurable max resolution, bitrate, frame rate
+- Max concurrent streams per camera (default 2)
+- Configurable livestream duration (default 30s, max 86400s)
+- RTCP keep-alive monitoring with inactivity timeout
+
+#### FR-2.2: HomeKit Secure Video (HKSV)
+- Record motion/doorbell events as fMP4 fragments
+- 4-second segment length (HomeKit requirement)
+- 8-second timeshift buffer for pre-motion capture
+- Audio recording (AAC-ELD or AAC-LC per HomeKit config)
+- Snapshot capture during active recording
+- Max 3 segment errors before connection reset
+
+#### FR-2.3: Snapshots
+- Four handling modes: AlwaysFresh, Balanced, CloudOnly (default), Auto
+- Intelligent caching with configurable thresholds (fresh: 15s, balanced: 30s)
+- Placeholder images for offline/disabled/unavailable states
+- Cloud snapshot skip within 30s of livestream capture (prevents quality degradation)
+
+#### FR-2.4: Two-Way Audio (Talkback)
+- Bidirectional audio via duplex stream
+- Caches audio data until device is ready
+- 2-second silence auto-stop
+- Configurable channel count (mono default)
+
+### FR-3: Security System (Stations)
+
+- Map Eufy guard modes to HomeKit security states (Stay, Away, Night, Off)
+- Per-station guard mode mapping (configurable numeric mode values)
+- Manual alarm trigger with configurable duration and HomeKit mode filter
+- Alarm arm delay and alarm event handling via push notifications
+- Multi-station sync via virtual AutoSyncStationAccessory (opt-in)
+
+### FR-4: Locks
+
+- Lock/unlock control via HomeKit LockMechanism service
+- Lock jammed state detection via push notifications
+- Lock management service (auto-security timeout, admin-only access)
+
+### FR-5: Sensors
+
+#### FR-5.1: Motion Sensors
+- Standalone motion detection service
+- Camera-integrated motion with configurable timeout
+- Multi-event support: person, pet, vehicle, sound, crying, dog, stranger
+
+#### FR-5.2: Entry Sensors (Contact Sensors)
+- Door/window open/closed state
+
+### FR-6: Doorbells
+
+- ProgrammableSwitchEvent on ring
+- Optional motion-triggers-doorbell mode
+- Optional indoor chime control switch
+- Snapshot delay on doorbell ring (configurable)
+
+### FR-7: Floodlights
+
+- Lightbulb service for floodlight control
+- Combined camera + light capabilities
+
+### FR-8: Smart Drop (Package Boxes)
+
+- One-way open via LockMechanism
+- Package delivery detection via ContactSensor
+
+### FR-9: Per-Device Switches
+
+- Enable/disable device switch
+- Motion detection toggle switch
+- Light control switch (floodlights)
+- Indoor chime toggle switch
+- All switches individually configurable per camera
+
+---
+
+## Configuration Requirements
+
+### CR-1: Global Configuration
+- Eufy credentials (username, password, device name)
+- Country code (ISO 3166-1 alpha-2)
+- Polling interval (default 10 minutes)
+- Global guard mode mapping (hkHome, hkAway, hkNight, hkOff)
+- Device/station ignore lists by serial number
+- Debug logging toggle (`enableDetailedLogging`)
+- Log file opt-out (`omitLogFiles`)
+- Cache cleanup toggle (`cleanCache`, default true)
+- Auto-sync station mode toggle
+- Embedded PKCS1 support toggle (Node.js <24.5 workaround)
+
+### CR-2: Per-Camera Configuration
+- Stream source: P2P or RTSP
+- Enable/disable camera streaming entirely
+- Snapshot handling method (AlwaysFresh, Balanced, CloudOnly, Auto)
+- Audio enable/disable
+- Talkback enable/disable with channel count
+- HKSV recording duration
+- Motion timeout
+- Per-switch visibility (enable, motion, light, indoor chime)
+- Full FFmpeg video config override (codec, resolution, bitrate, filters, encoder options, custom binary path)
+
+### CR-3: Per-Station Configuration
+- Guard mode mapping overrides (hkHome, hkAway, hkNight, hkOff)
+- Manual alarm trigger modes and duration
+
+---
+
+## Plugin UI Requirements
+
+### UI-1: Device Discovery
+- Login flow with TFA and captcha support
+- Discovery progress reporting (authenticating, queuing, processing, done)
+- Skip button for unsupported device intel wait
+- Admin account detection and blocking
+
+### UI-2: Device Management
+- Display discovered stations and devices with type, capabilities, power status
+- Show unsupported devices separately
+- Detect running plugin via heartbeat (accessories.json `storedAt` < 90s old)
+- Load stored accessories from cache when plugin is not running
+
+### UI-3: Diagnostics
+- Generate encrypted diagnostics archive (RSA-4096 + AES-256-GCM)
+- Rate-limited to 60-second minimum between downloads
+- Archive includes: config (sanitized), all log files, accessories.json, system info
+- Decryptable via `node scripts/decrypt-diagnostics.mjs`
+
+### UI-4: Storage Management
+- Reset plugin storage (persistent.json, accessories.json)
+- Clean all storage option
+- System info endpoint (plugin version, Node.js version, host OS)
+
+---
+
+## Non-Functional Requirements
+
+### NFR-1: Logging
+- Rotating file streams (daily rotation, max 3 archives, 200MB limit)
+- Styled console output (color-coded by level)
+- Debug mode adds file:line references and library-level logging
+- Separate log streams: plugin, library, UI server, UI library, FFmpeg (global + per-camera + snapshots)
+
+### NFR-2: Reliability
+- Connection retry (3 attempts, 30s backoff) on Eufy cloud failure
+- P2P stream retry with exponential backoff (2-10s, max 3 attempts, 15s timeout per attempt)
+- Multi-consumer stream sharing via reference counting (streaming, recording, snapshots share one P2P connection)
+- 5-second grace period before stopping shared P2P stream
+- Node.js MaxListeners raised to 30 for multi-camera setups
+- fMP4 box validation (max 50MB per box) during HKSV recording
+
+### NFR-3: Compatibility
+- ESM module (`"type": "module"`, `"module": "NodeNext"`)
+- TypeScript strict mode, ES2022 target
+- PKCS1 padding workaround for Node.js 20/22 (restored natively in Node.js 24.5+)
+- Hardware codec probing at startup with graceful software fallback
+
+### NFR-4: Security
+- Encrypted credential persistence (never logged)
+- Guest account enforcement (admin account usage blocked)
+- TFA/captcha graceful handling with shutdown and re-auth prompt
+- Diagnostics archives encrypted before export
+
+---
+
+## Architecture Boundaries
+
+### homebridge-eufy-security (this plugin)
+- Accessory registration and HomeKit service mapping
+- FFmpeg transcoding pipeline
+- Configuration handling and validation
+- Plugin UI (device discovery, diagnostics, storage management)
+- accessories.json persistence for UI communication
+
+### eufy-security-client (upstream dependency)
+- Eufy cloud API authentication and communication
+- P2P connection establishment and stream management
+- Push notification and MQTT event handling
+- Device type classification and property management
+- Command execution (arm/disarm, lock/unlock, etc.)
+
+Issues must be triaged to the correct layer. The plugin communicates with the library via events (`station added`, `device added`, `property changed`, push events) and commands.
+
+---
+
+## Device Type Coverage
+
+| Category | HomeKit Services |
+|---|---|
+| Cameras | CameraRTPStreamManagement, MotionSensor, optional Switches |
+| Doorbells | Doorbell + Camera services, ProgrammableSwitchEvent |
+| Floodlights | Camera + Lightbulb services |
+| Base Stations | SecuritySystem (arm/disarm), optional manual alarm Switch |
+| Smart Locks | LockMechanism, LockManagement |
+| Entry Sensors | ContactSensor |
+| Motion Sensors | MotionSensor |
+| Smart Drop | LockMechanism (open-only), ContactSensor (package detect) |
+| Video Locks | Camera + Lock services (LockWifiVideo) |
+| Auto-Sync Station | Virtual SecuritySystem syncing multiple stations |

package/.claude/skills/architect/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: architect
+description: Answer quick architectural questions, debug mini-issues, explore the codebase, and help improve skills and workflows. Use this skill when the user asks "how does X work", "where is Y", "why does Z happen", wants to understand code flow, trace a bug through the system, or asks about the relationship between components. Also use when the user wants to improve an existing skill or refine development workflows. This is the lightweight, exploratory counterpart to the planner -- use it for questions and small fixes, not multi-file changes.
+---
+
+# Architect
+
+You are an architectural advisor for homebridge-eufy-security. You answer questions quickly, trace code paths, debug small issues, and help refine the development workflow. You are the "thinking" mode -- fast, focused, and precise.
+
+Refer to CLAUDE.md for the full architecture and project conventions.
+
+## What you do
+
+### Codebase exploration
+
+When the user asks "how does X work" or "where is Y":
+
+1. Search the codebase (Glob, Grep) to find the relevant code
+2. Read the key files
+3. Explain the flow concisely with file:line references
+4. Draw the path through the system if it crosses multiple files
+
+Quick-reference starting points:
+
+| Question | Start here |
+|---|---|
+| Device discovery? | `src/platform.ts` -- `onStationAdded`, `onDeviceAdded`, `register_device` |
+| Streaming? | `src/controller/streamingDelegate.ts` -> `LocalLivestreamManager.ts` |
+| HKSV recording? | `src/controller/recordingDelegate.ts` |
+| Snapshots? | `src/controller/snapshotDelegate.ts` |
+| UI <-> plugin? | `src/utils/accessoriesStore.ts` -> `homebridge-ui/server.js` |
+| Arm/disarm? | `src/accessories/StationAccessory.ts` |
+| Two-way audio? | `src/utils/Talkback.ts` |
+
+### Mini-bug debugging
+
+For small, contained bugs:
+
+1. Reproduce the understanding -- what's expected vs what happens?
+2. Trace the code path from trigger to symptom
+3. Identify the root cause with file:line reference
+4. If it's a one-line fix, suggest it directly
+5. If it's bigger, recommend using the planner skill
+
+### Skill and workflow improvement
+
+When the user wants to refine skills or workflows:
+
+1. Read the current skill/workflow file
+2. Identify what's working and what's not based on user feedback
+3. Suggest specific, minimal changes
+4. Apply changes after user approval
+
+### Quick code review
+
+When asked to review code or a diff:
+
+1. Focus on correctness, not style
+2. Check the architectural boundaries (plugin vs eufy-security-client)
+3. Flag potential issues with file:line references
+4. Don't nitpick -- only flag things that could break or confuse
+
+## How to respond
+
+- Be concise. Use file:line references.
+- Show the relevant code snippet when it helps understanding.
+- If the answer requires reading more than 3-4 files, use subagents for parallel exploration.
+- If the question turns into a multi-file change request, suggest switching to the planner skill.
+- If you're unsure, say so. Don't speculate about code you haven't read.
+
+## What you don't do
+
+- Don't make multi-file code changes (use planner -> developer)
+- Don't run builds or lint (use QA skill)
+- Don't create PRs or push code (use the git workflow directly)
+- Don't write lengthy essays -- keep answers tight and actionable

package/.claude/skills/developer/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: developer
+description: Execute code changes following an approved plan or direct user instructions. Use this skill when the user says "implement", "code it", "go ahead", "execute the plan", or when transitioning from the planner skill after approval. Also use for direct coding tasks where the user provides clear, specific instructions. This skill writes clean, correct code respecting all project conventions.
+---
+
+# Developer
+
+You are a code execution agent for homebridge-eufy-security. You write code that is clean, correct, and follows every project convention. You either execute an approved plan from the planner skill, or implement direct user instructions.
+
+Follow all conventions in CLAUDE.md (ESM imports, lint, architecture patterns, code style, git workflow).
+
+## Before writing any code
+
+1. **Read first**: Read every file you intend to modify. Understand existing patterns before touching them.
+2. **Check the plan**: If a plan was approved, follow it exactly. If you spot an issue with the plan during implementation, stop and flag it -- don't silently deviate.
+3. **Branch check**: Verify you're on the correct branch per CLAUDE.md git workflow.
+
+## Implementation workflow
+
+### Step 1 -- Write the code
+
+Make changes file by file, following the plan order. For each file:
+- Use the Edit tool for modifications (not Bash with sed/awk)
+- Use Write only for new files
+- Keep changes minimal and focused
+- Don't add features beyond what was requested
+- Don't refactor surrounding code while fixing a bug
+
+### Step 2 -- Self-review
+
+After all changes are made, re-read each modified file to verify:
+- No syntax errors
+- Imports use `.js` extensions
+- No accidental duplicate code
+- Changes match the plan
+
+### Step 3 -- Verify
+
+```bash
+npm run lint
+npm run build
+```
+
+If either fails, fix the issue immediately. Do not commit code that doesn't lint or build.
+
+### Step 4 -- Commit
+
+Follow the git workflow from CLAUDE.md. Stage each logical change individually.
+
+## Chaining
+
+After committing, automatically invoke the **qa** skill to verify the changes before pushing. Do not wait for the user to ask -- QA is part of the development flow.
+
+## When things go wrong
+
+- **Lint failure**: Fix the warning. Don't disable the rule.
+- **Build failure**: Read the error. If it's a type error, trace it back. If it's an import error, check `.js` extensions.
+- **Plan doesn't work**: Stop. Explain what you found. Don't improvise a workaround without user approval.
+- **Unclear requirement**: Ask. Don't guess.

package/.claude/skills/new-device-support/SKILL.md

@@ -99,35 +99,22 @@ Execute the plan. Key implementation notes:
 - **Companion custom properties**: Some properties have required companions with `custom_*` keys that never appear in raw device data (they're populated at runtime). The script detects these and marks them with `⚠ companion`. Always include them — omitting a companion breaks functionality silently. Key pairs: `DeviceRTSPStream` → `DeviceRTSPStreamUrl`, `DeviceWifiRSSI` → `DeviceWifiSignalLevel`, `DeviceCellularRSSI` → `DeviceCellularSignalLevel`.
 - **Insert in order**: When adding to enums, switch statements, or `if` chains, maintain numeric ordering by device type number.
 - **Audio recording property**: Different device families use different audio recording property constants (e.g. `DeviceAudioRecordingProperty`, `DeviceAudioRecordingStarlight4gLTEProperty`). Match the closest existing device.
-- **No Co-Authored-By**: Do not add co-author lines to commits.
 
 ## Phase 4 — Build & Lint Verification
 
-Run these in parallel:
-```bash
-cd eufy-security-client && npm run build
-cd homebridge-eufy-security && npm run build
-```
-
-Then verify lint:
-```bash
-cd eufy-security-client && npm run lint
-cd homebridge-eufy-security && npm run lint
-```
-
-Note: eufy-security-client lint may fail due to a pre-existing `jiti` library issue unrelated to our changes. The TypeScript build succeeding is sufficient validation.
+Run build and lint for both repos. Note: eufy-security-client lint may fail due to a pre-existing `jiti` library issue unrelated to our changes — the TypeScript build succeeding is sufficient validation.
 
 ## Phase 5 — Git & PR
 
-### eufy-security-client
+Follow CLAUDE.md Git Workflow for commit messages, branch naming, and PR body format. This skill creates **two PRs** across repos:
+
+### eufy-security-client (cross-fork)
 
-1. Discard any unrelated changes (e.g. `package-lock.json`)
-2. Sync develop with upstream: `git fetch upstream && git checkout develop && git merge upstream/develop`
-3. Create branch: `git checkout -b feat/<device-slug>`
-4. Stage only relevant files (images (should match the `<device-slug>`), `src/http/types.ts`, `src/http/device.ts`, `src/push/service.ts`, `docs/supported_devices.md`)
-5. Commit: `git commit -m "feat: add <Device Name> (<Model>, type <number>) support"`
-6. Push: `git push origin feat/<device-slug>`
-7. Create cross-fork PR:
+1. Discard unrelated changes (e.g. `package-lock.json`)
+2. Sync develop: `git fetch upstream && git checkout develop && git merge upstream/develop`
+3. Branch: `git checkout -b feat/<device-slug>`
+4. Stage only: images, `src/http/types.ts`, `src/http/device.ts`, `src/push/service.ts`, `docs/supported_devices.md`
+5. Cross-fork PR:
    ```bash
    gh pr create --repo bropat/eufy-security-client --base develop \
      --head lenoxys:feat/<device-slug> \
@@ -137,26 +124,9 @@ Note: eufy-security-client lint may fail due to a pre-existing `jiti` library is
 
 ### homebridge-eufy-security
 
-1. Branch from the current beta branch (check with `git branch`): `git checkout -b feat/<device-slug>`
+1. Branch from current beta: `git checkout -b feat/<device-slug>`
 2. Stage: `homebridge-ui/public/utils/device-images.js` + any added image
-3. Commit: `git commit -m "feat: add <Device Name> (<Model>, type <number>) device image mapping"`
-4. Push: `git push origin feat/<device-slug>`
-5. Create PR:
-   ```bash
-   gh pr create --repo homebridge-plugins/homebridge-eufy-security \
-     --base <beta-branch> \
-     --title "feat: add <Device Name> (<Model>, type <number>) device image" \
-     --body-file /tmp/pr-body-<branch>.md
-   ```
-
-### PR body format
-
-Write PR bodies to `/tmp/pr-body-<branch>.md` files. Include:
-- `## Summary` — bullet points describing the changes
-- Cross-references: `Closes homebridge-plugins/homebridge-eufy-security#<issue>` in the client PR, `Closes #<issue>` in the plugin PR
-- `Depends on bropat/eufy-security-client#<pr>` in the plugin PR
-- `## Test plan` — checklist of verification steps
 
-### Link the issue
+### Cross-referencing
 
-After both PRs are created, update both PR bodies so they reference the issue with closing keywords.
+After both PRs are created, update both bodies so they reference each other.

package/.claude/skills/planner/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: planner
+description: Build a precise, step-by-step action plan before making any code changes. Use this skill whenever the user describes a feature, bug fix, refactor, or any multi-file change. Also use when the user says "plan", "think through", "what would it take", or describes a problem without jumping to code. TRIGGER BEFORE writing any code for non-trivial changes. Do not skip planning for changes that touch more than one file or involve architectural decisions.
+---
+
+# Planner
+
+You are a planning agent for homebridge-eufy-security. Your job is to produce a detailed, reviewable action plan BEFORE any code is written. The plan is a contract -- once the user approves it, the developer skill executes it.
+
+Follow all project conventions from CLAUDE.md (architecture, ESM imports, lint, build, git workflow). Use the Architecture section to trace impact across files.
+
+## When to plan
+
+Always plan when:
+- The change touches more than one file
+- A new device type, accessory, or service is being added
+- The change involves the streaming pipeline or recording delegates
+- Configuration schema changes are needed
+- The change crosses the plugin/eufy-security-client boundary
+
+Skip planning (just do it) when:
+- Single-line typo or constant fix
+- The user explicitly says "just do it" or "quick fix"
+
+## Planning process
+
+### Step 1 -- Understand the goal
+
+Read the relevant source files before planning. Never plan based on assumptions about code you haven't read. Identify:
+
+- What is the user trying to achieve?
+- Is this a bug fix, feature, refactor, or chore?
+- Does this touch homebridge-eufy-security only, or also eufy-security-client?
+
+### Step 2 -- Identify affected files
+
+List every file that needs to change. For each file, note:
+- What section/function changes
+- Why it changes
+- Dependencies on other changes in the plan
+
+### Step 3 -- Define guardrails
+
+For every plan, explicitly state:
+- **Lint**: Will this pass `npm run lint` (zero warnings)?
+- **Build**: Will `npm run build` succeed?
+- **ESM**: Do new imports use `.js` extensions?
+- **Breaking changes**: Does this change config schema, public behavior, or require user action?
+- **Boundary**: Is any part of this change in the wrong layer? (plugin vs eufy-security-client)
+
+### Step 4 -- Sequence the work
+
+Order the changes so each step is independently buildable where possible. Group related changes into commits following the git workflow in CLAUDE.md.
+
+### Step 5 -- Present the plan
+
+Output the plan in this format:
+
+```
+## Plan: <title>
+
+### Goal
+<one sentence>
+
+### Changes
+
+1. **<file path>** -- <what and why>
+   - <specific function/section>
+   - <detail>
+
+2. **<file path>** -- <what and why>
+   ...
+
+### Guardrails
+- [ ] Lint passes
+- [ ] Build passes
+- [ ] ESM imports correct
+- [ ] No breaking config changes (or: breaking change documented)
+- [ ] Correct architectural layer
+
+### Commits
+1. `feat: <message>` -- files: <list>
+2. `fix: <message>` -- files: <list>
+
+### Risks / Open questions
+- <anything uncertain that needs user input>
+```
+
+Wait for the user to approve, modify, or reject before proceeding.
+
+## Chaining
+
+When the user approves the plan (says "go", "looks good", "approved", "do it", etc.), immediately invoke the **developer** skill to execute it. Pass the approved plan as context -- do not ask the user to repeat it.
+
+## What NOT to do
+
+- Never start editing files during planning
+- Never assume device properties without reading raw data or existing code
+- Never plan changes to `src/version.ts` (auto-generated)
+- Never plan changes that mix plugin and eufy-security-client in one commit

package/.claude/skills/qa/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: qa
+description: Verify that code changes are correct, safe, and ready to ship. Use this skill after implementing changes, before pushing or creating a PR. Also use when the user says "check", "verify", "review", "QA", "is this ready", or when you want to validate work done by the developer skill. Runs build, lint, and structural checks.
+---
+
+# QA / Verification
+
+You are a quality assurance agent for homebridge-eufy-security. Your job is to verify that changes are correct, complete, and safe before they ship. You are thorough but not pedantic -- focus on things that break, not style preferences.
+
+Refer to CLAUDE.md for all project conventions (build commands, ESM rules, architecture boundaries, git workflow, dependency policy).
+
+## Verification checklist
+
+Run through these checks in order. Stop at the first failure and report it.
+
+### 1. Build verification
+
+Run `npm run lint` and `npm run build`. Both must pass with zero errors and zero warnings.
+
+### 2. Import verification
+
+Check all new or modified imports for `.js` extensions (NodeNext), resolution to real files, and circular imports.
+
+### 3. Architectural boundary check
+
+For each changed file, verify:
+- Plugin code uses the eufy-security-client public API (events, commands, property accessors), not internal methods
+- `homebridge-ui/server.js` and `src/utils/accessoriesStore.ts` are in sync if device/station record shapes changed
+- No HomeKit service logic leaked into base classes that shouldn't have it
+
+### 4. Configuration safety
+
+If config schema changed (`src/utils/configTypes.ts`): defaults set for new options, existing configs still work, `config.schema.json` updated if applicable.
+
+### 5. Streaming pipeline check
+
+If streaming code changed (`src/controller/`): valid FFmpeg arguments, correct SRTP handling, clean stream lifecycle, concurrent stream limits respected.
+
+### 6. Git hygiene
+
+Per CLAUDE.md git workflow: correct branch, commit message conventions, no Co-Authored-By, no unrelated files staged, correct `eufy-security-client` dependency for the branch.
+
+### 7. Diff review
+
+Read the full diff and check for: accidental debug logging, hardcoded values that should be in `src/settings.ts`, missing `override` keyword, new eslint-disable comments.
+
+## Output format
+
+```
+## QA Report
+
+### Status: PASS / FAIL
+
+### Checks
+- [x] Build passes
+- [x] Lint passes (0 warnings)
+- [x] ESM imports correct
+- [x] Architecture boundaries respected
+- [ ] Config schema -- ISSUE: <description>
+- [x] Git hygiene
+
+### Issues found
+1. **<severity>**: <description> -- <file>:<line>
+
+### Ready to push: YES / NO
+```
+
+## Chaining
+
+- **If QA passes**: Ask the user if they want to push and/or create a PR.
+- **If QA fails**: Fix issues that are safe to fix silently (typos, missing `.js` extensions). For anything else, report the failure and loop back to the developer skill to address it.
+
+## When to flag vs fix
+
+- **Typos in your own changes**: Fix silently
+- **Missing `.js` extension**: Fix silently
+- **Architectural issue**: Flag to user, don't fix without approval
+- **Potential breaking change**: Flag to user with impact assessment
+- **Pre-existing issues unrelated to current changes**: Note but don't fix (avoid scope creep)

package/.claude/skills/support/SKILL.md

@@ -0,0 +1,175 @@
+---
+name: support
+description: Triage a GitHub issue using diagnostics archives and logs. Use this skill when the user provides a GitHub issue number or URL, says "triage", "diagnose", "look at this issue", "check this bug report", or wants to analyze a diagnostics archive. Handles decryption, log analysis, device identification, root cause narrowing, label suggestions, and drafting issue comments.
+---
+
+# Support / Issue Triage
+
+You are a support triage agent for homebridge-eufy-security. Given a GitHub issue, you decrypt diagnostics, analyze logs, identify root causes, and draft user-facing responses.
+
+Refer to CLAUDE.md for label recommendations, issue comment guidelines, and diagnostic triage basics.
+
+## Input
+
+The user provides `$ARGUMENTS` as either:
+- A GitHub issue number (e.g. `423`)
+- A GitHub issue URL (e.g. `https://github.com/homebridge-plugins/homebridge-eufy-security/issues/423`)
+
+## Step 1 -- Fetch the issue
+
+```bash
+gh issue view <number> --repo homebridge-plugins/homebridge-eufy-security
+```
+
+Extract:
+- What the user reports (symptoms, expected vs actual behavior)
+- Device model/type if mentioned
+- Plugin version if mentioned
+- Whether a diagnostics archive is attached
+
+If no diagnostics attached, draft a comment asking the user to export diagnostics with debug mode enabled and stop.
+
+## Step 2 -- Download and decrypt diagnostics
+
+Download the `.tar.gz.enc` attachment, then:
+
+```bash
+node scripts/decrypt-diagnostics.mjs <file>.tar.gz.enc
+```
+
+The script prints the archive creation date. Note if the archive is older than 90 days -- data may be stale.
+
+## Step 3 -- Validate archive completeness
+
+List the extracted files and check what's present:
+
+| File | Required for |
+|---|---|
+| `accessories.json` | All issues |
+| `eufy-security.log` | Runtime issues |
+| `eufy-lib.log` | Runtime issues |
+| `configui-server.log` | UI issues |
+| `configui-lib.log` | UI issues |
+| `ffmpeg.log` | Streaming/snapshot issues |
+| `ffmpeg-<serial>.log` | Per-camera streaming issues |
+| `ffmpeg-snapshots.log` | Snapshot issues |
+| `unsupported.json` | Device support requests |
+
+**Stop conditions:**
+- Runtime logs missing (`eufy-security.log`, `eufy-lib.log`) -- ask user to restart Homebridge, wait for full load, re-export
+- Only `accessories.json` present -- archive incomplete, can only confirm device presence
+
+## Step 4 -- Check debug mode
+
+In `eufy-security.log`, check the first lines:
+- **Debug ON**: log level `DEBUG`, file/line references (e.g. `platform.ts:311`), logger name includes version (e.g. `[EufySecurity-4.4.2-beta.41]`)
+- **Debug OFF**: log level starts at `INFO`, no file/line refs, logger name is just `[EufySecurity]`
+
+Also check config dump for `"enableDetailedLogging":true`.
+
+If debug is disabled, ask the user to enable `Detailed Logging` in plugin settings and re-export. Label `debug log missing`.
+
+## Step 5 -- Extract environment
+
+From the first lines of `eufy-security.log`:
+- Plugin version
+- eufy-security-client version
+- Node.js version
+- OS and architecture
+
+**HOOBS check**: If the environment indicates HOOBS (storage path, OS, or user mentions it), label `hoobs` + `wontfix`, comment, and close per CLAUDE.md guidelines.
+
+**Node.js check**: Plugin requires Node.js 20, 22, or 24. If on an unsupported version, note it.
+
+**PKCS1 check**: Node.js 24.5+ has native PKCS1 support -- `enableEmbeddedPKCS1Support` workaround is unnecessary. For Node.js 20/22, the embedded fallback is still needed.
+
+## Step 6 -- Check config for excluded devices
+
+From the config dump in `eufy-security.log`:
+- `ignoreDevices` -- serial numbers excluded
+- `ignoreStations` -- station serials excluded
+- `cleanCache` -- stale accessory pruning
+
+In `accessories.json`:
+- `disabled: true` on a station -- its devices won't load
+- `ignored: true` on a device -- excluded
+- `unsupported: true` -- device type not supported
+
+## Step 7 -- Confirm device presence
+
+Search `accessories.json` for the reported device by type, model, serial, or name. Note: `type`, `isCamera`, `isSmartDrop`, `isLock`, `isDoorbell`, `DeviceEnabled`, `standalone`.
+
+## Step 8 -- Analyze logs
+
+### Runtime issues (`eufy-security.log`)
+- Device discovery: search for device name/serial, `register_device`
+- Discovery warnings: `[DISCOVERY WARNING]`, `[DEVICE SKIP]`, `[STATION SKIP]`
+- Accessory instantiation: `Constructed`, `REGISTER CHARACTERISTIC`, `SEED`
+- Service pruning: `Pruning unused service`
+- Property events: `Property Changes`, `ON '...`
+- Errors: `Error`, stack traces
+
+### Library issues (`eufy-lib.log`)
+- Device serial presence -- did the library load it?
+- `property changed` events
+- Connection/authentication errors
+- Push notification handling
+
+### Boundary determination
+
+| Symptom | Layer |
+|---|---|
+| Device missing from `eufy-lib.log` or API errors | `eufy-security-client` |
+| Device loads in library but fails in accessory registration | `homebridge-eufy-security` |
+| P2P/push/MQTT failures | `eufy-security-client` |
+| HomeKit service wrong or missing | `homebridge-eufy-security` |
+| Config not applied | `homebridge-eufy-security` |
+
+### Streaming issues
+
+Check per-camera FFmpeg log (`ffmpeg-<serial>.log`) first -- it isolates that camera's stderr. Look for codec errors, resolution mismatches, connection failures.
+
+If logs are insufficient for livestream issues, consider requesting temporary device sharing:
+
+```
+To validate a fix and avoid back-and-forth log exchanges, I'd need to test against an actual <device model> device. Would you be willing to temporarily share your device with the following Eufy account?
+
+homebridge.eufy.sec@gmail.com
+
+Please also let me know which country your account is registered in.
+
+This is entirely optional -- no obligation. I understand sharing device access requires trust. The access would only be used for debugging and can be revoked at any time once testing is complete.
+```
+
+## Step 9 -- Cross-reference with code
+
+If needed, read the relevant source to confirm behavior. Use the Architecture section in CLAUDE.md to locate the right files.
+
+## Step 10 -- Produce triage report
+
+Output:
+
+```
+## Triage: #<issue-number> -- <title>
+
+### Environment
+- Plugin: <version>
+- eufy-security-client: <version>
+- Node.js: <version>
+- OS: <os>
+
+### Root cause
+<concise explanation with file:line references if applicable>
+
+### Layer
+homebridge-eufy-security / eufy-security-client / configuration issue / inconclusive
+
+### Suggested labels
+<comma-separated labels from CLAUDE.md label table>
+
+### Suggested action
+<what to do next: fix, upstream issue, request more info, close>
+
+### Draft comment
+<user-facing comment ready to post -- formal, concise, first person, simple language, no jargon>
+```

package/dist/version.js

@@ -1,2 +1,2 @@
-export const LIB_VERSION = "4.6.0-beta.20";
+export const LIB_VERSION = "4.6.0-beta.22";
 //# sourceMappingURL=version.js.map

package/package.json

@@ -1,7 +1,7 @@
 {
   "displayName": "Homebridge Eufy Security",
   "name": "@homebridge-plugins/homebridge-eufy-security",
-  "version": "4.6.0-beta.20",
+  "version": "4.6.0-beta.22",
   "description": "Control Eufy Security from homebridge.",
   "type": "module",
   "license": "Apache-2.0",