I'm using CMX API 10.2 version A, and in the dataset obtained, not sure about several fields, could anyone give explanations to how those fields are generated? Eg: "firstLocatedTime" "Dot11Status" (PROBING, ASSOCIATED, UNKNOWN- especially the last status)
when would a record's firstLocatedTime be recorded? Will it change if the situation of the devices changed? (link to different AP, change status, change the locations..etc)
Providing the sampling intervals are at least every 5 mins, why there are macAddresses got "firstLocatedTime" few hour earlier than the first record of the same macAddress?
I haven't found any document defining the REST API output or response fields. Let me check to see if there are any presentations or tutorials online that I share. Please, check out the Cisco CMX Design and Implementation Guide, Cisco Connected Mobile Experiences (CMX) CVD - Cisco
Regarding firstLocatedTime gives the timestamp of the earliest acquired location update. Note, the History Storage Parameters can be changed to clear out old location history as a scheduled job, but will only delete lastLocatedTime, therefore you will still see old history such as firstLocatedTime as response for /api/location/v1/clients.
Dot11Status indicates connected to the network as Associated and the APMacAddress is the AP which it is connected; Probing to find a valid AP to connect and the APMacAddress is the AP which has strongest reception; and Unknown for inactive client devices and clients with unknown IP addresses. Note, that CMX aggregates information from the wireless network, and therefore refer to the values defined in the AP or WLC. These references can be found here Wireless Products, Wi-Fi Networking, and Mobility Solutions - Cisco
Thanks Matt, though I didn't find the manual or data book in the url you provided. It makes sense updating the lastLocatedTime and delete old ones. However, if the firstLocatedTime is the timestamp for earliest acquired location, would it be possible no record generated around that time but it's recorded and appeared later in the other records? As in my dataset, quite a lot devices in UNKNOWN/PROBING status was detected long time before their earliest records' generated time. Could you help me understand why this happened?
I found the following from different sources. The discussion of the history tables below doesn't exactly explain when the firstLocatedTime is updated, but we can assume that it remains in Current data until it's declared inactive for 24 hours default period. I will post a question to the CMX team mailer for an answer.
Here you go...
History tables are separate from current location tables, and archival duration for history is configurable in the History Parameters section. Pruning interval is the configurable schedule by which history tables are pruned. Current data is held in the Redis Cache. The Apache Cassandra database stores location History data. Cisco CMX 10.2 introduces the option to prune database size. The default disk-pruning task runs at an interval of 90 days.
In the typical single box Context Aware Service (CAS) deployment the Load Balancer simply forwards the received RSSI info from the NMSP messages to the Redis Cache and notifies the CAS process that new data has been received. The CAS process then computes the current location for the client from the received RSSI info.
Once the new position is calculated, it is compared to the previous calculated location for the client and if the difference is > 6 feet the previous client location is written from the Redis Cache into the History DB which is held in a Cassandra Database and the newly calculated position for the client is written to the Redis cache. If the difference is < 6 feet then only the information in the Redis cache is updated. Note, only row inserts occur on History tables, no row updates; and during Pruning, rows are deleted based on the archival configuration settings.
If the element becomes inactive for an hour, then it is declared as inactive element by the system. If the element remains inactive for 24 hours default, then it no longer tracked by CAS. It is not possible to see the location history in this case.
The history of an element is recorded only if:
It moves more than 6 ft.
If the emergency or panic button is pressed on the tags
If the tag encounters an Exciter
In case the element moves between floors
It's quite helpful to know the data is stored in the Cache then updated to the History tables, since we are using the CMX API and don't have much control in the storage process, is it fetching data from the History Database? If so, it might make sense that the firstLocatedTime be much earlier than the records' generated time, as long as the default tracking time is 24 hours, there might be 24 hours lag cause it's inactive. However, in the actual ones we got, some of the lag is longer than that, does this mean it's not the defaults? Or might caused by other issues like system adjustment? ( we might update the network during some periods). Thanks a lot for your answers again.
Hi, I posted this to one of the cmx team mailers for an answer. No reply, yet. I'll let you know what they say. Thanks, Matt
From: Matthew Farrell <email@example.com>
Date: Wednesday, August 3, 2016 at 9:54 AM
To: "cs-location(mailer list)" <firstname.lastname@example.org>
Subject: An question regarding firstLocatedTime
The discussion of the history tables does not completely explain when the firstLocatedTime is updated. I assume that it remains in current redis cache data until it’s declared inactive for the 24 hours default period and location data is no longer available. Please, advise.
I haven't found a good definition of use of firstLocatedTime. On the DevNet sandbox CMX 10.2 we have 67 wireless clients reporting firstLocatedTime within the last day or two, and four firstLocatedTime at "1970-01-01T01:00:00.000+0100". This may be a good time to experiment with inactive wireless clients to determine when the firstLocatedTime timestamp gets set, e.g., remove a wireless client device by disabling or shielding for >24 hour period.
Thanks for the advice, we might have some tests if permitted, when I got the results I would post the findings here. Is it possible the system is generating records based on the caching and the real time? Which might explain part of the strange records we got.
Hi, The firstLocatedTime probably updated by inactivity, and lastLocatedTime is pruned. So, it's possible for an element to never go inactive for >24 hours, therefore firstLocatedTime is old. and over period of weeks earlier location history gets pruned keeping the last 30-90 days. Let us know what you find out. Thanks, Matt
I got a reply, but wasn't what I expected. They say inactive for an hour will reset the firstLocatedTime. We need to verify this before using with certainty.
2nd Try - when is the firstLocatedTime is updated?
Reply from the cs-location mailer:
currentServerTime = Time of the CMX server in the local timezone that is configured on the server when this packet was written
firstLocatedTime = When device first was added to the ACTIVE MAC table
For this MAC address and this session of this MAC address, when was this device first located. First means a device was created for the first time ever (i.e. We have a memory structure, when was this MAC first added, or a device that could have been seen previously, but is not in active table now (for example due to timeout). So device here for 1 hour, then gone for 1 hour then back. You would have a firstLocatedTime different in the two records.
lastLocatedTime = Last time we have a location update for this device