# 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.