Feature request - Possibility to group APs and WLANs more

Today we have 100's of ESS profiles (wifi profiles) and when you manage a large number of wifi APs and wifi profiles it is just so messy. Another low-cost manufacter that has a free wifi controller has a very nice setup for this where sites with wifi profiles and ap groups is more separated.

Just a thought and a heads up for the developers :)

Hi bipbaep -- I am not sure I fully understand why so many Profiles are necessary (note Profile was changed to AP Group in the 1.4.0 release). In general cnMaestro has two configuration objects for WiFi: the AP Group (which has device configuration shared among many APs), and WLANs (which define the wireless configuration). WLANs can be mapped to multiple AP Groups, and devices are placed in one of a generally small number of AP Groups (for  shared configuration). Since some configuration parameters tend to be different across devices (such as static IP address, radio channels, etc.), these can be configured per-device in the Device Overrides section of the individual AP configuration page. This allows the AP Group to be shared widely, and individual APs can override this subset of configuration per device.

cnMaestro also adds an additional, non-configuration grouping called a Site, which aggregates APs (of potentially different configuration) into a single location and presents statistics and a dashboard for them (and allows one to set a floor plan). So one can aggregate APs through configuration using the AP Group, and view a consolidated Dashboard for all the devices in the group; or independently by locality using the Site, and also view consolidated Statistics for all devices at the Site.

As i said, when you have 100's of wifi profiles, it get's very messy with todays setup in cnMaestro. All the wifi profiles and AP groups is listed in the same place, regardless of which site it "belongs" to. And if you have ex. 100 sites, and all the 100 sites have different wifi profiles and different AP groups, it get's messy.

I get it now -- we do that so they can be shared. Oftentimes configuration can be reused across multiple Sites, so making the objects global makes this easier.

Well, think we have to agree to disagree on that.
If you absolutly want AP's to share config without creating it again, just put them on the same site.
In my 15 years as a network consultant, i have never reused a ESS profile across multiple sites.
But then again, we use the wifi equipment for enterprise wifi solutions, not as ISP/WISP.

Are you using the "Access and Backhaul" or "Wireless LAN" Account type?  The Wireless LAN Account Type has additional views for AP Groups similar to how Sites are treated.

We're using the "Wireless LAN" account type. It is allitle better than the "Access and Backhaul" but not exactly what we're looking for. The "problem" is that WLAN and AP groups is all togheter. If you for example have 500 AP's, 50 AP groups, and each AP group has 2 to 6 WLANs it is very messy to administer with todays setup in the GUI.

Just so I'm not misunderstanding you, what you're suggesting is to make WLANs exclusive to AP Groups and not shareable?  Or is it more to nest WLANs under AP Groups in some way in order to make the relationships clearer?  Both?

More the second thing you mention, to nest WLANs under AP Groups in some way, so the relationship is clearer. But this way of setting it up will make WLAN exclusive to a AP Group also, if i'm not mistaking.

Another (low end, *cremt* UBNT) WLAN manufactorer has a good setup for this, i think. They have virtual sites on the controller where APs is located, and under each site they have WLAN Groups where the WLAN is created. You can then create multiple WLAN Groups if you have a site with multiple physical locations for the APs with different WLAN setup for the same "customer"/site. This way you don't see APs, WLANs, WLAN Groups, statistics etc. from other sites. This way, if you create a WLAN in a WLAN Group, it is exclusive to that WLAN Group and site, and if you need the same WLAN setup on another WLAN Group or another site you have to create it again manually.

This is more clean and easy to manage from a administrative perspective if you have multiple customers on one controller.

1 Like

Have to pick this up again. We have been using cnPilot for quite some time now, and we are mostly very pleased with the quality and performance. But when comparing the management of cnMaestro to ex. Ubiquiti UniFi controller it is a total disaster.
Can you please try to make cnMaestro easier and more "straightforwardly"?
We manage ~1000 APs that is located at different sites, with different AP groups, and different ESS profiles.
To this day we have swapped 100 APs from Ubiquiti UniFi to Cambium cnPilot, and we have already started to loose controll since all APs, ESS (WLAN) profiles, WLAN groups etc. is in one big pot.

With the UniFi controller it is very simple to have controll with the way Ubiquiti has set this up with different sites that has it's own setup, it's own exclusive WLAN groups, and it's own ESS's (WLAN's).

We are exclusively using one cnMaestro on-prem controller for WLAN (cnPilot) management.

Please Cambium, make cnMaestro in "Wireless LAN" mode more intuitive and easy.

No one else want this? Is it just me (us)? And no response from Cambium?

Hi bipbaep -- we are currently working on an infrastructure update for managed service providers that I believe, with some modifications, would also address your use case. Fundamentally the goal is to provide a new account container that isolates a subset of UI components (WLANs, AP Groups, Sites) so they can be managed independently. There would be two views: one in which only the subset components are available -- which I think is essentially your request; and a second, which provides an aggregate across all the objects -- similar to what cnMaestro currently has. A globall administrator can manage the entire collection of deployments, or focus on a specific, independent subset. In the managed service case, this subset would be allocated to a tenant for administration; in your case, it would simply be an isolated grouping that represents the autonomous pieces of your network. Anyway, you will hear more about this direction in the next few weeks.