Логика работы коннектора

Предполагаем, что коннектор зарегистрирован в платформе и имеет идентификатор: <connector_id>.

На устройстве, на котором будет работать конфигуратор, создаём конфигурационный файл вида:
```
{
    id: "<connector_id>",
    url: "mqtts://<peresvet_server>"
    ssl: {
        certFile: "<path_to_certificate_file>", # путь к файлу сертификата
        keyFile: "<path_to_key_file>", # путь к файлу с приватным ключом
        caFile: "<path_to_ca_file>", # путь к файлу сертификата удостоверяющего центра
        certsRequired: "CERT_NONE" # CERTS_NONE | CERTS_OPTIONAL | CERTS_REQUIRED
    }
}
```
где:
- id - идентификатор коннектора в платформе.
- url - строка коннекта к платформе. В случае, если протокол mqtts, то необходим раздел конфигурации ssl.
- ssl - параметры безопасности для работы по протоколу SSL.
Примечание

Файл конфигурации содержит необходимый минимум информации для связи коннектора с платформой.

Полную информацию для работы коннектор получает от платформы.

Этим достигается централизация управления системой: настроить работу коннектора можно, исправив его конфигурацию в платформе. Внесённые изменения будут применены коннектором в режиме онлайн.
Запускаем коннектор в работу:
```
$ python <connector>.py <path_to_config_file>
```
В случае, если в строке запуска не указан путь к файлу конфигурации, то по умолчанию принимается, что файл конфигурации называется config.json и находится в текущем каталоге.
Коннектор читает сохранённую на диске конфигурацию, полученную от платформы при предыдущем сеансе запуска и начинает работать согласно этой конфигурации.

Если это первый запуск коннектора до этого связи с платформой не было, этот шаг пропускается.
Коннектор запускает на исполнение четыре независимых задачи, которые исполняются как бесконечные циклы:
Основной цикл работы коннектора также бесконечен: коннектор пытается установить связь с платформой. Каждый раз, когда связь устанавливается, коннектор посылает в платформу запрос на получение полной конфигурации.

Если полученная конфигурация отличается от старой, то задача чтения данных из источника останавливается, и запускается по-новой, в соответствии с новой конфигурацией.

Описание задач

Обработка сообщений от платформы

Коннектор может принимать от платформы сообщения, связанные с изменением его конфигурации:

изменение параметров подключения к источнику данных,
изменения в конфигурации журнала логов,
изменения списка привязанных тегов,
изменения параметров привязанных тегов.

Чтение данных из источника

Это единственный метод, который необходимо полностью определять в каждой реализации коннектора. Метод чтения данных должен помещать прочитанные данные в очередь данных. Вся обработка данных будет проводиться базовым классом коннектора в зависимости от указанных в конфигурации параметров.

Отправка данных в платформу

При наличии в очереди данных сообщений коннектор обрабатывает каждое сообщение.

Каждое сообщение - это массив данных тега(-ов).

Если у значения нет метки времени, коннектор добавит текущую метку времени.

Каждое значение тега:

Конвертируется с помощью JSONata.
Преобразуется к нужному типу данных, хранимых в теге.
Если разница между последним посланным в платформу значением и текущим больше указанного в параметре maxDev предела, то значение будет отправлено в платформу, если связь с платформой разорвана, то значение будет помещено в буфер.

Обработка буфера данных

Коннектор периодически проверяет наличие буфера данных. Если буфер есть и есть связь с платформой, то данные из буфера отсылаются в платформу.