I will fully confess, following is mostly drafted by Claude with my input, but I'm tired, and this summarized it better than I ever could. And I'm damned pleased with the outcome.
Been fighting this one for a while. My main SSID would stay connected but just stall whenever 5 GHz was on, so I'd been running it 2.4 only as a workaround. Omada setup, 5 APs, controller on my home server. The family room had trouble on my old Apple Wi-Fi too, so it wasn't just the new gear.
Over about a week with Claude Code we built a small measurement setup:
iPhone app that labels rooms and spots, switches between three temporary test SSIDs (2.4 only, 5 only, dual), and measures loss split by direction, latency, stalls, DNS and speed. Also a soak screen for standing in one spot for 20 min.
An iOS Shortcut to grab RSSI, noise and channel, since that's about the only way to get them on iOS.
Python helper on my server: UDP echo, a speed test endpoint, and a read-only poller against the Omada API (viewer account) for the AP side of things, signal, radio stats, client bytes.
Python analyzer that merges the phone side and the AP side and flags likely causes.
A few things I liked about the process. One session built it and wrote a review brief (what's verified, what isn't, where it was least sure), then fresh sessions reviewed it independently. The reviews caught real bugs before I ever walked around the house. It also ran the app in the simulator against 10 fault scenarios (loss each direction, stalls, server down, etc.) and that found a real defect too. And I kept it to one change at a time on the network; it proposes, I click it in Omada, it verifies through the API and logs it in a changelog with the rollback.
What we found:
Most of the house was clean, even weak spots around -77.
The family room couch was awful. 92-98% loss, one stall over 16 minutes. Phone still connected at -60, Omada showing good SNR, but the AP saw 0 upload bytes. All the loss was phone to AP.
2.4 at the couch was fine. Pulled the test SSID off the APs on channel 149, phone went to another AP on 36: 0% loss.
AirPort Utility scan showed nothing else on 149-165, so it's something non-Wi-Fi. Best guess is the alarm motion sensor on the wall behind the couch, but I didn't take it apart.
To make sure it wasn't the AP itself, moved that same AP to 44 and soaked the same spot. 17 min, 0% loss. So it follows the channel, not the AP.
Also turned up that Omada's nightly WLAN Optimization had set everything to wide channels (three APs at 160 MHz) and parked two APs on 149. That's off now.
Fix was a new channel plan, mostly 40 MHz, nothing on 149-165, then 5 GHz back on for the main SSID. Dress rehearsal on the test SSID first: 29 min at the couch with 0 stalls, and a walk through the house with 6 roams and no stalls at any of them. So far so good with the family.
It's not hands-off. I still did all the Omada changes myself, built the Shortcut (took multiple tries – very frustrating), and installed the app from Xcode. Some of its directions for the Omada UI didn't match what I was seeing and I had to ask more questions. But I'd never have found one bad channel at one spot on a couch by guessing – and this took care of something that's been frustrating me for over 10 years across multiple Access Point brands/hardware (Google, Deco, and now Omada).
Source: r/ClaudeAI · by /u/CompoundChord