The Core APIs facilitate the creation, configuration, and management of WiFi Motion networks via RESTful APIs. It offers interfaces for accessing topologies, events, motion data, and more.
Cognitive Systems App Core API
A wireless client refers to any device that connects to a network using WiFi technology. For optimal performance with WiFi Sensing, stationary devices such as voice assistants (like Amazon Echo or Google Nest), smart plugs, smart displays, and powered wireless speakers are ideal choices. Wireless clients that are mobile can move around and generally have aggressive sleep modes, less reliable Channel State Information (CSI) data, and are not able to be used to help identify localization, all of which can impact the WiFi Motion performance.
Guardian is the name of the application that runs on a device, such as an Access Point, WiFi Extender, or IoT device, within a WiFi Network. It's primary functions are to store configuration settings, communicate with WiFi devices within a network, and communicate with the WiFi Motion infrastructure.
- Mock serverhttps://docs.cognitivesystems.com/_mock/assets/specs/api/core/network/{network_id}/events/history
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X GET \
'https://docs.cognitivesystems.com/_mock/assets/specs/api/core/network/{network_id}/events/history?from=0&to=0&filter=string&last=10&sort=false&event_types=string' \
-H 'Authorization: YOUR_API_KEY_HERE'200 - OK
The loc field provides the most consistent method for identifying the source of a motion event. This field is reliably populated with the unique identifier (e.g., MAC address) of the device associated with the motion. Due to its stable format, the loc field is the preferred method for identifying the reported origin of motion, as opposed to fields that rely on variable display names. The values within the link_id field are split, and then added to the loc values.
The friendly name of the link that created the event. This will also be the same identifier that is seen at the beginning of the link_id field.
The Network ID is a unique identifier that is assigned to a WiFi Motion network when it is created. The Network ID is used by applications such as AppCloud, Device Manager, and via APIs, to uniquely identify a network.
Present in MotionStoppedEvent. References the UTC timestamp of preceding MotionDetectedEvent.
Array of float, of length guardian_config.motion_events.density_window -1 (Nominally len 7). Corresponds to the motion intensity values in the integration buffer at the time of the DetectedEvent.
The link_id field is used to describe the two devices that are involved in detecting motion. The link_id is in the format of link_dst_name.link_src_name.
The loc_name is intended to provide a description of the device that is listed in the loc field. The value populated in this field will depend upon the several factors. Examples of types of data that can be populated include the friendly name of the device, the name of the node, and the node location.
The friendly name of the link that received the event. This will also be the same identifier that is seen at the end of the link_id field.
Motion detection parameters from event generator. Used for debug and sensitivity calibration purposes. Present in MotionStoppedEvent on newer firmware.
Feedback of armed from GuardianConfig.motion_events
If 0, this event will not be stored in history or pushed to the user.
Event identifier
[ { "_id": "string", "category": "Link", "loc": [ … ], "detail": { … }, "link_dst_name": "string", "network_id": 0, "ts": 0.1, "evt_detected_ts": 0.1, "intensity_window": [ … ], "link_id": "string", "loc_name": "string", "tag": "string", "link_src_name": "string", "guardian_id": "string", "shard_id": "string", "node_id": 0, "deviceId": "string", "node_name": "string", "debug": { … }, "armed": 0, "event": "MotionDetectedEvent", "_consumer": "string", "data": { … } } ]
Request
Creates a new event, which must have all fields in the event schema populated. Note that the tag attribute will be ignored if provided. Tags can be applied after the event has been created.
The Network ID is a unique identifier that is assigned to a WiFi Motion network when it is created. The Network ID is used by applications such as AppCloud, Device Manager, and via APIs, to uniquely identify a network.
Event category (for filtering)
Event identifier
- Mock serverhttps://docs.cognitivesystems.com/_mock/assets/specs/api/core/network/{network_id}/events/create
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X POST \
'https://docs.cognitivesystems.com/_mock/assets/specs/api/core/network/{network_id}/events/create' \
-H 'Authorization: YOUR_API_KEY_HERE' \
-H 'Content-Type: application/json' \
-d '{
"ts": 0.1,
"guardian_id": "string",
"network_id": 0,
"category": "Link",
"event": "MotionDetectedEvent",
"deviceId": "string"
}'- Mock serverhttps://docs.cognitivesystems.com/_mock/assets/specs/api/core/network/{network_id}/events/tag
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X POST \
'https://docs.cognitivesystems.com/_mock/assets/specs/api/core/network/{network_id}/events/tag?eventid=string&tag=string' \
-H 'Authorization: YOUR_API_KEY_HERE'Event stored OK
The loc field provides the most consistent method for identifying the source of a motion event. This field is reliably populated with the unique identifier (e.g., MAC address) of the device associated with the motion. Due to its stable format, the loc field is the preferred method for identifying the reported origin of motion, as opposed to fields that rely on variable display names. The values within the link_id field are split, and then added to the loc values.
The friendly name of the link that created the event. This will also be the same identifier that is seen at the beginning of the link_id field.
The Network ID is a unique identifier that is assigned to a WiFi Motion network when it is created. The Network ID is used by applications such as AppCloud, Device Manager, and via APIs, to uniquely identify a network.
Present in MotionStoppedEvent. References the UTC timestamp of preceding MotionDetectedEvent.
Array of float, of length guardian_config.motion_events.density_window -1 (Nominally len 7). Corresponds to the motion intensity values in the integration buffer at the time of the DetectedEvent.
The link_id field is used to describe the two devices that are involved in detecting motion. The link_id is in the format of link_dst_name.link_src_name.
The loc_name is intended to provide a description of the device that is listed in the loc field. The value populated in this field will depend upon the several factors. Examples of types of data that can be populated include the friendly name of the device, the name of the node, and the node location.
The friendly name of the link that received the event. This will also be the same identifier that is seen at the end of the link_id field.
Motion detection parameters from event generator. Used for debug and sensitivity calibration purposes. Present in MotionStoppedEvent on newer firmware.
Feedback of armed from GuardianConfig.motion_events
If 0, this event will not be stored in history or pushed to the user.
Event identifier
{ "_id": "string", "category": "Link", "loc": [ null ], "detail": { "property1": "string", "property2": "string" }, "link_dst_name": "string", "network_id": 0, "ts": 0.1, "evt_detected_ts": 0.1, "intensity_window": [ 0.1 ], "link_id": "string", "loc_name": "string", "tag": "string", "link_src_name": "string", "guardian_id": "string", "shard_id": "string", "node_id": 0, "deviceId": "string", "node_name": "string", "debug": { "linkSens": {}, "msad": [ … ], "links": [ … ], "mconf": [ … ], "sens": 1 }, "armed": 0, "event": "MotionDetectedEvent", "_consumer": "string", "data": { "title": "string", "uuid": "string", "id": 0, "first_name": "string", "last_name": "string", "sub": "string", "user": { … } } }
A webhook is an automated message sent from one app to another when a specific event occurs, like a payment or a code commit. It works by sending an HTTP request containing data (a "payload") to a unique URL provided by the receiving application. This allows for real-time data sharing and communication between applications without constant polling.