Feature request: report the RSSI of a client device for every AP on the site.

Brief

Make the Omada controller API endpoint to report the signal strength between every client device and every (reachable from the client) AP in the network.
A single record should contain the following information:
 - AP MAC
 - Client MAC
 - RSSI
 - Timestamp
A customer backend requesting this information can use it to identify approximate location of a client device.

Motivation

Given the known location of the APs on the site and the signal strength between them and a client device, it's possible to estimate the location of the client device. To do this, one can use techniques like trilateration or Wi-Fi fingerprinting. Please see a wiki article for further information on the topic [external link]

https://en. wikipedia. org/wiki/Wi-Fi_positioning_system
The near-realtime client device location information finds many uses; it can be used by shopping malls for direct advertising and detailed marketing analysis, by offices, museums, schools for providing location-based services. My personal application would be to augment room presence in a smart home: having integrated this service, a smart home app could allow device controls only within a room where the client device is located.
A few more motivation points and other marketing information can be found in this blog post [external link]

https://mapsted. com/blog/wifi-positioning-system-explained

Competition

Exactly this functionality has been implemented in Cisco Meraki [external link]

https://documentation. meraki. com/MR/Monitoring_and_Reporting/Location_Analytics 
The linked page gives an in-depth implementation details for this service.
My problem with Cisco Meraki is that it's a cloud-only system, whereas I'd like to have everything on-premises.

Feasibility

To the best of my knowledge, many TP-Link APs and the Omada controller implement the smart/fast/seamless roaming feature.
To enable this feature, I assume, APs should listen the Wi-Fi probes periodically sent by the client and report them to the controller; the controller then takes into account these reports (which should contain client's MAC addresses and RSSI) to suggest a list of nearest APs for the client to roam (IEEE 802.11k).
This makes me believe that all necessary information on the AP side is already collected and sent to the controller.
The remaining part is on the controller software side - to aggregate and deliver these reports. The Meraki documentation I shared above outlines this process as well.

Implementation

To fit the feature into the existing API, the controller needs to aggregate and keep a DB table containing at least the four fields I defined in the brief.
Then, the API endpoint could optionally take the client MAC or the timestamp/range to filter the data for a single client or a short period of time to save the network/compute bandwidth.
Alternatively, you could follow the Meraki approach; the customer backend would send a single request to subscribe for the RSSI data, and the controller would send the RSSI data back in the form of post requests as it comes from the APs. I think this approach is better at saving the network/compute bandwidth as there's guarantee the customer backend doesn't bombard the controller with too many requests.

Previous discussion

https://community.tp-link.com/en/business/forum/topic/617866