Actuations allow for the invocation of remote action on a device connected to the platform. The API operations for launching, updating and checking the status of actions are descibed here. Actions are invoked with a POST operation on the URL “SO/actuations/” in the REST API, using the body to pass parameters to the device. The result of the operation will be an actuation Id that will be used afterwards by both the device and the invoker to refer the actuation. The body, along with other meta-information, will be passed will be exposed as a JSON document under the “/{soId}/actuations/{actuationName}” (HTTP, MQTT, STOMP over TCP and STORM over WS can be used).

The following NodeJs code shows an example of how a device would subscribe to the actuations endpoint in which invocations will take place. Internal actions to take place in the device are up to the device programmer.

The SO must be declared with a set of actions on it, like for instance

When the action is invoked,  a JSON document is published on the topic “/{soId}/actuations”. Actions are delivered through MQTT MQTT, STOMP over TCP and STORM over WS, but not over HTTP. The device, which should be subscribed to this topic will receive as the payload a document describing the operation to invoke. The device will be responsible for updating the status of the operation through the URL “/{soId}/actuations/{actuationId}”, providing as the body the new status string to be stored.

The following script would update the status string for a previously invoked actuation:

The invoker can check the status of the actuation by retrieving the following URL using a GET command “/{soId}/actuations/{actuationId}”.

The following script would return the status string for a previously invoked actuation:

More information on using alternative transports is available here.