RBCAPI
Содержание
- 1 Взаимодействие
- 2 Общие требования
- 3 Базовые запросы
Взаимодействие
Клиент (далее -- RBC (RecBot Client)) подключается к вебсокету вида
https://sys-domain.net:8092/ws
После соединения с серверным API (далее -- SRV) как RBC, так и SRV могут делать запросы в вебсокет, соответственно, противоположная сторона на них должна отвечать.
Для взаимодействия посредством простых json сообщений (кроме получения файла с данными от RBC) для тестирования достаточно использовать утилиту
wscat
Общие требования
- У RBC должна быть предусмотрена кнопка аппаратного сброса настроек
- При получении команды на старт записи RBC должен начинать запись с фронтальной камеры и переключать камеры с фронтальной на тыльную с периодичностью, заданной, в конфигурации
- RBC должен присылать и принимать конфигурацию, согласно которой должна происходить его настройка
- RBC должен отображать номер, уровень заряда аккумулятора, количество записанных видео "на борту" и статус (простой, запись, отправка данных и т.д...)
- RBC, наряду с получением команды на старт и стоп записи должен автоматически определять своё перемещение (движение) и стартавать запись автоматически, если движение было обнаружено (акселерометр и другие датчики). После остановки устройства необходимо определять полную остановку и останавливать запись.
- При остановке записи (вручную или автоматически) RBC должен автоматически инициировать отправку данных на SRV. Данные отправляются в бинарном виде в формате несжатого zip архива, внутри которого должны находиться записанные видеофайлы и один или несколько файлов метаданных о сессии записи.
- Начатая по команде старта запись (не автоматически определённый старт) не должна останавливаться до получения команды остановки записи (т.е. если запись включена по команде, то и останавливаться она должна по команде -- показатели датчиков движения не долджны участвовать в этой логике)
Базовые запросы
От SRV к RBC
Запрос статуса устройств или устройства
Запрос
{ "device-id": "*", "command": "status", "arguments": { } }
, где
device-id
-- MAC-адрес RBC, переданный без разделителей например:
5465033FFFF3
В случае указании значения
*
или в случае совпадения передаваемого MAC-адреса с MAC-адресом RBC в ответ на SRV должен придти запрос (он же ответ -- с т.з. RBC) вида:
Ответ
{ "result" : "success", "status" : { "device-id" : "5465033FFFF3", "device-alias" : "3", "battery-level" : 100, "uptime" : 17157021, "recording?" : false, "current-camera" : 1, "recordings": 9 } }
, где
device-alias
-- номер устройства (тот номер, который должен высвечиваться на дисплее устройства)
battery-level
-- процент заряда батарейки RBC
uptime
-- время в секундах с момента загрузки RBC
recording
-- флаг, показывающий: идёт ли в данный момент запись видео на устройство
current-camera
-- номер камеры, которая в данный момент записывает (0 - обе, 1 - первая камера (основная), 2 - вторая камера (дополнительная))
recordings
-- общее количество видеозаписей
Запрос на старт записи
Принцип работы параметра
device-id
аналогичен принципу, описанному в предыдущем разделе.
Запрос
{ "device-id" : "*", "command" : "start", "arguments" : {"devices": [ "front", "rear" ] } }
в массиве
arguments.devices
может быть одно или два значения, наличие которых в запросе определяет: запись с каких камер должна осуществляться.
Как минимум, должно быть указано одно устройство
Ответ
{ "result" : "success" }
Запрос на остановку записи
Принцип работы параметра
device-id
аналогичен принципу, описанному ранее.
Запрос
{ "device-id" : "*", "command" : "stop", "arguments" : {} }
Ответ
{ "result" : "success" }
Запрос на очистку данных на RBC
Принцип работы параметра
device-id
аналогичен принципу, описанному ранее.
Запрос
{ "device-id" : "*", "command" : "rm", "arguments" : { "name": "*" } }
Ответ
{ "result" : "success" }
Запрос на получение конфигурации RBC
Параметр
device-id
принимает значение MAC-адреса конкретного RBC. Например:
5465033FFFF3
Запрос
{ "device-id" : "5465033FFFF3", "command" : "conf", "arguments" : { } }
Ответ
{ "device-id" : "5465033FFFF3", "command" : "conf", "arguments" : { "conf" : { "server-address" : "192.168.1.2", "server-port" : 3000, "server-resource" : "\/ws", "server-use-tls?" : false, "device-alias" : "99", "camera-switch-timeout" : 15, "session-auto-remove?" : false, "camera-front-resolution" : "1920x1080", "camera-rear-resolution" : "1920x1080", "movement-detection-threshold" : 1.0 } } }
, где
server-address, server-port, server-resource, server-use-tls?
-- параметры настройки RBC для подключения к SRV.
По умолчанию при аппаратном сбросе RBC должны быть установлены те, что указаны в примере ответа.
device-alias
-- номер устройства (аналогичный параметр описан выше)
camera-switch-timeout
-- таймаут в секундах, после которого происходит переключение устройства на запись с другой камеры
session-auto-remove?
-- флаг: удалять ли данные после успешной отправки их с RBC на SRV
camera-front-resolution, camera-rear-resolution
-- разрешения камер, которое нужно использовать для записи видеофрагментов
movement-detection-threshold
-- коэффициент чувствительности акселерометра при детектировании старта движения
Запрос на сохранение конфигурации RBC
Запрос аналогичен запросу на получение конфигурации, за исключением того, что параметр
arguments
должен содержать не пустой объект конфигурации. Например:
{ "conf" : { "server-address" : "192.168.1.2", "server-port" : 3000, "server-resource" : "\/ws", "server-use-tls?" : false, "device-alias" : "99", "camera-switch-timeout" : 15, "session-auto-remove?" : false, "camera-front-resolution" : "1920x1080", "camera-rear-resolution" : "1920x1080", "movement-detection-threshold" : 1.0 } }
От RBC к SRV
Все ответы, описанные в предыдущем разделе, необходимо считать как запросы от RBC к SRV. Помимо них RBC ещё должен присылать ряд ответов
Отправка данных сессии видео
При отправке данных сессии от RBC к SRV архив с видеоданными (несжатый, в формате zip. Далее -- АрхивТИП1) должен быть разбит на фрагменты на бинарном уровне.
Каждый из таких фрагментов должен быть упакован в другой архив (несжатый, в формате zip. Далее -- АрхивТИП2). Этот архив помимо бинарного фрагмента данных должен содержать текстовый файл с мета-информацией о фрагменте (необходимый для восстановления большого архива из фрагментов).
Примеры архивов будут предоставлены
Содержимое фрагментов в контейнерах типа "АрхивТИП2" отсылается в вебсокет в формате
binarydata
SRV принимает данные, распаковывает, сохраняет мета информацию в базе данных и детектирует специальным вёркером наличие всех фрагментов, после чего собирает файл типа "АрхивТИП1", забирает его содержимое и инициирует задачу сборки видео.
Порядок приёма архивов типа "АрхивТИП2" не важен.