fizzlepoof/truenas-stacks
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
6ba3fe208e84b3287c6a5ba61b69cdd47f3dedc4
truenas-stacks/home/doris-dashboard/docs/unifi-client-cleanup-shortlist-2026-05-22.md
Fizzlepoof 77da65e64a
Some checks failed
secret-guardrails / artifact-secret-scan (push) Has been cancelled
Details
secret-guardrails / gitleaks (push) Has been cancelled
Details
docs: clarify current unifi protect chime state
2026-05-26 20:10:45 +00:00

5.4 KiB
Raw Blame History

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
Reference in New Issue View Git Blame Copy Permalink