Introducing Wireless LANs and SSIDs to Obelinf

The wireless network is usually the last part of the infrastructure anyone can point to. The racks are labeled, the switch ports are documented, and the VLANs have names, but the SSIDs you broadcast live only in whatever controller happens to be running today. When the controller is replaced, the office is split, or someone asks which networks you operate, that knowledge turns out to be locked in a configuration screen that nobody exported.

Obelinf now closes that gap. You can document wireless LANs and wireless LAN groups alongside your subnets, VLANs, devices, and cables, so the wireless layer becomes part of the same source of truth instead of a separate silo. Every SSID gets a record, and every record can belong to a group.

At a Glance: Where Wireless Records Live

Wireless Records Belong with the Rest of the Network

The argument for keeping wireless records next to the wired ones is the same argument that made you document cables and ports in the first place: the wireless layer is part of the network, and a list that lives only in a controller is one failed export away from being lost. A wireless LAN record gives every SSID a stable name you own, and grouping those records by purpose keeps a growing list of networks readable.

Obelinf does not replace the controller, and it does not claim to. The access points, the radios, and the VLAN a client actually lands in are still the controller’s job, and you verify those on the controller. What changes is where the map of your networks lives. Instead of a spreadsheet copied from a vendor portal, the SSIDs and their groups sit in the same inventory as your VLANs, subnets, and devices, so one search covers the whole network and every change lands in the same changelog.

What a Wireless LAN Record Holds

A wireless LAN record is deliberately small. It has a name for your own reference and the SSID that clients actually see, and the SSID must be unique within its group so you cannot document two different networks under the same broadcast name. It can also carry a description, which is the right place to note what the network is for. That record is the anchor for everything else you want to keep about the network: which group it belongs to, and by extension which purpose it serves.

Keeping the record separate from the access points matters. An access point is hardware, and the device inventory already handles hardware with serial numbers, ports, and rack positions. The SSID is a logical network that several access points may broadcast at once across several buildings, so it deserves its own record rather than being duplicated into every AP entry. One record describes the hardware, the other names the network, and each list stays useful on its own.

Grouping Wireless LANs by Site and Purpose

Wireless LAN groups are how you keep a growing list of SSIDs readable. A group has a name, a slug, an optional description, and an optional parent, so you can nest them the way your network is actually organized. Most teams end up with a small hierarchy near the top, for example a parent per site, with corporate, guest, and IoT groups beneath it. The slug gives each group a stable, readable identifier you can use in scripts and links without worrying about spaces or punctuation.

Grouping also makes multi site networks tractable. When the same ACME-Guest SSID exists in five offices, you document it once as a group, and the per site VLAN IDs live in your VLAN records where they belong. The names stay consistent, which means help desk scripts, onboarding material, and roaming behavior all line up, even though the underlying IDs differ by site.

Wireless Records Sit Beside Your VLANs and Subnets

Wireless LANs and groups live in the same inventory as your VLANs and subnets, so you are not maintaining a separate wireless document. You can search an SSID and a VLAN from one place, and every change to either lands in the same audit trail. That is the practical win: one inventory instead of a controller on one side and a spreadsheet on the other.

What Obelinf does not do yet is link a wireless LAN to a specific VLAN for you. The SSID to VLAN mapping is still a value you document and verify, and if you model segmentation with the VLAN and subnet management feature, the VLAN records remain the place those identifiers live. Keeping the wireless records next to them at least puts the two halves of the relationship in one inventory, rather than making you hold the connection in your head.

Available over the API and MCP

Wireless LANs and wireless LAN groups are not a display only feature. They are available over the REST API and through the MCP server, so a provisioning workflow can create an SSID record when a new network is deployed, and an AI agent can answer questions about your wireless inventory from the same data your team reads. Read only API keys can list wireless LANs and groups but cannot create, update, or delete them, so an assistant you have granted read access cannot quietly change your documentation.

What It Costs

Wireless LAN management is available on every plan. The free Personal plan includes 10 wireless LANs and wireless LAN groups combined, which is plenty to document a homelab or a single small office. Paid plans remove the cap, so a multi site organization can record every SSID and every group without counting. You can see the full breakdown on the pricing page.

Start Documenting Your Wireless Networks

The fastest way to make this useful is to start with the SSIDs you can name from memory, then fill the gaps from the controller once the skeleton exists. Create a group per purpose, add the SSIDs you broadcast, and give each record a description that explains what the network is for. The result is a wireless inventory that survives the next controller migration and stays searchable alongside the rest of your network.

You can create your account for free at obelinf.com and add your first wireless LAN in minutes.