docs: clarify current unifi protect chime state
This commit is contained in:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user