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.

3.1 KiB Raw Blame History