Умный дом

Что такое умные" города, цифровизация и интернет вещей? Какая роль в веке высоких технологий и искусственного интеллекта отведена программистам? Специально для школы Пиксель на эти вопросы и не только ответил менеджер ключевых проектов компании Schneider Electric Андрей Биневский.

Расскажи о своей работе чем ты занимаешься, связана ли твоя работа прямо или косвенно с программированием?

Я работаю менеджером ключевых проектов автоматизированных систем управления электроснабжения (АСУ) в компании Schneider Electric. Это крупный мировой вендер электрооборудования. Моя работа с программированием связана скорее косвенно, потому что я руковожу проектами программирования, я продаю проекты, в которых трудятся программисты, поскольку ни одна умная система не может быть организована без кодинга, без труда инженеров и программистов.

Что такое автоматизированные системы управления электроснабжения (АСУ)? Расскажи подробнее.

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

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

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

Для настройки этих систем нужны программисты?

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

Расскажи про свой первый опыт общения с компьютерами. Помнишь свою любимую компьютерную игру?

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

Тебе захотелось потом научиться программированию?

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

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

Как ты считаешь программист это профессия будущего?

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

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

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

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

Какие города считаются умными?

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

В России есть Иннополис в Татарстане, которые является российской Кремниевой долиной. Он построен по принципам энергоэффективности, но и там есть много нюансов. Даже сама Кремневая долина вызывает множество вопросов по расходованию энергоресурсов.

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

Что такое цифровизация?

Смотря в чем. Что такое цифровизация, если говорить лоб в лоб? Есть аналоговые сигналы, а есть цифровые. Если возможно что-то передать по цифре, это и есть цифровизация. Не всегда это применяют по делу.

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

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

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

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

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

Что такое интернет вещей? Максимально просто.

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

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

Простой пример. У вас есть загородный дом площадью 120 квадратных метров. Летом вы туда ездите постоянно, а зимой иногда на выходные. И когда вы приезжаете туда зимой, дом остывает и требуется пару часов, чтобы его прогреть. А если бы ваш дом был построен в соответствии с философией интернета вещей, этого бы не происходило. Вы могли бы дистанционно включить обогрев хоть электрический, хоть газовый, наружное освещение перед своим приездом, и при помощи телефона открыть ворота в гараж и зайти в теплый светлый дом. Но когда вас там нет, энергоресурсы на его отопление не расходуются. Система автоматически поддерживает оптимальную температуру, например, +5, когда за окном -30. Человеку здесь будет некомфортно, но все механизмы будут работать.

То, что ты описываешь похоже на умный дом.

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

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

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

Возможно я бы уменьшил часы по русскому и литературе. Не потому что мне это не нравится, а потому что наша литература так или иначе отражает нашу историю. Перечень тех книг, которые проходили в 1985 году и, например, в 2000 году, существенно разнятся, хотя здесь разница всего 1-2 поколения.

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

У тебя есть дети, сколько им лет? Ты отдал бы их в программирование?

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

Как бы ты выбирал школу для обучения программированию?

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

Справка. Чаще всего менеджеры АСУ вырастают из технических специальностей, таких как системные администраторы, наладчики оборудования, инженеры-электрики, инженеры-автоматчики и т.д. Зарплата специалиста чаще всего состоит из оклада и премии за выполнение плана. Средний размер оклада менеджеров АСУ в Москве по данным hh.ru от 100 тыс.руб.

Я Community Manager и у меня есть зависимость. Ну хорошо, не зависимость, но хобби: я увлекаюсь автоматизацией собственной квартиры с помощью того, что принято теперь называть Умным Домом. Начинал я пару-тройку лет назад с чистого Apple HomeKit, затем расширил его возможности с помощью Homebridge и далее полностью погрузился в дебри HomeAssistant.

Но поскольку я Community Mananger, мне интересна та часть моего хобби, которая касается вопроса коммуникации сообщества людей, имеющих такое же увлечение, как и моё.

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

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

Предыстория

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

Мой путь начался с того, что в один прекрасный момент я внезапно осознал, что имеющийся в хозяйстве AppleTV 4K может служить шлюзом для построения Умного Дома на базе Apple HomeKit. Было приобретено и успешно подключено несколько HomeKit ready устройств. Все было прекрасно, стабильно, но дорого. Хотелось дальнейшего расширения, но за меньшие деньги.

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

Так, с помощью внимательного чтения и вопросов к коллективному разуму я влился в обширное и очень эффективное русскоязычное сообщество строителей Умных Домов, Бань, Дач и прочих Гаражей. Мир DIY и OpenSource решений захлестнул меня и, нужно заметить, я был к этому подготовлен. Я уверенно обращался с паяльником и имел очень долгий опыт работы с Linux. Мне было легко и приятно быть среди единомышленников.

С каждой новой итерацией своего продвижения по этому пути все новые и новые ресурсы открывались мне, с великими Гуру можно было спокойно общаться в телеграм группах практически на одном языке и порой даже осмеливаться их критиковать. Я узнал, что большинство самых ценных сообществ живет в профильных телеграм каналах, что сообщество на форуме 4PDA живет какой-то своей жизнью, что известный всем русскоговорящим умнодомщикам Спрут портал раскинул свои щупальца настолько широко, что даже проник на территорию подкастов и инстаграма, что адепты св.Квазиса повсюду и что AlexxIT, Jager, Илья Киров и Иван Бессарабов настолько же доброжелательны и приветливы в общении, насколько круты в своем профессионализме. А для владеющих английским открываются поистине бездонные кладези знаний на Reddit, YouTube и, например, официальном форуме HomeAssistant.

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

OpenSource против готовых решений

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

На чем строить свой Умный Дом? На готовых решениях от Miija, Sonoff, Tuya, Apple, Aqara, Rubetek, Yandex, Google и прочих и прочих? Или же построить его самому на базе OpenSource решений типа HomeAssistant, NodeRed, OpenHub, IOBroker и так далее?

Тем, кто стоит перед таким выбором приходят на помощь авторитетные прожженные линуксоиды и начинают говорить о непревзойденной гибкости автоматизаций и отвязки от коварных "китайских облаков" в OpenSource решениях. Они будут говорить о том, что все будет контролироваться только лично тобой и что ты сможешь использовать почти весь доступный на рынке зоопарк устройств Умного Дома, да еще и DIY устройства. Стоит лишь купить "малинку", установить на нее Linux, потом поколдовать в командной строке, чтобы установить этот самый альтернативный Умный Дом, а потом еще потратить месяцы на настройку и понимание что вообще тут к чему.

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

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

Поэтому отсюда мое наблюдение: не стоит тащить и убеждать не готовых людей. Пусть каждый будет в комфортных для него условиях его личного выбора. И выбор этот нужно уважать.

Малинка против Intel NUC, Gigabyte BRIX и прочих x86

Итак, новоявленного строителя Умного Дома затащили на темную сторону OpenSouce и перед ним встает первый из ключевых вопросов: а на что мне все это хозяйство устанавливать?

Популярность использования платформы Rapberry Pi для сервера Умного Дома я могу объяснить лишь пресловутыми "исторически сложившимися причинами", а так же, не в последнюю очередь, мощью авторитета Алекса Квазиса и его YouTube канала.

При всех своих недостатках, "малинка" остается самой популярной платформой и поныне. А недостатки у нее серьезные:

1. Использование в качестве накопителя медленной и очень ненадежной SD карты

2. Необходимость в хорошем охлаждении

3. Склонность к троттлингу при недостаточно качественно обеспеченном питании

4. Слабый встроенный Bluetooth

5. Довольно слабая производительность ARM процессора, которой, впрочем, в большинстве случаев достаточен для систем Умного Дома

6. Важная для многих необходимость в приличном корпусе

Для устранения части этих недостатков потребуется покупка SSD или eMMC накопителя, мощного корпуса-радиатора, внешнего Bluetooth донгла, корпуса вроде Argon One. Все эти дополнительные покупки приводят к значительному удорожанию вашего сервера Умного Дома на базе "малинки".

И тут на авансцену выходят опытные члены сообщества с вполне резонным вопросом: А почему бы вам сразу не купить компактное, бесшумное и быстрое решение на базе гораздо более производительных процессоров x86 с встроенным SSD диском, расширяемой памятью? Ну, например, что-нибудь подходящее по цене из обширного семейства миниатюрных компьютеров Intel NUC или Gigabyte BRIX?

В действительности цены на подобные новые минисерверы довольно высоки и далеко не каждый будет готов потратится. Но на просторах интернет барахолок, вроде Avito, вполне можно найти приличные варианты за вменяемые деньги. Я, например, купил там немного устаревшую модель Gigabyte BRIX с процессором Celeron N3000, 4GB RAM, 120GB SSD и пассивным охлаждением всего за 5 тысяч рублей. И машинка эта прекрасно работает в круглосуточном режиме с HomeAssistant на борту вот уже больше года. Некоторые домовладельцы покупают на Авито даже подержанные HP Microserver Gen8 под свой домашний сервер, на котором, кроме системы Умного Дома, работает еще и медиасервер, торрент-качалка, NAS и что-нибудь еще. Многие используют в качестве сервера Умного Дома уже имеющиеся в хозяйстве NAS от Synology или реже Qnap с поддержкой Docker. Но в этом варианте много подводных камней, которые вызывают множество вопросов и дискуссий. Этот вариант сервера, на мой взгляд, подходит только уверенным пользователям Linux с достаточно глубокими знаниями Docker.

На мой взгляд, если говорить о сервере только для Умного Дома, наиболее целесообразным вариантом сейчас является использование миникомпьютеров на базе процессоров x86 (не Atom!). Это могут быть не обязательно Intel NUC или Gigabyte BRIX, а любой подходящий на базе Celeron и выше, и желательно с пассивным охлаждением, особенно для тех, кто строит Умный Дом в городской квартире и для кого уровень шума сервера является критическим параметром. Наличие именно SSD диска не обязательно, но крайне желательно для общего быстродействия. Памяти в большинстве случаев достаточно 2-4Gb. Подключать к сети такой сервер рекомендую по более надежному Ethernet, но и по WiFi 5Ггц у многих работает вполне стабильно.

Zigbee против WiFi (BLE mesh, Zwave, Thread пока не в счет)

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

У всех дома есть WiFi роутер и, как правило, Умный Дом начинает разрастаться за счет недорогих WiFi устройств от производителей вроде Sonoff, Yeelight, DIY устройств на базе ESP8266 и прочих. Действительно, WiFi прост, есть у всех, дополнительно что-то приобретать и настраивать не нужно. Отсюда в сообществе происходят иногда не то чтобы споры, но оживленные дискусси с основным посылом - зачем мне вообще этот ваш "зигбее" (варианты написания бывают порой очень забавными, "zig been" как-то попадался), мне и на WiFi хорошо и все отлично работает. Мне кажется это мнение происходит от недостаточно хорошего представления о преимуществах протокола Zigbee новичками. Давайте их перечислим:

• Низкое энергопотребление конечных устройств (где вы найдете WiFi датчик двери или, например, датчик движения, датчик протечки, который работал бы от батарейки годами?)

• Самоорганизующаяся Mesh сеть, в отличие от звездообразной WiFi сети, где роутер является центром звезды. Например, так выглядит моя домашняя Zigbee сеть, где хорошо видно, как устройства-роутеры (синие) являются точками подключения физически далеко расположенных устройств:

• Наличие класса конечных устройств-роутеров с постоянным питанием позволяет строить сеть на очень большой территории. Да, WiFi тоже умеет строить Mesh сети, но не с помощью исполнительных устройств-роутеров, а с помощью дополнительных WiFi роутеров подключенных в mesh сеть.

• Огромный выбор доступных устройств на рынке. На данный момент Zigbee Alliance насчитывает сотни членов, а на рынке существует тысячи разнообразных решений с заявленной поддержкой Zigbee.

• Безопасность. С 128-битным алгоритмом AES, используемым для шифрования данных и аутентификации, и тремя типами ключей, используемых для управления безопасностью, конечным пользователям не стоит беспокоиться об опасности взлома.

• Относительно низкие цены на устройства.

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

Лично для меня преимущества Zigbee очевидны и я строю свой Умный Дом почти полностью на этой технологии. Конечно, у меня еще есть несколько WiFi устройств, например, кондиционер управляемый WiFi USB стиком на ESP8266, датчик потребления фильтрованной воды на Wemos D1 mini, настольная лампа Yeelight. Среди активных сторонников Zigbee такой неоспоримый авторитет в сообществе, как Алекс Квазис, который в подкасте Спрута однозначно высказывался о преимуществах Zigbee перед Wifi. Кстати, кто не слышал подкаст, то рекомендую:

Если говорить о Zigbee дальше, то всплывает еще одна горячая тема: USB Zigbee стик, шлюз Xiaomi Gateway 3 (возможно перепрошитый Sonoff шлюз) или SLS использовать в качестве координатора сети Zigbee. Или еще одна, касающаяся пользователей HomeAssistant: что лучше, Zigbee2mqtt или ZHA? Это настолько объемные темы, что заслуживают отдельной статьи. Скажу лишь за себя - я за использование Zigbee USB стика в союзе с Zigbee2mqtt. В двух словах почему: стабильность, количество поддерживаемого оборудования, независимость от прихотей производителей шлюзов или SLS, при необходимости возможность самостоятельно обеспечить поддержку неподдерживаемого устройства с помощью zigbee2mqtt external converter. Но если вы уже имеете Xiaomi Gateway 3 шлюз и хотите использовать его в качестве координатора вашей Zigbee сети, а также, возможно и для BLE mesh сети, то очень рекомендую вам послушать подкаст с AlexxIT, авторитетнейшим участником сообщества и автором интеграции этого шлюза в HomeAssistant, чтобы узнать все нюансы из первых рук:

Говорить о распространенности других протоколов для Умного Дома можно, но на мой взгляд, пока рано. Отличный протокол Zwave живет своей жизнью уже очень давно, но из-за дороговизны устройств и географического разделения рабочих частот протокола мало распространен в русскоговорящем сообществе. Хотя есть пользователи очень давних реализаций Умных Домов на Vera или Homey, у которых осталось Zwave оборудование, например от Fibaro, и которые в рамках HomeAssistant, где поддержка этого протокола очень развита, успешно используют эти устройства и поныне.

Протокол BLE mesh выглядит очень многообещающим и поддерживается последними версиями шлюзов Xiaomi. Кроме того, явно заметно разделение направлений, если устройства для Умного Дома от Aqara практически все выпускаются для протокола Zigbee, то последние новинки от Xiaomi выпускаются почти исключительно для BLE mesh. И уже сейчас вполне реально активно использовать этот протокол, покупая доступные на рынке устройства.

Что касается протокола Thread, то его в последнее время стали продвигать в Apple, включив его поддержку в HomePod Mini и новой версии AppleTV. Солидные производители вроде Eve или Nanoleaf тоже стали включать поддержку Thread в своих новых устройствах. Я думаю, маркетинговая мощь Apple может продвинуть популярность этого протокола достаточно далеко и стоит не упускать из вида этот очевидный тренд.

Но пока протокол Zigbee в Умных Домах безусловно доминирует. И меня это устраивает. Я за Zigbee, как самое сбалансированное решение на рынке на данный момент.

Красивый GUI против текстовых конфигов и чистых автоматизаций

Это очень обширная тема со множеством ответвлений и нюансов. Постараюсь быть кратким и замечу, что в моем изложении она больше относится к HomeAssistant, как к системе Умного Дома, которую я использую. В целом, эта горячая тема подразделяется на следующие два больших направления:

• Как настраивать систему и писать автоматизации - через предоставленные возможности GUI или редактированием текстовых файлов конфигураций?

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

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

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

alias: Kitchen Lighttrigger:  - platform: state    entity_id: binary_sensor.kitchen_motion_group    to: 'on'  - platform: state    entity_id: binary_sensor.kitchen_motion_group    to: 'off'    for: '00:02:03'condition: []action:  - choose:      - conditions:          - condition: template            value_template: '{{ trigger.to_state.state == "on" }}'          - condition: time            after: '09:20'            before: '23:00'          - condition: numeric_state            entity_id: sensor.lux_kitchen_illuminance_lux            below: '23'        sequence:          - service: switch.turn_on            target:              entity_id:                - switch.relay_switch_l1                - switch.relay_switch_l2                - switch.switch_kitchen_switch_center          - service: light.turn_on            data:              transition: 4              color_name: crimson            target:              entity_id: light.led_strip      - conditions:          - condition: template            value_template: '{{ trigger.to_state.state == "off" }}'          - condition: time            before: '23:40'            after: '09:20'        sequence:          - service: switch.turn_off            target:              entity_id:                - switch.relay_switch_l1                - switch.relay_switch_l2                - switch.switch_kitchen_switch_center                - switch.switch_kitchen_switch_right                - switch.switch_kitchen_switch_left          - service: light.turn_off            target:              entity_id: light.led_strip      - conditions:          - condition: template            value_template: '{{ trigger.to_state.state == "on" }}'          - condition: time            after: '01:00'            before: '05:30'        sequence:          - service: switch.turn_on            target:              entity_id: switch.relay_switch_l2      - conditions:          - condition: template            value_template: '{{ trigger.to_state.state == "off" }}'          - condition: time            after: '01:00'            before: '05:30'        sequence:          - service: switch.turn_off            target:              entity_id: switch.relay_switch_l2    default: []mode: single

Но с другой стороны, эту же автоматизацию можно собрать в GUI автоматизаций HomeAssistant. А в последних версиях еще и появилась возможность визуального дебага автоматизаций в GUI:

Таким образом, по этому пункту, я бы посоветовал начинающим следующее. Попробуйте совмещать оба способа при написании автоматизаций, благо интерфейс теперь это позволяет. Пробуйте составить ее через GUI, потом переключитесь в текстовый режим и поправьте что нужно в нем. Или наоборот, скопипастите готовый yaml код автоматизации и затем переключившись в режим GUI попробуйте понять логику его работы, подставьте свои нужные сущности. На мой взгляд, сочетание обоих режимов при создании автоматизаций сейчас наиболее эффективный и оптимальный подход. Также не следует забывать об очень интересной недавней фиче в автоматизациях HomeAssistant: Blueprints, или готовых шаблонах автоматизаций.

Второй пункт нашего списка касается опять HomeAssistant и настройке его интерфейса Lovelace. Да, сейчас его можно настраивать исключительно средствами интерфейса, предоставленного HomeAssistant и не думать о правке вручную файла ui-lovelace.yaml в режиме Lovelace "yaml", как было в уроках Квазиса. Но лично я предпочитаю ручную полировку интерфейса. Весь интерфейс моих дашбордов как для десктопа, так и для мобильных устройств полностью написаны вручную. Сделать два разных дашборда очень просто, достаточно в configuration.yaml прописать что-то вроде:

lovelace:  mode: yaml  resources:  - url: /hacsfiles/mini-graph-card/mini-graph-card-bundle.js    type: module  - url: /hacsfiles/mini-media-player/mini-media-player-bundle.js    type: module  - url: /hacsfiles/ha-yandex-icons/yandex-icons.js    type: module  - url: /hacsfiles/lovelace-card-mod/card-mod.js    type: module  - url: /hacsfiles/lovelace-auto-entities/auto-entities.js    type: module  - url: /hacsfiles/button-card/button-card.js    type: module  - url: /hacsfiles/vertical-stack-in-card/vertical-stack-in-card.js?v=0.4.0    type: module  - url: /hacsfiles/simple-thermostat/simple-thermostat.js    type: module  - url: /hacsfiles/simple-weather-card/simple-weather-card-bundle.js    type: module  - url: /hacsfiles/text-element/text-element.js    type: module  dashboards:    lovelace-generated: # Needs to contain a hyphen (-)      mode: yaml      filename: mobile-ui.yaml      title: Mobile UI      icon: mdi:cellphone-text      show_in_sidebar: true      require_admin: true

и уже в файле mobile-ui.yaml конфигурировать ваш отдельный Lovelace для мобилок. Для десктопа мой интерфейс сейчас выглядит примерно вот так:

Для мобильных устройств примерно так:

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

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

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

HomeAssistant против Node Red. Или вместе с ним.

Эта тема характерна для споров между уже опытными и продвинутыми строителями Умных Домов, Бань, Дач и Сараек. Она не так остра и популярна, но написать о ней мне все же хочется. Хочется, потому, что когда-то этой теме было посвящено немало споров в уютном лампово-теплом сообществе телеграм чата Homever.

Скажу сразу, я попробовал Node Red и он мне не зашел. Визуальное создание автоматизаций перетаскиванием и связыванием каких-то прямоугольников различного назначения лично мне не показалось удобным и интуитивным. Мне гораздо проще и понятнее описывать автоматизации текстом, в yaml, в HomeAssistant. В общем, опыт с Node Red у меня небольшой, судить о нем авторитетно я не могу. Я запустил и отладил несколько флоу, но не более того.

Но тем не менее, я могу поговорить о чем спорят и говорят на эту тему в сообществе. А говорят следующее. Node Red может быть совершенно самостоятельной системой Умного Дома, с интеграцией устройств, собственным дашбордом, ну и конечно, собственными мощными автоматизациями. Также Node Red может работать в тесной связке с HomeAssistant выступая системой автоматизации для него. То есть вы подключаете устройства через HomeAssistant, который позволяет это сделать намного эффективнее, чем Node Red, и поддерживает гораздо больше интеграций для подключения огромного количества всевозможных устройств, но все автоматизации для этих подключенных устройств и сущностей вы создаете средствами подключенного Node Red.

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

Таким образом, целесообразность такой связки двух систем мне кажется избыточной и нерациональной хотя бы с точки зрения стабильности. Каждая из этих двух систем вполне самодостаточна, разве что в Node Red нет такого красивого интерфейса, как в HomeAssistant. Но это важно далеко не всем. Ну и возможности подключения огромного разнообразия устройств у Node Red значительно скромнее. Для чего нужен конгломерат двух серьезных и мощных систем, мне непонятно. Знаю пользователей таких симбиозов, которые используют подключения устройств и там и там, да еще и автоматизации создают средствами обоих систем. Представляете, какая каша из сущностей и связей там образуется? Надежность и стабильность такой связки двух систем вызывает у меня большие сомнения.

Мое мнение: максимально глубоко изучите возможности Node Red или HomeAssistant и используйте что-то одно. Каждая из этих систем в отдельности способна полностью удовлетворить все ваши требования к Умному Дому. Хотя, с другой стороны, я могу понять тех, кто имеет устройства, которые не поддерживаются в Node Red, но подключаются в HomeAssistant и он используется в качестве некоей прослойки для проброса подобных устройств в Node Red, а также, возможно, для красивых дашбордов для настенных панелей в виде вмонтированного планшета, например.

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

Заключение

На самом деле я затронул лишь малую часть горячих тем в сообществах строителей Умных Домов. Их гораздо больше по самому широкому кругу вопросов. Например, есть популярная тема о том, что лучше и надежнее - проводное или беспроводное подключение устройств? Или тема о том, каким воспользоваться способом для настройки подключения SSL сертификатов и проброса HomeAssistant наружу в интернет.

Если вас интересует тема Умных Домов и вы готовы погрузиться в нее с головой, подписывайтесь на профильные телеграм чаты по HomeAssistant, этот, или этот. На чат обо всем, касающемся темы Zigbee. На персональный канал большого авторитета Ивана Бессарабова, где найдете кладезь полезной информации. Ну и на упомянутый выше ламповый чат сообщества Homever

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

Доброго всем дня! В предыдущей части я представил на суд свою реализацию избитой идеи подсветки лестничного марша. Статья касалась только "железной" части проекта. В этот раз постараюсь описать процесс "оживления" сего девайса. Процесс получился достаточно затяжной, поскольку проект ведется "в свободное от основной работы время" с перерывами и явно проигрывает по важности прочим домашним делам :). Доработка ведется и сейчас, но уже есть, что показать.

Среда разработки

Пусть меня закидают грязными тряпками, но тут для меня однозначно лучшая - Keil uVision (4)5. Эта одна из самых мощных IDE для большого количества камней. Я даже не буду агитировать за нее и описывать все преимущества, поскольку мое мнение в данном вопросе крайне предвзято. Просто я давно работаю с этой IDE и она мне нравится. Самый большой ее минус - она платная и стоит очень конских денег. Но только не в данном случае. На наше счастье у Keil есть демо режим с ограничением в 32Кб. А в LPC11C14 всего 32Кб! Получается для этого камня можно вполне легально и полноценно использовать этот мощный инструмент! Достаточно скачать его с официального сайта. Заполняем простую анкету и получаем ссылку на скачку.

Остался открытым вопрос работы с "железом". Самый удобный - это использовать заводской программатор. Keil поддерживает большое количество отладочных систем и JTAG адаптеров. Такой подход позволит вести полноценную отладку проекта. А что делать, если нет отладчика\программатора и требуется только прошить контроллер? А на этот случай есть замечательная утилита Flash Magic, которая позволяет оживить устройство, используя вшитый в ARM загрузчик. Данная утилита работает только с контроллерами NXP. Загрузка происходит через UART. Эта замечательная прога не раз выручала меня в командировках, когда под рукой не было программатора или он выходил из строя. Замечу, что все необходимые сигналы у девайса уже выведены на разъем для программирования. Ссылка для скачивания Flash Magic здесь.

Сборка платы

Долго ли, коротко ли шли платы из Поднебесной, но вот они у меня на столе.

Монтаж не заставил себя долго ждать и вот что получилось в результате:

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

Подготовка софта

По началу тут было всё относительно просто. Пишем\адаптируем все необходимые драйверы для периферии, а именно:

• драйвер датчика освещенности MAX44009EDT

• драйвер датчика расстояния VL53L0X

• драйвер управления адресной лентой

• драйвер CAN интерфейса

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

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

Здесь хотел сделать небольшое техническое отступление, поскольку хронологически событие, с которым оно связано, именно здесь и наступило. Я раньше не работал с компонентами из ближайшего магазина и цели максимально снизить стоимость у меня на работе не стоит. Спрос идет за качество. А тут я в полной мере ощутил что значит "китайское электричество до конца не изучено". Просто все работало - работало, а в один не очень прекрасный день вдруг перестало. Причина была выявлена очень быстро. Сгорел линейный стабилизатор AMS1117-5.0. И не просто сгорел сам и все, а прикинулся перемычкой и утащил с собой всех, кто на него надеялся. Цензурных слов у меня в тот момент не было. Я, как человек, привыкший доверять техническому описанию на компоненты не мог понять, что не так. Стабилизатор работал в штатном режиме. А фраза из описания "The AMS1117 series have internal power and thermal limiting circuitry designed to protect the device under overload conditions" уже была похожа на издевку. Немного полазив по просторам инета я понял, что не у меня одного такие проблемы с этим стабилизатором. А что вы хотите? Дешево! Какой спрос? Короче, не имея никакого желания заново перепаивать половину схемы я поставил годами проверенный вариант - LM1117-5.0 (кстати, не в Чип-Дипе купленный). На мое счастье он встал на плату как родной.

Ну да ладно, плата восстановлена, можно двигаться дальше.

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

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

• в темноте светится дежурная подсветка (первая ступень)

• при пересечении датчика плавно разгорается центральная полоса подсветки вдоль всего пролета лестницы (видим линию по центру вдоль пролета)

• как только линия вдоль пролета разгорелась, она разделяется на две, которые расходятся в стороны (посадочные огни вдоль полосы)

• между этими огнями начинает плавно по очереди разгораться подсветка ступеней

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

Что-же потребуется для реализации?

Чисто технически вся подсветка пролета - это один длинный кусок ленты, просто разбитый на фрагменты (ступени). А поскольку по ленте бегают достаточно быстрые управляющие сигналы, для того, чтобы не было проблем с восприятием приказов, необходимо сделать мостики между лентами максимально короткими. Да и еще крайне желательно мостики эти выполнить из витой пары:

Для того, чтобы выполнить вышеописанные условия ленту пришлось уложить "змейкой".

Кроме этого необходимо не забыть, что потребление сего чуда достаточно большое и питание каждого фрагмента (ступени) желательно сделать индивидуальным.

Для того, чтобы проще было "рисовать" на таком "экране" и не требовалось каждый раз вычислять положение нужной LED-точки в программе подготавливается массив, содержащий "карту" их расположения:

// создание карты светодиодов (см. файл LED-карты)void CREATE_LEDS_MAP (void){static const uint8_t stepPerStair = STAIRS_NUM;static const uint8_t ledsPerStep = LEDGROUPS_FOR_STAIR;for (uint8_t step = 0; step < stepPerStair; step++){for (uint8_t led = 0; led < ledsPerStep; led++){if (step % 2 == 0){LedMap[led][step] = ((step) * ledsPerStep) + led + 1;            }            else            {LedMap[led][step] = ((step + 1) * ledsPerStep) - led;            }        }    }}

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

В качестве заключения

Я постарался описать всё, что происходило в процессе разработки сего девайса, кроме собственно жирной точки в виде финального видео. Никак не доходят руки смонтировать все непосредственно на лестнице (да и лестница, мягко говоря, пока не оформлена). Просто я решил больше не затягивать, а показать то, что есть пока проект не затянуло в болото. Если кому интересно выкладываю рабочие файлы:

Печатная плата

Программа

P.S. Если у кого-то будет желание доделать или внести что-то свое могу отдать два комплекта пустышек (по комплекту на лестницу) и процы к ним (как помните, у меня их много).

Привет, Хабр! Говорят, лень - это двигатель прогресса. Но никто не говорил, что этот самый двигатель, будет быстрым. Моя история о том, как я делал визуализацию голосового помощника Алисы с эффектом голограммы из подручных материалов.

Вступление

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

Например, у меня есть робот голосовой помощник "Vector" от Anki (сейчас им владеет Digital Dream Labs). Он отлично передает эмоции (радость, огорчение, злость и т.д.), когда с ним взаимодействуешь. Но его проблема в том, что программная часть голосового помощника Vector очень слабая по сравнению с такими гигантами как Alexa, Google Assistant, Siri, Алиса.

Недавно Яндекс выпустил умную колонку Яндекс.Станция Макс с LED-дисплеем. Через дисплей, голосовой помощник "Алиса" дополняет свои ответы анимацией и выражает "эмоции". И это уже хороший шаг в сторону визуализации голосового помощника, но все равно этого недостаточно для меня.

Бороздя просторы интернета во время всеобщего карантина, я увидел пост о том, как Джарем Арчер сделал рабочий концепт голограммы голосового помощника Cortana от Microsoft. Я вдохновился этой идеей и захотел это повторить, только вместо Кортаны, взять Алису от Яндекса.

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

• Старый монитор c TFT матрицей (BenQ GW2750HM)

• Старый ноутбук (core 2 duo p7350, GeForce 9300M, 4Gb RAM)

• 3D-принтер (Tevo Tarantula 2017)

• RGB-светодиодная лента

• Arduino Nano

Корпус

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

Модель делал в Autodesk Fusion 360. Сама модель состоит из нескольких частей и ее, в теории, можно сделать под любой размер монитора.

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

3D печать

Для печати корпуса выбрал ABS пластик т.к. он прочный и легко поддается обработке. Но есть и минусы: дико воняет и сильно чувствителен к сквозняку. На печать всех компонентов ушло дней 5 почти непрерывного печатания. Поэтому запах в доме еще долго не мог уйти.

Печатал первый раз и из-за того, что 3D-принтер был без внешнего корпуса, а дома был сквозняк, некоторые детали были с сильным браком и пришлось мастерить внешний корпус принтера из того, что было дома (спортивный коврик и полотенце). После этого детали стали немного лучше, но все равно были косяки, которые были терпимыми.

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

Эффект голограммы

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

У стекла есть эффект раздвоения изображения (особенно, если стекло толстое), когда изображение отображается на передней и задней стороне стекла. Чтобы это убрать, с обратной стороны наклеил антибликовую пленку.

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

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

Программная часть

Программная часть состоит из четырех частей: официальный, но уже устаревший desktop-клиент Алисы, Python-сервис для обработки сообщений, приложение на Unity для отображения модели и Arduino Nano для управления светодиодной лентой.

Общий принцип работы визуализации следующий: клиент Алисы передает текст команды от пользователя и ответ на Python-сервис. После обработки данных, сервис отправляет команду на вызов той или иной анимации в приложении на Unity и команды для управления светодиодной лентой на Arduino.

Чтобы перехватить запросы в клиенте Алисы, использовал реверс-инжиниринг. Для этого взял старую версию клиента Алисы. Данная версия работает на JS, но исходники были обработаны обфускатором, поэтому пришлось долго искать места, где можно перехватить команды. После этого вставил вызовы API моего сервиса для передачи данных.

После того, как сервис получил данные из клиента, он их обрабатывает. В зависимости от того, какие данные пришли, отправляет по MQTT сообщения: состояние (например, Алиса начала слушать пользователя), текст ответа на запрос и изображение ответа. Если с состоянием и текстом сообщения все легко и в сервис приходит простой JSON, то с изображением не так просто. Внутри клиента Алисы изображения строятся на основе сложного JSON, который приходит от сервиса Яндекса. Его нужно было бы обрабатывать и создавать изображение самому, а т.к. я ленивый человек, решил отправлять то, что клиент Алисы сам формирует (HTML блок + CSS). Далее сервис вставляет HTML блок в запущенный заранее веб-драйвер Chrome, делает скриншот и отправляет в MQTT JSON сообщение с изображением в Base64, высотой и шириной изображения для сохранения пропорций в Unity. Для включения/выключения светодиодной ленты, сервис отправляет по Serial порту сообщение/команду в Arduino, выбирая какую область (светодиод над моделью и/или заднюю и нижнюю светодиодную ленту) включить с каким RGB цветом и яркостью.

Есть еще одна функция. Клиент Алисы периодически опрашивает сервис на наличие новых команд для неё. Если есть новая команда, то клиент выполняет её таким образом, как это сделал бы пользователь через голос или текст. Например, если дать команду: "Алиса, повтори за мной: Перед уходом, не забудь покормить кота", то эту фразу она и повторит. Таким образом можно оповещать состояние датчиков.

Приложение на Unity принимает сообщения с MQTT для запуска анимации и отображения текста/изображения на специальных панелях. Модель отображают три камеры (каждое изображение попадает на свое стекло), на которых применен эффект "зеркала", чтобы после проецирования на стекло пользователь видел корректное изображение модели и текста.

Т.к. голос Алисы бы сделан на основе голоса Татьяны Шитовой, которая озвучивает большинство героинь Скарлетт Йоханссон, то для модели Алисы я взял образ персонажа из комиксов Marvel "Черная вдова", что дало визуализации свой "шарм". Саму 3D-модель я взял из открытого доступа, а скелет и его анимацию сделал в Blender, визуальный эффект голограммы был применен на модели в самой Unity.

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

Заключение

Огромное спасибо моей жене! Без её помощи, поддержки и терпения я бы забросил эту идею с самого начала.

Еще есть что доделать. Например, можно было добавить камеру, чтобы отслеживать лицо пользователя и "поворачивать" модель к пользователю для усиления эффекта голограммы, прикрутив к сервису OpenCV и отправку в MQTT значений поворота модели, но USB камеры нет.

Из минусов, найденных при эксплуатации:

1. У меня настроена система "Умный дом", через Home Assistant. На нем работают как свои устройства (на esp8266/Arduino), так и производителей (в основном от Xiaomi). Когда я начал делать этот проект, то была возможность управлять всеми устройствами через Алису. И можно было бы не использовать Яндекс.Станцию мини, но в какой-то момент Алиса в клиенте перестала находить эти устройства, хотя управлять ими через станцию все еще можно. Скорее всего поменяли API, поэтому перестало работать, но есть идеи как это можно исправить

2. Плохая идея использовать монитор с TFT матрицей

Еще нашел необычное применение для такого устройства: вместо Алисы, отображать время или таймер до какого-то события с включенной подсветкой.

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

Учтя всю критику и советы в первой статье, я решил питать светодиодные ленты в светильниках от специализированного драйвера. В качества драйвера был выбран драйвер фирмы Mean Well LDH-45B-350. Этот драйвер можно питать напряжением в широких пределах от 18 до 32 вольт. Я для питания приобрёл блок той же фирмы что и сами драйверы Mean Well LRS-100-24.

Небольшое отступление.

Скажу, что я немного разочаровался в этих блоках питания, да и драйверах, думал солидная фирма, всё должно быть так сказать по красоте и работать без нареканий, но на деле всё оказалось вообще не так. Блоки покупал в интернет магазине Чип и Дип, думал что никаких проблем не будет, солидный магазин, солидная фирма, должно всё работать идеально долгие годы. Но по факту первый звоночек я получил ещё когда собирался питать светодиодные ленты постоянным стабилизированным напряжением используя для этого 2 минвеловских блока питания соединённых последовательно LRS-50-24 и LRS-50-36.
Уже тогда я заметил, что эти блоки гудят при определённой частоте ШИМ. То есть регулировку яркости ленты я делал с помощью ШИМ и полевого транзистора IRF520N. Думал, может что-то не так рассчитал, не такой транзистор поставил и проблема в моём ШИМ, который как-то влияет на блок и заставляет его пищать. Но оказалось ни фига подобного, когда я уже потом к одному блоку, а именно к LRS-50-24 подключил указанный выше светодиодный драйвер, при определённой яркости этот блок всё равно начинал пищать. Тогда я решил купить блок помощнее на 100 ватт, вот он уже с этими драйверами вроде как перестал пищать или пищит, но гораздо тише чем 50-ти ваттный. В общем хочу всех предостеречь и посоветовать покупать блоки помощнее, c двойным, а то и тройным запасом по мощности. Я может даже куплю и поставлю блок на 150 ватт LRS-150-24. Хотя 3 моих светодиодных светильника потребляют в сумме 60 ватт. Но блок придётся покупать с более чем двойным запасом, чтобы не пищал и не гудел. Причём как уже сказал, пищат оба моих 50-ти ваттных блока и на 24 вольта и на 36 вольт. То есть, вряд ли это мне 1 такой из тысячи попался который гудит. А вот 100 ваттный вроде как и не гудит, или гудит, но гораздо тише. В общем даже если он и гудит, то этот уровень гудения меня устраивает, в отличии от 50-ти ваттных, они гудят довольно сильно.

Второй косяк который всплыл оказался в светодиодном драйвере. При уменьшении яркости с помощью ШИМ, 2 светильника переставали светить, а вот 1 светил. Проблема оказалось в том, что один из драйверов выдавал большее напряжение на выходе чем остальные. Естественно такая ерунда меня не устраивала, когда 2 светильника не горят, а один ещё светит, пусть и очень-очень тускло, я хочу сделать всё идеально, поэтому решил его обменять, но я уже впаял его в плату, пришлось выпаивать, а я ненавижу (хотя и могу) выпаивать детальки у которых больше чем 4 ножки, и ножки которых разнесены на несколько сантиметров друг от друга. Выпаять я конечно выпаял, аккуратно, не перегрев и не повредив ни плату, ни драйвер, но удовольствие такое занятие мне не доставляет, и покупая драйверы этой фирмы, я даже не подозревал что мне придётся их когда либо выпаивать, и уж тем более не думал, что придётся выпаивать сразу же, потому что один оказался бракованный. Причём он в принципе работал хорошо, до определённого понижения яркости, и перед впаиванием в плату, я как человек ОЧЕНЬ подозрительный их всё же проверял, но не на всём диапазоне яркости, и не очень досконально. Вот и оказалось, что при очень низкой яркости, когда уже все светильники не светили, один все же светил. Так что опять хочу предостеречь тех, кто будет покупать такие драйверы, и тем более платочный вариант. Лучше перед впаиванием сразу досконально проверить каждый драйвер, померить напряжение которое он выдаёт на максимуме и минимуме, ну и в середине диапазонов, в идеале вообще проверять всё со всеми подключаемыми светильниками которые должны работать синхронно.

Ну и ещё одна проблема прежде чем вернусь к самой теме статьи. Знаете сколько мне менял ЧИП ДИП драйвер который стоит 10$ ? 1/12 ГОДА! 1 месяц! Охренеть конечно сервис, а если бы это ни дача была, которую я только делаю, где могу месяц и подождать, тем более у меня в комнате 3 таких драйвера и соответственно 3 светильника, и 2 светят, то есть свет в комнате есть, а например в квартире, и светильников в комнате было бы не 3 как у меня, а один. Драйвера нет, получается освещения в комнате нет. Если всё заточено под драйвер, и человек не предусмотрел возможности быстренько переделать и пустить по этим проводам 220 вольт и поставить обычную лампочку в случае чего. Сиди месяц без света, пока ЧИП ДИП будет проводить экспертизу твоего драйвера, цена которому 10$. В общем это печально, такого от ЧИП ДИП я не ожидал.

В общем вот такие проблемы с блоками и драйверами. Подытожу:
1) некоторые (скорее всего маломощные) блоки питания Mean Well гудят (ну или могут гудеть);
2) из 6 драйверов 1 оказался бракованный, ЧИП ДИП это признал и поменял на новый;
3) экспертиза и обмен товара в ЧИП ДИП может занять около 1 месяца и даже немного больше 30 дней, может в самой Москве это было бы и быстрее, но из РБ города Гомель, отправка на экспертизу в Москву, потом отправка обратно нового товара. В общем я ждал более 30 дней прежде чем получил новый драйвер!

Ну да ладно, а теперь самое интересно.

Плата LED драйверов

Для светодиодных драйверов LDH-45B-350 была изготовлена плата со следующей схемой:

Шаблон (маска) платы размерами 186 х 76 мм:

Ну и фото того что получилось в итоге:

Чёрная гребёнка подключается к моей универсальной плате управления со 128 мегой о которой я писал в этой статье . А вот с помощью синих разъёмов, выводы PWM DIM соединяются вместе, и через резистор на 10К подключаются к выводам DIM -. Почему я не стал это соединение и сам резистор делать сразу на плате на постоянно, да потому что в будущем, возможно, я сделаю независимое включение/выключение каждого светильника, а может даже и независимую регулировку яркости, если придумаю простой интерфейс управления всем этим великолепием. Если всё будет очень сложно управляться, то колхоз с кучей кнопок и выключателей я делать конечно же не буду. Пока все светильники включаются синхронно и яркость регулируется также синхронно, но заложена возможность дальнейшей переделки на полностью независимое включение/выключение светильников, и может даже независимую регулировку яркости. В общем посмотрим. Независимое включение/выключение каждого светильника точно сделаю, даже уже придумал простой интерфейс управления, чтобы на стене не нужно было делать кучу выключателей. Будет только 1 выключатель и энкодер для управления яркостью, а поскольку на стене будет ещё и дисплей из матриц, показывающий яркость освещения, вот с помощью него и энкодера и будет сделан интерфейс для возможность выключения каждого светильника по отдельности.

Плата матриц

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

Схема платы с матрицами:

Шаблон (маска) платы матриц размерами 105 х 62 мм:

Ну и фото того что получилось:

Плата управления матрицами

Ну и для управления платой матриц, надо изготовить плату управления матрицами.
Схема её следующая:

Шаблон (маска) платы управления матрицами, размерами 105 х 52 мм:

Ну и то фото того что получилось:

Плата матриц с платой управления

Демонстрация работы дисплея

Поскольку мой дисплей состоит из 3 матриц, а каждая матрица 8 на 8 точек, то общая длинна дисплея получается 24 столбца. Максимальное количество символов на экране 4, это когда будет светиться 100%. Поэтому каждый символ будет занимать 6 столбцов (5 столбцов на сам символ + пустой столбец для отделения символов друг от друга).

Как многие поняли из видео, регулировка яркости у меня будет ступенчатая с шагом в 5%. Изменяться она будет энкодером. Всего будет 20 фиксированных значений яркости от 0 до 100%.

Осталось собрать всё это воедино и готово!

Резервированные источники питания используются повсеместно. Они обеспечивают бесперебойным электропитанием приборы охранной и пожарной сигнализации, оборудование систем контроля доступа и другие системы. На нашем предприятии в качестве таких источников, как правило, используются приборы от ЗАО НВП Болид. У некоторых из них, как, например, у РИП-12-6/80M3-R-RS, имеется интерфейс RS485, что позволяет включать их в систему мониторинга.

Средства мониторинга

Мы используем Zabbix 5.2. Получать данные от РИП будем по протоколу Modbus RTU over TCP. Поддержка этого протокола реализована в Zabbix с помощью загружаемого модуля libzbxmodbus. Также в процессе мониторинга принимают участие преобразователь протокола C2000-ПП (вер. 1,32) в режиме Master и преобразователь последовательных интерфейсов (RS485 в Ethernet).

Объекты мониторинга

Для начала определимся, что конкретно мы сможем контролировать. Из документации к РИП-12-6/80M3-R-RS и С2000-ПП выяснилось, что рассчитывать мы можем на получение состояния семи зон (ШС) и числовых значений тока и напряжения. В ходе экспериментов мне удалось воспроизвести следующие состояния ШС:

ШС 0 Состояние прибора

ШС 1 Выходное напряжение

ШС 2 Ток нагрузки

ШС 3 и ШС 4 Напряжение на батарее 1 и 2 соответственно

ШС 5 Степень заряда батарей

ШС 6 Напряжение сети

Крайне вероятно, что мной была получена только часть из всех возможных состояний. Например, имеются догадки, что ШС 3 и 4 должны также иметь состояние [204] Необходимо обслуживание, а ШС 0 - состояние [203] Сброс прибора и другие. К сожалению, чтение документации ситуацию не прояснило. В связи с этим нам необходимо следить и реагировать на появление событий, которые мы не предусмотрели.

Конфигурирование устройств

Не будем долго останавливаться на процессе конфигурирования приборов, только коротко рассмотрим перечень необходимых действий. Настройка устройств Болид осуществляется при помощи утилиты UProg и имеет следующий порядок:

1. Назначение сетевых адресов всем устройствам (РИП и С2000-ПП),

2. Конфигурирование интерфейса интеграции С2000-ПП (Modbus RTU),

3. Добавление ШС, описанных выше, в таблицу зон С2000-ПП. Крайне важно, чтобы, во-первых, были добавлены все ШС, а во-вторых, ШС должны следовать друг за другом в порядке возрастания.

При заполнении таблицы зон следует помнить следующее:

• адрес прибора - сетевой адрес РИП, в нашем случае 126,

• номер ШС - номер ШС от 0 до 6,

• тип зоны - тип ШС, для ШС 0 назначаем тип зоны "3 - состояние прибора", для всех остальных - "8-РИП напряжение / ток".

Создаем шаблоны Zabbix

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

• мониторинг состояния ШС.

• мониторинг как состояния, так и числовых параметров РИП.

Мониторинг состояния ШС

Итак, создадим шаблон RIP 12 mod 56 RIP 12 6 80 M3 R RS. Шаблон имеет один элемент данных с именем Request и типом "Простая проверка". Ключом элемента является функция: modbus_read[{$MODBUS_PORT},{$MODBUS_SLAVE},{$STATUS_REG},3,7*uint16] . В параметрах функции используются значения макросов, которые позволяют составить корректный modbus запрос к C2000-ПП.

• {MODBUS_PORT} - тип используемого протокола (enc - Modbus RTU over TCP), адрес и порт преобразователя последовательных интерфейсов.

• {MODBUS_SLAVE} - Modbus UID С2000-ПП (настраивается в UProg на вкладке прибор).

• {STATUS_REG} - адрес регистра в котором расположен ШС 0 интересующего нас РИПа. Получить данный адрес можно следующим образом: "Номер зоны в таблице зон С2000-ПП" + 40000 - 1. В нашем примере это: 450+40000-1 = 40449.

Основная задача элемента Request - запросить у С2000-ПП значение всех семи ШС контролируемого РИП и предоставить их в формате JSON. Результирующий JSON содержит объекты, ключами которых являются адресы регистров С2000-ПП, а значениями - содержимое этих регистров:

{  "40449":39115,  "40450":51195,  "40451":50171,  "40452":51963,  "40453":51451,  "40454":50683,  "40455":763}

Зависимые элементы данных

Элемент данных Request имеет 7 зависимых элементов. Основная задача этих элементов - распарсить JSON и получить состояние каждого ШС индивидуально. Вот эти элементы:

• Status - состояние прибора (ШС 0),

• Uout - выходное напряжение (ШС 1),

• Iout - ток нагрузки (ШС 2),

• Ubat1 - напряжение АКБ1 (ШС 3),

• Ubat2 - напряжение АКБ2 (ШС 4),

• Capacity - степень заряда АКБ (ШС 5),

• Uin - напряжение сети (ШС 6).

Предобработка зависимых элементов данных

Чтобы получить состояние ШС 0 (Status), нам достаточно два шага предобработки. На первом шаге мы воспользуемся стандартным функционалом JSONPath, а затем разделим полученное значение на 256, тем самым получим код состояния.

К сожалению, мне не удалось использовать математические операции в параметрах JSONPath. Поэтому для оставшихся элементов данных пришлось использовать javascritpt-предобработку. Например, для элемента данных Iout (ШС 2) javascript-предобработка выглядит так:

function (value){    var reg = parseInt({$STATUS_REG})+2;    var data = JSON.parse(value);    return data[reg];}

Триггеры

После добавления триггеров создание шаблона можно считать завершенным. Перечень созданных триггеров:

1. Взлом корпуса прибора,

2. Перегрузка источника питания,

3. Отключение выходного напряжения,

4. Неисправность батареи АКБ1,

5. Неисправность батареи АКБ2,

6. АКБ1 разряжен,

7. АКБ2 разряжен,

8. Авария сети 220 В,

9. Потеряна связь с прибором,

10. Неизвестное состояние Status,

11. Неизвестное состояние Iout,

12. Неизвестное состояние Uout,

13. Неизвестное состояние АКБ1,

14. Неизвестное состояние АКБ2,

15. Неизвестное состояние Capacity,

16. Неизвестное состояние Uin,

17. Превышено время отсутствия по MODBUS.

Демонстрация и импорт RIP 12 mod 56 RIP 12 6 80 M3 R RS

Ссылки для импорта: Шаблон RIP 12 mod 56 RIP 12 6 80 M3 R RS, Преобразование значений RIP 12 mod 56 RIP 12 6 80 M3 R RS.

Мониторинг состояния и числовых параметров

Мониторинг числовых параметров имеет свои особенности. Все дело в том, что для получения числового значения нам необходимо сделать два modbus-запроса к С2000-ПП. Первый запрос устанавливает зону для запроса тока или напряжения, второй - непосредственное получение значения. В таком случае мы не имеем возможности использовать функционал libzbxmodbus, т.к. попросту не cможем гарантировать правильную очередность запросов.

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

В связи с вышесказанным, для этих целей было решено отказаться от использования libzbxmodbus и написать скрипт, который сможет предоставлять и числовые параметры РИП и состояния его ШС.

Пишем shell скрипт для внешней проверки

Для того, чтобы синхронизировать доступ к преобразователю последовательных интерфейсов, воспользуемся утилитой flock. Работу с Modbus будем осуществлять при помощи modpoll. В /usr/lib/zabbix/externalscripts создадим скрипт rip_12_mod_56.sh

#!/bin/bash# rip_12_mod_56.sh# $1 - protocol://host:port# $2 - Modbus UID# $3 - Status register# $4 - Offset (0 - 6)# Example of requesting statuses:       ./rip_12_mod_56.sh enc://127.0.0.1:4001 1 40000# Example value request:                ./rip_12_mod_56.sh enc://127.0.0.1:4001 1 40000 3(($# < 3)) && { printf '%s\n' "You have given little data. Command exited with non-zero"; exit 1; }lockfile=$(echo "$1" | awk -F "://" '{print $2}')setzone(){        modpoll -m $1 -a $4 -r 46181 -0 -1 -c 1 -p $3 $2 $5> /dev/null 2>&1    (($? != 0)) && { printf '%s\n' "Command exited with non-zero"; exit 1; }    sleep 0.15}getvalue (){        value=$(modpoll -m $1 -a $4 -r 46328 -0 -1 -c 1 -t 4:hex -p $3 $2 |grep ]: |awk '{print $2}')        printf "%d" $value}getstatus (){        status=$(modpoll -m $1 -a $4 -r $5 -1 -c 7 -t 4:hex -p $3 $2 | grep ]: | awk -F "0x" 'BEGIN { printf"["} NR!=7{printf "\""$2"\","} NR==7 {printf "\""$2"\""} END { printf "]"}')    echo "{ \"status\": $status }"}(        flock -e 200        protocol=$(echo $1 | awk -F "://" '{print $1}');        host=$(echo $1 | awk -F "://" '{print $2}' | awk -F ":" '{print $1}')        port=$(echo $1 | awk -F "://" '{print $2}' | awk -F ":" '{print $2}')        register=$(($3+1))        if (($# >= 4)); then                zone=$(($register+$4-40000))                setzone $protocol $host $port $2 $zone                echo $(getvalue $protocol $host $port $2)                sleep 0.15                exit 0        fi        echo $(getstatus $protocol $host $port $2 $register)        sleep 0.15;) 200> /tmp/$lockfile

Подробности настройки внешних проверок в Zabbix уточняйте в документации.

Создаем RIP 12 mod 56 RIP 12 6 80 M3 R RS EXTENDED

Для получения информации о состоянии ШС шаблон содержит элемент данных Request с типом "Внешняя проверка". Ключом элемента является скрипт: rip_12_mod_56.sh[{$MODBUS_PORT}, {$MODBUS_SLAVE}, {$STATUS_REG}]. Как и в шаблоне RIP 12 mod 56 RIP 12 6 80 M3 R RS, задача элемента Request - сформировать JSON с состояниями всех ШС.

Возвращаемый JSON оптимизирован для использования функционала JSONPath. Для упрощения скрипта значения возвращаются в шестнадцатеричной форме:

{  "status": ["98CB","C7FB","C3FB","CAFB","C8FB","C5FB","02FB"]}

Состояния ШС. Снова зависимые элементы данных.

Как и в предыдущем шаблоне, элемент данных Request имеет 7 зависимых элементов. Задача этих элементов тоже неизменна - распарсить JSON и получить состояние каждого ШС.

Получаем числовые значения

Для получения числовых значений создадим 5 элементов данных с типом "Внешняя проверка".

• Uout_value - значение выходного напряжения, В.

• Iout_value - значение выходного тока, А.

• Ubat1_value - значение напряжения на батарее 1, В.

• Ubat2_value - значение напряжения на батарее 2, В.

• Uin_value -значение напряжения сети, В.

Ключом этих элементов является скрипт: rip_12_mod_56.sh[{$MODBUS_PORT}, {$MODBUS_SLAVE}, {$STATUS_REG}, <НОМЕР ШС>].

Триггеры

Перечень триггеров не отличается от триггеров, созданных в шаблоне RIP 12 mod 56 RIP 12 6 80 M3 R RS.

Демонстрация и импорт RIP 12 mod 56 RIP 12 6 80 M3 R RS EXTENDED

Ссылки для импорта: Шаблон RIP 12 mod 56 RIP 12 6 80 M3 R RS EXTENDED, rip_12_mod_56.sh.

Вместо заключения

В своем мониторинге мы используем шаблон RIP 12 mod 56 RIP 12 6 80 M3 R RS. По-большому счету причина такого решения одна - расширяемость системы. Использование загружаемого модуля позволяет включать в одну линию приборы разных типов и модификаций, организовать их мониторинг стандартными средствами. Кроме этого, большой потребности в получении числовых значений у нас пока не возникало.

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

Спасибо за внимание!

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

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

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

Разумеется, в историческом соборе никто бы не дал прокладывать воздуховоды "под потолком" :)
Поэтому проработка решения началась не со стандартного инженерного проектирования, а математического моделирования движения воздушных масс и распределения температур внутри собора. Расчёты показали и низкие температуры со сквозняком у входных дверей; и низкую температуру воздуха в алтаре; и эффект стекания холодного воздуха из алтаря. Таким образом, было объективно подтверждено то, что ранее ощущалось просто как недостаток комфорта. Для исправления ситуации было предложено установить более мощные воздушно-тепловые завесы на входе и рассчитано дополнительное количество тепла для алтаря. Моделирование охлаждения собора в летний период показало, что при подаче охлажденного воздуха, в нижней части основного объема собора образуется холодная воздушная подушка. Воздушная подушка оказалась склонна к вытеканию из собора через открытые двери, для предотвращения этого было рекомендовано использовать воздушно-тепловые завесы в режиме отсечки. Кроме того, была проработана технология использования "воздуховодов 19 века", проложенных внутри кирпичных стен во время строительства собора.

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

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

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

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

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

Для контроля параметров воздушной среды в наиболее характерных местах установлены датчики температуры и влажности: четыре датчика по углам основного объема собора, два в алтаре, по одному у входов и еще два на самом верху, на барабане собора.

Четыре приточно-рециркуляционные установки и приточно-вытяжная установка подвальных помещений оборудованы щитами управления, каждая со своим контроллером автоматики, тепловые завесы и конвекторы в алтаре управляются еще двумя щитами, также установлен щит управления в ИТП. Контроллеры в щитах автоматики и контроллеры холодильных машин соединены сетью Bacnet/IP со SCADA системой на 5000 точек данных.

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

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

Авторы: Аржаников Ростислав, к.т.н.; Осовский Кирилл

В последних релизах Zabbix "из коробки" стал поддерживать некоторые популярные протоколы промышленного оборудования. Имея поддержку Modbus и MQTT, его использование с системами промышленной автоматизации стало чуточку проще. Но подобный подход к мониторингу такого рода оборудования не всегда возможен.

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

Для чего нам Zabbix

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

Взаимодействие с OPC серверами

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

Установка OpenOPC

Как было сказано ранее, речь идет о стандарте OPC DA, а значит, о технологии DCOM и, соответственно, ОС Windows. В нашем случае установка OpenOPC производилась на машину с Windows XP, где и находится проприетарный OPC сервер. После завершения установки необходимо добавить путь до opc.exe в системную переменную среды PATH.

Проверим работу утилиты. Для начала выведем в консоль список доступных OPC серверов:

C:\Users\Администратор> opc.exe -qMerz.OPC_SAIA_S-BUS.1C:\Users\Администратор>

Теперь попробуем получить теги в удобном нам формате - csv:

C:\Users\Администратор>opc.exe -o csv -s Merz.OPC_SAIA_S-BUS.1 ATP.Register.OAT ATP.Register.OAT,197,Good,05/24/21 07:16:15C:\Users\Администратор>opc.exe -o csv -s Merz.OPC_SAIA_S-BUS.1 ATP.Register.OAT ATP5.Register.T_inlet ATP5.Register.T_outletATP.Register.OAT,198,Good,05/24/21 07:16:41ATP5.Register.T_inlet,627,Good,05/24/21 07:16:41ATP5.Register.T_outlet,654,Good,05/24/21 07:16:41C:\Users\Администратор>

Если что-то пошло не так

В ходе экспериментов с opc.exe выяснились некоторые моменты. Первое: каждый OPC клиент запускал новую копию OPC сервера, а их параллельная работа невозможна. Так как запустить используемый нами OPC сервер как службу не получилось, то через DCOM был настроен запуск OPC сервера от определенного пользователя. Все OPC клиенты - SCADA и агент Zabbix - были также настроены на запуск от этого пользователя. Второе: выявлены некоторые недостатки в работе самого OpenOPC. Например, клиент не вычитывает теги, в названии которых присутствуют символы, отличающиеся от латинских. С этим пока пришлось смириться и решать такие проблемы путем переименования тегов в OPC сервере.

Установка Zabbix агента

На ту же машину установим Zabbix агент, который сможет работать под Windows XP, например, zabbix_agent-5.2.0-windows-i386-openssl.msi. Агент будет выполнять активные проверки. Чтобы облегчить дальнейшую конфигурация агента, во время установки заполним следующие поля:

• Ноst name - уникальное имя хоста, совпадающее с именем узла сети на Zabbix сервере.

• Zabbix server IP/DNS - IP-адреса Zabbix сервера.

• Server or Proxy for active checks - IP-адрес Zabbix сервера для активных проверок.

Конфигурирование Zabbix агента

В конфигурационный файл C:\Program Files\Zabbix Agent\zabbix_agentd.conf были внесены некоторые изменения.

1. Увеличено время выполнения скрипта.

   ### Option: Timeout#Spend no more than Timeout seconds on processing.## Mandatory: no# Range: 1-30# Default:# Timeout=3Timeout=30
   

2. Создан параметр для мониторинга.

   #User-defined parameter to monitor. There can be several user-defined parameters.#Format: UserParameter=<key>,<shell command>## Mandatory: no# Default:# UserParameter=UserParameter=opc[*],opc.exe -o csv -s $1 $2
   

Узел сети и элементы данных на сервере Zabbix

На Zabbix сервере создадим узел сети. Имя узла сети должно совпадать с Ноst name, указанном при установке агента, интерфейс - IP-адрес агента.

Далее к созданному узлу сети добавим элемент данных c типом Zabbix агент (активный). Ключом должна являться конструкция типа: opc[<ИМЯ OPC СЕРВЕРА>, <ЗАПРАШИВАЕМЕ ТЕГИ ЧЕРЕЗ ПРОБЕЛ>].

Значениями элемента данных будут строки, разделенные запятыми:

ATP2.Register.OAT,273,Good,05/24/21 15:21:33ATP2.Register.GVS.T_inlet_W,501,Good,05/24/21 15:21:33ATP2.Register.GVS.T_outlet_W,445,Good,05/24/21 15:21:33ATP2.Register.T_outlet_w_com,404,Good,05/24/21 15:21:33ATP2.Register.RAD.T_outlet_W,256,Good,05/24/21 15:21:33ATP2.Register.P_in_W_com,39,Good,05/24/21 15:21:33ATP2.Register.P_out_W_com,36,Good,05/24/21 15:21:33ATP2.Register.RAD.P_outlet_W,43,Good,05/24/21 15:21:33ATP2.Register.FIRE.P_gidrant,68,Good,05/24/21 15:21:33

Зависимые элементы данных

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

В предобработке используем JavaScript, который получит необходимую нам строку в CVS, проверит качество тега и вернет результат.

function (value){    var nr_line = 4;    var lines = value.split('\n');    var fields = lines[nr_line].split(',');    if(typeof fields[2] != "undefined" &&  fields[2] == "Good"){    return (typeof fields[1] != "undefined") ? fields[1] : null;    }    return null;}

Пример визуализации полученных данных:

Заключение

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

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

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

Какие задачи стояли

По итогам формализации пожеланий заказчика мы договорились, что нами, как инженерами, в данном проекте должны быть решены следующие задачи:

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

2. Обеспечить единое управление всем и вся с графического интерфейса

3. Построить слаботочные и ИТ системы. В частности WiFi, который работает везде :)

Как решали климат и его автоматика

Поддерживать влажность - это достаточно сложно. Экспоненциально сложно, если сравнить с бытовым кондеем, висящим на стеночке. И требует много инженерки. Чтобы получить точную влажность и температуру в помещениях была запроектирована вентмашина о четырёх секциях. Первая секция умеющая нагревать воздух, вторая - увлажнять, третья - охлаждать, а четвертая - снова догревать...

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

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

Система управления ("умный дом", или, если угодно - "умный особняк") в этом проекте была разделена на бэкенд (классическая система автоматизации/диспетчеризации на контроллерах Sauter) и фронт-енд (графический пользовательский интерфейс на базе ориентированных под это контроллеров Crestron; плюс сюда же задачи по управлению мультимедией). Общаются бэкенд и фроненд по сети по протоколу Bacnet/IP.

Более 600 датчиков (температуры, влажности, давления воздуха, движения); порядка 650 устройств, подключенных к выводам контроллеров (реле, приводов, клапанов, ...). Около 1600 переменных в SCADA системе. 53 контроллера автоматики и парочка контроллеров умного дома.

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

Умный дом

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

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

Также управление освещением продублировано с настенных выключателей. Особое внимание было уделено отказоустойчивости системы включение/выключение света будет возможно даже при выходе из строя контроллеров автоматики.

Дополнительной вишенкой на торте является система позиционирования, позволяющая в автоматическом режиме определять, в каком помещение находиться хозяин дома с главным, Master iPadом и выводить на экран планшета соответствующую страницу меню управления. С точки зрения техники, данный функционал реализован на Bluetooth BLE маячках (BLE PinPoint beacons), установленных по дому. При появления iPad в поле их действия, софт на iPadе сигнализирует о событии центральному контроллеру и получает команды на определенные действия. Никакие датчики в пользователя не встраиваются ;)

Изнутри это обеспечивают контроллеры Crestron. На них же возложено общение с мультимедиа устройствами.

ИТ системы

Для обеспечения доступа хозяев дома в интернет, а также для работы системы управления во всём комплексе зданий развёрнута единая сеть WiFi, позволяющая перемещаться по помещениям, сохраняя соединение. В том числе не прерывая разговора по голосовым мессенджерам. Учитывая сложную радиообстановку (толстые стены, крайне высокое затухание сигнала), сеть создана на базе аппаратного контроллера WiFi и нескольких десятков WiFi точек доступа. Штукатурная сетка, появившаяся после радиопланирования и радиообследования объекта - добавила сложностей. Но в итоге всё кончилось хорошо - нас не расстреляли :)

Также на объекте создана проводная сеть Ethernet, обеспечивающая подсоединение всего оборудования: контроллеров автоматики, точек доступа WiFi, аудио-видео оборудования, камер видеонаблюдения. Для увеличения надёжности система разбита на сегменты VLAN.

Система фонового озвучивания обеспечивает простое воспроизведение музыки как с устройств Apple (через беспроводное Wi-Fi подключение, с использованием технологии AirPlay), так и воспроизведение интернет радио, CD, MP3 в зонах бассейна, SPA и веранды.

Что можно было бы сделать лучше.

По итогам эксплуатации считаю, что надо было настоять на использовании специализированных тач-панелей от производителя системы управления. Используемые в качестве сенсорных пультов управления выделенные iPad'ы в долговременной перспективе требуют к себе больше внимания, чем хотелось бы. То, несмотря на все настройки, обновляться соберутся, то ещё что-нибудь придумают :)

И да, замечания к дизайну SCADA, полученные в комментариях к прошлой статье, мы приняли с благодарностью. Но этот проект был реализован немножко раньше предыдущей статьи и учесть в нём замечания не представлялось возможным ;)

Заключение

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

Автор Кирилл Осовский, komrus@yandex.ru

Этот бот был разработан для просмотра информации, находящейся на mqtt сервере внутри локальной сети. Он может работать на одном компьютере с mqtt сервером (в том числе на Raspberry PI или подобном) или отдельно. Задача удалённого управления не ставилась, только предоставление доступа к данным.

Протокол MQTT предназначен специально для использования в различных устройствах автоматики, на нём очень легко организовать телеметрию и сбор данных. Этот протокол поддерживают как "умные" бытовые устройства, так и многие промышленные контроллеры. Также есть множество проектов на ESP8266, ESP32 или подобных платформах.

На mqtt сервере публикуются данные телеметрии с различных датчиков - допустим, это метеостанция и термометры в теплицах. Для их просмотра на десктопе я раньше делал виджет, веб-страницу, потом захотелось иметь эти данные всегда под рукой. Конечно, можно было пробросить доступ к серверу наружу или разместить его в облаке, но тут возникает ещё целый ряд проблем. Тема использования бота в мессенджере для меня не новая - ещё пятнадцать лет назад я использовал ICQ клиента на мобильном телефоне, чтобы с помощью ICQRemote и скрипта на AutoIt переключать треки в Winamp на десктопе. Сейчас средний телефон гораздо мощнее того десктопа и имеет почти столько же постоянной памяти, но проблема внешнего подключения к устройству в локальной сети по-прежнему существует. И боты всё так же отлично справляются с решением этой проблемы. В общем, было решено делать Телеграм-бота, который просто предоставляет по запросу необходимую информацию.

Я не буду рассказывать про регистрацию имени бота и получение токена, так как это всё уже есть в каждой предыдущей статье про телеграм-ботов. Перейду сразу к программе на Python. Она разрабатывалась под Windows, но я не вижу препятствий для её запуска под другими системами - используемые библиотеки python-telegram-bot и paho-mqtt это позволяют.

Настройки программы хранятся в ini файле. В секции TELEGRAM прописывается токен для бота, в секции MQTT адрес и логин/пароль mqtt сервера, а также топик для получения данных (если несколько - через запятую, без пробелов). При запуске бот подключается к mqtt серверу и подписывается на необходимые топики. Глубина вложенности уровней может быть любой. Поступающие данные попадают в словарь alldata, ключом является полный топик:

{'greenhouse/1/temp': '24.76','greenhouse/1/upd': '22.04 18:20:30','greenhouse/2/temp': '22.95','greenhouse/3/temp': '28.91','air/outdoor/1/temp': '17.32','air/outdoor/1/upd': '22.04 18:21:25','air/outdoor/1/pressure': '739','air/outdoor/1/humidity': '58.3'}

При необходимости чтения из этого словаря формируется разбитый на уровни вложенный словарь tree - дерево данных. Это преобразование выполняет функция maketree.

def maketree(group, items, path):    def sep(s):        return s.split('/', 1)    head = [i for i in items if len(sep(i)) == 2]    tail = [i for i in items if len(sep(i)) == 1]    if len(tail) == 1:        return group, tail[0]    gv = groupby(sorted(head), lambda i: sep(i)[0])    return group, dict([(i, path) for i in tail] + [maketree(g, [sep(i)[1] for i in v], '') for g, v in gv])

В результате получается такая структура:

{    "air": {        "outdoor": {            "1": {                "humidity": "58.3",                "pressure": "739",                "temp": "17.32",                "upd": "22.04 18:21:25"            }        }    },    "greenhouse": {        "1": {            "temp": "24.76",            "upd": "22.04 18:20:30"        },        "2": {            "temp": "22.95"        },        "3": {            "temp": "28.91"        }    }}

Из такого словаря очень легко получить нужные данные. Например, температура в 1 теплице находится по адресу tree[greenhouse][1][temp]. Так как данные обновляются намного чаще, чем запрашиваются, преобразование в момент запроса достаточно эффективно. При более частых запросах лучше будет формировать и обновлять такое дерево сразу при поступлении данных.

Затем идёт подключение к серверу Телеграм. Бот предназначен для работы в локальной сети без возможности пробросить необходимый для веб-хука порт, поэтому для подключения он использует Long Polling запросы. Используется библиотека python-telegram-bot версии 12.8, так как в 13 версии разработчики что-то поломали. Установить её можно командой pip3 install python-telegram-bot==12.8

Для упрощения работы с ботом не используются команды: в ответ на знакомое слово он отсылает информацию, на незнакомое выдаёт кнопки выбора. В моём случае кнопок две, они прописаны в функции get_keyb:

def get_keyb():    return [[InlineKeyboardButton('Погода', callback_data='1'),            InlineKeyboardButton('Теплицы', callback_data='2')]] 

А также в словаре, строчными буквами для удобства сравнения:

keys = {'погода': '1', 'теплицы': '2', 'приборы': '3'}

Ключ "приборы" добавлен для отладки, на него ответ всегда "40"

Кнопки можно многократно использовать для обновления информации.

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

Некоторое время назад мы попытались дать ответ на этот вопрос. Через призму нашего видения.

Вот, что у нас получилось.

За последнее время мы выпустили несколько крупных обновлений ПО, которые как исправляли некоторые недоработки, так и расширяли функционал устройства.

В целом, на сегодняшний день, термостат обладает всем разнообразием функционала, который мы хотели реализовать в нём. Конечно, будет еще несколько нововведений, добавление более продвинутого расписания; но контроллер, установленный в термостат, себя исчерпал. Надо двигаться дальше.

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

Позвольте представить, Панель управления климатом и светом.

По традиции, начнем с начинки. Как и ранее, Панель состоит из двух плат.

Верхняя плата

Мы решили выбрать народный микроконтроллер esp32. Два ядра, BLE, вагон памяти под наши задачи. Что еще можно желать?

ESP32 хорош, но какой умный дом без ZigBee? Компоновка платы позволяет, и мы полностью воспользовались этим, установив модуль NJ5169 (E75).

Нижняя плата

Над начинкой платы мы так же поработали и решили подойти с учетом имеющегося опыта.

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

Как насчёт экрана?

Установили экран диагональю 4 дюйма с IPS матрицей (разрешение 480х480px) и емкостным тачскрином.

Данный экран будет доступен и для обладателей предыдущей, 101, модели термостата. Заменить экран можно будет просто сняв старый и установив этот. Он раскроет свой потенциал у тех, кто использует MQTT. А для обладателей HK это будет чуть более информативный экран.

Какие протоколы поддерживает Панель?

Wi-Fi

Cамо собой - для связи с внешним миром.

ZigBee

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

MQTT

Все устройства, которые будут подключены к Панели по Zigbee, как и сами термостаты, будут передавать актуальные данные по MQTT. Можно будет как управлять, так и наблюдать. Подключить Панель можно будет и к нашему облаку, и к любому стороннему MQTT-брокеру.

Так будет выглядеть наше приложение, открывающее удалённый доступ ко всем подключенным устройствам в квартире:

Но на этом варианты применения MQTT не заканчиваются. Для обладателей таких систем как Home Assistant, MajorDoMo, OpenHub и аналогичных, будет возможность подписаться на сторонние топики и за счёт этого собрать свой вариант интерфейса Панели на основе заранее заготовленных нами шаблонов. Такие топики могут содержать как информацию с датчиков, так и управляющие топики для кнопок, реле и тому подобных исполняющих устройств. Также, можно будет связать кнопку и запуск/остановку какого-либо сценария.

Вот такой комбайн получился у нас.

Вроде и термостат, а вроде уже что-то более продвинутое.

Как же можно его применить?

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

Вдобавок, можно вывести датчики, установленные неподалёку от Панели.

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

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

Всех желающих поучаствовать в обсуждении функционала такого устройства приглашаем в нашу группу телеграм