Hi @Clive_A ,

Thanks for the quick reply!

I have some means of presence detection, but I figure the Wi-Fi signal analysis is still very useful for deciding which services should be available to a phone based on its location. The only reasonable alternative is bluetooth trackers; also not perfect since this means more harware to install and maintain (and an extra step for a user).

Would it be reasonable to make a feature request to add this functionality to the api? This forum gives me an impression that the Omada is an actively developed software with very responsive developers and a friendly community :) I have yet almost a year to decide on the WiFi devices before the house is ready for moving-in, so I can wait a bit.

Without any knowledge of the software, I'd guess a few points speaking for such a feature:

  - Hopefully, it's inexpensive to implement:

      * the controller seems to have an intelligent roaming logic; so the RSSI is probably already logged.

      * On the API side this could be as simple as adding a single key-value-pair (AP MAC, RSSI) list to the client details query response.

  - It could be interesting to business customers, such as offices/malls etc, to provide location-based services or ads.

[Sorry the form does not allow me to save external links]

Sure! One example is the location analytics by Cisco Meraki  documentation dot meraki dot com/MR/Monitoring_and_Reporting/Location_Analytics (the page by the link pretty much outlines the implementation plan). It seems to also be doable at the AP level using Mikrotik RouterOS or the OpenWRT CLI (which would require much more work on my/customer side). On the marketing side, check out the Mapsted blog post from a few months ago (mapsted dot com/blog/wifi-positioning-system-explained), which explains the motivation much better than me.

I don't want to peek the implementation details from you, but I'd assume your APs already send the logs of client Wi-Fi probes with the RSSI to the network controller in one way or another to allow smart roaming. Hence I think in the most basic form this can be implemented solely on the controller side (perhaps by saving a bit more information in its database).

For my purposes it's fine if the RSSI data is slightly outdated (if, let say, the controller would send timestamps attached to every AP+RSSI pair). Sending the data for all visible client devices at once could help to reduce the frequency of requests to the controller.

Hi @Clive_A thanks for delving into the issue!

Honestly, I don't see how it's not enabling the smart action/scene. The quote you posted says directly that it can provide this data in real-time for data warehousing, analytic platforms and enables customer engagement initiatives.

In fact, their picture in the introduction documentation. meraki. com/@api/deki/files/8413/Screen_Shot_2015-07-09_at_4.15.26_PM.png shows exactly what I'd like to get, if you relpace the drawing of a cloud with the Omada controller in it.

All the bits and pieces are there. On the one hand, I, as a private customer, have a particular implementation plan on how to turn the probe/RSSI data into device-room presence detection and use it in my apps. On the other hand, your team can build new features for the enterprise based upon this data; the features that are seemingly being developed by your competitors. In fact, I believe, the smart home application has an untapped market potential as well - this could turn into a collaboration with smart home solution provides, such as e.g. Loxone.

Thanks, @Clive_A , yes, this is the picture I meant in the previous post.

Just to make sure we're on the same page:

  1. Note, on the left side of the picture, probing and associated client devices send packets to the AP's. The key requirement here (may be not immediately clear from the picture) is that all APs, which receive the probe, send this information to the Controller and down to the device (not just the AP in which the client is currently associated/registered).

  2. In the picture, the controller sends the information proactively, which is very nice for me as a customer backend. But I think this is not absolutely necessary; it would be ok if the data for a short-period of time is aggregated on the controller side and is sent by request.

Thanks, @Clive_A, looking forward to hear from them!

A small note: "probing" is what clients do independently of the AP/network controller. The AP's merely listen to client probes and report to the controller. They likely do this already, because this information is needed for the controller, so that it can implement "smart roaming" (IEEE 802.11k): send the list of suggested nearest APs back to the client for migration between APs.