The WiFi Motion Core Cloud APIs facilitate the creation, configuration, and management of WiFi Motion networks via RESTful APIs. Additionally, it offers interfaces for accessing topologies, events, and motion data. This documentation outlines the endpoints for engaging with the WiFi Motion cloud and includes specifications for the following APIs:
The live motion API opens a web socket and triggers the network to emit recorded motion at a 500ms interval.
High-level APIs for retrieving the network's topology, last status message, or to view or modify the network's metadata.
The location data APIs expose localized motion data. Localization happens on a per mac, or custom location name base.
A set of APIs to find a network in the WiFi Motion Cloud. Individual, or groups of networks can be queried by their primary identifiers or by MAC.
APIs of the internal Home Insights Microservice. Used for motion-based activity and sleep insights.
Fine-grained network configuration. These APIs give full access to the underlying motion detection controls, but have no safeguards to prevent unwanted side effects. For friendlier configuration management, see the Network Settings APIs.
Interface to manage the access point or mesh nodes of a network. Provides APIs to find, delete or alter the configuration of nodes.
Endpoint used by WiFi Motion agent for the initial cloud connection. This API returns credentials for connecting to the MQTT broker and stores the initial network configuration. We don't recommend using this API directly.
Execute commands directly on the network's access point, or on a mesh node. We recommend using the NOC Management Page for these actions.
https://docs.cognitivesystems.com/_mock/assets/specs/mns/v3-x-x/
https://docs.cognitivesystems.com/_mock/assets/specs/mns/v3-x-x/manage/batch
curl -i -X POST \
https://docs.cognitivesystems.com/_mock/assets/specs/mns/v3-x-x/manage/batch{ "batch_id": 0 }
If not null, the execution of this action will be delayed until this trigger action has completed successfully (status=2xx).
If the trigger action fails (status=4xx), this action will fail with the same status.
000 - Pending start
001 - Waiting for action with trigger_id
002 - Waiting for device to come online
01x - Command was attempted "x" times
100 - Device acknowledged, action started
1xx - command_id specific progress codes
200 - Completed (Success)
4xx - Completed (Failed)
Optional batch group identifier for this action. If null then websocket-based monitoring of this action will not be possible.
https://docs.cognitivesystems.com/_mock/assets/specs/mns/v3-x-x/manage/create
curl -i -X POST \
'https://docs.cognitivesystems.com/_mock/assets/specs/mns/v3-x-x/manage/create?createBatch=false' \
-H 'Content-Type: application/json' \
-d '{
"network_id": 0,
"created_at": 0,
"updated_at": 0,
"trigger_id": 0,
"payload": {
"property1": "string",
"property2": "string"
},
"state": 0,
"node_id": 0,
"batch_id": 0,
"response": {
"property1": "string",
"property2": "string"
},
"id": 0,
"command_id": 0
}'OK.
If not null, the execution of this action will be delayed until this trigger action has completed successfully (status=2xx).
If the trigger action fails (status=4xx), this action will fail with the same status.
000 - Pending start
001 - Waiting for action with trigger_id
002 - Waiting for device to come online
01x - Command was attempted "x" times
100 - Device acknowledged, action started
1xx - command_id specific progress codes
200 - Completed (Success)
4xx - Completed (Failed)
Optional batch group identifier for this action. If null then websocket-based monitoring of this action will not be possible.
{ "network_id": 0, "created_at": 0, "updated_at": 0, "trigger_id": 0, "payload": { "property1": "string", "property2": "string" }, "state": 0, "node_id": 0, "batch_id": 0, "response": { "property1": "string", "property2": "string" }, "id": 0, "command_id": 0 }
https://docs.cognitivesystems.com/_mock/assets/specs/mns/v3-x-x/manage/monitor
curl -i -X GET \
'https://docs.cognitivesystems.com/_mock/assets/specs/mns/v3-x-x/manage/monitor?id=0'