Приветствую вас, Хабровчане!
В 2020-м году все мы знаем что такое Интернет Вещей и для чего он нужен. Но как много из нас знакомы с облачными платформами, которые представляют один из наиболее значимых пластов в IoT? Давайте разбираться.
Не секрет, что разношерстность протоколов существенно усложняет процессы подключения умных устройств, их конфигурирования и обработки данных. Подобные проблемы решаются благодаря облачным платформам Интернета Вещей. Сегодня на примере одной из российских платформ Интернета вещей я покажу, как легко подключить устройства с разными протоколами, а также использовать полученную информацию для построения процессов автоматизации.
В платформе, которую я обычно использую для своих задач, уже реализовано взаимодействие с устройствами, работающими по таким протоколам как MQTT, Wialon Combine, Wialon IPS, Galileosky, Modbus и некоторым другим.
Помимо использования представленных протоколов, для устройств, которые не имеют выхода в Интернет, есть возможность написания программных агентов – некоторых посредников между оборудованием и платформой, которые устанавливаются на другом устройстве (например, Raspberry Pi) и соединяются с этим оборудованием.
Допустим, вам требуется обеспечить взаимодействие с устройством, работающим по одному из представленных протоколов. В таком случае будет достаточно совершить три шага:
Разберем несколько кейсов и посмотрим, как же всё это подключается.
Начну с того, что однажды наша команда всерьез задумалась о том, чтобы автоматизировать рабочие процессы в офисе.
Так, в соответствии с Agile концепцией, в полдень рабочего дня все сотрудники собираются на Daily meeting. Уведомление в Slack о предстоящем собрании в процессе работы легко пропустить да и отвлекаться на часы не очень удобно… Так родилась идея создать Agile-gong – систему автоматизированного звукового оповещения.
Как реализовано? Железо – это NodeMCU (миниатюрный аналог Arduino со встроенным Wi-Fi-модулем), сервопривод и конденсатор. Каждый будний день в 12 часов нужно обеспечить поворот выходного вала сервопривода с ударным оборудованием на конце на угол, достаточный для того, чтобы гонг прозвенел и уведомил всех о подъеме.
Схема подключения железа довольно простая:
Код, зашитый на NodeMCU, обеспечивает:
На стороне платформы разработана модель устройства. В ней описываются параметры, которые можно получать от устройства, и команды, которые можно на него отправлять. В интерпретации MQTT-команды – это сообщения для клиента с определенным топиком и данными, в нашем случае в данных находится необходимый угол поворота.
Затем был создан объект с идентификатором, по которому происходит авторизация на платформе. После подключения отображение выглядит следующим образом:
В командах есть вариант отправки команды поворота на угол 0 и 90 градусов.
Теперь необходимо добавить сценарии автоматизации. Создадим автомат, который при наступлении нужного времени будет переходить в состояние поворота на 90 градусов, затем в цикле на конфигурируемое количество повторов совершит необходимое количество ударов и вернется в исходное состояние ожидания 12 часов.
Каждый сценарий автоматизации – это некая блок-схема, задающая логику поведения объекта. Прописав подобный сценарий, можно учитывать все изменения, которые происходят с устройством, и на основании того, какие именно изменения произошли, устройство сможет выполнять соответствующие действия автоматически, без отправки команды пользователем.
Полученный автомат можно использовать не только для конкретно одного устройства.
Например, можно сделать точно такую же систему с гонгом и установить ее еще в одном кабинете вашего офиса. Тогда у вас будет одна и та же модель, два разных объекта и один автомат, запущенный на двух объектах.
Вторым полезным решением для нас оказалось подключение датчика углекислого газа. Также подключили по MQTT. Опять же, схема сборки железа тривиальная.
Да, кстати, реализацией как первого, так и второго кейса мы занимались в рамках хакатона внутри компании. И никто из нас в работу железа не погружался, да и необходимости в этом не возникало.
Дальше порядок действий такой же. Модель включает параметр ppm (1000 ppm = 0,1% содержания СО2), который передает устройство, но оно не слишком наглядное, поэтому тут же в модели выведен еще один параметр — процент содержания CO2. Он рассчитывается как значение ppm, деленное на 10000.
Здесь вы также можете заметить две команды на включение лампочки. Ее решили использовать для индикации. А управляем мы ей, конечно, из автомата платформы. После подключения устройства отображение параметров следующее. Эти значения принимаются и отображаются в режиме реального времени, но также можно посмотреть прошлые накопленные пакеты в истории или отобразить график изменения параметра за определенный период.
Автомат для этого объекта работает следующим образом. В верхнем состоянии происходит выключение лампочки. В нижнем — запуск таймера на минуту и включение лампочки. Переход из первого состояния во второе происходит по событию получения данных от устройства с выполнением условия, что значение ppm больше 600 единиц. Возврат (переход из второго состояния в первое) происходит по срабатыванию таймера.
У вас может возникнуть два вопроса.
На самом деле, польза от автомата есть даже в таком простом кейсе. Этот датчик с лампочкой на время отладки я положила у себя на столе, и каждый раз, когда приходила на работу, лампочка загоралась, так как значение порога в автомате было довольно низкое. Какое-то время я пробовала разные значения в автомате и в итоге пришла к оптимальному значению в 600 единиц. Для подбора нужного значения мне нужно было просто поменять значение в автомате и сохранить его. Никакой перепрошивки устройства. А если это устройство мы перенесем в кабинет, где нужно поддерживать лучшее состояние воздуха и необходимо частое проветривание, то значение можно опять же просто поменять. Быстро и удобно.
Здесь поставлен таймер на минуту. Это необходимо, чтобы в течение минуты мы находились в состоянии высокого уровня CO2 и не реагировали на то, что какое-то время продолжает приходить высокое значение. Иначе, мы бы постоянно мигали лампочкой, совершая переходы до тех пор, пока состояние воздуха не нормализуется. Вы уже могли догадаться, что сделать переход в начальное состояние можно и по-другому. Также по событию получения данных, но в которых выполняется противоположное условие — ppm<600. Тогда мы будем находиться во втором состоянии ровно до тех пор, пока не придет нормальное значение.
Наиболее сложным примером будет описание работы с системой контроля и управления доступом, которая представляет собой электронный модуль, предназначенный для управления доступом в помещения, учета времени прохода и событий.
Контроллер обрабатывает информацию, поступающую со считывателя, имеющего выходной интерфейс «Wiegand» и с помощью встроенного реле осуществляет коммутацию исполнительного устройства — электромагнитного замка. У него нет выхода в Интернет и видимой возможности подключения к платформе. Однако у него есть свой протокол обмена данными с компьютером управления, благодаря которому можно отправлять на контроллер команды, такие как считать из контроллера, записать в контроллер, открыть/закрыть замок и другие. Поэтому в данном случае был организован нестандартный подход — использование агента, о котором я упоминала в начале статьи.
Работа по протоколу контроллера была реализована в коде С++ и запущена на исполнение на Raspberry Pi, которая в свою очередь была соединена с контроллером по RS-485 через преобразователь интерфейса. Основная задача программы — осуществить подключение к платформе, сериализировать команды и десериализовать данные, полученные с контроллера. Таким образом, мы смогли с помощью небольшой программной прослойки сделать устройство “умным”.
Модель устройства выглядит следующим образом:
Основная информация с контроллера — это события. На платформу она приходит в формате JSON и включает поля:
Для разбора JSON-полей по разным параметрам также используется модель.
В интерфейсе объекта это выглядит следующим образом:
А так выглядит интерфейс для отправки команд:
Можно заметить, что есть команда не только на чтение буфера событий, но и на запись новых границ. В памяти контроллера хранятся границы буфера — начало и конец. Когда на устройство приходит команда чтения, считываются эти границы и в этих пределах происходит чтение из буфера событий. Граница конца буфера сдвигается автоматически на контроллере при получении новых событий. А вот начальную границу буфера нужно перезаписать (указав конечную границу после прошедшего чтения), чтобы не прочитать одни и те же данные повторно. Но это необходимо сделать только после того, как данные о событиях были успешно отправлены на платформу. Зафиксировать получение данных и затем отправить команду на перезапись границ также удобно в автомате.
Данный проект нашел свое продолжение в интеграции с нашей внутренней CRM системой, в которой на вкладке информации о сотрудниках всегда видны актуальные сведения о том, кто находится или отсутствует в офисе. Также отображается время входа/выхода из офиса, считается суммарное количество часов в месяц.
Забор данных из платформы производится по RESTful API. API платформы предоставляет возможность работы, взаимодействия и использования сущностей платформы и их данных в таких внешних системах, как веб-порталы, мобильные и веб-приложения или, как в нашем случае, — CRM системах.
Также возникают случаи, когда в компанию пришел гость/доставщик еды или кто-то еще, кому нужно открыть дверь. Чтобы не пользоваться своей картой и тем самым не передать некорректные показания о своем статусе, можно воспользоваться кнопкой “Unlock” на платформе. А если человека нужно встретить у двери, то удобно сделать то же самое из мобильного приложения.
Моя личная история с огородом в квартире началась на фоне сумасшедшей паники людей и скупки продуктов. В очередной раз пойдя в магазин и увидев пустые полки там, где должна быть картошка, я решила использовать последнюю найденную картошку в холодильнике не совсем по прямому назначению. Эту картошку я посадила в огромный горшок. С такого наивного эксперимента начался мой огород на подоконнике, который спустя два месяца уже выглядит так:
Так как я не весть какой цветовод, а огороду воды нужно еще больше, чем цветам, довольно быстро я столкнулась с проблемой, что забываю его поливать. Про автоматические системы полива я рассказывать не буду, это слишком заезженная тема, а организовать ее работу качественно довольно сложно. Вместо этого у меня появились следующие идеи:
Интерфейс будет выглядеть следующим образом:
Автомат для первого случая выглядит следующим образом. Переход в состояние, в котором высылается уведомление, сделан по сложному условию — у одного из растений влажность ниже нормы. Связка между условиями — ИЛИ.
Возврат в исходное состояние происходит по условию — у всех растений влажность почвы выше нормы, связка И.
Автомат для второго случая выглядит следующим образом. Переход осуществляется по планировщику, возврат в исходное состояние — безусловный переход.
И наконец, автомат для последнего случая:
Эти автоматы запущены на одном объекте и работают параллельно.
Пожалуй, это все, что я хотела осветить в своей статье. Основная идея, которую мне хотелось донести, — это то, что работа с платформой Интернета вещей невероятно облегчает создание бизнес-процессов любой сложности, потому что в этом случае нужно изучить всего один интерфейс — интерфейс платформы, который позволяет избежать глубокого погружения в работу железа и его программирования.
В 2020-м году все мы знаем что такое Интернет Вещей и для чего он нужен. Но как много из нас знакомы с облачными платформами, которые представляют один из наиболее значимых пластов в IoT? Давайте разбираться.
Не секрет, что разношерстность протоколов существенно усложняет процессы подключения умных устройств, их конфигурирования и обработки данных. Подобные проблемы решаются благодаря облачным платформам Интернета Вещей. Сегодня на примере одной из российских платформ Интернета вещей я покажу, как легко подключить устройства с разными протоколами, а также использовать полученную информацию для построения процессов автоматизации.
В платформе, которую я обычно использую для своих задач, уже реализовано взаимодействие с устройствами, работающими по таким протоколам как MQTT, Wialon Combine, Wialon IPS, Galileosky, Modbus и некоторым другим.
Помимо использования представленных протоколов, для устройств, которые не имеют выхода в Интернет, есть возможность написания программных агентов – некоторых посредников между оборудованием и платформой, которые устанавливаются на другом устройстве (например, Raspberry Pi) и соединяются с этим оборудованием.
Допустим, вам требуется обеспечить взаимодействие с устройством, работающим по одному из представленных протоколов. В таком случае будет достаточно совершить три шага:
- сконфигурировать модель с желаемыми параметрами и командами;
- создать объект с уникальным идентификатором в платформе;
- сконфигурировать устройство для подключения к платформе.
Разберем несколько кейсов и посмотрим, как же всё это подключается.
Кейс №1 Agile-gong
Начну с того, что однажды наша команда всерьез задумалась о том, чтобы автоматизировать рабочие процессы в офисе.
Так, в соответствии с Agile концепцией, в полдень рабочего дня все сотрудники собираются на Daily meeting. Уведомление в Slack о предстоящем собрании в процессе работы легко пропустить да и отвлекаться на часы не очень удобно… Так родилась идея создать Agile-gong – систему автоматизированного звукового оповещения.
Как реализовано? Железо – это NodeMCU (миниатюрный аналог Arduino со встроенным Wi-Fi-модулем), сервопривод и конденсатор. Каждый будний день в 12 часов нужно обеспечить поворот выходного вала сервопривода с ударным оборудованием на конце на угол, достаточный для того, чтобы гонг прозвенел и уведомил всех о подъеме.
Схема подключения железа довольно простая:
Код, зашитый на NodeMCU, обеспечивает:
- установку Wi-Fi соединения и подключения к платформе по протоколу MQTT;
- установку начального положения сервопривода в 0 градусов;
- публикацию сообщений с данными о текущем положении;
- подписку на команды и поворот сервопривода на угол по команде.
#include "Arduino.h"
#include "EspMQTTClient.h" /* https://github.com/plapointe6/EspMQTTClient */
// Servo library
#include <Servo.h>
// Object Servo with name myservo
Servo myservo;
int pos;
EspMQTTClient client(
"<wifi-ssid>",
"<wifi-password>",
"<MQTT Broker server ip>",
"<ric-mqtt-client-id>"
);
void setup() {
Serial.begin(9600);
move(0);
}
void onConnectionEstablished() {
Serial.println("connected");
client.subscribe("move", [] (const String& payload) {
int angle = payload.toInt();
if (angle != pos) {
move(angle);
}
client.publish("position", payload);
});
}
void loop() {
client.loop();
}
void move(const int angle)
{
myservo.attach(5);
myservo.write(angle);
delay(800);
myservo.detach();
pos = angle;
}
На стороне платформы разработана модель устройства. В ней описываются параметры, которые можно получать от устройства, и команды, которые можно на него отправлять. В интерпретации MQTT-команды – это сообщения для клиента с определенным топиком и данными, в нашем случае в данных находится необходимый угол поворота.
Затем был создан объект с идентификатором, по которому происходит авторизация на платформе. После подключения отображение выглядит следующим образом:
В командах есть вариант отправки команды поворота на угол 0 и 90 градусов.
Теперь необходимо добавить сценарии автоматизации. Создадим автомат, который при наступлении нужного времени будет переходить в состояние поворота на 90 градусов, затем в цикле на конфигурируемое количество повторов совершит необходимое количество ударов и вернется в исходное состояние ожидания 12 часов.
Каждый сценарий автоматизации – это некая блок-схема, задающая логику поведения объекта. Прописав подобный сценарий, можно учитывать все изменения, которые происходят с устройством, и на основании того, какие именно изменения произошли, устройство сможет выполнять соответствующие действия автоматически, без отправки команды пользователем.
Полученный автомат можно использовать не только для конкретно одного устройства.
Например, можно сделать точно такую же систему с гонгом и установить ее еще в одном кабинете вашего офиса. Тогда у вас будет одна и та же модель, два разных объекта и один автомат, запущенный на двух объектах.
Кейс №2 Датчик углекислого газа
Вторым полезным решением для нас оказалось подключение датчика углекислого газа. Также подключили по MQTT. Опять же, схема сборки железа тривиальная.
Да, кстати, реализацией как первого, так и второго кейса мы занимались в рамках хакатона внутри компании. И никто из нас в работу железа не погружался, да и необходимости в этом не возникало.
Дальше порядок действий такой же. Модель включает параметр ppm (1000 ppm = 0,1% содержания СО2), который передает устройство, но оно не слишком наглядное, поэтому тут же в модели выведен еще один параметр — процент содержания CO2. Он рассчитывается как значение ppm, деленное на 10000.
Здесь вы также можете заметить две команды на включение лампочки. Ее решили использовать для индикации. А управляем мы ей, конечно, из автомата платформы. После подключения устройства отображение параметров следующее. Эти значения принимаются и отображаются в режиме реального времени, но также можно посмотреть прошлые накопленные пакеты в истории или отобразить график изменения параметра за определенный период.
Автомат для этого объекта работает следующим образом. В верхнем состоянии происходит выключение лампочки. В нижнем — запуск таймера на минуту и включение лампочки. Переход из первого состояния во второе происходит по событию получения данных от устройства с выполнением условия, что значение ppm больше 600 единиц. Возврат (переход из второго состояния в первое) происходит по срабатыванию таймера.
У вас может возникнуть два вопроса.
- А зачем автомат? Не проще ли на самой железке прописать такие условия? Ведь тут все так просто.
- Зачем тут таймер?
На самом деле, польза от автомата есть даже в таком простом кейсе. Этот датчик с лампочкой на время отладки я положила у себя на столе, и каждый раз, когда приходила на работу, лампочка загоралась, так как значение порога в автомате было довольно низкое. Какое-то время я пробовала разные значения в автомате и в итоге пришла к оптимальному значению в 600 единиц. Для подбора нужного значения мне нужно было просто поменять значение в автомате и сохранить его. Никакой перепрошивки устройства. А если это устройство мы перенесем в кабинет, где нужно поддерживать лучшее состояние воздуха и необходимо частое проветривание, то значение можно опять же просто поменять. Быстро и удобно.
Здесь поставлен таймер на минуту. Это необходимо, чтобы в течение минуты мы находились в состоянии высокого уровня CO2 и не реагировали на то, что какое-то время продолжает приходить высокое значение. Иначе, мы бы постоянно мигали лампочкой, совершая переходы до тех пор, пока состояние воздуха не нормализуется. Вы уже могли догадаться, что сделать переход в начальное состояние можно и по-другому. Также по событию получения данных, но в которых выполняется противоположное условие — ppm<600. Тогда мы будем находиться во втором состоянии ровно до тех пор, пока не придет нормальное значение.
Кейс №3 СКУД
Наиболее сложным примером будет описание работы с системой контроля и управления доступом, которая представляет собой электронный модуль, предназначенный для управления доступом в помещения, учета времени прохода и событий.
Контроллер обрабатывает информацию, поступающую со считывателя, имеющего выходной интерфейс «Wiegand» и с помощью встроенного реле осуществляет коммутацию исполнительного устройства — электромагнитного замка. У него нет выхода в Интернет и видимой возможности подключения к платформе. Однако у него есть свой протокол обмена данными с компьютером управления, благодаря которому можно отправлять на контроллер команды, такие как считать из контроллера, записать в контроллер, открыть/закрыть замок и другие. Поэтому в данном случае был организован нестандартный подход — использование агента, о котором я упоминала в начале статьи.
Работа по протоколу контроллера была реализована в коде С++ и запущена на исполнение на Raspberry Pi, которая в свою очередь была соединена с контроллером по RS-485 через преобразователь интерфейса. Основная задача программы — осуществить подключение к платформе, сериализировать команды и десериализовать данные, полученные с контроллера. Таким образом, мы смогли с помощью небольшой программной прослойки сделать устройство “умным”.
Модель устройства выглядит следующим образом:
Основная информация с контроллера — это события. На платформу она приходит в формате JSON и включает поля:
- время события,
- код события,
- номер карты сотрудника.
Для разбора JSON-полей по разным параметрам также используется модель.
В интерфейсе объекта это выглядит следующим образом:
А так выглядит интерфейс для отправки команд:
Можно заметить, что есть команда не только на чтение буфера событий, но и на запись новых границ. В памяти контроллера хранятся границы буфера — начало и конец. Когда на устройство приходит команда чтения, считываются эти границы и в этих пределах происходит чтение из буфера событий. Граница конца буфера сдвигается автоматически на контроллере при получении новых событий. А вот начальную границу буфера нужно перезаписать (указав конечную границу после прошедшего чтения), чтобы не прочитать одни и те же данные повторно. Но это необходимо сделать только после того, как данные о событиях были успешно отправлены на платформу. Зафиксировать получение данных и затем отправить команду на перезапись границ также удобно в автомате.
Данный проект нашел свое продолжение в интеграции с нашей внутренней CRM системой, в которой на вкладке информации о сотрудниках всегда видны актуальные сведения о том, кто находится или отсутствует в офисе. Также отображается время входа/выхода из офиса, считается суммарное количество часов в месяц.
Забор данных из платформы производится по RESTful API. API платформы предоставляет возможность работы, взаимодействия и использования сущностей платформы и их данных в таких внешних системах, как веб-порталы, мобильные и веб-приложения или, как в нашем случае, — CRM системах.
Также возникают случаи, когда в компанию пришел гость/доставщик еды или кто-то еще, кому нужно открыть дверь. Чтобы не пользоваться своей картой и тем самым не передать некорректные показания о своем статусе, можно воспользоваться кнопкой “Unlock” на платформе. А если человека нужно встретить у двери, то удобно сделать то же самое из мобильного приложения.
Кейс №4 Умный огород
Моя личная история с огородом в квартире началась на фоне сумасшедшей паники людей и скупки продуктов. В очередной раз пойдя в магазин и увидев пустые полки там, где должна быть картошка, я решила использовать последнюю найденную картошку в холодильнике не совсем по прямому назначению. Эту картошку я посадила в огромный горшок. С такого наивного эксперимента начался мой огород на подоконнике, который спустя два месяца уже выглядит так:
Так как я не весть какой цветовод, а огороду воды нужно еще больше, чем цветам, довольно быстро я столкнулась с проблемой, что забываю его поливать. Про автоматические системы полива я рассказывать не буду, это слишком заезженная тема, а организовать ее работу качественно довольно сложно. Вместо этого у меня появились следующие идеи:
- Сделать пуш-уведомление в платформе о том, что влажность почвы у какого-то растения ниже нормы и пора организовать массовый полив каждому по потребностям. Потребности легко понять, установив в каждый горшочек по одному датчику влажности почвы.
- Сделать аналогичное уведомление о том, что все горшки пора повернуть, так как растения имеют особенность расти по направлению концу, а Солнце только с одной стороны — в окне. То, что я долгое время не поворачивала картошку, привело к тому, что она завалилась на один бок. К тому же она такая огромная, что теперь ее остается только стенкой подпирать.
- Организовать включение и выключение ультрафиолетовой лампы в темное время суток по планировщику – включать в 18:00, а выключать в 6:00. Сразу хочу заметить, темное время суток — понятие растяжимое в зависимости от времени года. Но мы уже знаем, что для того, чтобы изменить время включения/выключения лампы, достаточно поменять значение в автомате и сохранить его.
Интерфейс будет выглядеть следующим образом:
Автомат для первого случая выглядит следующим образом. Переход в состояние, в котором высылается уведомление, сделан по сложному условию — у одного из растений влажность ниже нормы. Связка между условиями — ИЛИ.
Возврат в исходное состояние происходит по условию — у всех растений влажность почвы выше нормы, связка И.
Автомат для второго случая выглядит следующим образом. Переход осуществляется по планировщику, возврат в исходное состояние — безусловный переход.
И наконец, автомат для последнего случая:
Эти автоматы запущены на одном объекте и работают параллельно.
Пожалуй, это все, что я хотела осветить в своей статье. Основная идея, которую мне хотелось донести, — это то, что работа с платформой Интернета вещей невероятно облегчает создание бизнес-процессов любой сложности, потому что в этом случае нужно изучить всего один интерфейс — интерфейс платформы, который позволяет избежать глубокого погружения в работу железа и его программирования.
