docs: clarify current unifi protect chime state
Some checks failed
secret-guardrails / artifact-secret-scan (push) Has been cancelled
secret-guardrails / gitleaks (push) Has been cancelled

This commit is contained in:
Fizzlepoof
2026-05-26 20:10:45 +00:00
parent a282fe43bd
commit 77da65e64a
16 changed files with 193 additions and 43 deletions

View File

@@ -49,6 +49,11 @@ Architecture summary:
- Contains: doorbell, Protect chimes, future cameras, NVR-adjacent accessories, security-specific Wi-Fi endpoints
- Policy: no broad access to LAN; only specific flows to Protect/NVR services and operator/admin clients
Current live exception:
- this is still the target design, not the currently proven-safe lane for every Protect accessory
- a 2026-05-22 client-override attempt put the Wi-Fi chimes on the Camera lane, but they later had to be returned to Management/default `UniFi Wireless` because Protect health failed there
- future camera/security-lane work must preserve this documented exception until Protect connectivity is explicitly re-validated
## SSID Plan
Preferred steady-state SSIDs:
@@ -107,7 +112,7 @@ IoT / Smart Home:
Cameras / Security:
- front-doorbell
- Protect chimes
- Protect chimes (target design; current live exception keeps the Wi-Fi chimes on Management/default `UniFi Wireless` until Protect validation exists on the security lane)
- future wired/PoE cameras
- future Wi-Fi security accessories
@@ -176,7 +181,7 @@ Phase 2: servers
- update DNS/static mappings/firewall rules
Phase 3: cameras/security
- move doorbell and chimes to VLAN 60
- move doorbell and chimes to VLAN 60 only after explicit Protect-path validation proves that the Wi-Fi chimes stay healthy there
- prepare room for future camera growth
Phase 4: IoT migration