From 77da65e64a925664bb3c6892d79be137f398c864 Mon Sep 17 00:00:00 2001 From: Fizzlepoof Date: Tue, 26 May 2026 20:10:45 +0000 Subject: [PATCH] docs: clarify current unifi protect chime state --- docs/troubleshooting/KNOWN_QUIRKS.md | 6 ++ .../docs/legacy-cia-triage-worksheet.md | 11 +++- .../network-cutover-master-operator-sheet.md | 29 +++++---- .../docs/network-cutover-minute-checklist.md | 15 +++-- .../docs/network-cutover-red-team-card.md | 4 ++ ...igration-remaining-checklist-2026-05-22.md | 10 +++- ...network-redesign-implementation-runbook.md | 16 +++-- .../docs/network-redesign-plan.md | 9 ++- .../docs/old-iot-tomorrow-disposition-list.md | 4 ++ ...ifi-client-cleanup-shortlist-2026-05-22.md | 14 +++-- .../unifi-client-rehome-results-2026-05-22.md | 22 +++++-- ...nifi-live-preflight-snapshot-2026-05-22.md | 7 ++- ...doorbell-chime-current-state-2026-05-26.md | 60 +++++++++++++++++++ .../docs/unifi-readonly-recon-2026-05-22.md | 15 +++-- .../unifi-ssid-cleanup-proposal-2026-05-23.md | 10 +++- .../docs/usw-pro-hd-24-cutover-port-sheet.md | 4 ++ 16 files changed, 193 insertions(+), 43 deletions(-) create mode 100644 home/doris-dashboard/docs/unifi-protect-doorbell-chime-current-state-2026-05-26.md diff --git a/docs/troubleshooting/KNOWN_QUIRKS.md b/docs/troubleshooting/KNOWN_QUIRKS.md index 7d321f2..7cc8f03 100644 --- a/docs/troubleshooting/KNOWN_QUIRKS.md +++ b/docs/troubleshooting/KNOWN_QUIRKS.md @@ -59,6 +59,12 @@ Per-service gotchas that aren't bugs but will bite you if you forget them. - `docker restart` or `docker compose restart` will NOT fix missing network attachments - Must use `docker compose --env-file .env down && docker compose --env-file .env up -d ` +### UniFi Protect WiFi chimes after doorbell/network changes +- A UniFi Protect WiFi chime can look healthy in UniFi Network while still showing offline in Protect if a per-client Camera virtual-network override puts it on a lane that does not preserve the required Protect path. +- In John's current environment, the known-good fallback for the two Wi-Fi chimes is Management/default `UniFi Wireless`, not the Camera-lane override that was tried on 2026-05-22. +- After a doorbell is re-adopted, also verify each chime's `ringSettings.cameraId` still points at the current doorbell object; a stale camera binding can break ringing even when the network path is healthy. +- Treat "device online in UniFi Network" and "device healthy in Protect / rings for the current doorbell" as separate checks. + --- ## Serenity diff --git a/home/doris-dashboard/docs/legacy-cia-triage-worksheet.md b/home/doris-dashboard/docs/legacy-cia-triage-worksheet.md index 3741478..c8050a6 100644 --- a/home/doris-dashboard/docs/legacy-cia-triage-worksheet.md +++ b/home/doris-dashboard/docs/legacy-cia-triage-worksheet.md @@ -2,6 +2,11 @@ > For Doris: this worksheet exists so tomorrow does not devolve into vibes and guessing. Every device on Legacy CIA gets one label: migrate, quarantine, or kill. +Historical status note: +- this is a 2026-05-22 migration worksheet, not the current remaining-work checklist +- do not treat its "tomorrow" language as active backlog without checking later result docs +- current truth for Protect accessories lives in `unifi-protect-doorbell-chime-current-state-2026-05-26.md` + Goal: classify every remaining device on the legacy CIA Via VLAN/SSID so we can make deliberate decisions during and after the cutover. Rules: @@ -47,8 +52,8 @@ Use `kill` when all or most are true: - MyQ -> IoT VLAN 40 - Samsung FamilyHub -> IoT VLAN 40 - LG dryer -> IoT VLAN 40 -- doorbell -> Cameras VLAN 60 -- Protect chimes -> Cameras VLAN 60 +- doorbell -> Cameras VLAN 60 only if immediate validation is available +- Protect chimes -> Cameras VLAN 60 only after explicit Protect-path validation; current known-good live state keeps them on Management/default `UniFi Wireless` ### Migrate later / careful handling - Google Home Mini -> IoT VLAN 40 after discovery testing @@ -114,7 +119,7 @@ If answers are bad, it does not earn migration tomorrow. ### Protect chimes / doorbell - These are not Legacy CIA end-state residents. -- Move to Cameras/Security as early cleanup. +- Treat Cameras/Security as the target design, not an automatic next action. The Wi-Fi chimes currently have a documented Management/default-SSID exception because the Camera override broke Protect health. ### old bulbs / old plugs - If still useful but irrecoverable, quarantine. diff --git a/home/doris-dashboard/docs/network-cutover-master-operator-sheet.md b/home/doris-dashboard/docs/network-cutover-master-operator-sheet.md index a1ca920..a31c55b 100644 --- a/home/doris-dashboard/docs/network-cutover-master-operator-sheet.md +++ b/home/doris-dashboard/docs/network-cutover-master-operator-sheet.md @@ -2,6 +2,11 @@ > For Doris: this is the one-page live operator sheet for tomorrow. Use this instead of bouncing between five docs while tired. +Historical status note: +- this file is a 2026-05-22 live cutover sheet, not the current remaining-work source of truth +- do not treat its open checkboxes or "tomorrow" language as active backlog +- current truth lives in `network-migration-remaining-checklist-2026-05-22.md` and `unifi-protect-doorbell-chime-current-state-2026-05-26.md` + Goal: execute the UniFi network redesign with minimal improvisation, explicit stop/go gates, per-port actions, per-device dispositions, and fast rollback discipline. Architecture: @@ -43,7 +48,7 @@ Current client counts: - Trusted: 14 Current hazards: -- two unnamed `espressif` devices are on Management via `UniFi Wireless` on the U7 Pro +- the two historical `espressif` Management hazards are now known Protect WiFi chimes, not unidentified junk - almost all Wi‑Fi clients are on the U7 Pro - there are no custom firewall rules/groups yet, so tomorrow’s segmentation policy is basically greenfield @@ -110,7 +115,7 @@ Stop/go gate: - [ ] Trusted admin path still fine ### Minute 20-35: management cleanup first -- [ ] identify/address the 2 Management `espressif` devices +- [ ] confirm the two former Management `espressif` devices are still understood as the documented Protect-chime exception - [ ] ensure infra devices remain on Management intent - [ ] remove obvious non-infra junk from Management @@ -120,7 +125,7 @@ Stop/go gate: ### Minute 35-50: security cleanup - [ ] validate Camera lane -- [ ] move Protect chimes if ready +- [ ] move Protect chimes only if Protect health is explicitly validated during the move - [ ] confirm doorbell remains healthy ### Minute 50-85: core server move wave @@ -160,22 +165,22 @@ Stop/go gate: ## 5. Management Offender Sheet -These two devices are currently on Management and need identification or removal from that lane: +These two devices were the historical Management offenders that needed identification. They are no longer mystery devices, and they are not a rediscovery task: 1. `espressif` - IP: `10.5.0.123` - AP: `U7 Pro` - SSID: `UniFi Wireless` -- Default call: identify first; if it is smart-junk, move/quarantine off Management +- Current call: known Protect WiFi chime; keep on the documented Management/default-SSID exception unless doing an explicit Protect-validation move 2. `espressif` - IP: `10.5.0.189` - AP: `U7 Pro` - SSID: `UniFi Wireless` -- Default call: identify first; if it is smart-junk, move/quarantine off Management +- Current call: known Protect WiFi chime; keep on the documented Management/default-SSID exception unless doing an explicit Protect-validation move Operator note: -- these are almost certainly exactly the sort of device that should not live on your infrastructure lane +- target architecture still says these belong with security estate, but the current known-good live state keeps them on Management/default `UniFi Wireless` because the Camera override failed in Protect ## 6. Exact Core Port Move Sheet @@ -272,10 +277,14 @@ Rule: Already true: - `front-doorbell` is already on Camera at `10.5.20.217` -Tomorrow’s security work is therefore mainly: -- move/clean up chimes -- tighten policy +Current known-good chime exception: +- Protect WiFi Chime `upstairs landing` is intentionally on Management/default `UniFi Wireless` at `10.5.0.123` +- Protect WiFi Chime `Living Room` is intentionally on Management/default `UniFi Wireless` at `10.5.0.189` + +If revisiting security work, the goal is therefore: - preserve the doorbell’s healthy state +- tighten policy carefully +- only revisit chime placement during an explicit Protect-validation test ## 9. Firewall Build Priorities diff --git a/home/doris-dashboard/docs/network-cutover-minute-checklist.md b/home/doris-dashboard/docs/network-cutover-minute-checklist.md index b4467ac..c54d528 100644 --- a/home/doris-dashboard/docs/network-cutover-minute-checklist.md +++ b/home/doris-dashboard/docs/network-cutover-minute-checklist.md @@ -2,6 +2,11 @@ > For Doris: this is the live change-window script. Use it like a pilot checklist, not a brainstorming prompt. +Historical status note: +- this file is a 2026-05-22 cutover script, not the current remaining-work checklist +- do not treat unchecked boxes or "tomorrow" phrasing here as active backlog +- current truth lives in `network-migration-remaining-checklist-2026-05-22.md` and `unifi-protect-doorbell-chime-current-state-2026-05-26.md` + Goal: execute the redesign tomorrow with deliberate pauses, validation after every block of changes, and clean rollback points. Assumptions: @@ -83,7 +88,7 @@ Stop/go check: - [ ] Confirm UDM, switches, and APs are mapped to Management intent. - [ ] Remove obvious non-infrastructure devices from Management. - [ ] Identify any stragglers remaining in Management and list them. -- [ ] If Security lane is ready, prepare to move chimes immediately. +- [ ] If revisiting Protect accessory placement, first confirm the documented chime Management exception and only move them during explicit Protect validation. Validation: - [ ] UniFi still sees gateway, switches, APs. @@ -97,9 +102,9 @@ Rollback trigger: - [ ] Activate/validate Cameras VLAN 60. - [ ] Activate Security SSID if needed. -- [ ] Move Protect chimes. -- [ ] Move doorbell if ready. -- [ ] Confirm no security devices remain polluting Management. +- [ ] Move Protect chimes only if Protect health is validated during the move. +- [ ] Move doorbell only if immediate post-move validation is available. +- [ ] Confirm any remaining security-device Management exception is documented explicitly. Validation: - [ ] device rejoins expected lane @@ -107,7 +112,7 @@ Validation: - [ ] no broad emergency rules added yet Rollback trigger: -- [ ] If doorbell/chimes become unrecoverable fast, revert that device only. +- [ ] If doorbell/chimes become unrecoverable fast, revert that device only; for the Wi-Fi chimes, clearing the Camera override and returning to Management/default `UniFi Wireless` is the known-good rollback. ## Minute 50-75: move core servers to Servers VLAN 30 diff --git a/home/doris-dashboard/docs/network-cutover-red-team-card.md b/home/doris-dashboard/docs/network-cutover-red-team-card.md index b12373d..988a4fb 100644 --- a/home/doris-dashboard/docs/network-cutover-red-team-card.md +++ b/home/doris-dashboard/docs/network-cutover-red-team-card.md @@ -2,6 +2,10 @@ Use this during the live window when your brain gets dumb. +Historical status note: +- this card belongs to the 2026-05-22 cutover-planning wave +- keep it as operator evidence, but do not treat it as the current backlog without checking later migration result docs + Goal: - make one clean change - validate it diff --git a/home/doris-dashboard/docs/network-migration-remaining-checklist-2026-05-22.md b/home/doris-dashboard/docs/network-migration-remaining-checklist-2026-05-22.md index f2e66d1..0916282 100644 --- a/home/doris-dashboard/docs/network-migration-remaining-checklist-2026-05-22.md +++ b/home/doris-dashboard/docs/network-migration-remaining-checklist-2026-05-22.md @@ -2,10 +2,14 @@ Current intent: only safe, low-drama follow-up work remains. The easy-value client cleanup already completed should not be re-run. +Current truth note: +- use this file plus `unifi-protect-doorbell-chime-current-state-2026-05-26.md` as the source of truth for what is actually still pending +- treat earlier cutover-prep docs with "tomorrow" language as historical planning artifacts unless they were explicitly updated later + ## Already completed - Servers network/profile exists in UniFi -- Protect WiFi Chime `upstairs landing` moved from Management -> Camera -- Protect WiFi Chime `Living Room` moved from Management -> Camera +- Historical attempt moved both Protect WiFi chimes from Management -> Camera, but that change was later reversed after Protect health failed on the Camera-lane override +- Current known-good state keeps both Protect WiFi chimes on Management / default `UniFi Wireless`; see `unifi-protect-doorbell-chime-current-state-2026-05-26.md` - `LG_Smart_Laundry2_open` moved from Trusted -> IoT - `MyQ-29B` moved from Old IoT -> IoT - `LG_Smart_Dryer2_open` moved from Old IoT -> IoT @@ -28,6 +32,7 @@ Current intent: only safe, low-drama follow-up work remains. The easy-value clie - keep unknown Legacy CIA devices explicitly quarantine-first - Trusted-lane Intellirocks cleanup is now resolved separately; see `intellirocks-triage-result-2026-05-23.md` - Legacy CIA leftovers are now dispositioned separately; see `unifi-legacy-cia-closeout-2026-05-23.md` + - Protect chime lane cleanup is intentionally deferred until Protect connectivity is explicitly re-validated on a non-Management lane 3. Non-disruptive firewall planning cleanup - compare staged firewall objects/policies against desired rule order @@ -96,6 +101,7 @@ Important distinction: - final validation sweep - confirm no temporary panic exceptions remain - document any intentionally deferred weird devices +- keep the Protect doorbell/chime exception documented until a future validated lane migration replaces it ## Suggested execution order from here 1. Wait for laptop session diff --git a/home/doris-dashboard/docs/network-redesign-implementation-runbook.md b/home/doris-dashboard/docs/network-redesign-implementation-runbook.md index 27d8ae4..328745a 100644 --- a/home/doris-dashboard/docs/network-redesign-implementation-runbook.md +++ b/home/doris-dashboard/docs/network-redesign-implementation-runbook.md @@ -2,6 +2,11 @@ > For Doris: use this during the live UniFi change window. Goal is a controlled cutover with explicit validation and rollback at each boundary. +Historical status note: +- this runbook came from the 2026-05-22 cutover-planning wave +- preserve it as the detailed plan, but do not treat every "tomorrow" step as still pending without checking later result docs +- current remaining-work truth lives in `network-migration-remaining-checklist-2026-05-22.md` and `unifi-protect-doorbell-chime-current-state-2026-05-26.md` + Goal: deploy the target VLAN/SSID/firewall design with minimum drama, keep legacy CIA Via as a quarantine lane for devices that cannot yet be migrated, and finish the window with an understandable, supportable network. Architecture summary: @@ -258,7 +263,7 @@ Exit criteria: ### Phase C: Management cleanup first 1. Ensure UDM, switches, and AP management surfaces are on VLAN 10 intent. 2. Remove obvious non-infrastructure devices from Management. -3. Move Protect chimes out of Management as top cleanup item if Security lane is ready. +3. Treat Protect chimes as a documented temporary Management exception unless you are explicitly re-validating their Protect health on a non-Management lane. 4. Re-validate UniFi visibility of gateway, switches, APs. Rollback if: @@ -272,14 +277,14 @@ Exit criteria: ### Phase D: Build/activate Cameras lane 1. Activate/validate `NET-CAMERAS`. 2. Activate `Security` SSID if used. -3. Move doorbell and Protect chimes to Cameras/Security. +3. Move doorbell and Protect chimes to Cameras/Security only if Protect health is explicitly validated during the move. 4. Validate app/admin behavior. Rollback if: - security devices fall offline and cannot be recovered quickly Exit criteria: -- doorbell/chimes are no longer polluting Management +- either doorbell/chimes are healthy on Cameras/Security, or the documented Management exception is preserved intentionally - Camera lane exists for future growth ### Phase E: Move core servers to Servers VLAN 30 @@ -353,8 +358,8 @@ Exit criteria: ## 9. Explicit Device Triage Move tomorrow if practical: -- Protect chimes -- doorbell +- Protect chimes only during an explicit Protect-validation test +- doorbell only if healthy-state validation is immediate and reversible - PD - Serenity - Nomad @@ -403,6 +408,7 @@ Minimum successful tomorrow outcome: - IoT lane exists and at least easy-value devices are moved - Legacy CIA is converted into explicit quarantine/sunset lane - no broad insecure exceptions were added out of fatigue +- any documented temporary Protect chime exception is written down instead of being rediscovered later Nice-to-have, not mandatory tomorrow: - U6 LR restored and tuned diff --git a/home/doris-dashboard/docs/network-redesign-plan.md b/home/doris-dashboard/docs/network-redesign-plan.md index 0d6e11b..ba56db7 100644 --- a/home/doris-dashboard/docs/network-redesign-plan.md +++ b/home/doris-dashboard/docs/network-redesign-plan.md @@ -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 diff --git a/home/doris-dashboard/docs/old-iot-tomorrow-disposition-list.md b/home/doris-dashboard/docs/old-iot-tomorrow-disposition-list.md index 2cb66a7..67def1b 100644 --- a/home/doris-dashboard/docs/old-iot-tomorrow-disposition-list.md +++ b/home/doris-dashboard/docs/old-iot-tomorrow-disposition-list.md @@ -2,6 +2,10 @@ > For Doris: this is the concrete disposition call for every current live Old IoT client seen during read-only recon. This is the list to use tomorrow unless live validation proves otherwise. +Historical status note: +- this is a 2026-05-22 planning artifact +- several "tomorrow" items here were completed later; do not use this file as the current backlog without checking `network-migration-remaining-checklist-2026-05-22.md` + Source basis: - live UniFi read-only recon on 2026-05-22 - all devices listed were active on SSID `CIA Via` through the `U7 Pro` diff --git a/home/doris-dashboard/docs/unifi-client-cleanup-shortlist-2026-05-22.md b/home/doris-dashboard/docs/unifi-client-cleanup-shortlist-2026-05-22.md index 95cd282..2d3df98 100644 --- a/home/doris-dashboard/docs/unifi-client-cleanup-shortlist-2026-05-22.md +++ b/home/doris-dashboard/docs/unifi-client-cleanup-shortlist-2026-05-22.md @@ -1,5 +1,7 @@ # UniFi Client Cleanup Shortlist +Status note: this file started as a live shortlist on 2026-05-22. Most of the appliance/thermostat cleanup in here is completed. For the current Protect doorbell/chime truth, do not rely on the original chime recommendation below without also reading `unifi-protect-doorbell-chime-current-state-2026-05-26.md`. + Live basis: - Captured from PD with `python3 automation/bin/unifi_network.py --raw` - Capture time: 2026-05-22 21:45:20 UTC @@ -40,8 +42,8 @@ These are the clearest remaining misclassifications, and the smart-appliance tar - Why: vendor-family clustering strongly suggests it belongs with the other low-trust embedded devices, not with human/operator endpoints. - Caution: identify before moving if possible; if unknown, do not promote it by leaving it in Trusted. -## Management offenders -These are now identified and should not remain on Management. +## Management offenders (historical identification, but not current next-step guidance) +These were correctly identified on 2026-05-22, but the original recommendation to re-home them immediately to `Camera` / security is no longer the standing advice. - `58:d6:1f:54:e5:6d` (`10.5.0.123`, hostname `espressif`) - Identified as: UniFi Protect WiFi Chime @@ -56,7 +58,9 @@ These are now identified and should not remain on Management. Notes: - Both are Wi-Fi clients on `UniFi Wireless`. - UniFi fingerprint metadata reports `product_line=unifi-protect` and `product_model=Protect WiFi Chime`. -- This means they are not mystery ESP junk anymore; they are known Protect accessories that should be treated like camera/security estate, not management-plane clients. +- This means they are not mystery ESP junk anymore; they are known Protect accessories. +- Current known-good live state keeps them on Management/default `UniFi Wireless` because the Camera-lane override caused them to show offline in Protect. +- Do not re-home these two chimes again unless Protect connectivity is explicitly validated during the move. ## Old IoT move-now set These still look like the cleanest deliberate moves from `CIA Via` into `IoT`. @@ -88,7 +92,7 @@ Leave these in legacy quarantine unless/until they are identified better. If doing a low-drama cleanup pass, use this order: 1. Move `LG_Smart_Laundry2_open` out of `Trusted` into `IoT` -2. Re-home the two identified Protect chimes out of `Management` into `Camera` / security +2. Leave the two identified Protect chimes on their current known-good Management/default-SSID path unless you are doing an explicit Protect-validation test 3. Migrate the approved Old IoT move-now set into `IoT`, one app-validated batch at a time 4. Leave Google/cast-class gear for later unless everything else is stable 5. Keep unknown leftovers quarantined; do not “clean them up” by granting `Trusted` @@ -98,5 +102,5 @@ The clearest remaining lane problems are now: - one approved LG appliance still sitting in `Trusted` - one likely Google cast/display-class client in `Trusted` - one likely Intellirocks smart-home client in `Trusted` -- two now-identified Protect chimes still sitting in `Management` +- the Protect chimes are a documented temporary exception, not a rediscovery task - the approved appliance/thermostat/MyQ devices still lingering in `Old IoT` diff --git a/home/doris-dashboard/docs/unifi-client-rehome-results-2026-05-22.md b/home/doris-dashboard/docs/unifi-client-rehome-results-2026-05-22.md index bb535ab..72cbb48 100644 --- a/home/doris-dashboard/docs/unifi-client-rehome-results-2026-05-22.md +++ b/home/doris-dashboard/docs/unifi-client-rehome-results-2026-05-22.md @@ -1,13 +1,15 @@ # UniFi Client Rehome Results +Historical execution note: this file records what was applied on 2026-05-22, not the final lasting truth for every device. For the current known-good Protect doorbell/chime state, see `unifi-protect-doorbell-chime-current-state-2026-05-26.md`. + Executed from PD against the live UniFi controller using per-client virtual network overrides plus targeted `kick-sta` reconnects. -## Requested changes completed +## Requested changes applied on 2026-05-22 ### Trusted -> IoT - `LG_Smart_Laundry2_open` (`60:ab:14:5f:b4:ba`) -> `IoT` -> `10.5.10.141` -### Management -> Camera +### Management -> Camera (historical attempt; later reverted for the chimes) - Protect WiFi Chime `upstairs landing` (`58:d6:1f:54:e5:6d`) -> `Camera` -> `10.5.20.191` - Protect WiFi Chime `Living Room` (`58:d6:1f:54:e5:af`) -> `Camera` -> `10.5.20.8` @@ -18,11 +20,23 @@ Executed from PD against the live UniFi controller using per-client virtual netw - `Main-Floor` ecobee (`44:61:32:1d:ee:8f`) -> `IoT` -> `10.5.10.160` - `Upstairs` ecobee (`44:61:32:3f:0b:4c`) -> `IoT` -> `10.5.10.64` -## Validation result -All 8 targeted clients were re-read live from `stat/sta` and matched their intended target lanes. +## Validation result at the time +All 8 targeted clients were re-read live from `stat/sta` and matched their intended target lanes during the 2026-05-22 apply window. + +Important caveat: +- lane placement success in UniFi Network did not prove Protect health for the chimes +- a later follow-up showed the two chimes could appear associated in UniFi Network while still showing offline in Protect + +## Follow-up result that supersedes the chime portion + +Later known-good state: +- Protect WiFi Chime `upstairs landing` was returned to `Management` / default `UniFi Wireless` -> `10.5.0.123` +- Protect WiFi Chime `Living Room` was returned to `Management` / default `UniFi Wireless` -> `10.5.0.189` +- the Camera-lane virtual-network override for the chimes should now be treated as a failed experiment in this environment, not as the standing recommendation ## Notes - Rehome mechanism used: `PUT /rest/user/` with `network_id`, `virtual_network_override_enabled=true`, and `virtual_network_override_id=` - Reconnect mechanism used: `POST /cmd/stamgr` with `cmd=kick-sta` - `LG_Smart_Laundry2_open` had a temporary probe note during discovery; it was cleared during the live apply - Some clients still show their original SSID names in UniFi telemetry even after landing on the target virtual network override; the authoritative validation point for this pass was the live `network` / `network_id` state +- The Protect lesson learned here is specific and important: a client can look correctly placed in UniFi Network while still being unhealthy in Protect. diff --git a/home/doris-dashboard/docs/unifi-live-preflight-snapshot-2026-05-22.md b/home/doris-dashboard/docs/unifi-live-preflight-snapshot-2026-05-22.md index 9feb3b9..12c964f 100644 --- a/home/doris-dashboard/docs/unifi-live-preflight-snapshot-2026-05-22.md +++ b/home/doris-dashboard/docs/unifi-live-preflight-snapshot-2026-05-22.md @@ -1,5 +1,10 @@ # UniFi Live Preflight Snapshot +Historical snapshot note: +- this file is a dated preflight capture from 2026-05-22 +- preserve it as evidence, but do not treat it as the current source of truth for remaining work or final device placement +- later results and reversals are documented in `network-migration-remaining-checklist-2026-05-22.md` and `unifi-protect-doorbell-chime-current-state-2026-05-26.md` + Date: 2026-05-22 Mode: read-only live pull from PD using the Doris UniFi operator account Controller: `https://10.5.0.1` @@ -82,7 +87,7 @@ Interpretation: - `58:d6:1f:54:e5:6d` -> `10.5.0.123` - `58:d6:1f:54:e5:af` -> `10.5.0.189` -These are still the two management-lane ESP-class offenders to identify or evict. +Historical interpretation only: these were later identified as the two Protect WiFi chimes, so this section is evidence of the pre-identification state, not an open rediscovery task. ## Fresh anomalies vs the earlier planning assumptions diff --git a/home/doris-dashboard/docs/unifi-protect-doorbell-chime-current-state-2026-05-26.md b/home/doris-dashboard/docs/unifi-protect-doorbell-chime-current-state-2026-05-26.md new file mode 100644 index 0000000..34ea333 --- /dev/null +++ b/home/doris-dashboard/docs/unifi-protect-doorbell-chime-current-state-2026-05-26.md @@ -0,0 +1,60 @@ +# 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. diff --git a/home/doris-dashboard/docs/unifi-readonly-recon-2026-05-22.md b/home/doris-dashboard/docs/unifi-readonly-recon-2026-05-22.md index 19d8ebb..ee8b34b 100644 --- a/home/doris-dashboard/docs/unifi-readonly-recon-2026-05-22.md +++ b/home/doris-dashboard/docs/unifi-readonly-recon-2026-05-22.md @@ -1,5 +1,10 @@ # UniFi Read-Only Recon Notes +Historical snapshot note: +- this file records the 2026-05-22 read-only discovery pass +- preserve it as evidence, but do not use it as the current next-step checklist without checking later outcome docs +- later results and reversals are documented in `network-migration-remaining-checklist-2026-05-22.md` and `unifi-protect-doorbell-chime-current-state-2026-05-26.md` + Date: 2026-05-22 Mode: read-only only Auth status: verified working with upgraded Doris admin login @@ -79,9 +84,9 @@ Likely quarantine until identified better: ### 6. Camera lane live state - `front-doorbell` is already on Camera network at `10.5.20.217` -Interpretation: -- the doorbell is already where it belongs logically -- tomorrow’s security cleanup work is mainly about chimes and future policy tightening +Interpretation at the time: +- the doorbell was already in the expected camera lane during this snapshot +- later follow-up changed the chime guidance, so do not treat this paragraph as the final remaining-work instruction set ### 7. Trusted lane still carrying infrastructure-class hosts Trusted currently includes: @@ -131,8 +136,8 @@ Interpretation: - Rocinante needs a quick extra look because the client is live on port 2 but that port did not show an explicit profile name in the returned record ## Recommended next actions for tomorrow -1. identify the two Management `espressif` devices before or during the window +1. historical note: the two Management `espressif` devices were later identified as Protect WiFi chimes; do not treat this as an open rediscovery task 2. move/changeprofile for server ports on the USW Pro HD 24 one at a time 3. treat Google devices as late-batch or defer 4. treat unknown Old IoT clients as quarantine by default, not migration by default -5. keep Camera cleanup focused on chimes and policy, because the doorbell is already in the correct lane +5. keep Camera cleanup focused on validated policy and documented exceptions; the doorbell was already in the correct lane during this snapshot, but later chime guidance changed diff --git a/home/doris-dashboard/docs/unifi-ssid-cleanup-proposal-2026-05-23.md b/home/doris-dashboard/docs/unifi-ssid-cleanup-proposal-2026-05-23.md index 77ccee3..6e30c48 100644 --- a/home/doris-dashboard/docs/unifi-ssid-cleanup-proposal-2026-05-23.md +++ b/home/doris-dashboard/docs/unifi-ssid-cleanup-proposal-2026-05-23.md @@ -2,6 +2,10 @@ Purpose: turn the remaining SSID cleanup into an exact low-risk keep/retire proposal before any live Wi-Fi changes. +Status note: +- this remains useful as a keep/retire proposal, but the Protect chime portion must now be read together with `unifi-protect-doorbell-chime-current-state-2026-05-26.md` +- current known-good chime behavior is on Management/default `UniFi Wireless`, not on the Camera/Security lane + ## Basis Artifact-based planning only. No live SSID edits were made in this pass. @@ -87,8 +91,11 @@ Long-term, the network should converge on: - doorbell and Protect-chime estate justify a distinct security SSID - keeping security separate from generic IoT matches the redesign intent and future camera growth plan - Preconditions to call it final: - - doorbell/chimes remain healthy + - doorbell/chimes remain healthy after explicit Protect validation on that lane - no evidence that merging them into general IoT would be safer or simpler +- Current caution: + - treat the Security SSID as future-state design intent, not proof that the Wi-Fi chimes are safe there today + - the current known-good live path for the chimes is still Management/default `UniFi Wireless` ### 5) Guest SSID - Proposed role: `create or enable separately when ready` @@ -116,6 +123,7 @@ This is the safest order based on current evidence: - do not rename and repurpose a live SSID in one step if disabling/creating separately would be clearer - do not infer that Google/cast is solved globally from one successful pilot reassociation - do not collapse Security into generic IoT unless there is a deliberate design change +- do not assume that because `UNEF's Playhouse` exists, the Protect chimes are already proven safe on it ## Practical one-page operator version If you want the shortest operator call: diff --git a/home/doris-dashboard/docs/usw-pro-hd-24-cutover-port-sheet.md b/home/doris-dashboard/docs/usw-pro-hd-24-cutover-port-sheet.md index b4c0838..746754f 100644 --- a/home/doris-dashboard/docs/usw-pro-hd-24-cutover-port-sheet.md +++ b/home/doris-dashboard/docs/usw-pro-hd-24-cutover-port-sheet.md @@ -2,6 +2,10 @@ > For Doris: this is the mechanical switch-port sheet for tomorrow. Do not freestyle. Change one thing, validate, then continue. +Historical status note: +- this is a 2026-05-22 cutover sheet, preserved as evidence of the original plan +- do not treat its "tomorrow" wording as active backlog without checking later migration result docs + Source basis: - live UniFi read-only recon on 2026-05-22 - /home/fizzlepoof/repos/truenas-stacks/home/doris-dashboard/docs/unifi-readonly-recon-2026-05-22.md