# 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
- Scope: active clients only

## What looks correct already
- Servers lane: `PlausibleDeniability`, `Serenity`, `Nomad`
- Camera lane: `front-doorbell`
- Trusted human/operator lane: `Rocinante`, `FlyingDutchman`, `Pixel-7`, `Pixel-9-Pro-XL`, `Valkyrie`, `steamdeck`
- Trusted tooling/device that is probably intentional: `MeshMonitor (MT)`

## Immediate cleanup candidates

### 1. Move out of Trusted first
These are the clearest remaining misclassifications, and the smart-appliance targets are now approved for `IoT`.

- `LG_Smart_Laundry2_open` (`10.5.1.184`, `60:ab:14:5f:b4:ba`)
  - Current lane: `Trusted`
  - Approved target: `IoT`
  - Identification confidence: high
  - Why: named LG appliance endpoint and sibling to `LG_Smart_Dryer2_open`; does not belong in the human/operator lane.

- `dc:e5:5b:8f:57:d2` (`10.5.1.132`, Google)
  - Current lane: `Trusted`
  - Likely identity: Google cast/speaker/display-class client
  - Likely target: `IoT`, but late-batch after discovery validation
  - Why:
    - Google vendor fingerprint
    - same family as the three Google clients still on `Old IoT`
    - consumer Wi-Fi client on the compat Trusted SSID, not a human endpoint
    - heavy traffic pattern is consistent with a media/cast-style household device
  - Caution: treat like the other Google/cast discovery-sensitive devices. Do not broaden policy just to appease casting.

- `d4:ad:fc:f2:df:d2` (`10.5.1.154`, Shenzhen Intellirocks Tech)
  - Current lane: `Trusted`
  - Likely identity: sibling to the two unnamed Intellirocks devices already on `Old IoT`; likely smart-home / embedded device class
  - Likely target: `IoT` or quarantine later if still unidentified
  - 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 (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
  - Friendly name from controller fingerprint: `upstairs landing`
  - Best-fit target lane: `Camera` / security

- `58:d6:1f:54:e5:af` (`10.5.0.189`, hostname `espressif`)
  - Identified as: UniFi Protect WiFi Chime
  - Friendly name from controller fingerprint: `Living Room`
  - Best-fit target lane: `Camera` / security

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

1. `MyQ-29B` (`192.168.1.130`)
2. `LG_Smart_Dryer2_open` (`192.168.1.186`)
3. `Samsung-FamilyHub` (`192.168.1.149`)
4. `Main-Floor` ecobee (`192.168.1.102`)
5. `Upstairs` ecobee (`192.168.1.131`)

## Old IoT move-later / discovery-sensitive
These are probably IoT-class eventually, but not the first things to touch if the goal is a calm cleanup.

- `Google-Home-Mini` (`192.168.1.185`)
- `3c:8d:20:f3:92:36` (`192.168.1.192`, Google)
- `90:ca:fa:b6:7f:6e` (`192.168.1.129`, Google)

## Old IoT quarantine-first leftovers
Leave these in legacy quarantine unless/until they are identified better.

- `5c:61:99:41:73:40` (`192.168.1.172`)
- `60:74:f4:54:fd:ec` (`192.168.1.136`)
- `60:74:f4:7b:6a:11` (`192.168.1.117`)
- `c0:f5:35:20:5d:94` (`192.168.1.183`)
- `d4:ad:fc:60:90:6a` (`192.168.1.100`)
- `d4:ad:fc:ea:7f:65` (`192.168.1.101`)

## Recommended next move order
If doing a low-drama cleanup pass, use this order:

1. Move `LG_Smart_Laundry2_open` out of `Trusted` into `IoT`
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`

## Bottom line
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`
- the Protect chimes are a documented temporary exception, not a rediscovery task
- the approved appliance/thermostat/MyQ devices still lingering in `Old IoT`