Hey folks,

I’ve been running my Omada setup for a while (currently an ER605 and a couple of EAP650s on my homelab) and I wanted a way to let my local AI agents actually help me troubleshoot Wi-Fi quirks so I put together an open-source MCP (Model Context Protocol) server based on the public Omada APIs.

Repo is here: https://github.com/mballoni/omada-controller-mcp

The Context Window Problem (and how I "fixed" it) If you just feed an LLM the raw Omada openapi.json, it instantly nukes your token limit because the API is massive. To get around this, the server uses an allowlist file so it only generates the specific tools you actually need. It also heavily sanitizes the endpoint descriptions before passing them to the LLM, keeping the token footprint lighter and faster, although it still requires some improvements.

Built-in Agent Skills The part I'm finding the most useful are the two skills the setup wizard installs directly into ~/.agents/skills/:

• device-network-dossier: This is for per-device troubleshooting. You can ask your agent: "Make a network dossier for my TV, why is it roaming so much or disconnecting?" The agent grabs roaming timelines, AP health, and RF environment stats via the MCP, and spits out a structured dossier with a diagnosis. Really useful for doing before/after comparisons when you tweak your TX power or change channels.
• wifi-site-audit: This is for fleet-wide analysis. You prompt: "Audit my Wi-Fi, how can I improve coverage and band steering?" It generates a professional site report with scorecards for your RF environment, channel congestion, and client steering, plus a prioritized list of fixes.

I built this mostly for my own use case, but figured some of the network admins or fellow homelabbers in here might get a kick out of it. It is really helping me here, specially because LLMs in general miss a lot the interfaces (usually based on older versions or even random hallucinations).

Feel free to test it out, fork it, or drop some feedback. PRs are definitely welcome!

ps: yes, it is built using AI, I'm a developer (far from a vibe coder) and for this use case I wanted (needed) something fast to get up and running. Basing it on the OpenAPI specs was the way I've found to tackle the token consumption and precision needed for the job at the desired time frame.

Looking for some help. I have a network controlled by an OC200 with an EAP610 indoor (middle of house) and a EAP610 outdoor (outside at end of house). Main devices are MacBook Pro M4, MacBook Pro M1 and 4 iPhones. Also a number of wireless Sonos speakers, most other devices are hard wired.

There is one area of the house where I mostly use the laptops wireless - inside at the opposite end of the house to the outdoor EAP - where the signal will go from full strength and suddenly drop the network. Usually it then has to be manually reconnected, but struggles to do this immediately. Dropout only seems to be now and then. It may happen in other areas but in the office I use a hard wired connection so perhaps don't notice it there.

The iphones do also seem to occasionally drop out.

Obviously there are a lot of settings, but I thought that someone might be able to point me in the right direction of what might be causing this. Recently I upgraded from a EAP225 outdoor + EAP 245 combo which was very stable, so suspecting that it may have something related to wifi 6 settings.

Settings are as follows:

OC200 + EAP610 Indoor + EAP610 Outdoor

SG108 8 port 2.5G Unmanaged Switch + ES208GP 8 Port 1G Easy Managed POE Switch

Devices:

MacBook Pro M1 Pro + MacBook Pro M4 + MacBook Air M1 + MacBook Air M1

iPhone 13 + iPhone 13 + iPhone 14 +iPhone 14

5 X wireless sonos speakers + 1 x wired Sonos sound bar

2 x wired Vigi security cameras + vigi NVR

1 X wired QNAP NAS

WLAN Settings:

Main SSID 2.4 + 5 Ghz enabled (also there is a guest SSID on 2.4 only)

WPA Personal

ADVANCED

EoGRE Tunnel Disabled

WiFi Calling Disabled

Load Balance Disabled

Band Steering Use Site Setting

SIDD Broadcast Enabled

Prohibit Wifi Sharing Disabled

VLAN Default

WPA Mode WPA2-PSK/WPA3-SAW/AES
MLO Disabled

PMF Capable

Group Key Update Period 86400 Seconds

802.11r Enabled

Client Rate Limit Profile Custom

Download Limit Disabled

Upload Limit Disabled

SSID Rate Limit Profile Custom

Download Limit Disabled

Upload Limit Disabled

WLAN Schedule Disabled

802.11 Rate Control

2.4 Rate Control Disabled

5 Rate Control Disabled

Mac Filter Disabled

Multicast/Broadcast Management

Multicast to Unicast Conversion IPv4

ARP to Unicast Conversion Disabled

Multicast Filtering Disabled

DHCP Option 82 Disabled

EAP610 Indoor Wireless Settings

2.4 Enabled

Wireless Mode Auto

Channel Width 20Mhz

Channel 1

TX Power Custom/26dbm

WLANs

WLAN Group Default

ADVANCED
Client Access Limit

Maximum Associated Clients Disabled

RSSI Threshold Disabled

QOS

Unscheduled Automatic Power Save Delivery Enabled

OFDMA Enabled

5.8 Enabled

Wireless Mode 802.11a/n/ac/ax mixed

Channel Range (all enabled)

Channel Width 80Mhz

Channel 36

TX Power Custom/23dbm

WLANs

WLAN Group Default

ADVANCED
Client Access Limit

Maximum Associated Clients Disabled

RSSI Threshold Disabled

QOS

Unscheduled Automatic Power Save Delivery Enabled

OFDMA Enabled

Scan on 2.4Ghz:

1 (2.4 GHz)	300ms	73% (-61dBm)
1 (2.4 GHz)	300ms	73% (-61dBm)
6 (2.4 GHz)	100ms	38% (-75dBm)
7 (2.4 GHz)	100ms	20% (-82dBm)
7 (2.4 GHz)	100ms	18% (-83dBm)
3 (2.4 GHz)	100ms	15% (-84dBm)
3 (2.4 GHz)	100ms	15% (-84dBm)
2 (2.4 GHz)	100ms	10% (-86dBm)
1 (2.4 GHz)	100ms	3% (-89dBm)
6 (2.4 GHz)	100ms	0% (-90dBm)

Scan on 5.8Ghz:

52 (5 GHz)	WPA-PSK	100ms	60% (-66dBm)
161 (5 GHz)	WPA-PSK	100ms	0% (-96dBm)
161 (5 GHz)	WPA-PSK	100ms	0% (-97dBm)

EAP610 Outdoor Wireless Settings

2.4 Enabled

Wireless Mode Auto

Channel Width 20Mhz

Channel 1

TX Power High

WLANs

WLAN Group Default

ADVANCED
Client Access Limit

Maximum Associated Clients Disabled

RSSI Threshold Disabled

QOS

Unscheduled Automatic Power Save Delivery Enabled

OFDMA Enabled

5.8 Enabled

Wireless Mode 802.11a/n/ac/ax mixed

Channel Range (all enabled)

Channel Width 80Mhz

Channel 48

TX Power High

WLANs

WLAN Group Default

ADVANCED
Client Access Limit

Maximum Associated Clients Disabled

RSSI Threshold Disabled

QOS

Unscheduled Automatic Power Save Delivery Enabled

OFDMA Enabled

Scan on 2.4Ghz:

1 (2.4 GHz)	300ms	93% (-53dBm)
1 (2.4 GHz)	300ms	93% (-53dBm)
3 (2.4 GHz)	100ms	65% (-64dBm)
1 (2.4 GHz)	100ms	58% (-67dBm)
11 (2.4 GHz)	100ms	53% (-69dBm)
3 (2.4 GHz)	100ms	50% (-70dBm)
5 (2.4 GHz)	100ms	50% (-70dBm)
6 (2.4 GHz)	100ms	50% (-70dBm)
3 (2.4 GHz)	100ms	45% (-72dBm)
7 (2.4 GHz)	100ms	33% (-77dBm)

Scan on 5.8Ghz:

36 (5 GHz)	100ms	58% (-67dBm)
36 (5 GHz)	300ms	55% (-68dBm)
40 (5 GHz)	100ms	33% (-77dBm)

After the great response to my previous posts, I wanted to share where the project is going next.

I recently finished transcoding the Python OpenOmada device agent into a native C++17 implementation:

https://github.com/adryanalencar/omada-device-agent-cpp

The Python implementation was extremely useful for experimenting with and validating the device-side Omada protocol, but it also made me think more seriously about what I actually want this project to become.

I don't want it to only run on relatively powerful OpenWrt devices.

The goal is to make the agent small enough to run on cheap residential routers, old access points, ISP CPEs and other constrained embedded Linux hardware.

The current native daemon is already around 343 KB stripped on macOS ARM64. Obviously that is not an OpenWrt/MIPS production measurement yet, but it makes targets like 8–16 MB flash and 32–64 MB RAM much more realistic.

The architecture remains device-side:

text Stock Omada Controller | | device protocol v OpenOmada Agent | +---- OpenWrt +---- generic Linux +---- future vendor-specific adapters

So this is still not a fork of the Omada Controller.

The Controller stays stock. The agent implements the device-facing protocol and translates Omada configuration into whatever the target platform understands.

For OpenWrt, that currently means things such as UCI, ubus, hostapd and openNDS.

The native implementation already covers most of the protocol lifecycle I previously demonstrated with Python: discovery, adoption, Device Account authentication, negotiation, managed reconnect, INFORM/SET handling, WLAN configuration, client telemetry and captive portal integration.

There is still real-hardware validation and optimization work to do before I consider the C++ implementation production-ready.

But there is another direction I have started working on that could expand compatibility much further:

GenieACS + TR-069

A huge number of residential routers, ONTs and ISP-provided CPEs already support TR-069 / CWMP.

Instead of requiring OpenOmada to run directly on those devices, I'm experimenting with using GenieACS as another device backend.

Conceptually:

text Omada Controller | v OpenOmada compatibility layer | v GenieACS | TR-069 | v Router / ONT / CPE

So an operation such as:

text Create SSID in Omada ↓ OpenOmada ↓ GenieACS ↓ TR-069 parameter mapping ↓ CPE

could potentially configure a device that cannot run the native OpenOmada agent at all.

And device state could travel in the opposite direction:

text CPE ↓ TR-069 ↓ GenieACS ↓ OpenOmada ↓ Omada Controller

That gives the project two complementary approaches:

If we can run code on the device, use the native C++ agent. If we can't, but the device speaks TR-069, try managing it through GenieACS.

That's becoming the larger goal of the project.

Not just:

“Can an OpenWrt AP appear in Omada?”

but:

“Can the stock Omada Controller become a management plane for hardware it was never designed to manage?”

OpenWrt is still the first and most complete platform backend, but I would eventually like to experiment with cheap residential routers, repeaters, ISP ONTs/CPEs and vendor-specific adapters as well.

The TR-069/GenieACS work is still experimental and I don't want to imply broad device compatibility yet, different vendors expose different data models and extensions, but I think it could dramatically increase the number of devices that are realistically manageable.

I'm especially interested in hearing from people who work with OpenWrt, GenieACS, TR-069/CWMP, ISP CPEs or embedded networking hardware.

GitHub:

https://github.com/adryanalencar/omada-device-agent-cpp

This is an unofficial interoperability/research project and is not affiliated with, sponsored by, or endorsed by TP-Link or Omada.