4.2 KiB
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. |
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.
What it does (current = Plane 1, read-only)
- Audit a site — config + interference, no live plane needed:
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).
bash .claude/skills/unifi-wifi/scripts/audit-site.sh <site-name|site_id> bash .claude/skills/unifi-wifi/scripts/audit-site.sh cascades - 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), therogueneighbor-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 asinfrastructure/uos-server-network-api. See data-access.md "Plane 2".
Applying changes — IMPORTANT boundary
This skill is audit + advisory today. Writing config to the controller is not wired and is
high-stakes (a bad channel/power/disable push degrades a live facility). When change-application is
added it MUST: go through the controller API with an authed account; change one zone at a time;
capture live cu_total/satisfaction before and after each change; and never run nightly/auto
channel optimization in ultra-dense sites (pin a manual plan). Until then, hand the recommended
plan to a tech to apply in the UniFi UI, or get explicit go before any write path is built.
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 --siteslists them. Cascades =685f39068e65331c46ef6dd2.