Пример подключения устройства по протоколу MQTT

Конфигурирование модели

Рассмотрим следующий кейс. Допустим, дана комната, в которой необходимо постоянно регулировать температуру. Если температура в помещении превысит 22 градуса и окно закрыто, нужно будет включить кондиционер. Если температура упадет или откроется окно, кондиционер должен выключиться.

Таким образом, даны следующие устройства:

  • кондиционер;
  • датчик открытия окна;
  • датчик температуры в комнате.

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

В нашем примере устройства общаются с платформой через контроллер. Контроллер отправляет данные по протоколу MQTT. Поэтому именно контроллер в данном случае будет являться объектом контроля с точки зрения платформы, и модель будет создана одна.

Создадим новую модель MQTT.

scheme

Она будет выглядеть следующим образом. Как видно, по умолчанию доступны два параметра: температура (Temperature) и влажность (Humidity) — и две команды: включить и выключить светодиодную лампу (Turn-on LED и Turn-off LED).

scheme

Управление кондиционером должно осуществляться на основе данных, отправляемых датчиками, которые должны собирать текущие показания о температуре в комнате и об открытом или закрытом состоянии окна.

Стоит учитывать, что для двух данных датчиков необходимо добавить аргументы с различными типами данных. Датчик температуры может сообщать различные значения температуры. Соответственно, это должен быть числовой аргумент, значение которого должно быть представлено в градусах Цельсия. Так как окно может находиться только в двух состояниях: открытом или закрытом, — то типом данных для данного аргумента является логический тип. Данные от датчика на окне могут быть либо отправлены со значением 1, если окно закрыто, и со значением 0, если оно открыто. При этом сам кондиционер умеет выполнять две команды: включение и выключение.

Итак, при конфигурации модели необходимо добавить новый аргумент для датчика на окне и дополнить некоторые сведения об аргументе Temperature (например, указать источник). Параметр Humidity, добавленный в модель по умолчанию, не пригодится, поэтому он может быть удален.

Подробнее о назначении полей смотреть раздел Модель объекта контроля.

При создании нового параметра заполняются все необходимые поля. В качестве типа выбирается аргумент. Поле «Идентификатор» можно оставить без изменений (поскольку в данном примере не предполагается использовать API).

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

Далее вводится удобное для дальнейшего просмотра в интерфейсе имя. Так как от датчика передается значение 0, если окно открыто, и 1 — если закрыто, то в качестве типа данных нужно выбрать логический тип boolean. В поле «Источник» указывается topic, по которому устройство отправляет значение параметра окна.

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

scheme

В качестве типа параметра указывается действие. Каждой команде присваиваются понятные идентификатор и имя. Задается тип действия — команда к устройству. При отправке сообщения о необходимости выполнить команду необходимо задать команду PUBLISH (Опубликовать). Сообщение будет отправлено и опубликовано по прописанному topic’у — base/air_con. При отправке по этому topic’у значения 1, заданного в payload в виде текста, контроллер включит кондиционер, так как окно будет закрыто, при получении 0 — выключит.

Создание объекта

Для данного кейса главным устройством является контроллер, который управляет работой кондиционера и считывает показания с датчиков. Поэтому нужно создать только один объект для контроллера.

Для этого необходимо перейти в меню «Объекты» и открыть диалоговое окно создания нового объекта. Из выпадающего списка выбирается модель. Затем вводится идентификатор, используемый в качестве ClientID при прошивке устройства для его подключения к платформе. Далее вводится имя объекта, при необходимости указываются его тип и статус.

scheme

После того, как были созданы модель и объект, а само устройство было настроено и сконфигурировано, его можно считать подключенным к платформе. Теперь остается убедиться, что данные от устройства действительно присылаются на платформу и отображаются в ее интерфейсе.

scheme

Проектирование сценария автоматизации

В данном кейсе ключевыми моментами являются включение и выключение кондиционера. Именно они и будут выступать в роли состояний при проектировании сценария автоматизации.

При запуске автомата объект находится в некотором «Начальном состоянии». Переход из этого состояния в состояние «Кондиционер включен» (первое включение кондиционера) должен происходить при одновременном выполнении двух условий: если температура в комнате превышает значение в 22 градуса и если окно закрыто.

Далее образуется цикл. Кондиционер может быть либо во включенном, либо в выключенном состоянии. Переход из состояния «Кондиционер включен» в состояние «Кондиционер выключен» происходит при выполнении одного из условий: либо температура падает ниже 22 градусов, либо открывается окно. Обратный переход происходит при тех же условиях, что и при переходе из «Начального состояния».

scheme

Осталось запустить спроектированный сценарий на исполнение, создав контейнер на объекте контроля.