I have some feature request for Omada Controller collected over time from our Omada customers and from Omada users here in the forum. I would appreciate very much if you could consider those features in a future version of Omada controller.
1. Statistics page
It would be helpful if the statistics page would allow to select a pie chart for showing numbers of users/guests per EAP, not only per SSID. Often, sites have only one SSID at all and the current pie chart always shows 100% users for this SSID. I know, it's already in Omada App, but sysadmins would like to see this in Omada software controller and OC200, too.
2. Client hostnames
If WiFi hostnames are empty (device shows up as »Unknown«), Omada Controller should query the DNS server for the hostname. DNS servers in small SOHO networks keep track of the hostname sent by DHCP automatically. Business users often use a full-fledged DNS server. Additionally, the client's hostname should be allowed to be set manually – you have accepted the latter suggestion of a manual settings for home users already as far as I know. But DNS names should be queried for power (business) users, too, and it would be beneficial even for SOHO users.
3. Proxying capabilities
It would be helpful to allow use of web proxys such as the nginx or apache web server, which can forward requests to Omada controller. This would just require the ability to bind Omada controller to specific IP addresses set in the properties, thus preventing the controller to listen to all IP addresses of the server. Business class servers often have web front-ends and load-balancing while the software runs on a back-end server. Those load balancing functions of a proxy could be used easily for Omada controller with only small changes in the Java code which allow binding to certain IP adresses.
4. mongod database
Sysadmins should be able to use a system-provided mongodb instance alternatively to the built-in one. Currently Omada controller always starts an own mongod instance. If it would be possible to prevent this start, Omada controller could use an existing (already installed) mongod by just changing the port in the properties. So please make start of the built-in mongod optional for those users who run an own mongod already. No need to run DB servers twice on the same system.
5. Make Java code platform-independent again
In version 2.x Omada controller's Java code was platform-independent. Java classes for Windows could be used on Linux and FreeBSD UNIX without any change. Starting with version 3 Omada controller introduced platform dependency, which isn't really needed (Java has been designed to be platform-independent). Only change required in V3 Omada controller would be to not query for the platform the controller is running on, but instead querying for the existance of platform-dependend helper commands such as ps (then it's running on Linux or FreeBSD) or tasklist (then it is running on Windows).
By querying for the existance of helper commands instead of querying the platform you would have to support only one version of Omada controller's Java code for every platform. No more differences in Java code for Windows, Linux and FreeBSD – just one Java code base like it was in versions 2.4 to 2.7. You only would need to package different software packages versions for distribution of built-in binaries such as mongod, but the Omada community version, which avoids any built-in binary, could run on any platform, whether it's 32 bit, 64 bit or x86, mips or arm architecture.
If R&D doesn't want to unite the Java code base, then please remove at least the platform checks in Java method »com.tp_link.eap.start.EapLinuxMain« and consider removal of the platform checks in the Linux version of Omada controller. For example, if you remove those platform checks, the Linux version could be made easily to run also on FreeBSD, which is often used as an Internet server. And I'm sure, no-one would download the Linux version anyway if he runs Windows.
6. SSL certificates
While it is possible to change SSL certificates in the Linux version easily, it isn't possible at all on OC200. Please consider an upload mechanism for OC200 either through the web UI or maybe through the optional USB stick, which can be added to OC200. There is a lot of space on USB sticks used for auto-backups. Why not use it for other things, too?
7. Client isolation
Please consider to add a setting for »Client Isolation« again. It would be not necessary to change the current existing setting »Guest Network«, which still could co-exist and which could enable client isolation, too. But it would be beneficial to only enable client isolation without the invisible ACLs being set when using »Guest Network« setting. This would also simplify access from guest users to the OC200 portal when OC200 is the only device in the (wired) LAN.
These are the feature requests I'm often asked for by our customers and by users here in the forum. It would definitely improve Omada Controller.
Thanks very much for your consideration.