-
Notifications
You must be signed in to change notification settings - Fork 1
End Points
To initiate new device, send a POST
request to http://<ip>:<port>/device
with valid JSON
data of the following structure:
{
"device_id": "<unique device id>", # e.g. "PBR-01"
"device_class": "<device class>", # e.g. "PSI"
"device_type": "<device type>", # e.g. "PBR"
"address": "<device address>" # e.g. "/dev/usb/port0"
}
All requests must provide a unique device_id
; a valid device_class
and device_type
- check complete list of supported devices or their documentation; and an address
on which DeviceControl
can find the device (usually identification of a port).
Furthermore, certain devices may require multiple additional parameters to be passed in the POST request in order for the device to initiate and function properly. Always check the documentation for the targeted device in order to prevent errors.
To initiate a certain task, send a POST
request to http://<ip>:<port>/task
with valid JSON
data of the following structure:
{
"task_id": "<unique task id>", # e.g. "PSI-PBR-01-task-measure-all-01"
"task_class": "<task class>", # e.g. "PSI"
"task_type": "<task type>" # e.g. "PBR_measure_all"
}
All requests must provide a unique task_id
and a valid task_class
and task_type
- check complete list of supported tasks or their documentation.
Furthermore, certain task may require multiple additional parameters to be passed in the POST request in order for the task to initiate and function properly. In some cases, even encapsulation of other tasks is possible. Always check the documentation for the targeted task in order to prevent errors.
In order to execute a particular command, send a POST
request to http://<ip>:<port>/command
with valid JSON
data of the following structure:
{
"device_id": "<target device id>", # e.g. "PBR-01"
"command_id": "<ID of the command as specified in the Device's interpreter>", # e.g. "3"
"arguments": "[<arguments ordered as expected by the command, separated by a comma>]", # e.g. "[30]"
"source": "<the signature of the command>", # e.g. "manual"
"await": "<wait for command result>" # e.g. True
}
The request must include the target device's device_id
and valid command_id
as specified in the device's interpreter (available in the documentation of individual devices). The arguments
field is optional in general but must be provided if the given command requires it. Otherwise, even though the command may be accepted, it will not be executed. The source
field is optional as well and if not provided, a default external
signature will be saved. The optional field await
allows to wait for the command to be executed and result is obtained in the response; otherwise, result is stored in the events (False
by default). Please note the command execution is not stored in events if await
is True
.
To retrieve data measured for a specific device, send a GET
request to http://<ip>:<port>/data?device_id=<id>&type=<type>
. It is necessary to provide valid device_id
in the request as the data are always device-related. Another argument is type
, which is either values
or events
, determining what kind of data will be retrieved from the server.
Both values and events are identified by an log-ID
. To retrieve only more recent data than a specific log-ID
, you can pass the last known log-ID
in the URL:
http://<ip>:<port>/data?device_id=<id>&type=<type>&log_id=<log-ID>
or alternatively provide last known time-stamp
of received data:
http://<ip>:<port>/data?device_id=<id>&type=<type>&time=<YYYYmmddHHMMSSfff>
Keep in mind that time-stamp
and log-ID
are mutually exclusive (cannot be combined) and make sure to use correct format YYYYmmddHHMMSSfff
for the time-stamp
.
In the case of values, the request returns a JSON
response with the following structure:
{
"<log-ID>": {
"time": datetime, # time of measurement
"value": float, # value of measured quantity
"dev_id": str, # identification of associated device
"var_id": str, # identification measured quantity
"attribute": int, # a special flag (check docs)
"note": str # additional information
},
...
}
and in the case of events it has the following structure:
{
"<log-ID>": {
"dev_id": str, # identification of associated device
"event_type": int, # identification of the event
"time": datetime, # time of occurrence
"command": int, # identification of associated command
"args": list, # arguments of the command
"response": dict, # content of the event
},
...
}
Additionally, use endpoint http://<ip>:<port>/data?device_id=<id>&type=<type>
to obtain latest log-ID
for the data type
.
The option to terminate devices and tasks is provided to the user at http://<ip>:<port>/end
- a POST
request with data of the following structure is expected:
{
"type": "<device, task or all>", # e.g. "task"
"target_id": "<id of the task or device>" # e.g. "PSI-PBR-01-task-measure-all-01"
}
To end a device, provide a string device
in the type field and a valid device ID in the target_id
field. To end a task, provide a string task
in the type field and a valid task ID in the target_id
field. Keep in mind that ending a device without ending tasks which expect this device to exist will cause these tasks to fail or the device to not be terminated properly.
TBD: this should be checked and such device cannot be terminated / all related tasks must be also terminated
To end all current devices and tasks, provide a string all
in the type
field. The target_id
field is not necessary in this case.
In order to check which devices are connected and which tasks are currently running, send a GET
request to http://<ip>:<port>/ping
. In the response, the server will provide a JSON
with the the following pattern:
{
"devices": {
"<device id>": bool
},
"tasks": {
"<task id>": bool
}
}
Each device will have a boolean value according to the result of its test_connection
method. Each task listed in the response should have a true
value, as inactive tasks are to be automatically deleted. The occurrence of a false
value indicates faulty implementation of the task and should be fixed according to the documentation or reported.