DNA Spaces Clients History REST API - Question

[a.veneziano]

Hi,

In Cisco Spaces Location API, there is a GET operation for retrieve information about clients history (/v1/history),I need some clarification about data that are retrieved by this method, in particular:

1) I saw that more records are identical with same data, for example:
tenantid,macaddress,devicetype,campusid,buildingid,floorid,floorhierarchy,coordinatex,coordinatey,sourcetimestamp,manufacturer,associated,ssid,username,associatedapmac,computetype,source,hierarchy_id

XXXX,XX:XX:XX:XX:dd,CLIENT,8685ebd5-5b61-4a12-8b64-d582e980368e,f5eb76a9-ecc3-49df-8949-1f37bcdee2bc,181d2380-7eab-4359-9fa7-95f9dd0d3983,XXXX,215.4,345.2,1730761205170,Unknown,true,XXXX,84842f814abb66fc31d5e5b6bc092a923a4b3bb2,90:e9:5e:e4:41:60,RSSI,Compute,abe2b01a-f581-4398-995b-1dea72ad5633

XXXX,XX:XX:XX:XX:dd,CLIENT,8685ebd5-5b61-4a12-8b64-d582e980368e,f5eb76a9-ecc3-49df-8949-1f37bcdee2bc,181d2380-7eab-4359-9fa7-95f9dd0d3983,XXXX,215.4,345.2,1730761205170,Unknown,true,XXXX,84842f814abb66fc31d5e5b6bc092a923a4b3bb2,90:e9:5e:e4:41:60,RSSI,Compute,abe2b01a-f581-4398-995b-1dea72ad5633

XXXX,XX:XX:XX:XX:dd,CLIENT,8685ebd5-5b61-4a12-8b64-d582e980368e,f5eb76a9-ecc3-49df-8949-1f37bcdee2bc,181d2380-7eab-4359-9fa7-95f9dd0d3983,XXXX,215.4,345.2,1730761205170,Unknown,true,XXXX,84842f814abb66fc31d5e5b6bc092a923a4b3bb2,90:e9:5e:e4:41:60,RSSI,Compute,abe2b01a-f581-4398-995b-1dea72ad5633

It is correct? Does it have a special meaning?

2) Each record contains coordinatex and coordinatey fields, Do this fields are relative position on floor maps or are they related to accesspoint position?

Please if you can provide some help about the them it would be highly appreciated.

[ammahend]

Based on what I am reading here is the breakdown

1. XXXX: Placeholder for tenant ID or organization-specific identifier. Typically, this is masked for security or privacy reasons.
2. XX:XX:XX:XX:dd: MAC address of the client device (e.g., laptop, smartphone).
3. CLIENT: Denotes the type of entity (in this case, a client device).
4. 8685ebd5-5b61-4a12-8b64-d582e980368e: Unique identifier for the event or session associated with the client.
5. f5eb76a9-ecc3-49df-8949-1f37bcdee2bc: Unique identifier for the access point (AP) the client is connected to or near.
6. 181d2380-7eab-4359-9fa7-95f9dd0d3983: Unique identifier for the building or floor where the client is located.
7. XXXX: Placeholder, possibly for additional contextual or organizational data.
8. 215.4: X-coordinate of the client's location on the floor plan map.
9. 345.2: Y-coordinate of the client's location on the floor plan map.
10. 1730761205170: Timestamp of the event in epoch milliseconds (convertible to human-readable date and time).
11. Unknown: Status or additional property of the client, such as location type or unknown classification.
12. true: Boolean value, often indicating whether the client is active or connected.
13. XXXX: Another placeholder, possibly for reserved fields or additional metadata.
14. 84842f814abb66fc31d5e5b6bc092a923a4b3bb2: Token or hashed identifier for the client session or organization.
15. 90:e9:5e:e4:41:60: MAC address of the access point interacting with the client.
16. RSSI: Received Signal Strength Indicator, representing the signal strength of the connection between the client and the AP.
17. Compute: Method or algorithm used to calculate the client's location.
18. abe2b01a-f581-4398-995b-1dea72ad5633: Identifier for the specific calculation instance or additional metadata associated with the computation.

for the other question, client coordinates in Cisco DNA Spaces are mapped to the actual physical locations within the building's floor plan

[Torbjørn]

1) Might be a result of an implementation issue, do you get the same records if you query for that specific deviceid and associatedapmac in a single API call?

2) These are relative position on floor maps. 

[a.veneziano]

Hi Torbjørn,

Yes, Might be a result of an implementation issue.

I need to retrieve clients history data in a time range, for example each day.

I notice that If I use a time interval of a day I retrieve less data then I use the same time range splitting requests by hours.

Have you found any strange behaviour with pagination?

Thanks in advance

[Torbjørn]

Sounds likely that the API isn't returning the objects in a consistent order which can cause issues like this. You can work around this by adding the retrieved records to a set and verifying that you have retrieved all records by comparing the length of the set with the expected count of records.

[ciscoritz]

Is there a way to stream these data points like when client disassocates (back in 8540s) enhanced Snmptraps gave great data but 9800s they dont offer those type of disassocated with bytes/ssid/apname/ thus pulling from API in a minute/minute chunk with API pagination doesnt seem the best route when you have 1000s of clients online.