First you need to find a ZONE ID. This is in the heterarchy, you can poll the API with the following: https://MSEIPADDRESS/api/config/v1/heterarchy/Zone Then you need to use this ZONE ID in the following API to get the summary date You can also change date ranges. https://MSEIPADDRESS/api/analytics/v1/overview?areas=177&yAxis=absoluteVisits&timeRange=00%3A00-23%3A59&period=yesterday&durationCategories=5-480&includeStationary=false&connectionState=all&type=deviceCount&_=1483484600804 REPLACE 177 above with the ZONEID from the first API Results should be " value ": {" primary ": {" title ": "Total Visitors" ," value ": 20 , ... View more

     If you happen to be in an secure internal network where even outbound traffic via HTTPS requires that it move through a server, there is an option to allow this. On your CMX server, you should do the following su root     vi /etc/profile.d/cmxprof.sh     Add new line to the file:     export https_proxy= http://proxy-wsa.esl.cisco.com:80     exit     cmxctl agent restart     cmxctl connect restart ... View more

With CMX Analytics, people often ask how long the data is kept for. The answer is "it depends", but here is some more details. First, in memory we keep the ACTIVE clients list, this is the list of clients that we are actively getting data from the WLC from until the following PURGE TIME = TIME WE LAST RECEIVED MESSSAGE FROM CONTROLLER(mac) + 600 Seconds The second duration of devices that are kept is the location history table. PURGE TIME = Job run at Midnight for all MAC address > Days configured in History Pruning Interval. This is the BIG table that is purged daily. The THIRD set of purging is for REPEAT visitors.  Each MAC address is classified as a NEW or REPEAT visitor. To do that, we need to who has been here before, for that we maintain a list of MAC addresses and say where the device has been in the ZONE at a MONTHLY level For example, we would keep that MAC address aa:bb:cc:dd:ee:ff has been in the venue in July, August and Sept and then in the month of Jan, we would delete the data from July. For example, this query that show over 6534 devices, over 3384 are new and 3150 are devices which have been seen more then once. Finally, when we do have analytics data about a zone, we can keep the aggregated data for a total of up to 8 years back so you can look at year one vs year two.  CMX is not that old, but the data is still there. The only limit here is based on harddrive space. ... View more

Author: Darryl Sladden, Senior TME Manager Date:   October, 2016 Subject: CMX 10.2.x HEATMAPS Cisco CMX Analytics has the capability to create an hourly heatmap of client activity for any floor as part of the analytics capabilities. The heatmap is generated hourly and is in the format of a JPG image which is accessible via the GUI. As part of the GUI you can play the hourly generated heatmaps back to form an understanding of what has happened on the floor during the day. The heatmap is generated by a dataset of devices that have had a locations calculated during the last hour.  It is important to note the following; - With Standard location, a datapoint for location is generated when the client decides to send a PROBE packet out.  This is normally done when a client first enters a venue, and is done less frequently when a device is in a venue and is in a static location.  This would mean location such as lounges that have static devices may not have as many devices shown with standard location as would be shown with HyperLocation.  In addition, places where devices first encounter WIFI access points will be shown hotter. - A new location is usually determined when a device has moved, as such for a large number of static devices, there will not be a lot of location calculated. - With Hyperlocation, a datapoint is calculated much more frequently, approximately one time each 15 seconds.  These datapoints give a more realistic view in the heatmaps of where devices are. - The data in a heatmap and the colors are based on a logarithmic scale where the specific color will not associate to a specific number. - The primary uses cases for HEATMAP is as a comparison tool for two different events or two different days.  Given the same pattern of visitors the heat map would appear in the same way. USE CASES FOR HEATMAP GENERATED WITH STANDARD LOCATION 1) Compare different days of the weeks to see if different days have specific times or places then a benchmark day 2) Compare different events to see if the timing of the event resulted in different enterances uses or different location of devices USE CASES FOR HEATMAP GENERATED WITH HYPERLOCATION 1) Determine and compare different areas of the venue to see where CONNECTED devices are more likely to be. 2) Determine the flow of devices in and out of a venue during an event. NOTE: HyperLocation refers to the uses of Datapackets and if available Angle of Arrival for the determination of a client location.  HyperLocation can be accomplished with either a standard AP in Enhanced Local Mode where it scans for other clients, it can be accomplished with a dedicated monitor mode radio such as the RM3010 or, in the most advanced method is accomplished with a dedicated HyperLocation Antenna Array and a RM3010L module. ... View more

Author: Darryl Sladden, Senior TME Manager Date:   October, 2016 Subject: CMX 10.2.x ANALYTICS Device Counts Change from 10.2.0 to 10.2.2 REPORT AGGREGATION OF DUPLICATES Reports with the selection of multiple Zones or multiple Floors in 10.2.0 DEDUPLICATE visits.  For example, when the same device visits ZONE 1 and ZONE 2. With 10.2.0 it is counted as 1 VISIT in a report of ZONE 1 and ZONE 2. With 10.2.2 we do NOT DEDUPLICATE visits when the same device visits ZONE 1 and ZONE 2. With 10.2.2 it is counted as 2 This can result in the exact same report showing a much higher number of devices with CMX 10.2.2 vs CMX 10.2.0. This issues occurs with a CAMPUS report if you have multiple top level CAMPUS, but is not the case if you have a single top level CAMPUS for campus level reporting. If you select a report with more than one zone/floor/campus, you will have this issue. The workaround is to TAG multiple CAMPUS/BUILDINGS/FLOORS/ZONE with the same TAG and report at the TAG level. This change is NOT retroactive. HEAT MAP CHANGES In 10.2.0 there were some errors in calculating location of some devices due to heat map failure. This resulted in devices that had not been in the venue for a long time to not be counted. With 10.2.0 the total number of devices with locations calculated is lower due to this error. In 10.2.2 we have corrected and expanded the HEATMAPS (an internal construct that is used for calculating how far from an AP a client is), this results in more device having a valid location calculated. With this change you will see more devices that are seen for a short period of time if the AP are in public spaces.  You will need to filter devices that are seen for a short period of time if you want this removed from your dataset.   This should be done by setting the DWELL TIME FILTER to 30 mins With 10.2.2 device count in analytics will be higher due to this correction. This change will persist in all future releases. CHANGE IN EXIT NOTIFICATION (Does not impact counts or Dwell time) In 10.2.0 we exit devices from zones when a device is not reported from WLC after 20 mins. In 10.2.2 we exit devices from a zone when a device is not reported from WLC after 10 mins. This change will impact the DETECT and LOCATION page device counts. FILTERING OF UNREGISTERD OUI AND RANDOM MAC ADDRESSES – MAC ADDRESS VENDOR A small number of devices have unrecognized OUI and send locally administered (ie RANDOM) MAC addresses.  These should be filtered out by the location engine.  This filter remains constant in 10.2.0 and 10.2.2 and will remain the same in 10.2.3. The OUI list of valid MAC addresses is updated as part of the ongoing system updates. Please note, Apple devices, when they are not associated to WIFI do not send out a valid MAC addresses and are not included in PROBING device counts by default. SHORT DURATION DEVICES There can be a large number of short duration devices in the any CMX analytics dataset if the AP are outdoors and can hear devices that are very infrequent, such as a car driving by. The method to filter these short duration devices would be to use the DWELL TIME FILTER and set the minimum DWELL time for a report to 30 mins.  RSSI STRENGTH FILTERING The Filtering for RSSI signal strength is based on at least one AP reporting the signal at a value of which is higher than a preset value.    The default value in 10.2.0 was -128.  The default value in 10.2.2 was set to -85.  The user can configure this value to what is appropriate to the specific venues.  If the values where changed when the report was created, then you would have resulted in different values from 10.2.0 vs 10.2.2.  A recommended value for this setting in many WIFI networks is -75. PRESENCE vs LOCATION ANALYTICS In Presence the calculation of a VISITORS in a specific ZONE is based on the device being present in a ZONE for 8 minutes in the last 20 mins.  The device count widget also shows the total number of detected visitors. The visitors have to be in a zone for a specific length of time (configured) and at a specific signal strength. REPEAT VISITOR COUNTS There is an error in the repeat visitor count in CMX 10.2.2.  They show as 100% repeats in many cases.  This is fixed in 10.2.3.  There is no workaround to correct in CMX 10.2.2 ... View more

With CMX 10.2.2 and CMX 10.2.3 there will be changes / corrections in analytics numbers from previous releases.  This document helps to explain some of these changes. ... View more

This document helps to describe how CMX analytics creates heatmaps and uses cases for them. ... View more