Files

Mike Swanson 0b174792ad sync: auto-sync from GURU-5070 at 2026-06-15 18:45:55

Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-15 18:45:55

2026-06-15 18:46:11 -07:00

6.9 KiB

Raw Blame History

name, description

name	description
unifi-wifi	Analyze and tune UniFi WiFi for performance + stability, especially in dense/congested environments. Audits AP/radio config and the neighbor-interference map from the UOS controller, flags issues (2.4GHz over-provisioning, channel width, min-RSSI/sticky clients, channel plan), and recommends prioritized changes. Works for any UniFi site on the UOS (172.16.3.29); Cascades is the hard case. Triggers: unifi wifi tuning, RF/airtime/channel analysis, 2.4GHz congestion, AP channel plan, sticky clients, wireless performance.

name

description

unifi-wifi

Analyze and tune UniFi WiFi for performance + stability, especially in dense/congested environments. Audits AP/radio config and the neighbor-interference map from the UOS controller, flags issues (2.4GHz over-provisioning, channel width, min-RSSI/sticky clients, channel plan), and recommends prioritized changes. Works for any UniFi site on the UOS (172.16.3.29); Cascades is the hard case. Triggers: unifi wifi tuning, RF/airtime/channel analysis, 2.4GHz congestion, AP channel plan, sticky clients, wireless performance.

UniFi WiFi tuning (UOS sites)

Data-driven WiFi tuning for UniFi sites on the UOS Server (172.16.3.29). Goal: solid performance + stability for connected devices in congested environments by analyzing what the controller knows and making prioritized, validated changes. Built for any site; Cascades (77 APs, ~550 clients, brutal 2.4GHz) is the reference hard case.

First, load context

references/data-access.md — what data the UOS exposes and how to read it (the two planes: Mongo config/interference now, live Network API later).
references/methodology.md — the prioritized tuning playbook (synthesized from a multi-model pass + live recon). Read before recommending any change.
references/interference-model.md — design for the AP-interference / airtime-reduction model (which radios to disable / power down), incl. the data feasibility (needs Plane 2 + a collector — the signals aren't in Mongo).

What it does (current = Plane 1, read-only)

Audit a site — config + interference, no live plane needed:
```
bash .claude/skills/unifi-wifi/scripts/audit-site.sh <site-name|site_id>
bash .claude/skills/unifi-wifi/scripts/audit-site.sh cascades
```
Outputs 2.4/5/6 config summary, the per-channel neighbor-density (interference) map, and flagged issues (2.4 over-provisioning, 40/80/160MHz width, off-1/6/11 channels, min-RSSI off, high power).
Rank airtime-reduction candidates — which radios to disable / power down, from real history (ace_stat: per-AP airtime cu_total/cu_interf/num_sta + the wifi_connectivity_event roam graph). Works for any band:
```
bash .claude/skills/unifi-wifi/scripts/model-rank.sh <site> [days=7] [band=ng|na|6e|all]
```
(Cascades 2.4: 75 radios at 74–94% utilization, 61–81% interference, ~1 client each → disable/power-down.)
Optimize (coverage-safe plan) — which radios to power-down (do first) vs disable (after), per band, without opening coverage holes or capacity cascades:
```
bash .claude/skills/unifi-wifi/scripts/optimize-radios.sh <site> [days=14] [band=ng|na|6e]
```
Coverage model = the roam graph (materials-aware: clients can't roam through Cascades' steel hallway walls, so the model never calls cross-wall APs redundant). Multi-model hardened (bidirectional roams, load-shift simulation, 40%/zone cap, stepwise). On Cascades 2.4 it recommends power-down on 74/75 radios (safe big win) and 0 disables until the live RF table proves redundancy — see interference-model.md.
Validate live (Plane 2) — current cu_total/satisfaction/per-AP RF, before+after a change, and the AP-to-AP RF-neighbor table that unlocks confident disables:
```
bash .claude/skills/unifi-wifi/scripts/live-stats.sh <site> [--clients]
```
Needs a read-only controller admin vaulted at infrastructure/uos-server-network-api (the script prints the one-time provisioning steps if it's missing).
- Per-AP live watch (no controller lag) — SSH straight into an AP and stream channel-busy% + noise + clients/retries every ~2s, to watch a targeted change land in real time:
```
bash .claude/skills/unifi-wifi/scripts/watch-ap.sh <ap-ip> [interval]
```
  Uses mca-dump + iw survey on the AP. Device-auth cred vaulted (clients/cascades-tucson/unifi-ap-ssh). Needs L3 reach to the AP (at Cascades: bring up the site VPN; APs are on 192.168.2.x/3.x) + local sshpass.
Interpret the flags against methodology.md (fix order: prune 2.4 -> shrink cells/power -> min data rates -> manual 1/6/11 plan -> min-RSSI + roaming -> steer to 6GHz).
Recommend a prioritized, per-zone change plan. Roll out per zone, not site-wide at once.

Ad-hoc Mongo queries: .claude/scripts/uos-mongo.sh (recipes in data-access.md). Access is the vaulted dedicated key infrastructure/uos-server-ssh-key (works from any fleet machine).

The two data planes (know which you're using)

Plane 1 — Mongo ace (available now, read-only via SSH): radio config (radio_table), the rogue neighbor-interference map, channelplan, AP/client inventory. Enough for the full config audit + channel/interference plan — covers the 2.4GHz "first problem".
Plane 2 — live Network API (stat/device, stat/sta; NOT yet wired): live channel utilization (cu_total), per-client RSSI/SNR/retries, AP satisfaction. Needed to validate changes (before/after) and find the worst APs by live airtime. Wiring it needs a dedicated read-only UniFi admin or integration API key on .29, vaulted as infrastructure/uos-server-network-api. See data-access.md "Plane 2".

Applying changes — IMPORTANT boundary

Config changes CAN be automated across many APs (no per-AP UI clicking) via the controller REST API (PUT .../rest/device/<id> radio_table) — scripts/apply-radio.sh does this:

bash .claude/skills/unifi-wifi/scripts/apply-radio.sh cascades ng power low [--zone "Floor 3"]   # DRY-RUN preview

Dry-run prints per-AP before->after + rollback values + the exact REST payload. Writes are GATED OFF until (1) a read-WRITE controller admin is vaulted (infrastructure/uos-server-network-api-rw; the root SSH key is the data plane, NOT an API write session) and (2) --apply is passed — and even then must: capture old values, go one --zone at a time, validate live cu_total/busy% with watch-ap.sh before and after, and never run nightly/auto channel optimization in ultra-dense sites. disable is intentionally NOT in apply-radio.sh yet — it needs the RF-neighbor table to prove redundancy first (see interference-model.md). Get explicit go before enabling any write.

Roadmap

Phase 1 (done): config + interference audit, flags, methodology. Read-only.
Phase 2: wire the live Network API (Plane 2) for cu_total/satisfaction/per-client RF → before/after validation + "worst APs by airtime" ranking.
Phase 3: assisted change application (per-zone, API-driven, with live before/after gating).

Notes

The methodology is independent-model guidance + config-plane recon — validate against live stats before trusting any single recommendation, and roll out per zone.
Multi-site: pass any site name/id; uos-mongo.sh --sites lists them. Cascades = 685f39068e65331c46ef6dd2.

6.9 KiB Raw Blame History Unescape Escape