Previous implementation fetched connected client IPs via API (which was
returning empty data). The filter now checks the AP's own management IP
directly from the data already in the table — no network request, instant.
An AP is shown when its IP last octet is between 150 and 155 inclusive.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
New "Filter .150–.155" button fetches all connected clients via
GET /api/all-clients (one request per site, grouped by AP MAC),
then hides any AP row that has no client with a last-octet IP
between 150 and 155. Clicking again clears the filter.
The name/site search and IP filter compose (AND logic) via a shared
applyFilters() function. Client data is cached in-memory for the
current page session so repeated toggles don't re-fetch.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
After confirming a reboot (single or bulk), the row button and checkbox
are immediately disabled and can't be re-triggered in the current session.
Button text changes to "Rebooting…" while the request is in flight, then
"Rebooted" on success or "Failed" on error — but stays disabled either way.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Clicking an AP name opens a modal showing all wireless clients currently
associated with that AP: hostname/MAC, IP, SSID, band, channel, signal
strength with quality label, TX/RX link rate, and connection uptime.
Backend: GET /api/ap-clients?mac=&site_key= calls the Omada clients
endpoint with filters.apMac; falls back to client-side filtering if the
controller doesn't support that query param.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
FastAPI/Jinja2 web app for viewing and rebooting TP-Link Omada APs
across all sites. Authentik OIDC auth, SQLite audit log, Docker deploy.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
