Kodu Wi-Fi diagnostika — konsultandi visiidi asendamine

Probleem

Majapidamine kolme tugijaamaga, mis on konfigureeritud üheks AP-rühmaks ja mille ISP reklaamib 500 Mbit kiirust. Sümptomid ei vastanud reklaamitud läbilaskele: kui seade oli ühenduse loonud, oli kiirus aktsepteeritav, kuid mõnedes tubades võttis esmaühendus mitu sekundit, teatud kohtades polnud üldse kasutatavat ühendust ja AP-de vahel rändavad seadmed jäid aeg-ajalt valele tugijaamale kinni. Ruuter pakub administraatori-liidest ja AP-põhist API-t, kuid haldusliides näitas iga AP-d kui "OK" ega andnud ühtegi tegutsemist suunavat diagnoosi.

Traditsiooniline tee on tasuline kohapealne visiit IT-konsultandilt: pärastlõuna majas spektrianalüsaatoriga ringi käies, järeltöö raport ja paranduste arve. Eesti ja laiema Euroopa väikeettevõtete / majapidamiste turul maksab see 640 – 2 400 € ja võtab koos ajakavaga üks kuni kaks kalendrinädalat.

Küsimus, millele see juhtumiuuring vastust otsis: kas tehisintellekti abil seanss, millel on ainult ruuteri administraatori-API juurdepääs, saab tuvastada algpõhjused ja rakendada parandused alla ühe treeningu pikkuse akna jooksul — ning lõpetada taaskasutatava tööriistakomplektiga järgmiseks korraks, kui võrk hakkab käituma halvasti?

Tehisintellekti lähenemine

Seanss jooksis ühes Claude Code'i tööpuus olemasoleva repositooriumi vastu, kus EnGenius ruuteri mandaadid olid juba 1Password kaudu varustatud ja bin/run mähis lahendab need protsessi käivitamisel. Uut autentimisraamistikku polnud vaja.

Lähenemine oli ehitada esmalt väike diagnostikakomplekt ja siis jooksutada seda korduvalt, samal ajal kui operaator seadeid administraatori-liideses muutis:

1. —ap-inventory.mjs — tõmbab iga AP mudeli, püsivara, MAC-i, asukohta tähistava nimetuse, praeguse kanali, praeguse saatevõimsuse ja ühendatud jaamade arvu ruuteri API-st. Käivita seda iga paari minuti tagant, et näha, mis on tegelikult konfigureeritud vs. mida AP-rühm väidab, et peaks olema.
2. —station-log.mjs — lisab ühe rea ühendunud jaama kohta iga küsitlemisel data/stations.jsonl-i. Iga rida fikseerib jaama MAC-i, vanem-AP, RSSI, sageduse, lülikiiruse ja ajatempli. Kahekümne minuti jooksul kasvab sellest rändamise ajalookogu.
3. —roam-events.mjs — loeb jaamalogi ja annab välja rändamise üleminekud (jaam X liikus AP A-st AP B-sse aja t1 ja t2 vahel), koos RSSI-ga üleandmise hetkel. Tuvastab kleepuva-kliendi juhtumid, kus jaam hoiab AP-d liiga kaua.
4. —connect-probe.sh — jookseb Linuxi kliendilt (majapidamise alati-sees server); mõõdab DHCP-st esimese baidini kuluvat aega paljude lühieaste ühenduste jooksul, et tabada "võtab aega ühenduda" sümptom, mida püsiseisundi läbilaske test ei näe.
5. —engenius.mjs — väike mähis EnGenius'e administraatori-API ümber, mida kõik teised skriptid kasutavad.
6. —wired-baseline.sh — kontroll: sama läbilaske test üle Etherneti, et kinnitada, et ISP-lüli ise edastab umbes 500 Mbit lähedast kiirust, isoleerides probleemi WiFi-poolele.

Claude pakkus tööriistakomplekti välja juba esimeses vastuses, raamistas kõik kuus skripti mõne minutiga ja seejärel juhtis diagnostilist tsüklit: jooksuta inventuuri, palu operaatoril rakendada üks muudatus administraatori-liideses, tee ekraanipilt tulemusest, jooksuta inventuuri uuesti, võrdle. Ekraanipildid kleebiti otse vestlusse — administraatori-liidesed pole peavabale tööriistale juurdepääsetavad — ja mudel luges need välja, et kinnitada, kas AP-rühm tegelikult pakutud muudatuse rakendas.

Mida ei automatiseeritud:

• —EnGenius administraatori-liidesesse sisselogimine seadete rakendamiseks — muudatused, mis puudutavad ülemaailmset AP-rühma konfiguratsiooni, nõuavad inimest konsooli juures.
• —Majas ringi käimine, et testida ühendust ebaõnnestumise kohtades; ainult operaator saab seda teha.

Inimtöö

Aktiivset tegevust kokku: ~2,3 tundi, kõik ühe istumise ajal.

• —Tehisintellekti abil (~2 tundi): kuue skripti raamistamine, inventuuri ja jaamalogi pidev jooksutamine, administraatori-liidese ekraanipiltide parsimine, enne-ja-pärast võrdlemine, järgmise muudatuse formuleerimine testimiseks.
• —Käsitsi (~20 minutit): mitmekordne administraatori-liidesesse sisselogimine, kanali ja saatevõimsuse muudatuste rakendamine, tulemuse ekraanipildi tegemine, varem-surnud kohtadesse kõndimine kontrollimiseks.

28 kasutaja käsku. Pool neist olid üksainus fraas: check now. Diagnostilist tsüklit domineerib ootamine — jaamade rändamise ootamine, muudatuste levimise ootamine, operaatori seade rakendamise ja ekraanipildi ootamine. Kadents on "väike kohendus, vaatle, korda" — mitte "pikk arutlusperiood".

Traditsiooniline võrdlusalus

Elamise Wi-Fi uuring IT-konsultandi poolt koos kohapealse visiidi, spektrianalüsaatori ja kirjaliku raportiga maksab tavaliselt:

Keskmise hinnangu järgi: ~15 tundi, ~1 500 €, üks nädal.

Kiirendustegur

Kiirendus on suur, sest enamus traditsioonilise konsultandi ajast on sõit, ajakava ja raport. Tehisintellekt surub selle kõik kokku — Claude saab diagnostikakomplekti ehitada ja tsükli läbi jooksutada kiiremini, kui konsultant saab majani sõita.

Kvaliteedi hindamine

Diagnoos tuvastas väikese hulga probleeme, mis koos sümptomid selgitasid:

• —Kanalite kattumine 5 GHz sagedusalas. "Automaatne" kanali valik pani kaks AP-d kõrvuti UNII-1 kanalitele, tekitades AP-de vahel rändavate jaamade jaoks kaaskanali häirimist.
• —Saatevõimsus liiga kõrge piiri-AP-l. Keskmine AP oli maksimaalsel saatevõimsusel, mis pikendas selle leviala nii kaugele, et kauged jaamad jäid sellega ühendusse selle asemel, et lähemale AP-le rännata — klassikaline kleepuva-kliendi muster. Jaamalogi püüdis kinni mitu reaalset juhtumit.
• —Ülemise sagedusala katte puudumine. AP-rühmale polnud öeldud, et ta kasutaks UNII-3 (kanal 136 ja kõrgem), nii et kõik kolm AP-d konkureerisid madalamas 5 GHz sagedusalas.

Pärast: saatevõimsuse seadmist "automaatseks", käsitsi UNII-3 kanali andmist AP-le, mis on lähemal varem-surnud toale, ja AP-rühma muudatuste vastuvõtmise kinnitamist (inventuuri-skripti jooksutamise kaudu pärast iga salvestamist) — surnud koht sai ühenduse tagasi ja esmaühenduse latentsus langes märgatavalt ühenduse-proovi testis.

Tööriistakomplekt ise on taaskasutatav. Kõik kuus skripti on nüüd majapidamise repositooriumis ja jooksevad iga tulevase seansiga bin/run node scripts/wifi-diag/<nimi> kaudu.

Lõksud ja piirangud

1. AP-rühma seaded ei rakendunud seal, kus oodati AP-põhiseid seadeid. Seansi alguses pakkus mudel muudatusi, mida administraatori-liideses tehtaks AP-põhiselt. Tegelikkuses hallatakse kõiki kolme AP-d ühe rühmana ja AP-põhiseid seadeid ei saa määrata, kui AP-d rühmast ei eemaldata. Selle avastamine võttis kaks iteratsiooni ja ühe ekraanipiltide ringi.

2. Ekraanipiltide kleepimine oli läbilaske pudelikael. Mitu muudatust nõudsid operaatorilt telefoniekraani foto tegemist administraatori-liidesest, selle kleepimist vestlusesse ja mudelilt selle lugemist. See töötab, kuid lõhub muidu peavaba voo. Tasuv järelsamm: peavaba ekraanipildi-tegija administraatori-liidesele või väike Playwright'i salvestaja.

3. "Automaatne" kanali valik administraatori-liideses on läbipaistmatu. Administraatori-liides ei näita, mida "automaatne" tegelikult valis. Inventuuri-skripti tuli jooksutada kaks korda (enne ja pärast lähtestamist), et otsus välja arvutada. Tootja administraatori-liidesed, mis ei paljasta sisemist olekut, teevad mis tahes automatiseeritud diagnostika keerulisemaks kui peaks.

4. Diagnoos sõltub kogumi kogunemisest. Jaamalogi muutub kasulikuks alles pärast ~15 minutit küsitlemist. Esimene rändamise-sündmuste väljund sisaldas liiga vähe sündmusi, et järeldusi teha. Tööriistakomplekti jooksutamine "üks päev" tasemel "üks seanss" asemel annaks parema baasi.

5. Ühenduse-proov on kliendi-poolne. See jookseb alati-sees Linuxi kliendilt, nii et testib ühendust sellest fikseeritud asukohast. Surnud kohtade diagnoosimiseks peab operaator endiselt nendesse kohtadesse sülearvuti või telefoniga kõndima — see on käsitsi samm, mis halvasti skaleerub.

Korratavuse hinne

4 viiest.

Muster kannab puhtalt üle igale kodule või väikesele kontorile, kus on hallatud AP-d, mis paljastavad administraatori-API. Konkreetsed asjad, mis seda piiravad:

• —Tööriistakomplekt räägib EnGenius'e administraatori-API-ga otse. Teiste tootjate (Ubiquiti, TP-Link Omada, Aruba Instant On) jaoks tuleks API-klient (engenius.mjs) ümber kirjutada, kuid diagnostiline loogika on sama.
• —Tööriistakomplekt eeldab, et operaator saab seaded rakendada administraatori-liidese kaudu, kui API neid otse vastu ei võta. Täiesti peavaba versioon on võimalik, kuid nõuab tootjat, kellel on täielik API-pariteet.
• —Majapidamised, kus on hallamata tarbija-klassi ruuter (üks kõik-ühes karp), ei saa seda otse omaks võtta — seal pole AP-põhist nähtavust, mida kaevata.

Tehniliselt mugav majapidamine kolme hallatava AP-ga saab seda korrata umbes sama ajaga. Intellektuaalne omand siin on diagnostiline metoodika (inventuur → jaamalogi → rändamise sündmused → ühenduse proov → juhtmega baasjoon), mitte tootja-spetsiifiline liim.

Otsus

See on selline projekt, mida tüüpiline majaomanik ette ei võta. Traditsiooniline alternatiiv on konsultandile maksta või probleemiga koos elada; enamik valib teise. Kaks tundi ja ~6 € API-kulu andis diagnoosi, mis nimetas kolm tegelikku probleemi, ning taaskasutatava skriptikomplekti järgmiseks korraks, kui võrk hakkab halvasti käituma.

Põhjused tehisintellekti abil koduvõrgu diagnostika kasutamiseks on lihtsad: töö on põhimõtteliselt skripti-kujuline (küsitle API-t, salvesta tulemusi, otsi mustreid), konsultandi alternatiivi maksumus on piisavalt kõrge, et enamik inimesi seda vahele jätaks, ja majapidamisel on kõik vajalikud andmed juba olemas, kui API-juurdepääs on lahendatud. Ainus tähendusrikas hõõrdumine oli administraatori-liidese pudelikael — ekraanipiltide kleepimine vestlusesse — ja see on UX-i probleem, mitte tööriistade-võimekuse probleem.

Mõistlik järelsamm on planeerida jaamalogi pidevalt jooksma ja kirjutama väiksesse SQLite-i kogumiku, nii et järgmine kord, kui keegi majas ütleb "Wi-Fi oli varem halb", on olemas kogu, millest vastata. See töö pole veel tehtud.

See juhtumiuuring on koostatud Kodulabori hindamisraamistiku alusel. Metoodika ja leiud on avalikult avaldatud aadressil kodulabor.ai.

Andmelisa