Как написать программу для умного дома

Программное обеспечение для умного дома

Всем добрый день. В качестве хобби написал программу, которую можно использовать как часть системы “умный дом”. Чтобы сразу заинтересовать читателя, продемонстрирую некоторую малую часть сценариев использования ПО:

Вкратце:

1. Основная часть ПО — сервер, который крутится на ОС Windows, написан на C#;
2. Клиент на ОС Android, написан на Java;
3. Планируются клиенты на UWP и IOS, web-клиент.

Некоторые особенности ПО:

1. Конструктор сценариев. Создание сложных сценариев с циклами и условиями;
2. Работа с устройствами ZWave и Modbus;
3. Вложенность сценариев. Можно один сценарий использовать в другом в качестве процедуры;
4. Запуск удаленного сценария. В сценарии текущего сервера можно запускать сценарий удаленного;
5. Возможность добавлять в систему свою функциональность посредством создания модулей;
6. Запуск сценариев с помощью смартфона.

Конструктор сценариев

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

Одиночное действие

— это сценарий, который содержит только одно действие. В нем нет возможности создавать циклы и условия, а можно лишь “замапить” определенное действие на кнопку в UI клиента.

В качестве примера приведу свой способ их использования: создал категорию “Розетки”, в ней собрал все лампы, бытовой вентилятор, светильники, телевизор и компьютер. Теперь, чтобы включить одно из этих устройств, следует открыть клиент на андроиде, зайти в категорию “Розетки” и выбрать соответствующий пункт меню.

Обычно, одиночные действия использовать неудобно, так как различные устройства удобно запускать при каком-то условии или хотя бы не по одному. Именно для этого нужен “сложный сценарий”, о чем далее.

Конструктор сложного сценария

позволяет создавать сценарии с циклами и условиями. Имеет два режима: просмотр и редактирование.

ЕСЛИ и ИНАЧЕ в конструкторе. В данных конструкциях можно создавать цепочки условий с логическими операторами НЕ, ИЛИ, И. Конструктор позволяет создавать группу условий и использовать операторы непосредственно с группой. Если условие остается пустым, то оно автоматом вычисляется как ложь.

Есть некоторое количество встроенных проверок (такие как проверка на дату, время и т.д.), а также некоторое количество в качестве подключаемых модулей.

Цикл ПОКА в конструкторе. Цикл состоит из условия и тела. Условие создается аналогично тому, как он создается в конструкции ЕСЛИ (группы условий, операторы НЕ, ИЛИ, И).

Тела ЕСЛИ, ИНАЧЕ и ПОКА нужно чем-то заполнять. Собственно, это содержимое и есть самое важное в сценарии.

Основное окно конструктора сценариев

Также можно настроить следующие параметры сценариев:

— Запуск извне (вкл/выкл), позволяет запретить или разрешить запуск сценария с другой машины или из клиента;
— Автоматический запуск сценария при старте системы;
— Выбор категории сценария, позволяет отображать в UI клиента пункт меню для запуска сценария в определенной категории.

Работа с устройствами ZWave и Modbus

На данный момент система поддерживает устройства ZWave (на основе openzwave) и Modbus RTU (на основе nmodbus).

ZWave

— это беспроводной протокол связи, использующийся в домашней автоматизации. Для реализации протокола используются миниатюрные маломощные радиочастотные модули. Сейчас на рынке ZWave представлен довольно обширный перечень устройств, таких как ZWave лампочки, розетки, релейные модули, переключатели, замки, датчики температуры (влажности, движения, протечки), терморегуляторы, устройства управления кондиционером и т.д. Также распространены мультисенсоры — устройства, сочетающие несколько датчиков (например, датчик освещенности, присутствия, температуры, дверной датчик и т.д.), что весьма привлекательно с точки зрения финансовых затрат и расположения в помещении.

В моей программе модуль ZWave позволяет производить все стандартные операции с устройствами, такие как удаление, добавление устройств, сброс контроллера. Также можно использовать несколько ZWave контроллеров, конечный пользователь не увидит разницы. К примеру, можно осуществить снятие показаний температуры с датчика, который соединён с контроллером «А», и запустить кондиционер с помощью контроллера «Б». Тут нет ни каких ограничений, любое действие и проверка осуществляются стандартными способами и добавляются в конструкторе сценариев.

	Рынок ZWave устройств достаточно широк. Имеется множество исполнительных устройств, таких как релейные модули, лампочки, устройства для работы с кондиционером, терморегуляторы, регуляторы теплого пола, розетки, переключатели. Так же существует множество датчиков: датчик открытия двери, температуры, датчик протечки, датчик присутствия и т.д. В качестве контроллера ZWave можно использовать USB stick.
	Основное окно ZWave модуля
	Окно выбора контроллера и операций с ним
	Выбор узла (датчики, переключатели и т.д.)
	Выбор параметра узла (включен/выключен, различные числовые параметры, такие как температура, влажность и т.д.)

Modbus

— это проводной протокол, применяемый для связи между электронными устройствами, которые его поддерживают. В контексте нашей программы может быть полезен для работы с релейными модулями, для чего я его и использую у себя дома.

Вложенность сценариев

Вложенность сценариев используется для декомпозиции сценариев умного дома. Часто бывают такие ситуации, когда одно действие участвует во многих сценариях (например, отключение всех бытовых устройств может происходить по нажатию на пункт меню в программе, по сценарию выхода всех wi-fi устройств из сети, просто по таймеру), и поэтому каждый раз создавать (или править) одинаковый алгоритм в каждом из сценариев не представляется удобным. Для этого существует такое встроенное действие, которое позволяет запускать уже созданный сценарий в текущем. Также это может быть удобно, когда часто добавляются новые бытовые устройства (или другие частые изменения в алгоритме работы “умного дома”), для изменения работы всех сценариев достаточно будет изменить лишь один сценарий, который используется в них.

Запуск удаленных сценариев

Посредством запуска удаленных сценариев можно запускать сценарий одного сервера в сценарии другого. В качестве примера хочу привести мой вариант использования этого функционала: создал сценарий (на домашнем сервере) под названием “свет+мультимедиа”, который включает свет в помещении, запускает мой десктоп (используя WakeOnLan), включает тв, к которому подключен десктоп и ждет пока на нем (десктопе) запустится экземпляр нашей программы, затем запускает на ней сценарии “включить музыку” и “звук на 20 единиц” с помощью запуска удаленных сценариев.

Написание собственных модулей

Помимо того, что пользователь может создавать сложные сценарии штатными средствами, программа позволяет “расширять” ее пользовательскими модулями на C#. Все элементы действий и проверок в сценариях (такие как “Проверка по дате”, “Показать сообщение”, “Действие Modbus”, “Действие ZWave” и т.п.) это классы, унаследованные от ICustomAction и ICustomChecker. Следуя определенным правилам, любой пользователь может создать свой модуль, который может быть как очень простым (например, озвучивание текущей температуры воздуха за окном), так и сложным, за которым может крыться целый фреймворк. Достаточно наследоваться от интерфейсов ICustomAction или ICustomChecker, расставить несколько атрибутов, скомпилировать DLL и добавить в программу через вкладку “МОДУЛИ” (полная инструкция создания модулей).

Вкладка «МОДУЛИ»

Запуск сценариев с помощью смартфона

*пока только OS Android

Сценарии отображаются на главном экране и в категориях. Категория является виртуальной “папкой”. При запуске сценария обновляется статус соответствующей кнопки.

Помимо этого, есть возможность запускать сценарии из меню быстрого запуска на PC.

Меню быстрого запуска

В дальнейшем планируется клиент для UWP, IOS, web, а так же голосовой модуль для управления устройствами (планы на ближайшее будущее) и создания сценариев с помощью голоса (стратегические планы).

Видео напоследок:

» Страничка программы
» Ссылка для скачивания
» Инструкция для пользования
» Инструкция для создания собственных модулей

P.S.: Если нашли ошибку в программе, то пожалуйста, перешлите её на почту.

Всем привет!

Решил написать про свой опыт построения «умного дома». Тема конечно достаточно избита и статей последнее время про нее много. Но это же и хорошо – значит люди занимаются, делают. Недавно, например, вышел совершенно могучий материал (очень большой труд): Умный Дом. Большое пособие по организации умного дома и автоматизаций в Homekit.

Сразу оговорюсь, что мой кейс достаточно специфический, цели и задачи всей затеи тоже не вполне классические (спойлер: изучить Kotlin и React для работы), поэтому эта статья – для разработчиков, гиков и просто увлеченных людей. Всё что вы увидите под катом я позиционирую как дополнение к материалу «Мой умный дом на ESP8266» (автор: khusamov).

Вместо эпиграфа

Совсем недавно я прочитал заметку писателя Леонида Каганова про проблематику умного дома – очень понравилось (не настолько круто, конечно, как его же рассказ «За что я ненавижу Линукс»), но все равно очень хорошо, рекомендую. Позволю себе процитировать:

Проблема УД — никчемность. Объем задач, которые электроника может решить, — это около 1% всех домашних дел, связанных с ведением хозяйства, пищей, уборкой и повседневными операциями. Электроника не сварит борщ, не сбегает в магазин, не протрет пыль с книжных корешков, не сметет крошки со стола, не почистит за вас зубы и не помоет голову, не вынесет мусор, не выгрузит и не развесит белье, не погладит рубашку, не уберет г#%$о за котом.

Электроника сможет включить свет на кухне. Но как раз это не проблема сделать самостоятельно. Среди этого 1% задач нет качественных — тех, которые дают принципиально новое качество жизни. В основном УД предлагает решения количественные: снизить количество секунд, затраченных для включения света — с пяти секунд (при традиционном путешествии к выключателю) до 11 секунд (поиск смартфона и запуск специального приложения в нем).

Для кого этот материал

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

Иными словами, если у вас есть страх перед железяками, но вы нормально общаетесь с компьютером, софтом и программированием – вам сюда. Ну и как предупреждение – делайте скидку там, где «электронные» рассуждения будут наивными.

Что такое «умный дом» (imho)

Само название себя достаточно дискредитировало, поэтому я сам склоняюсь к термину «автоматизированный дом». В моем случае я сделал пока только включалку лампочек и розеток.

Цели и задачи

Настало время сформулировать цели и задачи:

1. Развиваться всегда хочется разносторонне, для этого вполне подойдет реализация какого-нибудь очередного pet-проекта;

2. Давно присматриваюсь к «умным домам», потому что это интересно, это «железяки + программы»;

3. Также хочется провести время с пользой и поэтому ключевое – изучить некоторые новые языки программирования и фреймворки. Забегая вперед скажу, что в части софта речь пойдет про Kotlin/Spring и React.

Остановимся на третьем пункте, ключевом для меня. Большое количество статей и поделок основано на том, чтобы взять какое-нибудь ПО и «сконфигурировать его должным образом». Чаще всего, как мне кажется, берут Domoticz, Home Assistant (не ставил ни то ни другое), но перечень постоянно растет.

Почему этой дорогой идти не хотелось: вероятно, получилось бы «стройнее» и «грамотнее», но приобретенные знания заключались бы в том, что я научился хорошо конфигурировать специализированное ПО. А цель ставилась другая. В моем случае изучение языков программирования помогает в текущих и будущих проектах, позволяет лучше понимать коллег из фронтэнда и бэкэнда. В общем, одни сплошные плюсы.

Начало

Итак, приступим. Решено было делать все на знаменитой микросхеме 8266. Плюсы:

1. Очень популярна;

2. Куча документации, информации;

3. Работает по Wi-Fi, а провода (слаботочка) у меня не проложены;

4. Может быть точкой доступа и веб-сервером;

5. Некий опыт работы с «ардуиной» уже имеется, поэтому как минимум – не с нуля.

Принципы умного дома

Сформулируем основные принципы, это важно:

1. Все должно функционировать в локальной сети дома;

2. Должен быть доступ из интернета. А когда нет интернета, см. п.1;

3. Должно работать с мобильных устройств и из браузеров;

4. Никакие сторонние серверы для управления устройствами быть не должны (только те, что из п.1);

5. Также прикрутить это все к Алисе, раз уж она есть;

6. Пульт управления должен находиться внутри самой квартиры.

Выбор оборудования

Можно было строить все на голых платах и реле – их доступно масса (Алиэкспресс, родной), но, посмотрев, выбор пал на устройства Sonoff. Что мы тут имеем:

Заказываем на Али устройства: Sonoff 4Ch Pro, Sonoff Basic, Sonoff S26. Первая – штуковина на четыре устройства. Не знаю, нужно ли было брать Pro, но что взял то взял. Есть смысл брать подобные, так как подключить можно четыре канала, а соединение по Wi-Fi одно – бережем сеть. Вот он, красавец, смонтирован даже в корпус и на дин-рейку.

Для пульта управления купил на Авито планшет Amazon Fire по совсем уж скромным деньгам (оно и понятно – пользоваться им в 2021 году вряд ли кто уже будет, но для пульта управления подойдет). Видимо даже чуть ли не одной из первых версий, с андроидом аж второй версии, причем сильно кастомизированной.

После танцев с бубном удалось поднять версию до обычной 5-ки, этого хватит для запуска браузера. Планшет хоть и дубовый, но качество сборки у Амазона все-таки выше, чем у китайского ноунейма. Он был прикручен к стене в коридоре

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

Как прошивать

Не буду подробно останавливаться, в статьях выше есть. Ключевое – покупается платка (конвертор интерфейса USB в TTL UART). Я покупал на Авито, можно на Али (но не хотелось ждать), можно скорее всего в «чип и дипе».

Магии почти никакой нет, куча информации есть на 4pda (важно во всей этой мелкой электронике никогда не путать 3.3V и 5V – иногда на платах даже есть переключатели). Одной стороной плата смотрит в USB компьютера, другой припаивается к Sonoff (важно не перепутать контакты Rx и Tx, но если и перепутаете, то греха не будет – просто прошивка не пойдет, ничего не сломается).

Прошивка инициируется определенными действиями – либо надо кнопку нажать, либо определенный контакт замкнуть (зависит от устройства – смотреть в профильной теме на 4pda). Все сработает, хоть и не с первого раза.

После прошивки устройство поднимает собственную Wi-Fi сеть. Нужно подключиться к ней и прописать устройство в сеть роутера, тогда оно станет полноценным членом этой сети.

О прошивках

Интереснее выглядит ESP-Easy, она такая, более техническая что ли. Но у меня была проблема – пробовал прошить бэйсики одной из версий, в итоге все время отключалась сеть (видимо была проблема в конкретной версии). Тогда я поставил на эти устройства «Тасмоту», с ней проблем не было (хотя, 4ch очень успешно работает на ESP-Easy).

Минимально все сделано, можно монтировать. Все устройства доступны по HTTP, включать/выключать можно простым GET запросом из браузера. Но это ведь не то, что мы хотели?

Нужно написать софт, который всем этим будет управлять. Софт должен где-то располагаться, т.е. ему нужен сервер. В качестве сервера подойдет любой более-менее приличный одноплатник (jvm все-таки ресурсоемкая штука).

Под это дело я купил Orange Pi 4B (попутно на нем еще несколько других штук крутится), плата достаточно хорошая, сравнительно недешевая – производительность на хорошем уровне. Из минусов – греется как утюг, но вроде это ее не портит, иначе не работала бы. На всякий случай просверлил две дырки и поставил ей вентилятор (стало шумновато).

Пишем софт

Концепция приложения

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

Основные понятия:

1. Конфигурация. Идея следующая – чтобы можно было вести в одной программе несколько конфигураций. Допустим дома одна картина мира, а на приусадебном участке – другая. Пока не пригодилось, но оставим задел на будущее;

2. Пользователи. Да, все пользователи у нас авторизованные, по паролю. И один служебный – для работы Алисы.

3. Локация. Группирующий элемент, ближайший аналог – комната;

4. Устройство. Собственно, само устройство. Здесь, как раз, записываются конкретные команды на включение / выключение / получения статуса.

5. По мелочи и не совсем по теме. Решил также вести перечень полезных ссылок – всего, что дом умеет отдавать себя через браузер.

Самое время придумать приложению название – пусть у нас будет «Умное гнездо», т.е. Clever nest.

Рассказ про Kotlin

Настало время чуть более подробно остановиться на приложениях. Серверную часть писать будем на Kotlin. Почему он? Java я уже более менее знаю, а Kotlin у нас на работе набирает популярность, т.е. есть смысл к нему присмотреться. Тем более в Андроиде он сейчас уже язык по умолчанию, а еще он сейчас шагает и в сторону Native, JS и iOS. Как оказалось – не зря. Изначально его воспринимаешь как некий синтаксический сахар «над явой» (прощай lombok!), но потом начинаешь уже думать на нем.

Синтаксис интересный, в чем-то даже напоминает старый добрый паскаль – ощутимо проще и лаконичнее явы. Главная киллер-фича, вокруг которой носятся котлинисты – это, так называемая, null safety. Хотя я считаю, что программист все-таки должен уметь обрабатывать нуллы и не бояться их, в целом – это действительно очень удобно.

Есть много статей, в которых преимущества Kotlin описаны более подробно, например недавно попалась на глаза из свежих – в целом там все более-менее нормально описано.

Также мы будем использовать Spring (Spring Boot 2), так как этот фреймворк тоже максимально популярен, мы его также используем.

Что будет делать приложение?

Оно будет принимать входящие запросы (GET, POST) и отдавать в ответ данные в формате JSON. Визуальной части у приложения не будет, хотя одна страничка все-таки есть:

Целью статьи не ставится детальное описание процесса написания софта (больше хочется показать всю картину в целом), поэтому остановлюсь тезисно:

1. Разработка велась в IntellijIDEA. Лучшая IDE на мой взгляд, вполне хватило бесплатной версии;

2. Из базового шаблона был выбран Kotlin + Spring Boot + Gradle. Шаблон приложения можно построить инициализатором: https://start.spring.io/;

3. В качестве БД была взята легковесная Java БД: H2 database (https://www.h2database.com/html/main.html). Не знаю почему, просто было интересно попробовать. В целом – никаких нареканий, все нормально. Хотя, как-то развивается она вяло и в следующий раз я взял бы HSQLDB или SQLite;

Какие удалось применить и опробовать фишки, которые ранее не пробовал:

• Самодокументирование методов и отдача REST-эндпоинтов в качестве Swagger интерфейса. Отлично и для описаний, и для тестирования, не требует почти ничего дополнительного. Всегда сейчас буду пользоваться (на скриншоте ссылка /swagger-ui/ как раз об этом). Выглядит вот так:

Вляпался в одну неприятность – самая последняя версия Spring Boot не захотела работать со сваггером (вернее он с ней), но “предпоследняя» вполне работает – если будете брать проект и обновлять версии библиотек – вы предупреждены (сейчас уже могло все измениться).

• Мониторинг java-melody. Тоже в целом приятная штука со всякими графиками и т.д., которая много чего показывает. Особо не нужно в таком мелком проекте, но для интереса – прикрутил. Умеет даже SQL запросы выводить и время их выполнения;

• Аутентификация в сервисе с помощью Spring security, JWT-токенов с хранением пользователей в таблице БД. Использовалась библиотека «Java JWT: JSON Web Token for Java and Android». Так как интерфейса для ввода пользователей нет (вводятся напрямую в БД), а пароли в БД хранятся в виде закодированных хэшей – сделана сервисная ссылка: password encryption;

• Опробованы также действия по расписанию через Spring аннотацию @Scheduled (пригодилось для периодического опроса устройств)

• Приложение установлено в систему в виде systemd сервиса, при перезагрузке устройства (плановой и аварийной) автозапускается;

• Исходники доступны на github.

Минусы и планы. Весь ввод данных сейчас идет напрямую в базу данных (я использую DBeaver). По хорошему, надо под это дело сделать интерфейс. Но, конечно, в целом не критично.

Рассказ про React

Настало время написать клиентское приложение.  С этим всем у меня куда как хуже. То есть на базовом уровне о Javascript я представление имею. Когда-то использовал jQuery и это очень классная библиотека.

Почему React? Тут тоже все просто – у нас много пишут на нем (хотя пишут и на ангуляре и на vue, но на реакте больше). Это знание также показалось полезным, хотя можно было тут поэкспериментировать с тем же котлином (он сейчас умеет в Javascript). Ну ладно, пойдем путем мэйнстрима – итак все вокруг незнакомое – будем разбираться.

Для начала yужно установить node.js. В качестве среды разработки я взял VSCode, и потом немного пожалел. Он конечно классный, на нем много чего можно, но почему-то он у меня под убунтой (периодически) достаточно крепко зависал – и я так и не разобрался почему (может плагины были тому виной). IDEA же заявляет поддержку JS только в Ultimate версии. Но в нее можно поставить бесплатное расширение, которое подсветит синтаксис JS. И этого, в целом, тоже хватило.

Честно говоря, впечатление от современной фронтовой разработки у меня остались неоднозначные. React – это некий «псевдо-js» (jsx), который компилируется уже в js и запускается в браузере (но этот js уже принимает технический вид, т.е. становится нечитаемым).

Приложение на реакте далось уже сложнее, видимо фронтэнд – не моя сильная сторона. Много гуглил, пробовал, двигался на ощупь. Тем не менее – приложение получилось (простенькое конечно), успехи следующие:

• Удалось разобраться в базовых вещах;

• Также получилось разобраться в жизненном цикле компонента, передаче параметров между компонентами;

• Авторизация, куки, токены;

• Удалось прикрутить всё это к первому приложению;

• Исходники доступны на github.

Правда мне не удалось досконально разобраться с CSS, но видимо оставлю на следующий заход. Но в целом – все работает, причем прекрасно ведет себя как на большом мониторе, так и на смартфонах. В качестве компонента взял material-ui, выглядит достаточно лаконично:

Как всё работает технически

React-приложение ставится тоже на тот же сервер (Orange PI4B), но на другой порт — под управлением Nginx. Когда вы на него заходите в браузере, оно запускается у вас на устройстве и переговаривается с приложением на бэкэнде. Таким образом между сервером и устройством на котором приложение отображается должна быть связь. Эта связь есть по умолчанию, если все устройства находятся в домашней сети.

Но мы же хотим через интернет? Поэтому пару слов о роутере и настройке портов.

Про роутер Mikrotik

Для того, чтобы попасть «домой» из интернета нам нужно знать домашний ip-адрес и настроить перенаправление портов. Так как провайдер в общем случае не гарантирует постоянство этого адреса, это может быть проблемой. Чаще всего она решается двумя способами:

1. Фиксацией IP-адреса у провайдера. Обычно это стоит дополнительной ежемесячной оплаты;

2. Регистрация на каком либо Dynamic DNS сервисе, который может выдать (и обновлять) вам символьное имя, гарантируя его постоянство.

К счастью, у меня есть роутер Mikrotik (про эти роутеры очень много материалов – это могучие устройства, поэтому в статье я буквально вскользь упомяну), второй вариант у нас есть «из коробки». В разделе «IP Cloud» мы можем включить «DDNS Enabled» и получить адрес вида: цифрыибуквы.sn.mynetname.net.

Запускаем все вместе, проверяем

Все запустилось, работает, устройства щелкают, мигают.

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

Алиса, Домовенок Кузя и другие сказочные персонажи

Так как в доме живет Алиса, интересно было все это прикрутить к ней. Велосипед у нас самосборный, поэтому задача не выглядит простой

Для Алисы есть так называемые навыки, это что-то вроде расширений. Навык регистрируется, настраивается. Запускается он просто голосом – «Алиса, запусти навык Х». 

Изучив каталог навыков стало понятно, что нам нужен Домовенок Кузя. Для настройки он имеет свой веб-интерфейс (https://alexstar.ru/).

У него тоже есть своя парадигма, начинается настройка с правил. Приведу пример описания правила:

Разберем URL, который мы ему даем:

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

Всё? Не всё.

Теперь чтобы включить, например, принтер…

О принтере

Cтаренький принтер даже не знал о том, какая яркая судьба ждет его в финале карьеры – при помощи платы Orange Pi Lite из обычного лазерного МФУ он превратился в сетевой принтер (с помощью CUPS), а еще в сетевой сканер (с помощью SANE).

…мы должны сказать:

1. «Алиса, включи навык Домовенок Кузя»;

2. Включить принтер;

3. «Алиса, хватит».

Вот теперь неплохо!

Заключение

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

• Прошло больше года со старта этой затеи. Приятно, что все работает;

• Сдох планшет, висящий на стене, но это мелочь – скоро появится новый;

• Настала и не закончилась пандемия, мы практически все время работаем из дома и необходимости в удаленном управлении практически нет;

• Но есть приятные фишки, такие как удаленная (из другой комнаты) перезагрузка принтера, если он завис;

• Sonoff 4CH Pro иногда немного глючит – выключает один из своих четырех каналов, при этом его нужно включить фразой «Алиса, включи свет в большой комнате» и все работает дальше;

• Мы в департаменте продолжаем работать на Котлине, теперь это у нас основной язык для разрботки бэкэнда и небольших утилит;

• Планы по развитию проекта? Если честно, особо нет. Хочется еще освоить лампочку (тоже на 8266, даже куплена одна), хочется в люстры закинуть basic-устройства (подвесной потолок позволяет), чтобы можно было регулировать не целиком вкл/выкл, а «по половине люстры». Были мысли посмотреть в сторону ZigBee устройств, но они (мысли) пока не вызрели. Наверное в подобных затеях есть смысл на даче, в своем доме и т.д. В рамках квартиры же – это скорее интересные эксперименты, чем реальная необходимость;

• Здесь могла бы быть реклама нашего РТ-шного умного дома (знаю, что эта тема активно развивается в компании), с посылом «Ну, если не хотите идти такой сложной и запутанной дорогой, то вот вам, смотрите как клево». Но этот пользовательский опыт у меня еще впереди

Вернемся к эпиграфу – прав ли был писатель lleo? Предлагаю вам решить это самим

В качестве дополнения напишу, что еще можно поднять на одноплатнике.

Чтобы было весело и интересно

Ссылки на проекты в GitHub:

• Серверное приложение: github;

• Клиентское приложение: github.

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

Сценарии настраиваются на защиту и помощь владельцу дома. Их разработка довольно долгая, но для большей функциональности умного дома следует очень тщательно подходить к этому вопросу.

Самые популярные сценарии

Запрограммированная модель «поведения» датчиков обычно срабатывает в отношении следующих факторов:

• определенное время суток (включается свет, компьютер, отключается микроволновка и так далее);
• датчики могут реагировать на движение и изменение температуры;
• поступила команда на выполнение (она может быть отдана с телефона или ноутбука, в том числе в online-режиме, а также голосом или при помощи пульта).

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

• уход за аквариумными рыбками и комнатными растениями;
• подсушивание крыши и подъездов к дому;
• наполнение и нагрев бассейна и сауны.

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

Проектировка и программирование системы

Создание умного дома состоит из следующих пунктов:

1. Набросок общего плана. В нем подробно рассматривают этапы взаимодействия внутренних составляющих сценария с пользователем и между собой, а также отклик программы на нестандартные ситуации.
2. Подбираются или пишутся с нуля драйвера для дома, и подходящий интерфейс. Не для каждого устройства производитель предлагает оригинальный драйвер, поэтому задача специалиста – его создать. Дополнительно идет написание различных модулей. Что касается интерфейса – обычно все устройства управления разбиваются на отдельные группы; за каждой дальнейшее программирование закрепляет свой интерфейс. Его можно установить для каждого пульта, но это будет неудобно в первую очередь для самого пользователя.
3. Затем идет непосредственно программирование на основе предыдущих пунктов. Используя ранее логически выверенный проект, подготовленное для него программное обеспечение, специалисты приступают к написанию собственно программы сценария.
4. Монтаж, тестирование, сдача в эксплуатацию.

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

Обычно фирмы, предоставляющие подобные услуги, включают в обслуживание абонента вторичное программирование системы, которая чем-то не устроила заказчика. Резервные копии создаются в обязательном порядке и сохраняются отдельно для каждого дома, чтобы в случае неполадок можно было все переустановить.

Все начинается с протокола

Не так давно наша компания завершила очередной этап проекта по разработке программной части системы «умный дом» для компании Nero Electronics. В работе над умным домом Nero нам пришлось работать сразу с двумя протоколами. Один – это общедоступный z-wave, а второй – собственная разработка Nero.

И второй момент очень интересен. Разработка «самописного» протокола связана с несколькими серьезными вызовами.

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

Есть ли альтернативы самописным протоколам?

Да. Это публичные протоколы Z-wave, ZigBee и Bluetooth LE. Они уже «из коробки» обеспечивают помехоустойчивость, приличный радиус действия, хорошо справляются с препятствиями типа стен. Их множество, но для умных домов подходят только протоколы с низким энергопотреблением.

При этом у Z-wave есть одна существенная проблема – это дорогие устройства (датчики, управляющие элементы и прочее), которые с ним совместимы. Их цена может быть в два-три раза выше, чем у устройств, работающих с другими протоколами. Как следствие, выбор Z-wave отсекает огромный пласт клиентов, которые не готовы платить за устройства большие деньги.

В этом плане Bluetooth LE может показаться оптимальным решением, так как он обеспечивает хорошую дальность работы и низкое энергопотребление.

Но его существенным минусом является топология работы. Если устройства Z-wave и ZigBee могут сами ретранслировать сигнал от роутера, позволяя расширять сеть, то каждое Bluetooth-устройство должно взаимодействовать напрямую с роутером. И если в квартире еще можно построить сеть с прямой видимостью роутера, то в загородном доме дальности действия Bluetooth может не хватить.

Почему мы работали с самописным решением?

Когда мы только начинали работу, указанных протоколов или еще не было, или же они были «сырыми». Приходилось «отсекать» большой кусок потенциальных покупателей, выбирая Z-wave с его дорогими устройствами.

На данный момент разработка собственного протокола мне видится нецелесообразной. Уже есть из чего выбирать.

Две сложности в разработке умного дома

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

Обычно у пользователей возникают проблемы именно на этом этапе. Например, в решениях типа того, что предлагает Xiaomi, нужно «руками» объединять устройства в сеть – вручную находить и прописывать номера, настраивать все в интерфейсе и так далее.

Наш замысел состоял в том, чтобы система все делала автоматически. Причем сразу после того, как включается в розетку. В итоге процесс выглядит так: при первом включении управляющее устройство всего дома подключается к Wi-Fi, затем сканирует пространство вокруг себя, находит устройства умного дома (датчики, исполняющие устройства), включает их в сеть и настраивает. Мы даже предусмотрели систему идентификации по QR-кодам на тот случай, если кто-то вдруг боится, что сеть «прихватит» соседские устройства. Чтобы этого не произошло, достаточно лишь сфотографировать этот QR-код – и система распознает устройство.

Проблема могла бы решиться «белым» IP-адресом (то есть IP, под которым устройство всегда находится в сети), к которому всегда можно подключиться. Проблема в том, что таких адресов очень мало. Провайдеры не предоставляют их своим клиентам, выдавая постоянно меняющиеся. И здесь встает задача: как «связать» пользователя именно с его домом?

Решить такую проблему помогает технология WebRTC. Если вкратце описать суть ее работы, то она помогает пользователю и умному дому «находить» друг друга посредством «облачного посредника». Используя облачную инфраструктуру, мы смогли построить решение, которое знает обо всех подключенных умных домах.

Рабочий процесс выглядит так: когда к платформе подключается пользователь, то с его устройства поступает запрос: «А дай-ка мне такой-то дом». «Посредник» (это могут быть сервера Amazon или Google, например) ищет IP-адрес, который прямо сейчас присвоен умному дому, после чего соединяет обе стороны, давая доступ пользователю к его управлению.

О проблемах с видеонаблюдением

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

Передача видео с одной Full HD-камеры способна потреблять примерно мегабит трафика в секунду. А теперь представим, что вы захотели посмотреть трансляцию из дома, сидя на работе. Как уже было сказано выше, напрямую подключиться к умному дому нельзя из-за динамического IP, так что в дело снова вступает «облачный посредник». И вот здесь возникает большая статья расходов – передача видеотрафика.

Представим, что в сети тысяча домов – это гигабит в секунду. Многие провайдеры не способны предоставить скорость выше 100 мегабит в секунду. Следовательно, мы упираемся в инфраструктурные ограничения. И это без учета тех затрат на трафик, которые понесет владелец дома.

В общем, задача с передачей видео до сих пор не решена в полной мере.

Служба поддержки и ведения логов

Важная часть работы над «умным домом» – это организация пользовательской поддержки. И здесь есть свои сложности: как понять, что делал клиент (или что произошло), перед тем как что-то пошло не так?

Перед нами встала задача организовать систему поддержки. Для этого мы разработали специальную систему логов, которая записывает все происходящее в системе, а затем отправляет информацию в «облако», откуда она перенаправляются на специальный сервер обработки. Там все данные структурируются.

В итоге мы построили систему таким образом, что специалист службы поддержки имеет доступ ко всем логам и данным в них за любую дату. Это нужно, чтобы можно было быстро выяснить, что происходило с системой до выхода из строя, какие ошибки в ней появились. Например, специалист увидит, что пропало интернет-соединение или не работает GSM-модуль. Имея эту информацию, он уже сможет посоветовать клиенту что-то конкретное вместо того, чтобы «вслепую» выдвигать гипотезы или просто гадать.

Например, в одном доме есть GSM-модуль, устройства с LCD-дисплеями, система управления устройствами, связь мобильного клиента и сервера – это все разные системы. Например, если сломался GSM-модуль, то система потеряла возможность отправлять SMS-сообщения. В этом случае мы имеем дело уже с двумя записями в логах – поломка GSM-модуля и невозможность отправки сообщения. Службе поддержки же нужно собрать их все вместе, чтобы получить цельную картину состояния дел в доме и выявить причину проблемы.

В общем, задача оказалась сложной, но решить мы ее смогли с помощью стека Elasticsearch плюс Kibana. Логи хранятся в базе Elasticsearch, а просматриваются с помощью приложения Kibana, которое и выдает всю картину по дому.

О безопасности

Конечно, когда разрабатывается умный дом, то безопасности придается большое значение. Все-таки он управляет большим количеством критически важных вещей: видеонаблюдение, двери, свет… В чем опасность? Получив доступ к системе, злоумышленник, например, может открывать двери или ворота.

Важно не дать ему эту возможность. Но как это сделать, если все работает через интернет, а трафик вполне может быть перехвачен?

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

Что касается возможности перехвата трафика, то здесь мы внедрили шифрование. Причем данные шифруются на всех этапах передачи: от устройства до умного дома, от умного дома до «облака» – все это защищенное соединение.

Кстати, один из наших аналитиков предположил, что если удастся каким-то образом украсть бэкап умного дома и «залить» его на новое управляющее устройство, то можно будет получить доступ к нему. В итоге и эту возможность мы закрыли: для восстановления из бэкапа нужно будет вводить логин и пароль суперадминистратора, а также знать секретное слово.

Если суперадминистратор забудет пароль, то сможет восстановить его по кодовому слову. Даже если нарушитель его узнает, то это ему ничем не поможет.  Дело в том, что новый пароль приходит через SMS на телефон, который был указан при регистрации умного дома или на email суперадминистратора. Взломщик, даже зная кодовое слово, не сможет установить себе приложение и сменить пароль потому, что нужен еще доступ к номеру телефона или почте суперадминистратора. Следовательно, он ничем не сможет управлять.

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

«Облака» и безопасность

Так как многие сервисы завязаны на «облаке», то отдельный блок вопросов безопасности возникает именно из-за опасений за его безопасность.

Учитывая этот факт, мы решили разместить в нем сугубо технические данные, которые ничем не будут полезны взломщикам. При этом никакой критически важной информации туда не передается. Что же у нас там хранится?

Прошивки. Прошивки локального сервера и устройств управления. Каждое устройство может «забрать» оттуда новую версию ПО и обновиться. Это системная информация, которая не несет пользы нарушителю.

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

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

Инфраструктура

Самая большая сложность в разработке системы умного дома – поддерживать стабильность ее работы. Так или иначе, но все умные дома поддерживают связь с «облаком», которое помогает мобильным устройствам их находить. И если выйдет из строя мобильный «облачный» сервер, то они сразу одновременно потеряют доступ к ним (а клиенты – к домам).

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

Все это упирается в огромные затраты на инфраструктуру. Многие компании полагают, что можно сфокусироваться лишь на разработке умного дома, а для решения инфраструктурных вопросов достаточно будет «отделаться» облачным сервером Amazon, но это не так. Например, через Amazon нельзя пустить видео. Во-первых, сам провайдер ограничивает канал 10 мегабитами. Во-вторых, сервера далеко, а это значит, что видео может сильно замедлить скорость работы, что скажется на стабильности работы всей системы. Возможно, это неплохой вариант для тестирования, но точно не для полноценной эксплуатации.

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

---

Материалы по теме:

Почему программирование должны учить не только программисты

22 полезных инструмента для начинающих кодеров

«Работа AI ничем не отличается от того, как функционирует мозг» – история программиста с 30-летним стажем

Россия переходит на собственное ПО: плюсы и минусы

Как стать программистом, если очень хочется, но опыта нет

Иллюстрация: Оля Ежак для Skillbox Media

Журналист, коммерческий автор и редактор. Пишет про IT, цифровой маркетинг и бизнес.
Сайт: darovska.com.

Интернет вещей (Internet of Things, IoT) — это когда вещи и предметы физического мира могут взаимодействовать между собой напрямую, не требуя вмешательства человека.

Простой пример — холодильник, который сам следит за количеством молока и других продуктов и делает заказ в интернет-магазине, когда они заканчиваются. Или умная колонка, которая связана с датчиками протечки, задымления и другими девайсами в вашем доме и способна управлять ими и снимать с них показания.

Архитектуру IoT-решений принято делить на четыре уровня:

• датчики, которые собирают данные: например, датчики протечки, движения, освещения и тому подобные, подключённые к микроконтроллеру;
• локальные шлюзы — устройства, которые передают и обеспечивают обмен данными;
• Edge Servers — граничные серверы, которые хранят, аккумулируют и обрабатывают данные непосредственно там, где информация производится (например, это могут быть производственные помещения);
• облачная инфраструктура.

Компании, которые занимаются разработкой IoT-устройств и решений, нередко разрабатывают как и сами устройства, так и всё ПО для всех четырёх уровней устройств. Исключение — компании, которые собирают отдельные датчики или девайсы для уже готовых экосистем и стандартов, поддерживаемых крупными вендорами. «Железо» и различные архитектуры мы почти не затронем — подробности об этой стороне IoT можно узнать в выпуске нашего подкаста «Люди и код», посвящённом микроконтроллерам.

Так как архитектура интернета вещей состоит из четырёх уровней, для программирования под каждый из них разработчики выбирают свои технологии. Согласно исследованию Eclipse Foundation от декабря 2021 года, в IoT наибольшей популярностью пользуются такие языки:

• Лидеры на встраиваемых устройствах и микроконтроллерах — C, C++, Java и Python.
• Для программирования шлюзов чаще всего выбирают Python, C++, C и Java.
• Для серверной разработки предпочтение отдают Python, Java, C++ и C.
• В облаках — Python, Java, JavaScript, C++.

«В разработке IoT-устройств всё делается с применением стандартных подходов — подводных камней нет, и всё более-менее предсказуемо. Выбор конкретного языка программирования чаще всего зависит от удобства и принятых стандартов, но на безопасность почти не влияет».

Иван Юшков,
разработчик в сфере IoT

Примечательно, что по итогам 2021 года явным лидером стал Python — хотя за год до этого в топе был Java. Это, кстати, интересный тренд: в том же рейтинге популярности языков программирования TIOBE в 2021 году Python наконец-то сумел обойти Java и C — фактически бессменных лидеров последних десятилетий.

«Python прост в освоении и поддерживается большим отзывчивым сообществом. Его синтаксис чистый и простой, что привлекает большое количество программистов. Поэтому Python часто выбирают социологи и биологи — чтобы программировать лабораторные устройства. А ещё это предпочтительный язык для одного из самых популярных микроконтроллеров на рынке — Raspberry Pi».

Кинман Кови,
разработчик микроконтроллеров

Рост популярности Python вполне понятен: это удобный и быстрый с точки зрения написания кода язык с кучей библиотек почти под каждую задачу (особенно силён в сфере машинного обучения и работы с данными), он прекрасно взаимодействует со многими языками программирования (недаром его часто называют «клеем» среди языков программирования). Кроме того, устройства с каждым годом становятся всё мощнее и вопрос оптимизации стоит уже не так остро, как вопрос скорости разработки и поставки ПО.

Если проект простой и не требует больших вычислительных мощностей, можно использовать стандартные библиотеки Python, а вот для микроконтроллеров стоит посмотреть на пакет MicroPython — он подходит для запуска Python на небольших платах с 256 КБ памяти и 16 КБ оперативки и площадью в пару квадратных сантиметров.

Хотя вполне очевидно, почему в нише микроконтроллеров и встроенных устройств позиции Python не так прочны — здесь гораздо выше требования к скорости исполнения, энергосбережению и экономному расходованию памяти. Конечно, в таких условиях Python и MicroPython уступают более скоростным C, C++ и Java.

«В IoT существует свой набор ограничений — например, интернет-соединение в один килобит или ограничение частоты отправки сообщений. Такие ограничения возникают из-за повышенных требований к экономии ресурсов — например, может быть критично, чтобы ваше устройство было способно проработать условные 100 лет на одной батарейке».

Иван Игнатьев,
Cloud Solution Architect из Pluto Informatics

Второе место можно отдать «плюсам» — всё-таки ещё не перевелись любители пощекотать себе нервишки Его часто используют на одноплатных компьютерах типа Raspberry Pi — он быстрый, как C, но при этом разработка на нём, как правило, занимает меньше времени.

Сила Java — в переносимости и принципе write once, run anywhere. Если виртуальная Java-машина (JVM) поддерживает какую-то архитектуру, вы обычно можете быть уверены, что ваш код будет на ней работать так же, как и на других платформах.

Кроме того, Java — это классический ООП-язык, удобный для энтерпрайз-решений, с большим набором библиотек и инструментами для работы с безопасностью, а байт-код и сама Java-машина за долгие годы были оптимизированы и могут исполняться с достаточно хорошей скоростью.

«Какой язык использовать в проекте, зависит от юзкейсов. Например, есть задача — определить заполняемость мусорных баков в городе. Для этого внутри них ставят датчики и следят за наполнением. Датчик в этом случае должен быть как можно менее энергозатратный, так как мы не можем подключить каждый мусорный бак к розетке или регулярно ездить и менять в них батарейки. Поэтому для таких задач используются языки более низкого уровня вроде C или предназначенного для встроенных систем Java Embedded».

Иван Игнатьев,
Cloud Solution Architect из Pluto Informatics

Да, этот старичок ещё очень популярен во встраиваемых системах и в качестве средства для системного программирования — где-то в силу традиций и накопленной большой кодовой базы на C, которую пока невозможно (да часто и не нужно) перевести на более современные языки, где-то в силу его скорости и других плюсов. К тому же благодаря C разработчик может напрямую взаимодействовать с памятью и любым «железом» — не зря C называют «переносимым ассемблером».

«У меня был проект промышленного IoT с „Роснефтью“ с системой предиктивной (предсказательной) аналитики. С помощью датчиков она определяла, сколько нефти проходит через весы, а сколько попадает в хранилища, а потом анализировала, сходятся ли эти данные, нет ли издержек. Датчики весов подключались к интернету и передавали данные на сервер. Софт для них был написан на C».

Алексей Барышников,
Java-/JS-разработчик

JavaScript тоже используют в IoT. Причём не только для веб-интерфейса приложений, но и для софта серверов. А в сочетании с фреймворком Node.js — ещё и для датчиков, серверов и шлюзов на ОС Linux. Например, построить софт на Node.js удалось в микроконтроллерах производителей Espruino и Tessel.

«Если объект можно запитать от солнечной панели или другого внешнего источника, то обычно в IoT используют Python, MicroPython, JavaScript и Node.js».

Иван Игнатьев,
Cloud Solution Architect из Pluto Informatics

Этого языка (как и последующих) нет в топе исследования, однако он часто упоминается в связи с IoT. Фишка языка — он специально был разработан для поддержки средств описания данных, у него есть особый фреймворк Node.lua, то есть порт, или аналог, Node.js в LUA-мире, к тому же построенный на облегчённом интерпретаторе LUA.

У Go богатая стандартная библиотека, отличная работа с параллелизмом из коробки, и его популярность в мире постоянно растёт.

«Golang в основном заменяет JavaScript/Node.js для серверных HTTP-приложений. На мой взгляд, он гораздо лучше JavaScript. Golang можно использовать и в других компонентах IoT, но, по моему опыту, он для этого не очень подходит. Часть кода используется в высокоуровневых программах, а часть должна работать на низком уровне — ближе к „железу“. В IoT хватает и того, и другого.

И вот для низкоуровневой работы Go практически не годится. Он некрасиво обрабатывает данные, а использование указателей — так и вообще устаревший подход. Короче говоря, для работы с протоколами он не подходит. Конечно, даже несмотря на это в подобных задачах он ещё лучше Java, но гораздо хуже C. А если вас пугает сложность C и вы думаете, чем бы его заменить, — лучше обратите внимание на Julia».

JP Norair,
IoT-разработчик, комментарий на Quora

Это особая версия PHP для работы с чипами. Удобна для тех, кто уже знает PHP и хочет заняться интернетом вещей. Плюс в этом диалекте из коробки есть средства, полезные для разработки под IoT. К тому же более 90% серверов в мире по-прежнему работают на PHP, поэтому этот язык также популярен в интернете вещей и применяется для управления микросервисами на базе Linux.

Swift используется для создания приложений для умных устройств в экосистеме Apple. У Swift собственные библиотеки для платформы HomeKit, которая обеспечивает поддержку интеграции каналов данных из сети совместимых устройств.

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

Во встраиваемых устройствах, шлюзах и микроконтроллерах самым популярным выбором является Linux (в основном урезанные или специфические версии — из «обычных» линуксов более-менее популярен разве что CentOS). Linux — гибкая и свободная ОС, которую можно «доработать напильником» практически под любые нужды, которая умеет запускаться на множестве разных архитектур. Плюс у него огромное сообщество и куча готового софта почти под любые задачи (разве что с Photoshop и Microsoft Office проблемы — но кому они нужны в IoT).

«Для всего, что можно воткнуть в розетку, существует операционная система Linux. В качестве use case может быть определение безопасности закрытия дверей в поезде. Для этого используют обычные компьютеры, которые соединены с датчиками по проводу или с помощью Bluetooth.Чтобы эта система работала, нужно полноценное питание и интернет-соединение. Приложения для умного дома можно писать на чём угодно — в серверных используют файрволы, роутеры и хранилища App Storage для загрузки файлов. Для написания приложений существует множество open-source-проектов, в основном построенных на PHP».

Иван Игнатьев,
Cloud Solution Architect из Pluto Informatics

За Linux следует FreeRTOS — операционка реального времени, созданная специально под микроконтроллеры. А значит, она умеет экономно использовать даже самые скромные ресурсы. Особенность систем реального времени — они заранее гарантируют, что задача будет выполнена в конкретные сроки. То есть работают максимально предсказуемо, что особенно важно для обработки критических запросов в военной или космической промышленности, а также везде, где от точной до миллисекунды обработки задачи зависят жизни людей или работоспособность дорогостоящего оборудования. Кстати, Linux так не умеет.

На третьем месте с большим отрывом — Windows. Все мы работали с терминалами оплаты или банкоматами, в которых нередко используется именно система от Microsoft. Это закрытая и гораздо менее гибкая система, и подходит она только для тех устройств, в которых достаточно много свободных ресурсов.

На четвёртом месте Zephyr — ещё одна свободная операционка реального времени, созданная специально для работы со встраиваемыми устройствами и микроконтроллерами.

А вот на серверах и в облаках ситуация отличается — хотя в рейтинге всё так же присутствуют Linux (лидирует с большим отрывом) и Windows. Кроме того, достаточно популярен майкрософтовский вариант Linux — Azure Sphere. Неудивительно — на ней строится Azure, а это один из лидеров в мире среди облачных платформ. Четвёртое место скромно заняла FreeBSD, ещё одна свободная операционка, которая традиционно считается более надёжной и безопасной, чем Linux.

Среди каналов связи, конечно же, лидирует классический Ethernet — проводной, надёжный, стабильный и предсказуемый. Он обеспечивает самые большие скорости и может быть почти «бесплатным» с точки зрения энергопотребления.

Из беспроводных технологий наибольшей популярностью пользуется Wi-Fi — его можно развернуть относительно дёшево, не нужно использовать базовые станции, привязанные к операторам связи, у него отличная скорость, и он может покрывать относительно неплохое расстояние.

Чуть менее популярны сети сотовой связи. Их плюс — они уже есть на куче смартфонов, могут обеспечить хорошую зону покрытия и работают на больших расстояниях. То есть удобны там, где нет проводов, а Wi-Fi просто «не добивает».

Bluetooth на четвёртом месте — у него достаточно низкая скорость передачи данных, он не так стабилен в работе, и у него серьёзные ограничения по расстоянию между устройствами. Зато он экономнее в потреблении электроэнергии, чем Wi-Fi и сотовые сети связи.

«Приведу пример промышленного IoT-проекта — карта заводов с цветовой дифференциацией состояния. С помощью этой карты любой из менеджеров мог зайти на конкретный завод и посмотреть, в чём конкретно проблема на дашбордах с цифрами по каждому цеху — давление, температура и другие данные с промышленных IoT-устройств. Для передачи данных использовали DSL-линию — с её помощью выгружали Python-скрипты. Скрипты использовали для построения прогнозных моделей по объёмам производства нефти на заводе в Сочи. Для отображения моделей в единой ноде использовали Node.js и React, Polymer и Angular. С их помощью строили таблицы и графики из уже посчитанных дата-сайентистами данных, а также сырых данных, выгружаемых из Data Lake.

Конечный результат проекта — интерактивная карта в формате SVG, на которой отмечены точки с заводами „Роснефти“».

Алексей Барышников,
Java-/JS-разработчик

Мир IoT — это наше будущее, а значит, разработка ПО для интернета вещей будет всё более востребованным занятием. Если вы уже кодите на Python, PHP, Java, Go или JS — попробуйте вкатиться в эту сферу через них. Python будет лучшим выбором для тех, кто ещё не знаком с программированием. А если вы хотите напрямую поработать с «железом» и памятью — обратите внимание на C/C++.

Научитесь: Профессия Python-разработчик
Узнать больше

Сегодня наблюдается рост интереса пользователей к внедрению в домах и квартирах если не полноценных систем «умного дома», то некоторых элементов Home Automation (домашней автоматизации).

В связи с этим производители ведут разработки и наращивают выпуск систем различной сложности – от полноценных коробочных решений с использованием ИИ, до комплектов на базе микроконтроллеров, позволяющих быстро решать прикладные задачи различной сложности.

Некоторые из них помогут как сделать первые шаги в разработке, так и реализовать достаточно сложные проекты. Например¸ вполне реальный вариант – умный дом на Arduino своими руками.

Что такое Arduino

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

Аппаратные средства Arduino позволяют получить сигналы от сенсоров (например, уровень температуры, наличие света, нажатие на кнопку) или более сложных систем, таких как html-страницы.

Программный код обрабатывает их и выдает сигналы на исполнительные механизмы, например, включает сервопривод, замыкает контакты реле или сервисы, способные выполнять весьма сложные операции – от отправки сообщений на e-mail до размещения контента на страницах.

Основными преимуществами платформы являются:

Как сделать умный дом на Arduino своими руками

Создание умного дома на Arduino своими руками мало чем отличается от разработки и реализации любой другой электронной системы. Процесс включает несколько обязательных этапов.

Разработка эскизного проекта

Соответственно, разработчику придется решить несколько задач.

Формулировка задания

Задание для проекта должно быть определено максимально точно и подробно. Например, решается одна из частных home automation – включить освещение крыльца, когда в темное время к нему приближается человек. Это общее описание задачи нуждается в более конкретных формулировках для проектирования.

Они описывают:

1. Основные условия для срабатывания автоматики – триггеры (triggers) в терминах home automation. В рассматриваемой задаче такой триггер один – приближение человека к крыльцу.
2. Дополнительные условия (conditions). Они задают разрешения на срабатывание триггера и, в большинстве случаев, определяют длительность их действия. Для данной задачи дополнительное условие – темное время. Действительно, включать свет на крыльце днем смысла не имеет. Нет необходимости делать это и когда крыльцо освещено – свет уже включен или задействованы другие источники. Соответственно, дополнительные условия можно задать в нескольких вариантах: наступило темное время суток, и свет на крыльце не включен. Практически полное описание условий, но не учитывает возможность освещения от других источников, освещенность на крыльце ниже порогового значения. Хотя условие и выглядит проще, но учитывает практически все случаи.
3. Действия (actions). Описывает реакцию системы на триггеры и дополнительные условия. Для текущего примера система должна выполнить единственное действие – включить свет.
4. Действия в случае отсутствия триггеров и/или невыполнения условий. Здесь необходимо рассматривать 2 случая: ни основные, ни дополнительные условия не были выполнены. Наиболее логичное поведение – бездействие, триггер и условия были выполнены, произошло срабатывание, затем ситуация изменилась (т.н. post-action действия). Поведение проектируемой системы должно выглядеть следующим образом – не включать свет до срабатывания триггера и выполнения условий, выключить после того, как он перестал быть нужен.

Таким образом, результат – подробное описание задания:

1. Проверять, есть ли у крыльца человек.
2. Бездействовать, пока его нет.
3. Если человек подошел – проверить освещенность.
4. Если она ниже заданной – включить свет.
5. Проверять, остается ли нужен свет.
6. Если да – оставаться в текущем состоянии, если нет – выключить свет.

Выбор способов реализации алгоритма

На этом этапе определяется набор сенсоров для получения данных (триггеров и условий) и исполнительных механизмов для выполнения действий.

Даже в простейшем рассматриваемом случае возможны несколько вариантов реализации. Например, определять присутствие человека у крыльца можно:

• по сигналу стандартного инфракрасного датчика;
• разместив под площадкой у крыльца датчики, реагирующие на давление (например, тензодатчики на основе пьезоффекта);
• получая с работающего в квартире Wi-Fi-роутера сигнал о подключении нового/конкретного абонента к домашней беспроводной сети и т.д.

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

Завершает этап запись алгоритма с учетом принятых решений, например:

1. Опрашивать проводной ИК-датчик.
2. Если сигнала нет – ничего не делать.
3. При появлении сигнала, проверить состояние проводного датчика освещенности.
4. При наличии сигнала – ничего не делать.
5. При отсутствии сигнала – выдать на ZigBee хаб команду на включение выключателя по соответствующему адресу (отвечающему за освещение на крыльце).
6. Опрашивать ИК датчик.
7. Пока есть сигнал (человек на крыльце) – ничего не делать.
8. Если сигнала нет – отключить свет, т.е. выдать на ZigBee выключатель команду на отключение.
9. Вернуться к началу цикла.

Еще один результат этого этапа – перечень необходимого оборудования и материалов. Для сборки системы потребуются:

• Контроллер с возможностью опроса проводных каналов связи (минимум, двух, для датчика освещенности и ИК-датчика).
• ZigBee выключатель.
• ZigBee хаб (без него моно обойтись, если контроллер имеет интерфейс для прямого управления ZigBee устройствами).

Выбор оборудования

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

Выбор контроллера Arduino

Поскольку базовая платформа – Arduino, определена ранее, остается выбрать конкретную модель контроллера и, при необходимости, расширение. Задача не сложная, поскольку ассортимент устройств достаточно обширен и включает модели для большинства практических задач.

В список оборудования входят:

Контроллер	Чип	Память (ОЗУ/ПЗУ)	Порты ввода/вывода и интерфейсы	Дополнительно
Due	32-битный Cortex-M3 ARM SAM3U4E,, 84 МГц	64+36Кб/256+256Кб (возможна прямая адресация всего пространства)	54 цифровых IO (некоторые со специальными функциями, например, ШИМ) 12 аналоговых входов (с АЦП) 2 аналоговых входа	Питание контроллера 3.3В
Uno	8-бит ATmega328 или ATmega8U2 (в новой версии), 16 МГц	2Кб/32Кб+1Кб EEPROM	14 цифровых IO (6 могут использоваться как ШИМ) 6 аналоговых входов с АЦП UART TTL USB Разъемы для модулей расширения
Leonardo	8-бит ATmega32u4, 16МГц	2.5кБ/32Кб+1Кб EEPROM	20 цифровых IO (7 с функциями ШИМ) 12 аналоговых входов (могут работать как цифровые) USB расширения	Встроенная поддержка USB позволяет настраивать видимость при связи с ПК (как клавиатуру, мышь, виртуальный последовательный порт) Функционально и конструктивно аналогичен Uno
Duemilanove, Decimila	8-бит ATmega168, 16МГц	1Кб/16Кб+512б EEPROM	В остальном полностью аналогичны Uno на базе ATmega328
Mini	8-бит ATmega168, 16МГц	1Кб/16Кб+512б EEPROM	14 цифровых IO (6 могут использоваться как ШИМ) 6 аналоговых входов с АЦП	Для программирования требуется адаптер MiniUSB Компактное решение для макетирования
Micro	8-бит ATmega32u4, 16МГц	Компактный контролер, по функциональности и аналогичный Leonardo, для подключения и программирования используется кабель microUSB
Nano	8-бит ATmega168 или ATmega328, 16МГц	Компактный вариант Duemilanove, отличающийся только габаритами и отсутствием разъема для подключения внешнего источника питания
Mega	8-бит ATmega1280, 16МГц	8Кб/128Кб+4Кб EEPROM	54 цифровых IO (14 с функциями ШИМ) 16 аналоговых входов с АЦП 4 порта UART USB расширения
Mega 2560 Mega ADK	8-бит ATmega2560, 16МГц	Отличаются от Mega увеличенным до 256Кб объемом ПЗУ для хранения программ и реализацией USB-интерфейса на ATMega8U2. В Mega ADK сконфигурирован USB host, который моет работать с другими устройствами, в частности, смарифонами
Pro	8-бит ATmega328, 16МГц (3.3В) или ATmega168, 8МГц (5В)	2 или 1 Кб/32 или 16 Кб + 1 Кб или 512б EEPROM	14 цифровых IO (6 могут использоваться как ШИМ) 6 аналоговых входов с АЦП UART TTL USB Разъемы для модулей расширения	Разъемы ввода/вывода и интерфейсов не установлены, разработчик может использовать собственные
Pro Mini	Аналогична Mini, но как и в полномасштабной Pro требуется установка разъемов

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

• Yun – устройство по возможностям (чип, выводы) аналогичное Leonardo, но со встроенным Wi-Fi модулем на базе Atheros AR9331.
• BT – платформа со встроенным BlueTooth интерфейсом.
• Fio – контроллер, аналогичный Uno по функциональности, но без установленных разъемов на портах ввода/вывода. Предназначен для работы в беспроводной сети ZigBee.
• Serial – функционально аналогична базовой Uno с интегрированным стандартным последовательным интерфейсом RS232.

Кроме того, для работы с различными стандартами связи и устройствами можно использовать стандартные платы расширения:

• Wi-Fi с поддержкой протокола 802.11 b/g;
• Xbee Shield, с интегрированным модулем Maxstream Xbee Zigbee, поддерживающим до 32 устройств ZigBee (35/90 м в помещении и на открытом пространстве соответственно);
• Ethernet Shield – с установленным портом стандарта Ethernet 10/100 Base-T для проводного сетевого соединения;
• Motor Shield – с портами для управления двигателями постоянного тока и получения сигналов обратной связи от датчиков положения.

При необходимости можно найти и другие конфигурации полностью совместимых контроллеров, выпускаемые сторонними разработчиками. Полный список одобренного оборудования размещен на странице https://playground.arduino.cc/Main/SimilarBoards/ официального сайта.

При выборе контроллера необходимо учитывать:

1. Производительность;
2. Наличие необходимого количества портов ввода/вывода, цифровых и аналоговых;
3. Объем памяти для хранения программ и данных (все платы Arduino используют небогатые ресурсы микроконтроллера и не предполагают расширений);
4. Удобство работы – программирования, отладки программ, установки готового устройства в корпус.

Выбор периферии

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

Однако, при желании, и это требование легко обходится за счет сборки собственных или использования готовых плат согласования.

Разработка принципиальной схемы

После покупки контроллера и периферийных устройств следует начертить принципиальную схему системы автоматизации. С платами Arduino это труда не составит, главная задача разработчика – выбрать пины портов ввода/вывода для подключения – это важная информация для написания программы.

Работа с программным обеспечением

Когда принципиальная схема готова, начинается важнейший этап проектирования – написание программы для контроллера. Для этого необходимо скачать среду разработки Arduino IDE.

Загрузка, установка, проверка ПО

Программное обеспечение скачивают со страницы официального сайта https://www.arduino.cc/en/software.

Стабильная версия – Arduino IDE 1.8.13 поддерживает:

• Windows 7 и более новые версии ОС, х86 и х64;
• MacOS 10.10 и новее;
• 32- и 64-битные версии Linux и Linux ARM.

Для работы под Windows можно скачать установщик или ZIP-архив софта. Использовать установщик для неопытных пользователей предпочтительнее – установка драйверов будет произведена автоматически вместе с установкой программы.

При использовании ZIP-архива достаточно развернуть программу на жестком диске ПК и запустить IDE. В этом случае программа также попытается установить драйвера, но, возможно, придется обновить их вручную в Панели управления. Все необходимые .inf файлы входят в комплект поставки.

Возможности среды разработки Arduino IDE:

• Создание проектов (скетчей, от англ. sketch – набросок).
• Их проверка и компиляция для загрузки в контроллер;
• «Заливка» готового машинного кода в контроллеры;
• Поддержка всех версий плат;
• Подключение библиотек, не входящих в комплект поставки.

Для этого достаточно выполнить входящий в комплект поставки простейший скетч с управлением светоиодом.

Пошагово процесс выглядит следующим образом:

1. Подключить плату Arduino Uno (именно на ней остановился выбор для реализации предложенной задачи) кабелем к USB-порту компьютера.
2. Запустить Arduino IDE.
3. В среде разработки открыть готовый скетч – в меню File выбрать папку Examples-1.Basic, в ней файл Blink.
4. Выбрать плату контроллера для работы – меню Tools-Board.
5. Указать порт для связи с платой (как правило COM3 или другой COM с бОльшим номером). Если этих портов нет, следует проверить, подключена ли плата или установить вручную драйверы.
6. Откомпилировать скетч через меню Sketch-Verify/Compile или нажатием на соответствующую кнопку в панели инструментов под строкой меню.
7. Загрузить готовый скетч в контроллер (Sketch-Upload) или нажатием кнопки панели инструментов. На этом этапе можно наблюдать мигание светодиодов Rx и Tx , которое свидетельствует об обмене с ПК.
8. После окончания загрузки через несколько секунд начнет мигать светодиод на плате Uno. Это говорит о том, что и контроллер и среда разработки полностью работоспособны.

После проверки можно приступать к разработке собственной программы.

Программирование скетчей

Программирование скетча можно выполнить непосредственно в редакторе среды разработки или в любом другом удобном текстовом редакторе (в последнем случае не забыть сохранить работу в файле .ino). Встроенный язык программирования Arduino является клоном языка C++ с некоторыми упрощениями и дополнительными функциями и библиотеками для обращения к функционалу контроллера.

Для работы с программой в IDE необходимо:

1. Создать новый скетч (File-New).
2. Подключить необходимые библиотеки. Стандартные библиотеки функций входят в комплект поставки, нестандартные нужно разместить в соответствующих папках папки Libraries. После этого их имена станут доступны разработчику в меню Sketch-Import Library. Достаточно выбрать нужные имена, и они будут включены для обработки препроцессором.
3. В функции setup() прописать все необходимые действия для инициализации системы. Эта функция выполняется один раз перед стартом. Как правило, в ее тексте достаточно ограничиться назначением функций пинам ввода/вывода.
4. В функции loop() прописать код, реализующий алгоритм автоматизации – опрос сенсоров, анализ условий, выдачу сигналов на исполнительные механизмы. Функция выполняется в бесконечном цикле, операторы прерывания этого цикла не предусмотрены.
5. Откомпилировать написанный скетч.
6. Загрузить его в контроллер.

Отличия языка Arduino от стандарта C++

• Не требуется включения заголовочных файлов (хидеров, файлов с расширением .h)в текст программы, препроцессор добавит их автоматически в соответствии с импортированными для скетча библиотеками.
• Добавлены предопределенные константы для уровней (HIGH и LOW) и функций выводов портов ввода/вывода (INPUT и OUTPUT).
• Добавлены функции для работы:
  • c цифровыми портами ввода/вывода pinMode(), digitalWrite(), digitalRead();
  • с аналоговыми пинами analogReference(), analogRead(), analogWrite();
  • дополнительными IO функциями, например, побитного вывода со сдвигом shiftOut();
  • временем mills() – время в мс, micros() время в мкс, delay() – задержка в мс, delayMicroseconds – задержка в мкс;
  • внешними прерываниями attachInterrupt() и detachInterrupt();
  • последовательным портом.
• В комплект поставки включены библиотеки для сервоприводов (Servo), шаговых двигателей (Steps), EEPROM, SPI-интерфейса.

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

Со всеми платами контролеров и расширений поставляются необходимые библиотеки для работы со всем аппаратным обеспечением. Кроме того, в сети доступны тысячи готовых библиотек разработанных сообществом. Подобрать нужную (с документацией) можно по ссылкам на официальном сайте https://playground.arduino.cc/Main/LibraryList/ и https://www.arduinolibraries.info/ или на GitHub.

Соответственно, для реализации поставленной задачи разработчику нужно:

1. Создать скетч.
2. Скачать и подключить библиотеку для работы с Xbee (ZigBee).
3. Выполнить назначение портов для опроса датчиков в функции setup();
4. Инициализировать работу с интерфейсом ZigBee в setup();
5. Прописать опрос датчиков и выдачу команды управления по условиям в loop().

Работать с Arduino можно и без установки IDE. Для этого удобно использовать:

• Web-редактор на официальном сайте. Полностью поддерживает синтаксис (с подсветкой), включает все необходимые для работы библиотеки. Альтернативный вариант – любой тестовый редактор.
• Компилятор avr-gcc.
• Программатор, поддерживающий чипы микроконтроллеров, используемых на платах Arduino,

Для пользователей, далеких от программирования на любых языках, созданы альтернативные варианты разработки проектов – визуальные. Среди наиболее известных:

• Scratch (http://s4a.cat);
• Snap (http://snap4arduino.rocks/);
• Ardublock (http://ardublock.com);
• XOD (https://xod.io/).

Таким образом, умный дом на Arduino своими руками – решение, доступное практически каждому. Ассортимент аппаратных средств позволяет решать задачи от простейших до максимально сложных (в том числе, за счет взаимодействия нескольких контролеров).

Способствует этому и накопленный сообществом богатый опыт, и полная открытость проекта, благодаря которой можно найти готовые программные разработки для большинства процессов home automation.

Часто спрашивают