61 lines
3.1 KiB
Markdown
61 lines
3.1 KiB
Markdown
# UniFi Protect Doorbell / Chime Current State — 2026-05-26
|
|
|
|
Purpose: capture the current known-good state for the adopted doorbell and the two Protect WiFi chimes so future cleanup work does not accidentally re-run a reverted change.
|
|
|
|
## Status summary
|
|
|
|
Current known-good state:
|
|
- `front-doorbell` remains the Protect doorbell endpoint
|
|
- Protect WiFi Chime `upstairs landing` is intentionally on `Management` / default `UniFi Wireless`
|
|
- Protect WiFi Chime `Living Room` is intentionally on `Management` / default `UniFi Wireless`
|
|
- per-client Camera virtual-network overrides for the chimes should remain disabled unless a later validation proves a safe Protect path on the Camera/Security lane
|
|
|
|
Current chime IPs from the last known-good state:
|
|
- `upstairs landing` -> `10.5.0.123`
|
|
- `Living Room` -> `10.5.0.189`
|
|
|
|
## What changed from the earlier migration notes
|
|
|
|
Historical 2026-05-22 action:
|
|
- both chimes were moved from `Management` to `Camera` using per-client virtual network overrides
|
|
- UniFi Network showed them associated on the target lane
|
|
|
|
Why that is not the source of truth anymore:
|
|
- in this environment, the Camera-lane override made the chimes show offline in Protect even though UniFi Network still showed them connected
|
|
- the working fix was to remove the Camera override and let the chimes return to the known-good Management/default-SSID path
|
|
|
|
Operational conclusion:
|
|
- treat the 2026-05-22 chime move as a historical experiment, not a standing recommendation
|
|
- do not re-home the chimes to `Camera` / `Security` as routine cleanup without fresh Protect validation
|
|
|
|
## Doorbell adoption note
|
|
|
|
After a doorbell is re-adopted:
|
|
- verify the chimes are still logically bound to the current adopted doorbell object
|
|
- if chime ringing breaks even though the devices are online, check whether each chime's `ringSettings.cameraId` still points at the old doorbell object instead of the current adopted one
|
|
|
|
This is separate from the network-lane issue:
|
|
- network-lane failure symptom: chime looks connected in UniFi Network but offline in Protect
|
|
- adoption-binding failure symptom: doorbell is adopted and devices are online, but the chimes do not ring for the current doorbell object
|
|
|
|
## Future-state intent versus current safe state
|
|
|
|
Long-term design intent still favors a dedicated Camera/Security lane and SSID for Protect accessories.
|
|
|
|
Current safe live state is narrower:
|
|
- doorbell can stay where it is if healthy
|
|
- chimes stay on Management/default `UniFi Wireless` until Protect connectivity is explicitly re-validated on the Camera/Security lane
|
|
- future migration is blocked on proving the required Protect path, not on re-discovering the device identities
|
|
|
|
## Files that were updated to reflect this
|
|
|
|
Key current-truth docs:
|
|
- `network-migration-remaining-checklist-2026-05-22.md`
|
|
- `unifi-client-cleanup-shortlist-2026-05-22.md`
|
|
- `unifi-client-rehome-results-2026-05-22.md`
|
|
- `unifi-ssid-cleanup-proposal-2026-05-23.md`
|
|
- `network-redesign-plan.md`
|
|
- `network-redesign-implementation-runbook.md`
|
|
|
|
Historical planning/snapshot docs were also marked so they are not mistaken for current next-step instructions.
|