@blindox 

Perhaps the Site's 'Clients' table?  Add the 'VLAN' column and then sort by VLAN.  You can extract current bitrate as well as aggregate.  Probably extract the table into Excel and massage it a bit more if you needed to.

  @blindox 

I do not believe the Omada controller goes to this level of granularity at this time.  Perhaps suggest it in the Requests & Suggestions forums? 

The only thing I can think of is maybe to put a cheap (SG2008?) Omada-controlled switch between the 7206 and your primary switch.  You would then map port profiles on the SG2008 such that each VLAN has its own cable between the SG2008 and the 7206 (obviously you need 1 LAN port on the 7206 for each VLAN your want to measure).  You can then use the Insights->Switch Status page to view what each VLAN is sending north through the router (of course this only works if your subscribers local storage doesn't require inter-VLAN routing on the 7206 for their local resources).

So imagine an SG2008 with a trunk port (VLAN profile = ALL) pointed downstream at your switch(es), servers and APs, and then several ports, each dedicated (and tagged) to a single VLAN and physically connected 1:1 to a unique LAN port on the 7206 (and one more for your management VLAN), you would get stats as below

Of course this may not work for your setup at all.

  @blindox 

Happy you found my idea useful.  I can see the utility of this funcitionality on a broader scope, as there are many people here that run multi-tenant wifi solutions and who might find it useful to provide per tenant reporting.  I think the issue will come down to the ability of the software in the router to separate out the information, because it requires the software and hardware to interact, and if there is to be any performance at all, the hardware has to do much of the heavy lifting (work).  That's why I suggested the 'insert a switch' approach, as I don't think the switch hardware integrated into any of the Omada routers would be capable of this (TPlink can feel free to prove me wrong!).

You can try posting it as a feature enhancement, but I would not count on it coming down the development pipe any time soon.  The $100 switch should get you there a lot sooner.

  @blindox 

You can actually get what you need from even the most basic of TPlink routers...below I show the ER605v1 (the original ugly stepchild router now discontinued) being monitored via SNMP using the free LibreNMS solution running in docker containers (any small linux based box will do).  Advantage here is you get realtime plus historicals, and you can expose the UI via a port forward and so 'access' it via the web.  You can also create tiered user access...thus potentially given some of your clients access to their realtime stats.

Sadly, this partticular site is dormant, so not much going on traffic wise, but enough that you can see the utility.

Lastly, the good news is that the info (counters) already exists so TPlink *could* incorporate this info into the Omada controller.

First the 'combined' graphs:

and then if you want to break it down by VLANs

  @blindox 

Happy to share.

Yes, the ER605v1 has not seen any development in a long time (basically its resources are maxed out).  For instance, it will never get Wireguard or DPI.  I too have a load of these devices, which with a monthly reboot schedule (because of a memory leak they never could fix) and the latest firmware are (still) good enough for small sites.  The ER605v2 is quite a step up and should have a longer happier lifetime as well as handling Wireguard.

LibreNMS is apparently the community version of Observium (or a fork thereof).  It's running here on a local Synology NAS (you don't want to run it on SSDs...lot of drive r/w's).  I was using it to track long term memory consumption, and just never tore it down :)

You can enable SNMP under the Omada Controller...that's how I have mine setup.  The stats I shared above are actually from a remote site, connected via L2TP/IPsec.  The SNMP access is independent of the controller, so you'll be fine.

Honestly, I'd run it locally and use the NAS to proxy connections via AWS.  It's also easier to debug :). Once you get it running, then you can transistion to a cloud instance.

With a little futzing around you could probaby create some customized reports per VLAN and then give your users read/only access to just that report.  More importantly you can show historicals and generate averages, uptimes etc.