Русский
Русский
English
Статистика
Реклама

Умный дом

Миниатюрный датчик качества воздуха на батарейке с e-ink экраном

21.06.2021 12:17:59 | Автор: admin
Приветствую всех читателей Habr! В своей сегодняшней статье, хочу рассказать вам о своем новом DIY беспроводном устройстве датчике качества воздуха. Помимо оценки качества воздуха, датчик может оценивать уровень освещенности в помещении, температуру, влажность и атмосферное давление, на основе данных атмосферного давления, устройство может предсказывать прогноз погоды. Это полностью открытый проект.



Внутреннее устройство


Датчик работает на микроконтроллерах nRF52, были разработаны 4 версии плат датчика под радиомодули nRF52 разных производителей. Одна основная и еще три расширенные версии (пояснения будут чуть ниже по тексту).

Используемые в проекте модели радиомодулей:

  • основной MINEW MS88SF3 (nRF52833, nRF52840)
  • дополнительные: MINEW MS50SFA1 (nRF52810, nRF52811), MINEW MS50SFA2 (nRF52832), EBYTE E73-2G4M08S1C (nRF52840) и EBYTE E73-2G4M08S1E (nRF52833)

Используемые в проекте сенсоры:

  • сенсор качества воздуха в помещении для измерения ЛОС SGP40
  • сенсор давления, температуры и влажности BME280
  • сенсор освещенности MAX44009

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

Устройство может выводить данные на экране и передавать данные в системы Умного Дома, так же может работать в режиме без сети.

Для вывода информации использовался e-ink дисплей со сверхнизким потреблением и диагональю 2.13 дюймов компании WaveShare.



Характеристики дисплея:

  • Разрешение: 250x122
  • Диапазон рабочих температур: 0 50 C
  • Потребление в рабочем режиме: 3мА
  • Потребление в режиме глубокого сна: 1мкА
  • Минимальное время обновления экрана: 0.3 сек.

В ближайшее время в проект будет добавлена поддержка дисплея DES e-Ink 2.13 c рабочим температурным режимом -20C~60C (что такое DES).
..upd Пока статья писалась сделал драйвер, дисплей протестирован, в морозильнике работает :), из минусов разрешение 212х104, но зато морозов не боится, в общем рабочий вариант.


Основная версия PCB датчика:

Дополнительные версии:



Основным сенсором в данном проекте является сенсор качества воздуха в помещении SGP40. Можно сказать что это новинка на рынке от компании Sensorion c весьма неплохими характеристиками.


Сенсор измеряет общую концентрации летучих органических веществ (TVOC). В сравнении с предыдущим датчиком этой компании SGP30 потребление было значительно снижено, 48 мА при измерении у SGP30 и 2.6мА у SGP40. Правда предыдущий датчик мог отдавать уже готовые значения VOC и эквивалента СО2, в то время как новинка отдает сырые данные которые в дальнейшем надо обрабатывать на стороне МК при помощи поставляемой с датчиком библиотеки с алгоритмом расчета качества воздуха. Даташит на датчик SGP40.


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

Схема устройства:



Передача датчиком данных с сенсоров в системы Умного Дома реализована на открытом проекте MySENSORS.




Функционал датчика


Устройство, при подаче питания, осуществляет попытку поиска сети, если сеть не найдена, то устройство переходит в основной режим работы без работы в сети (не шлет данные), но периодически делает короткие запросы на поиск сети(~раз в 2 часа). Интервал опроса сенсора SGP40 3 секунды, чтение остальных сенсоров, отправка данных, основное обновление экрана раз в 1 минуту. Обновление экрана и отправка данных(если сеть доступна) происходит при изменении данных уровня качества воздуха (TVOC) на 10 единиц, температуры на 0.5C, влажности на 5%, давления на 1 единицу, при изменении уровня освещенности на 10 люкс, при изменении прогноза по погоде. Интервал опроса батарейки задается пользователем в интервале от 1 часа до 24 часов, по умолчанию опрос один раз в 6 часов.
Так же есть дополнительная подпрограмма для обновления экрана и отправка данных при резком повышении уровня TVOC на 30 единиц, интервал проверки раз в 6 секунд.

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

Доступный функционал кнопки меню:

  1. Инверсия экрана
  2. Отправка презентации
  3. Вход в режим конфигурации внешними командами по радио
  4. Поиск сети
  5. Сброс устройства

Так же, помимо кнопки меню, датчик может настраиваться внешними командами из интерфейса УД. Для этого необходимо активировать нужный пункт меню конфигурация датчика нажатием кнопки меню. После активации режима конфигурации, датчик перейдет в режим прослушивания на 20 секунд. В этот интервал необходимо отправить команду. Внешними командами можно настроить интервал проверки батарейки, изменить вывод информации на экран в инверсии, выбор режима работы: LP (чтение сенсора SGP40 раз в 3 секунды) или ULP (чтение сенсора SGP40 раз в 5 секунд).

Датчик умеет анализировать данные атмосферного давления и рассчитывать по ним прогноз погоды, выводить на экран данные о прогнозе погоды и отправлять эти значения в УД. Описание алгоритма расчета прогноза погоды (NXP Application Note 3914 | John B. Young)

На экране рядом с каждым типом данных выводится индикация направления изменения значений.



Для компиляции нужной версии ПО необходимо сконфигурировать файл aConfig.h.

//#define MY_DEBUG#define LANG_RU // If this is not used the English localization will be displayed.#ifndef LANG_RU#define LANG_EN#endif#define SN "eON Air Quality Sensor"#define SV "0.99"#define MY_RADIO_NRF5_ESB#define MY_NRF5_ESB_PA_LEVEL (0x8UL)//#define MY_PASSIVE_NODE//#define MY_NODE_ID 151//#define MY_NRF5_ESB_MODE (NRF5_1MBPS)#define MY_NRF5_ESB_MODE (NRF5_250KBPS)#define ESPECIALLY#define SEND_RESET_REASON#define MY_RESET_REASON_TEXT

Потребление датчика в режиме сна составляет в среднем 33мкА (смотрите даташит на SGP40), в режиме считывания сенсоров и обновления экрана 4мА(среднее), в режиме передачи данных 8мА(среднее), время передачи одного сообщения 10мc (идеальные условия).
Датчик работает от батарейки CR2477 (950мА), среднее расчетное время работы устройства 1 год(зависит от конфигурации прошивки, установленных сенсорах на устройстве, больше сенсоров больше данных нужно будет отправлять, а передача по воздуху это основной потребитель), данных о реальном сроке работы пока нет, устройство пока работает 2 месяца.



Модели разработанного корпуса датчика я печатал на FDM 3D принтере, что бы добиться более или менее приличного вида, корпус после печати шлифовался и полировался. На задней крышке корпуса можно установить магниты.



GitHub проекта github.com/smartboxchannel/

В файле readme находится инструкция по установке и настройке среды для редактирования и компиляции ПО для датчика.

OPEN SOURCE HARDWARE CERTIFICATION
OSHWA UID: RU000004


В завершении, уже как обычно, сделаю небольшой фото анонс проектов с которыми в скором времени поделюсь и о которых расскажу (Датчики влажности почвы Zigbee, Уличный датчик температуры и влажности Zigbee Long Range, Датчик качества воздуха bme680 c e-ink3.7).

Новые проекты на стадии тестирования












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

Если вы как и я, хотите понять что такое Zigbee, попытаться сделать свои первые DIY Zigbee устройства, то приглашаю вас в чат для разработчиков zigbee девайсов/прошивок ZIGDEV

Всем, кто хочет делать устройства, начать строить автоматизацию своего дома, я предлагаю познакомиться с простым в освоении протоколом Mysensors телеграм-чат MySensors

А тех кто смотрит в будущее IOT приглашаю в телеграм-чат Open Thread (Matter, Project CHIP). (что такое Thread?, что такое Matter?)

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


Подробнее..

Интервью с менеджером проектов АСУ цифровизация, интернет вещей и умные города

19.05.2021 20:18:09 | Автор: admin

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

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

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

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

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

Дом с солнечными батареями на крышеДом с солнечными батареями на крыше

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Концепция "умного" городаКонцепция "умного" города

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

Иннополис в ТатарстанеИннополис в Татарстане

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

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

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

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

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

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

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

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

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

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

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

Концепция "умного" домаКонцепция "умного" дома

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

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

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

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

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

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

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

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

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

Дети на занятиях по робототехнике в школе "Пиксель"Дети на занятиях по робототехнике в школе "Пиксель"

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

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

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

Подробнее..

Перевод Send My Произвольная передача данных по сети Apple Find My

07.06.2021 12:06:42 | Автор: admin
  • Можно загружать произвольные данные сустройств, не подключенных к интернету, широковещательно посылая сообщения Find My по технологии BLE (Bluetooth с низким энергопотреблением)на расположенные поблизости устройства Apple, которые затем загружают данные для вас
  • Мы выпустили прошивку дляESP32, превращающую микроконтроллер в модем (работающий только на загрузку) и приложение дляmacOS, предназначенное для извлечения, декодирования и отображения загруженных данных: https://github.com/positive-security/send-my
  • В силу природы той парадигмы приватности и безопасности, на которых основан дизайн системы оффлайн-поиска Find My, представляетсямаловероятным, что такое злоупотребление ею можно будет полностью предотвратить




Find My modem (ESP32) // Модем Find My (ESP32)

Nearby Apple Devices // Расположенные поблизости устройства с Apple

Mobile Tower or Wifi Access Point // Сотовая вышка или точка доступа Wifi

macOS device with data retrieval app // Устройство macOS с приложением для извлечения данных

Data flow // поток данных

.

Введение


После состоявшегося недавно релиза технологии AirTags от Apple я заинтересовался, можно ли злоупотреблять системой оффлайнового поиска Find My, чтобы загружать в Интернет произвольные данные с устройств, не подключенных к WiFi или мобильному интернету. Эти данные могли бы широковещательно транслироваться по Bluetooth с низким энергопотреблением и подхватываться устройствами Apple, расположенными поблизости. Эти устройства, стоит им подключиться к Интернету, сразу переправляли бы эти данные на сервера Apple, откуда их впоследствии можно извлечь. Такой прием мог бы использоваться небольшими сенсорами в неконтролируемых окружениях, чтобы не тратить лишнюю энергию на использование мобильного Интернета. Кроме того, она могла бы быть интересна для кражи данных из мест, защищенных клеткой Фарадея, стоит туда только заглянуть человеку с айфоном.

Теоретически такое должно быть возможным: если удастся эмулировать два AirTags, то можно закодировать данные, активировав в конкретный момент времени лишь один из них. В таком случае устройство-получатель должно проверить, какой AirTag был активен в какое время, и декодировать данные обратно в исходный вид. Однако такая схема представляется исключительно ненадежной и, пожалуй, непригодной к использованию в реальных практических ситуациях по причине очень узкой полосы передачи данных (особенно с учетом ограничения в 16 AirTag на Apple IDпредставлялось, что объем передаваемых данных не может превышать нескольких бит в час).

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


Результат: извлечение ранее переданных/загруженных данных при помощи специального приложения Mac

Описание сети оффлайнового поиска


К счастью, этот протокол уже был в значительной степени воспроизведен методом реверс-инжиниринга группой исследователей из Дармштадтского Технического Университета, опубликовавших статью Who CanFind MyDevices? в марте 2021 и для проверки концепции выпустивших реализациюOpenHaystack с открытым исходным кодом. При помощи этой реализации можно создавать собственные компоненты, отслеживаемые в сети Apple Find My. Огромная благодарность этой команде! Именно благодаря их работе смогла состояться наша, и на OpenHaystack основана как наша прошивка (также сделанная для проверки концепции), так и приложение для Mac.

В слегка упрощенном виде принцип работы оффлайновой системы поиска Find My таков:

  1. При сочетании метки AirTag с устройством Apple, совместно генерируется пара ключей на эллиптических кривых, причем, открытый ключ остается на AirTag (а также используется разделенный секрет для генерации сменяющихся открытых ключей)
  2. Каждые 2 секунды AirTag посылает широковещательное сообщение по низкоэнергетическому протоколу Bluetooth, причем, содержимым этого сообщения является открытый ключ (детерминированно меняется каждые 15 минут при помощи заранее разделенного секрета)
  3. Расположенные поблизости айфоны, макбуки, т.д., распознают широковещательное сообщение Find My, определяют свое текущее местоположение, шифруют его широковещательно переданным открытым ключом (при помощи механизмаECIES) и загружают на сервер зашифрованный отчет о местоположении
  4. В ходе поиска устройств сопряженное Устройство Владельца генерирует список сменных открытых ключей, которые AirTag, должно быть, использовал в последние дни, и запрашивает у сервиса Apple их хеши SHA256. Бэкенд Apple возвращает зашифрованные отчеты о местоположении для тех ключей, чьи идентификаторы были запрошены.
  5. Устройство владельца дешифрует отчеты о местоположении и выводит приблизительное местоположение.



Apple's servers // Серверы Apple

Finder devices // Ищущие устройства

Owner device // Устройство владельца

Lost device // Потерянное устройство

  1. // Сопряжение при начальной настройке
  2. // Широковещание. Представление Bluetooth с открытым ключом
  3. // Загрузка зашифрованных отчетов о местоположении
  4. // Скачивание и дешифрование отчетов о местоположении

Рис. 1. Упрощенная схема потока задач, решаемых при оффлайновом нахождении устройств

Этот весьма красивый дизайн обладает характерными свойствами безопасности, в частности:

  • Защита от отслеживания, направленная против находящихся поблизости злоумышленников, обеспечивается сменными открытыми ключами
  • Невозможность определить местоположения пользователей Apple

Однако для нас в данном случае наиболее интересно вот что: Apple не знает, какие открытые ключи относятся к вашему AirTag, и, соответственно, какие отчеты о местоположении адресованы вам. Таким образом, оконечная точка, запрашивая отчеты о местоположении по конкретному id ключа, не выполняет при этом никакой авторизации (но вы должны аутентифицироваться по вашему Apple ID, чтобы получить доступ к оконечной точке).

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

Проектирование протокола кражи данных


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

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

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

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

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

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

Итак, отправляя конкретный бит, мы создаем 28-байтный массив вида [4b индекс бита] [4b ID сообщения] [4b ID модема] [заполнение нулями...] [значение бита], оперируем им как открытым ключом и отправляем представления BLE, например, для широковещательной передачи информации бит 0 сообщения 0 равен 1.

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



Message to encode // Сообщение, которое нужно закодировать

Generated public key to broadcast // Сгенерированный открытый ключ для широковещательной передачи

Bit index // Индекс бита

Bit value // Значение бита



Кодирование бит сообщения в широковещательно передаваемую полезную нагрузку

При выборке данных приложение-получатель будет генерировать такие же 28-байтные массивы (по два на бит, где возможными значениями бита являются 0 и 1) и запрашивать сервис Apple с хешами SHA256 этих открытых ключей. Только к одному из этих ключей должны быть прикреплены отчеты о местоположении, что затем поддается интерпретации (напр., бит с индексом 0 равен 1).



Potential bits to query // Биты, которые потенциально можно запрашивать

Potential public keys to test // Открытые ключи, которые потенциально можно протестировать

Query Apple Backend // Запрос к бекенду Apple

Decode public key existence back to original data // Расшифровываем открытый ключ, получая исходные данные


Извлечение ранее отправленных данных с устройства с macOS, подключенного к Интернету

Примечание: можно передавать не только всего один бит на сообщение, а, например, посылать целый байт, в котором будут записаны последние 8 бит открытого ключа. Притом, что для этого требуется более широкая полоса передачи данных, на стороне получателя теперь придется запрашивать 255 разных идентификаторов ключей, чтобы выбрать/подобрать простым перебором один байт (сравните с 16 ID ключей при побитовой кодировке).

Реализация


Сторона отправителя


На стороне отправителя я решил использовать ESP32 совершенно обычный и дешевый микроконтроллер (а быстрый тест показал, что он может менять адрес BT MAC гораздо быстрее, чем, скажем, Raspberry Pi, основанная на Linux). При загрузке прошивка, основанная на OpenHaystack, широковещательно передает жестко закодированное заданное по умолчанию сообщение, а затем слушает последовательный интерфейс (в виде цикла), не поступят ли какие-то новые данные для широковещательной передачи и так продолжается, пока не будет получено новое сообщение. При широковещательной передаче открытого ключа его требуется разделить на части и закодировать первые 6 байт в адресе Bluetooth MAC (все биты кроме первых двух, поскольку стандарт Bluetooth требует, чтобы первые два бита были установлены в 1). Отсылаем вас к разделу 6.2 из статьи Дармштадтского Технического Университета,где эта самодельная кодировка описана подробнее.

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


Вывод модема ESP32 в последовательной консолиа

Сторона извлечения данных


Приложение для Mac также основано на OpenHaystack и использует тот же фокус с плагином AppleMail, чтобы отправлять к бекенду Apple правильно аутентифицированные запросы на извлечение местоположения. Пользователь получает приглашение ввести 4-байтный ID модема (может быть установлен в процессе прошивки ESP), после чего приложение автоматически выберет, декодирует и отобразит сообщение с id 0. Затем пользователь может выбрать другие сообщения или сменить модем.

Сообщение выбирается по 16 байт (128 бит) за раз (при этом запрашивается 256 id ключей), пока не останется ненайденных отчетов (за целый байт).

Небольшое осложнение: срок действия открытого ключа


Реализовав и сторону отправителя, и сторону получателя, я провел первый тест, широковещательно передав и попытавшись получить 32-битное значение. Спустя пару минут, я смог достать 23 из 32 бит, каждый однозначно верный и примерно с 100 отчетами о местоположении, но не получил ни одного такого отчета на оставшиеся 9 бит.

Заподозрил, что некоторые из сгенерированных открытых ключей были отклонены расположенными поблизости устройствами Apple на этапе шифрования ECIES как недействительные открытые ключи и это удалось быстро подтвердить, попытавшись загрузить каждую из сгенерированных полезных нагрузок как закодированные при помощи SEC-1 открытые ключи на кривой P224 при помощи пакета Python fastecdsa: для каждого бита, по которому у меня не нашлось отчетов о местоположении, микроконтроллер широковещательно передал открытый ключ, выбрасывающий исключение InvalidSEC1PublicKey при импорте ключа fastecdsa.

Небольшой контекст применяемого здесь шифрования:

  • 28-байтный EC public представляет координату X конкретной точки, закодированную при помощи SEC1.
  • У открытого ключа SEC1 обычно также есть знаковый бит, от которого зависит, какая из двух возможных координат Y для данной конкретной координаты X должна кодироваться. Этот бит при широковещании не передается и не важен применительно к сроку действия открытого ключа
  • При декодировании сжатого открытого ключа соответствующая координата Y вычисляется с использованием фиксированных параметров кривой и проверяется, действителен ключ. Некоторые сгенерированные открытые ключи этот тест не проходят. Подробнее об этом рассказано в разделе 3.2.2 в статье Валидация открытых ключей на эллиптических кривых:



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

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

Преимущество второго варианта заключается в том, что на каждый полученный бит мы также могли бы дешифровать и отчеты о местоположении, чтобы определить, в какой точке был получен данный бит, но для этого требуется несколько больше вычислительной обработки. Реализуя такой вариант, я обнаружил, что из-забагов в реализации умножения эллиптических кривыхв используемой для этого библиотеке uECC, для некоторых закрытых ключей ESP вычисляла иные открытые ключи, нежели BoringSSL на Mac и fastecdsa на Python (случайно вкрался дифференциальный фаззинг?). Эти открытые ключи даже считались недействительными собственной функцией uECC uECC_valid_public_key(). Следовательно, в этом пилотном проекте я остановился на варианте 1.



Message to encode // Кодируемое сообщение

Generate public key to encode // Генерируем открытый ключ для кодирования

BT MAC address // адрес BT MAC

Test validity, else increment counter // Проверить, действителен ли ключ, если нет увеличить счетчик на единицу

Advertisement payload // Полезная нагрузка для представления

Кодирование и отправка сообщения

Тестирование / Производительность


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

  • Скорость передачина микроконтроллере в настоящее время составляет ~3 байт в секунду. Можно было бы достичь и более высоких скоростей, просто кэшируя результаты кодирования или кодируя всего один байт на каждое представление
  • В моих тестахскорость приемабыла ограничена из-за медленного аппаратного обеспечения Mac. На извлечение16 байтодним запросом уходит~5 секунд
  • Задержкаобычно составляетот 1 до 60 минут, в зависимости от того, сколько вокруг устройств, и от других случайных факторов. На следующем графике показано распределение задержки между широковещательной передачей открытого ключа и загрузкой соответствующего отчета о местоположении. Правда, отметьте, что кривая построена по данным о загрузке отдельных отчетов, и не дает точных данных о том, когда именно такой отчет можно будет скачать (чтобы это определить, обычно достаточно уже первого отчета о местоположении от любых расположенных поблизости устройств Apple)



CDF // Кумулятивная функция распределения

Median min // Медиана 26,3 мин.

Publication delay (min) // Задержка до публикации (мин.)

Рис. 8. Задержки при поступлении всех отчетов, рассмотренных в 7.1 как кумулятивная функция распределения


Задержки при поступлении отчетов, измеренные командой из Дармштадского Технического Университета, по материалам Who can Find My Devices?

Потенциальные способы применения


Притом, что в основном мне было интересно проверить осуществимость описанного, полагаю, потенциально наиболее распространенное практическое применение загрузка показаний датчиков или любых данныхсустройств IoT без широкополосного модема, SIM-карты, тарифного плана или Wifi-соединяемости. Учитывая, что Amazonиспользует подобную сеть под названием Sidewalk, использующую устройства Echo, на такие технологии вполне может быть спрос. Поскольку в кэше ищущих устройств скапливаются полученные широковещательные сообщения, оставаясь там, пока не будет установлено подключение к Интернету, датчики могут отправлять данные даже из районов, где нет покрытия мобильными сетями, если в таких местах ходят люди с устройствами.

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

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

Как сгладить проблему


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

Apple проектировала систему, исходя из принципа экономии данных. Они не могут читать незашифрованные местоположения и не знают, ни какие открытые ключи относятся к вашему AirTag, ни даже с каким открытым ключом связан конкретный зашифрованный отчет о местоположении (поскольку получают только хеш SHA256 открытого ключа).

В таком свете заявленное ограничение в 16 AirTags на Apple ID представляется интересным, так как мне кажется, что на данный момент Apple не в силах обязывать к его использованию.

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

  • Аутентификация представления BLE.В настоящее время ищущие устройства не различают, например, AirTag и его клон на основе OpenHaystack, тем самым допуская спуфинг в виде многих тысяч несуществующих AirTag для кодирования и передачи данных. Можно попробовать подписывать открытые ключи, но, учитывая, что размер представления BLE уже исчерпан, отметим, что AirTag низкоэнергетические и не подключены к Интернету, а широковещательно передаваемые ключи постоянно проходят ротацию, так что задача не из легких.
  • Ограничение частоты при получении отчетов о местоположении Тогда как Apple не знает, связан ли id запрошенного ключа к id одного из запрашивающих пользовательских AirTag, можно кэшировать id запрошенных ключей и обеспечивать, чтобы в течение 15 минут можно было запросить не более 16 новых id ключей и Apple ID (но для первичного поиска в последнее время допустимое количество id стало гораздо больше). Притом, что такой подход реализовать проще, здесь есть лазейка: использовать по принципу карусели множество свободных Apple ID и задействовать их для извлечения данных.


Заключение


В этой статье мы ответили на вопрос о том, можно ли загружать произвольные данные при помощи устройств с Apple, принадлежащих другим пользователям: однозначно да.

Реализована прошивка модема ESP32 и приложение для извлечения данных под macOS, они выложены на Github,можете с ними поэкспериментировать.

Обращаю внимание, что эта реализация лишь доказательство осуществимости, и сам протокол ни шифруется, ни аутентифицируется. Например, можно исследовать данные модема с ID 0x42424242, просто введя его ID (может быть, тем временем кто-то также сможет продемонстрировать, что в этом протоколе отсутствует аутентификация ).

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



Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Подробнее..

О чем спорят строители Умных Домов, Бань, Дач и Гаражей

29.04.2021 08:22:29 | Автор: admin

Я 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 против готовых решений

Xiaomi MiHome стал уже символом консьюмерской системы Умного ДомаXiaomi MiHome стал уже символом консьюмерской системы Умного Дома

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

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

NodeRed очень популярное OpenSource решение для Умного ДомаNodeRed очень популярное OpenSource решение для Умного Дома

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

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

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

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

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

Та самая знаменитая "Малинка" Raspberry Pi 4 Та самая знаменитая "Малинка" Raspberry Pi 4

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

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

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

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

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

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

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

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

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

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

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

Очень популярный Intel NUCОчень популярный Intel NUC

В действительности цены на подобные новые минисерверы довольно высоки и далеко не каждый будет готов потратится. Но на просторах интернет барахолок, вроде 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:

Дебаг автоматизаций в HomeAssistantДебаг автоматизаций в HomeAssistant

Таким образом, по этому пункту, я бы посоветовал начинающим следующее. Попробуйте совмещать оба способа при написании автоматизаций, благо интерфейс теперь это позволяет. Пробуйте составить ее через 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Примерный вид обычного Node Red

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

Логотип HomeAssistantЛоготип HomeAssistant

Но тем не менее, я могу поговорить о чем спорят и говорят на эту тему в сообществе. А говорят следующее. 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

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

Подробнее..

Рожденные в карантине беспроводной датчик и все-все-все. Битва роботов в конце

26.04.2021 12:16:37 | Автор: admin
image
Рабочая неделя сокращена и теперь ты мой
Твоя прокрастинация. Апрель 2020.


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


Устройство представляет собой микроконтроллер с приемопередатчиком nrf24l01 и выходами до 3А стоимостью всего от 2*. Заинтересовались и хотите попробовать сами? Последние 10 плат вышлю по Германии абсолютно бесплатно.
* по ценам на 07.2020

Что в черном ящике?

Требования к устройству


Необходимость разработки, как ни странно, пришла от желания установить банальный беспроводной датчик температуры. Я знаю, на Хабре и в Интернете представлено огромное количество температурных датчиков на любой вкус. Но у большинства готовых работ есть серьезный недостаток цена. Платить по 10-15 за штуку, на фоне текущего дефицита и подорожания микросхем, это не серьезно, особенно когда тебе надо больше 10 штук.
Почему так много?
Когда температура в доме опускается ниже 19C, возникает дискомфорт и желание включать отопление. Двери в комнатах закрываются и там образуется свой микроклимат. Слишком высокая температура плохо скажется на счетах и выбросах СО2, а низкая температура будет способствовать избыточной влажности и появлению плесени.
Для помещений рекомендуется соблюдать следующие температуры: гостиная +22C, спальня +20C, ванная +25C, детская +23C, коридор +18C, подвал > +1C, гараж > 0C.
Вторым недостатком увиденных мною датчиков является радиус действия. WiFi с трудом пробивает междуэтажные перекрытия, а что уже говорить о подвале. Можно протянуть WiFi в подвал, для любимой мышки, но она перегрызет провода, испугавшись излучения. Поэтому, датчик должен уметь ретранслировать сообщения от других датчиков.

Третье требование автономность. Для 10 датчиков нужно более 10 батареек и, конечно, хотелось бы заряжать батарейки не чаще 2-3 раз в год. А лучше вообще забыть про зарядку. Например, датчик расположенный на улице может заряжаться от солнечной батареи, а датчик в кладовке может работать от таблетки, просыпаясь 1 раз в час.

Четвертое требование универсальность. Хочется иметь класс устройств, которые будут долго спать, отправлять 5-8 байт в сеть, а при наступлении события включать что-нибудь маломощное, до 2-3А.

Выбор компонентов


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

Датчик температуры/влажности должен иметь цифровой интерфейс и точность выше 1 градуса и опять же приемлемую цену. Выбор пал на SHTC3.

Дисплей должен быть дешевым и информативным. В качестве дисплея было выбрано семейство больших и малых SSD1306 дисплеев. Кончено, я задумывался и над E-paper и для него зарезервировано место, но он плохо ведет себя на морозе и все еще дорого стоит.

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

Аккумуляторы были выбраны 2 типов: NiMH, как безопасное и дешевое решение для домашних и уличных нужд, если постоянная отрицательная температура длится меньше 1-2 недель и LiFePo4 для уличных нужд при сильных отрицательных температурах.

Контроллер заряда аккумуляторов был выбран CN3085 для NiMh и CN3058e для LiFePo4. Они имеют схожую цоколевку, за исключением вывода DONE, без которого можно обойтись. NiMH также можно заряжать через токоограничительный резистор.

Так и сложились требования к микроконтроллеру: SPI, I2C, RTC с alarm, PWM, ADC, 5 свободных gpio, малое потребление, рабочую температуру -40C..+85C, диапазон напряжений аналогичный NRF24L01, также, имеет значение цена, комфортный для пайки корпус и большой lifetime.
Взвесив все за и против выбор пал на STM8L051. Некоторые могут обвинить меня в предвзятости к STMicroelectronics и будут правы, но на самом деле
были рассмотрены и отброшены следующие варианты:
ESP32-S2FH4 дешево, но WiFi энергозатратен и придется возиться с отладкой высокочастотных схем;
STM32L0XX + NRF24L01 очень хорош, но хотелось бы дешевле;
PIC16Fxx + NRF24L01 также понравился, но нет RTC;
nRF52810 хорош в своем классе, но будет дороже, чем NRF24L01 + дешевый микроконтроллер;
и некоторые китайские производители были отброшены по причине плохой поддержки.

Таким образом определился следующий список компонентов:
Наименование компонента Цена*, Минимум Обычный Обычный с экраном Метеостанция Внешняя метеостанция
STM8L051 0.4 x x x х х
NRF24L01+ 0.6 x x x х х
PCB 0.2 x x x х х
Кварц. резонатор 1TJF090DP1AI075 0.2 x x х х
Датчик температуры SHTC3 0.8 x x х х
Датчик движения SR602 0.4 x х х
Аккумулятор NiMh 1 x x х х
Зарядка аккумулятора CN3085 и стабилизатор напряжения AP2210K-3.3 0.3 x х х
Дисплей SSD1306 0.91 1.1 x
Дисплей большой SSD1306 2.4 10 х х
Солнечная панель 2 х
Итого, 1.2 3.2 5 13.9 15.9

* по состоянию на 07.2020, текущая цена может отличаться в 2-10 раз. Будем надеяться, что это скоро пройдет.

Схема принципиальная.


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

Основные узлы


Питание


Ключик для датчиков и внешних устройств, 2 шт



и многочисленные разъемы



Схема разрабатывалась универсальная и необходимость пайки элементов зависит от конфигурации устройства. Пайка всех элементов сделает устройство нерабочим.
Например, в схеме предусмотрены 3 варианта зарядки батарей через зарядные контроллеры, с подключением внешнего блока питания и через токоограничительный резистор для подключения солнечной панельки.
Также невозможно одновременно использовать датчик движения и диод D2, как индикатор MCU.
Цоколевки для SMD модулей NRF24L01 и NRF24L01 Long Range разные и можно подключить только один из них.

С целью снижения энергопотребления, был установлен отдельный ключ Q1-VT1, который прерывает питание дисплея, приемопередатчика и датчика температуры. В режиме сна основными потребителями являются микроконтроллер, 100К подтяжки на VT1,VT2 и датчик движения, при его установке. I2C шина также была подтянута на отключаемое питание датчиков, дабы избежать утечки драгоценного заряда в режиме сна.

Для подключения внешних устройств, таких как водная помпа, сервопривод, аналоговые датчики или кнопки управления, предусмотрен разъем J4 с управляемым питанием Q2-VT2. Этот выход может иметь раздельное питание с основной платой J3. Максимальное напряжение зависит от подобранных транзисторов и здравого смысла.

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


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

Нижний слой


SMD компоненты выбраны размером 0804, для комфортного разглядывания номиналов резисторов и ручной пайки. Знаю, что многие из вас способны запаять 0204 с закрытыми глазами 60Вт паяльником, так вот это схема и для тех кто этого не может. Для самого мелкого компонента температурного датчика SHTC3 нанесена разметка для его точного позиционирования. Посадочное место для ключей управления устройством, к которому можно подработать транзистор с переключением до 6А при 8V, что больше возможностей дорожек.

Датчик температуры\влажности разместился рядом с контроллером в надежде, что большую часть времени контроллер будет спать и не будет нагревать датчик. По этой причине, силовые элементы унесены на противоположные концы платы, но это не помогает и в режиме зарядки температура увеличивается на 4-5 градусов. NRF24L01 припаивается отдельным модулем, для экономии времени и возможности выбора типа приемопередатчика. Проект данной платы вы найдете на GitHub.

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

Плата распаивалась с помощью паяльной пасты и утюжных технологий. Запекать 2 мин. при температуре Лён:

Смотрится вполне сносно:


Корпус


Размер платы удачно совпадает с размерами 2 батареек ААА, что делает доступными все корпуса с батарейками 2xААА или 2xАА. Также подойдут некоторые корпуса для 1x18650 при диагональном размещении платы. Вид у этих коробочек соответствует цене, но мы их спрячем и замаскируем.
Для устройств находящихся на видном месте спешу поделится технологией быстрого и дешевого изготовления красивых корпусов.
Покупаем или печатаем пластиковый корпус и фанеру толщиной 1-2мм из благородных пород дерева. С помощью цианокрилата(берегите глаза и нос) клеем фанеру на пластик и отрезаем все лишнее. Если у вас такие же кривые руки, то необходимо запастись шпатлевкой по дереву и замазать сделанные щели и сколы. Затем, надо дать просохнуть клею и шпатлевке, затереть всё наждачной бумагой и покрыть маслом или лаком.
Таким образом, из
серой пластиковой коробочки


получается теплый деревянный корпус.


Тестирование


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

Измеренный ток в спящем режиме ~1.5мкА при 2.6В. При включенном режиме потребление зависит от количества подключенных устройств, яркости дисплея, количестве включенных пикселей и режимах приемопередатчика, в среднем получилось 40мА.
Ниже приведено расчетное время работы в зависимости от используемой батареи.
АКБ Заряд, mAh Номинальное напряжение, V Период передачи данных, c Расчетное время работы на 70% заряде, дней
AAx2 2500 2.4 300 217
AAAx2 900 2.4 300 77
AAx3 2500 3.6 120 174
AAAx3 900 3.6 120 62
CR2025 150 3 3600 189
AAx6 5000 3.6 120 350

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

Программное обеспечение.


STM8L051 является 8 битным MCU, имеет 1Кб RAM и 8 Кб ПЗУ. Это значит, что в 8 Кб необходимо уместить максимальную комплектацию:
поддержка интерфейсов i2c, spi;
поддержка устройств: датчик, NRF, дисплей, часы;
протокол передачи данных SMESH;
шрифт (цифры, знаки, буквы);
график вывоза мусора.
И здесь придется бороться за каждый байт. Программный код был написан на языке С для компилятора sdcc. Из допущенных ограничений стоит отметить, что шрифт уместился только от пробела до заглавной Z, а годовой график вывоза мусора пришлось упаковать в 1 байт на событие. Для дисплея размером 128*32 пикселя требуется RAM буфер 512 байт, что приемлемо для микроконтроллера, а вот для экрана 128*64 требуется уже 1Кб, что в RAM уже не помещается. Поэтому, для большого экрана, его буфер пришлось делить на 2 части верхние 3 строки текста и нижние 3 строки текста.

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

SMESH (Simular MESH)


Да, уместить полноценный MESH в 8Кб не получилось, но по крайней мере он умеет ретранслировать сообщения. Для управления необходим контроллер, который будет синхронизировать устройства, принимать показания датчиков, передавать время и другие данные. Каждое устройство имеет уникальный ID(4 байта) и динамический однобайтовый адрес. Одна сеть поддерживает до 126 узлов, с максимальным диаметром 22 узла. Кроме этого, каждый узел может ретранслировать данные с устройств не участвующих в сети.

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

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

Как мы знаем в аббревиатуре IoT буква S означает seсurity. Нарушать эти традиции у меня не хватило памяти. Но можно быть уверенным, в случае атаки злоумышленник будет находится в радиусе 100 метров от крайнего узла, и при обнаружении невероятных значений температуры вам следует выпустить ваших собак.

На данный момент полноценного тестирования сети проведено не было, но в первом приближении это работает.

Контроллер сети


Изначально контроллер сети планировалось сделать также на базе микроконтроллера, в виде шлюза NRF24L01 WiFi. Но, посчитав соотношение цена\функциональность\время разработки, выбор пал на полноценный PC Raspberry PI Zero(20) c 6'' HDMI дисплеем+touchscreen(30). Несмотря на свою одноядерность и 1Гб RAM RPi Zero справился со своей задачей отображения сенсоров и почасового прогноза погоды на остаток дня.
В качестве ОС был развернут минимальный образ OC *Linux* и установлен Kivy, который поддерживает egl, умеет работать с framebuffer и не нуждается в Xwindows. Следуя заветам Unix, было написано несколько программ, каждая из которых вносит небольшой вклад в отображение информации. Основной является программа управления сетью, которая также принимает данные с устройств, распределяет динамические адреса и передает точное время, погоду и другую информацию. Программа написана на языке С и может быть портирована на любой микроконтроллер. Также работают несколько небольших Python-скриптов: однин из них прекрасно генерирует картинку первого этажа дома, второй для второго этажа, еще один для генерации погоды от OpenWeatherMap на следующие 12 часов, отправки данных на сервер и телеграмм, и наконец, программа, которая показывает сгенерированные картинки по кругу, с возможностью swipe и обеспечивает интерфейс с пользователем.



Чтобы монитор не светился постоянно, к RPI был приделан все тот же датчик движения, по сигналу с которого или с touchpad подается команда к включению монитора. Через 30 секунд монитор выключится, если сигналы не поступят опять.

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



Автоматический полив цветов на солнечной батареи


Скоро лето, время когда люди уезжают в отпуска, оставляя свои комнатные растения без воды под жаркими лучами палящего солнца. Я знаю, на Хабре и в Интернете представлено огромное количество систем полива для цветов. Большая их часть требует питания 220В или емких LiPo АКБ.

Для модификации нашей платы в автоматическую поливку цветов нам потребуется маломощная водяная помпа до 3А и напряжением 3-4В. Помпу необходимо поместить в емкую канистру от 5л. Желательно, чтобы канистра находилась на одном уровне с цветком, иначе мощности помпы может быть недостаточно для подъема воды более, чем на 30см. Если канистра с водой будет выше цветка, то необходимо поставить обратный клапан, который будет предотвращать самотек воды, запуская в трубопровод воздух. Помпа подключается к разъему J4.

В простейшем случае, длительность включения насоса можно настроить экспериментально. Например, установить включение на 3 минуты 2 раза в день. Для ручной регулировки цикла подачи воды можно подключить дисплей и 2-3 кнопки к разъему J7. В качестве обратной связи можно использовать ADC канал или поместить датчик влажности ближе к поверхности земли. А источник питания лучше использовать 3-6 аккумуляторов АА и солнечную батарею(блок батарей) площадью от 0.4 кв.м., которую необходимо подключить к разъему J8 и приклеить(прислонить) к окну.

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

Безопасный пускатель фейерверков


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

Для этого понадобится 2 таких устройства: одно для запуска, с нитью накаливания, а второе для управления. В качестве нити накала можно использовать никелевую нить малого сечения, намотанную на разъем и подключенную к J4. Для нагрева нити достаточно 3-4 аккумулятора АА и соответствующий току и напряжению транзистор в ключе VT2. Длину нити следует подобрать так, чтобы она светилась ярко-желтым светом, но при этом не перегорала мгновенно.

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

Бонус. Битва роботов.



Их схватка будет легендарна

В качестве побочного продукта(своего рода вложенная прокрастинация) сопряжения STM8L0xx+NRF24L01 были изготовлены роботы для игры всей семьей. Схему печатной платы, ПО и модели деталек для 3D печати можно найти на GitHub.

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

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

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

За все время эксплуатации сломалось 6 больших колес, 2 кнопки пульта управления, 2 сервопривода и 1 мотор. Запасайтесь колесами!
Подробнее..

Декоративная подсветка лестницы. Часть вторая. Программная

06.05.2021 12:20:25 | Автор: admin

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

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

Пусть меня закидают грязными тряпками, но тут для меня однозначно лучшая - 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. Если у кого-то будет желание доделать или внести что-то свое могу отдать два комплекта пустышек (по комплекту на лестницу) и процы к ним (как помните, у меня их много).

Подробнее..

Визуализация голосового помощника Алисы с эффектом голограммы

28.05.2021 12:18:53 | Автор: admin

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

Вступление

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

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

Робот Vector от AnkiРобот Vector от Anki

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

Яндекс.Станция Макс с LED-дисплеемЯндекс.Станция Макс с LED-дисплеем

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

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

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

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

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

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

  • Arduino Nano

Дисклеймер по качеству фото

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

Корпус

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

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

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

Модель корпуса в Autodesk Fusion 360Модель корпуса в 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 для запуска анимации и отображения текста/изображения на специальных панелях. Модель отображают три камеры (каждое изображение попадает на свое стекло), на которых применен эффект "зеркала", чтобы после проецирования на стекло пользователь видел корректное изображение модели и текста.

Визуализация в UnityВизуализация в Unity

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

3D-модель Алисы3D-модель Алисы

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

Заключение

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

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

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

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

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

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

Отсчет до нового годаОтсчет до нового года

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

Подробнее..

Как я переделываю недиммируемые светодиодные светильники в диммируемые. Статья вторая

10.06.2021 04:21:04 | Автор: admin

Учтя всю критику и советы в первой статье, я решил питать светодиодные ленты в светильниках от специализированного драйвера. В качества драйвера был выбран драйвер фирмы 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 была изготовлена плата со следующей схемой:

Схема соединения LED драйверовСхема соединения LED драйверовДизайн платы в EagleДизайн платы в Eagle

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

Шаблон (маска) платыШаблон (маска) платы

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

Плата LED драйверовПлата LED драйверовПлата LED драйверовПлата LED драйверовПлата LED драйверов (обратная сторона)Плата LED драйверов (обратная сторона)

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

Плата матриц

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

МатрицыМатрицы

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

Схема соединения матрицСхема соединения матрицДизайн платы матриц в EagleДизайн платы матриц в Eagle

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

Шаблон (маска) платы матрицШаблон (маска) платы матриц

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

Плата матрицПлата матрицПлата матриц (обратная сторона)Плата матриц (обратная сторона)Плата матрицПлата матриц

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

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

Схема платы управления матрицамиСхема платы управления матрицамиДизайн платы управления матрицами в EagleДизайн платы управления матрицами в Eagle

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

Шаблон (маска) платы управления матрицамиШаблон (маска) платы управления матрицами

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

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

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

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

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

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

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

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

Подробнее..

Как я мониторил РИП-12 от Bolid

28.04.2021 02:24:00 | Автор: admin

Резервированные источники питания используются повсеместно. Они обеспечивают бесперебойным электропитанием приборы охранной и пожарной сигнализации, оборудование систем контроля доступа и другие системы. На нашем предприятии в качестве таких источников, как правило, используются приборы от ЗАО НВП Болид. У некоторых из них, как, например, у РИП-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 Состояние прибора

149

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

Корпус РИП открыт

152

Восстановление корпуса прибора

Корпус РИП закрыт

250

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

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

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

193

Подключение выходного напряжения

РИП подключил выходное напряжение при появлении напряжения в сети

192

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

РИП отключил выходное напряжение при отсутствии напряжения в сети и разряде батареи

199

Восстановление питания

Напряжение питания прибора пришло в норму

250

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

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

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

194

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

Выходной ток РИП более 7,5 А

195

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

Выходной ток РИП менее 7,5 А

250

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

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

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

200

Восстановление батареи

Напряжение батареи выше 10 В, заряд батареи возможен

202

Неисправность батареи

Напряжение на батарее ниже 7 В или не подключена

211

Батарея разряжена

Напряжение на батарее ниже 11 В при отсутствии сетевого напряжения

250

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

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

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

196

Неисправность зарядного устройства

ЗУ не обеспечивает напряжение и ток для заряда батареи в заданных пределах

197

Восстановление зарядного устройства

ЗУ обеспечивает напряжение и ток для заряда батареи в заданных пределах

250

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

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

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

1

Восстановление сети 220

Сетевое напряжение питания < 150 В или > 250 В

2

Авария сети 220 В

Сетевое напряжение питания в пределах 150250 В

250

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

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

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

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

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

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

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

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

UProg. Конфигурация С2000-ППUProg. Конфигурация С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 в картинкахПример создания узла сетиПример создания узла сети

Ссылки для импорта: Шаблон 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 RIP 12 6 80 M3 R RS EXTENDED в картинкахПоследние значения 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 RIP 12 6 80 M3 R RS EXTENDED, rip_12_mod_56.sh.

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

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

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

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

Подробнее..

Строим и автоматизируем вентиляцию Спас-на-Крови

14.05.2021 12:21:34 | Автор: admin

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

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

Спас-на-Крови (Собор Воскресения Христова на Крови)Спас-на-Крови (Собор Воскресения Христова на Крови)

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

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

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

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

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

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

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

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

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

Один из экранов SCADA системыОдин из экранов SCADA системы

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

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

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

Подробнее..

Zabbix OPC DA

25.05.2021 00:13:35 | Автор: admin

В последних релизах 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, можно приступить к дальнейшей организации мониторинга: создание и обработка разнообразных триггеров, генерация графиков, отчетов и т. д.

Подробнее..

Умный особняк

04.06.2021 10:04:57 | Автор: admin

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

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

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

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

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

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

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

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

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

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

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

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

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

Немножко труб - тепловой пункт (БТП) живьём.Немножко труб - тепловой пункт (БТП) живьём.

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

скучные технические подробности :)

В составе системы автоматики были развёрнуты:

1. Комнатная автоматика, которая осуществляет:

- поддержание желаемой температуры воздуха путем управления отопительными приборами и холодными потолками;

- поддержание необходимой температуры теплого пола;

- контроль температуры, влажности воздуха;

- регулирование воздухообмена в комнатах, где предусмотрено курение;

- управление освещением, в том числе с димированием,

- управление шторами.

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

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

- вытяжных вентиляторов.

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

- котельной;

- ИТП дома и ИТП СПА.

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

- диспетчеризацию двух чиллеров;

- управление и контроль состояния двух узлов приготовления холодоносителя для холодных потолков.

5. Для управления и контроля состояния инженерного оборудования было предусмотрено:

- развёрнута Web-SCADA система;

- установлен диспетчерский компьютер;

- установлена панель в помещении охраны для отображения критичных аварий котельной и других систем;

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

И БТП в SCADA системе.И БТП в SCADA системе.

Умный дом

Что же касается фронтенда, то визуально для пользователя он выглядит как 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

Подробнее..

Простой Telegram-бот для получения информации через MQTT

04.05.2021 06:11:43 | Автор: admin

Этот бот был разработан для просмотра информации, находящейся на 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

Подробнее..

Samsung превратит устаревшие смартфоны пользователей в устройства для управления умным домом

22.04.2021 18:21:21 | Автор: admin

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

В новой жизни смартфоны станут элементами систем умного дома. Доступ к сервису получат пользователи из США, Кореи и Великобритании. Программа будет реализована в рамках инициативы Galaxy Upcycling at Home. Сейчас проект вошел в стадию бета-тестирования.

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


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

Во что превратят устаревшие модели телефонов серии Galaxy:

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


2. Решение по присмотру за домашними питомцами со световым сенсором.


3. Датчик уровня освещенности в помещении. Причем устройство сможет автоматически включать свет, если уровень освещенности опустится ниже заданного.

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

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

В итоге все устройства будут легко взаимодействовать с широким спектром IoT-систем.

Что еще


По словам вице-президента и руководителя группы SmartThings в Samsung Джайен Джанг (Jaeyeon Jung) интерес пользователей к умным домашним устройствам активно растет, поэтому неиспользуемые устройства Galaxy могут помочь превратить каждый дом в умный.

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

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

Подробнее..

Умное не значит дорогое для smart-часов за 25 от Pine64 выпустили open-source прошивку

23.04.2021 16:06:54 | Автор: admin

Команда Pine64 часто выпускает интересные устройства ПО к ним. Об этих гаджетах на Хабре пишут достаточно часто. Например, вот статья о Linux-смартфоне PinePhone c KDE Plasma Mobile. Эта же команда разрабатывает одноплатник с RISC-V чипом, а вот еще один одноплатник, с процессором RK3566.

Но речь сейчас не обо всех этих классных девайсах, а об умных часах PineTime, которые выпущены еще в 2019 году. Большинство смарт-часов через пару лет уже считаются морально устаревшими и прекращают получать обновления. Но только не в этом случае разработчики выпустили для девайса open-source прошивку.

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

И сейчас версия InfiniTime 1.0.0 уже доступна, это стабильная версия операционной системы для часиков. ОС включает все необходимые для работы и быта компоненты:

  • Пульсометр.
  • Шагомер.
  • Умные часы.
  • Таймер.
  • Навигационное приложение.
  • Трекер активности.
  • Игрушки вроде клона 2048 и Pong.
  • Управление воспроизведением музыки и видео на смартфоне.


Кроме того, новая версия получила такие возможности:

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


Экран сенсорный, есть и физические кнопки. Часы подключаются к ПК или смартфону при помощи беспроводного модуля Bluetooth Low Energy. Подключить можно к Android или Linux-смартфону. Для Android используется Gadgetbridge, а для Linux Siglo или Amazfish.

Характеристики девайса:

  • Дисплей 1.3 дюйма, с разрешением 240 x 240 пикселей. IPS LCD RGB display with 65K colors
  • Чип Nordic Semiconductor nRF52832 с ARM Cortex-M4F 64 мГц
  • Память: 512 КБ Flash, 64 КБ RAM
  • Дополнительно: SPI NOR 4 МБ Flash
  • Батарея: 170 -180 мАч LiPo


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

Подробнее..

Умные лампы Hiper

26.04.2021 20:23:29 | Автор: admin
Продолжаю тестировать и изучать умные лампы, управляемые по Wi-Fi.
Компания Hiper выпускает 20 моделей умных ламп и светильников, а также 12 моделей умных выключателей.
Я протестировал шесть моделей ламп.




Все лампы и светильники Hiper управляются по Wi-Fi из приложения, а также с помощью голосовых ассистентов и систем умного дома. Лампы можно включать и выключать, регулировать их яркость (диммировать), изменять цветовую температуру света. Часть ламп оснащены дополнительными RGB-светодиодами, дающими возможность изменять цвет освещения.

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

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



Результаты моих измерений.



Лампа-свечка C1 RGB в режимах белого света потребляет 5.1-5.2 Вт и даёт 458-544 лм в зависимости от цветовой температуры. Эта лампа способна заменить лампу накаливания, мощностью 55-60 Вт. На минимальной яркости в режиме самого тёплого света лампа даёт 55 лм (12% от максимальной яркости). В цветных режимах лампа потребляет около 1 Вт и даёт 6-18 лм в зависимости от цвета.

Лампа-спот B1 RGB с цоколем GU10 в режимах белого света потребляет 5-5.1 Вт и даёт 399-443 лм, это замена галогенной лампе 50 Вт. Минимальная яркость 11%, потребление в цветных режимах также около 1 Вт, световой поток 7-19 лм.

У обеих ламп пульсация света отсутствует во всех режимах.

В этих лампах используются тёплые светодиоды с цветовой температурой 2700К и холодные 6100K, поэтому цветовая температура регулируется в диапазоне 2700 6100K.

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



Результаты моих измерений.



Измеренная потребляемая мощность всех четырёх ламп составляет 7.1-7.2 Вт, световой поток 782-882 лм, они могут заменить лампы накаливания, мощностью 75-80 Вт.

У этих ламп совершенно нет пульсации при максимальной яркости в режимах самого тёплого и самого холодного света, есть небольшая пульсация 1.4-6.4% при смешивании света тёплых и холодных светодиодов, при снижении яркости пульсация возрастает (5-9% при 50%, 9-18% при 1% яркости). Замечу, что пульсация всех ламп во всех режимах неразличима визуально.

В филаментных лампах используются тёплые светодиоды 2400K, холодные 5000-5200K, соответственно и диапазон регулировки цветовой температуры 2400 5000-5200K.

У всех шести ламп довольно высокие индексы цветопередачи CRI(Ra) 81-88.

На коробках всех ламп указан диапазон напряжения сети 220-250 В. Если напряжение сети опускается ниже 220 В лампы начинают мерцать (у разных ламп минимальное рабочее напряжения составило 217-220В), поэтому эти лампы не стоит использовать там, где в сети бывает пониженное напряжение.

Для примера, приведу спектры и результаты измерений лампы-свечки C1 RGB.

Режимы самого тёплого, нейтрального и самого холодного света.



Режимы красного, зелёного и синего цветов.



Лампы построены на платформе Tuya, поэтому можно использовать как фирменное приложение Hiper IoT, так и стандартные приложения Smart Life или Tuya.

Интерфейс приложения.



Интерфейс управления лампой.



Умные лампы Hiper стоят от 890 до 1690 рублей. Все лампы имеют гарантию 1 год.

Большой плюс ламп Hiper разнообразие ассортимента. Насколько мне известно, только у Hiper есть умный спот с цоколем GU10, а также много тонированных декоративных филаментных ламп с изменяемой цветовой температурой. Ещё один большой плюс использование самой популярной платформы смарт-освещения Tuya, благодаря чему лампами Hiper можно управлять совместно с устройствами разных производителей из единого приложения.

2021, Алексей Надёжин
Подробнее..

ЖКХ, автономный транспорт и повсеместная роботизация главные элементы умных городов

27.04.2021 16:10:26 | Автор: admin


Smart-технологии очень активно развиваются, проникая во все сферы деятельности. Не являются исключением и города согласно прогнозу аналитического агентства Frost & Sullivan, к 2025 году в мире появится 26 умных городов. Конечно, далеко не все будут отстроены с нуля. Большинство мегаполисы, которые мы все знаем, модернизированные в соответствии с последними достижениями науки и техники.

Зачем нужны smart-технологии в городах? Главным образом для того, чтобы эффективно распределять ресурсы и управлять городскими пространствами. Мегаполисы лидеры в потреблении ресурсов. В частности, около 80% производимой в мире энергии приходится именно на них. Сейчас, по мнению большинства экспертов, в мире нет ни одного города, который можно назвать умным. Да, появляются отдельные smart-системы вроде освещения, дорожной инфраструктуры и т.п. Но совокупности этих технологий, которые и превращают обычный город в умный, пока нет нигде.

Что это за технологии?


Роботизация



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

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

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

Дорожная инфраструктура



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

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

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

Скоростная беспроводная связь



О чем бы мы ни говорили в этой статье, какие бы технологии не обсуждали, все они возможны лишь при условии наличия скоростной беспроводной связи. Без нее невозможна передача видео, аудио и прочих данных в режиме реального времени. Более того, без скоростного канала связи нельзя реализовать и IoT-проекты, которые нужны для развертывания систем умного ЖКХ, той же дорожной инфраструктуры и т.п.

Такая связь уже появилась это 5G. Скорость передачи данных по 5G каналам доходит до 25 Гбит/с это в 50 раз быстрее скорости действующих беспроводных сетей (LTE, LTE Advanced и т.п.). В крупнейших городах мира уже постепенно внедряют сотовой связи пятого поколения.

Сети пятого поколения постепенно разворачиваются в Китае, Южной Корее, России, ряде стран городов и Европы. К сожалению, пока что покрытие 5G не повсеместное, но это будет исправлено в скором времени.

Более того, есть еще один вариант, альтернатива 5G спутниковые системы глобального интернета от SpaceX, OneWeb и некоторых других компаний. В скором будущем планируют развернуть собственные системы спутникового интернета и китайцы. В общем, проблем со связью почти нет все что, нужно, либо уже работает, либо заработает в скором времени.

Цифровое ЖКХ

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

Возможных примеров работы таких платформ может быть много, так что стоит привести лишь несколько основных:
  • Координированное управление инцидентами и событиями между городскими ведомствами.
  • Централизованное управление уличным освещением.
  • Автоматизация зданий.
  • Умная энергетика и управление водоснабжением и очисткой сточных вод.
  • Интеллектуальное управление движением (ИТС) и уличным освещением.
  • Автоматизация общественного транспорта.
  • Мониторинг и автоматизация парковок.
  • Решения для образования, здравоохранения.
  • Цифровое ЖКХ.
  • Безопасный Город.

Цифровые ЖКХ смогут сделать потребление и распределение ресурсов городами гораздо более эффективным. Человек, каким бы он ни был талантливым управленцем, не способен следить за всем, анализируя всю поступающую информацию. А вот искусственный интеллект, smart-системы да, заявила Ксения Борбачева, заместитель генерального директора Агентства Инноваций Москвы, руководитель направления Бизнес

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

Автономный общественный транспорт



Автопилоты в транспортных средствах актуальный тренд последних лет. Беспилотные технологии развивают Tesla Inc, Mercedes Benz, Volvo, Nikola Motor и другие компании.

Умный мегаполис будущего невозможно представить без общественного транспорта без водителей. Испытания беспилотных автобусов проводятся в Вене, Барселоне, Пекине, Копенгагене, Хельсинки и других городах разных стран мира. В ближайшие два года их станут использовать гораздо шире. Запустить автономный транспорт планируют власти Хельсинки (Финляндия), Барселоны (Испания), Пало-Альто (Калифорния) и других городов.

Есть и проекты летающих автоматических такси. Такие транспортные средства разрабатываются, в частности, Uber и Bell Nexus. В общем, впереди нас ждет много интересного.

Учитывая все сказанное выше, можно сформулировать критерии умного города:
  • Квартиры, дома, районы и весь населенный пункт в целом связаны в единую ЖКХ инфраструктуру.
  • Реализована smart-инфраструктура дорог, где встроенные системы способны вести мониторинг дорожного движения и реагировать на различные события, включая пробки, аварии, превышение скорости отдельными участниками движения и т.п.
  • Все системы ЖКХ оснащены системами саморегулирования и способны реагировать на внешние (погодные условия, изменение потребления ресурсов и т.п.) и внутренние (аварии, техническое обслуживание) факторы.
  • Жители города имеют надежный канал связи с различными муниципальными организациями с обратной связью. Система взаимодействия между администрацией населенного пункта и жителями работает, в том числе, благодаря мобильным приложениям (сейчас такая система активно развивается в Москве). Если возникает проблема (например, порыв водопровода), срабатывает система уведомлений, сервисного обслуживания, и коммунальные сервисы оперативно реагируют. Аналогичным образом между собой связаны отдельные подразделения ЖКХ, дорожных и других муниципальных служб.

Но почему умных городов так мало?


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

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

Настройка SIP-видеодомофонов Fanvil для работы с iRidium

07.06.2021 12:06:42 | Автор: admin
Компания Иридиум автор и разработчик инновационных систем управления iRidium провела тестирование своей платформы iRidium pro с IP-домофонами Fanvil и предоставила обзор по итогам. Используемое окружение: SIP-сервер 3CX, SIP-клиент iRidium на устройстве iPhone 7. Сравнение качества звука производилось с SIP-панелью 2N Helios. Версия i3Pro 1.3.26.0.24027.

Протестированные устройства:



Настройка IP-домофонов Fanvil


В зависимости от модели и версии прошивки видеофонов настройки могут незначительно отличаться.

Модель Fanvil i31S

image

Данная модель оснащена встроенными динамиком, микрофоном, фронтальной камерой. Камера 2 Мп с инфракрасной подсветкой и режимом ночного видения обеспечивает достаточное качество передачи видео для идентификации посетителя. Видео передается в качестве 720p при помощи кодека H264.

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

Настройка панели (версия прошивки 2.6.1.6726):

1. Войдите в web-интерфейс, введите логин и пароль (по умолчанию admin и admin).

2. Настройте IP-адрес так, как требуется для сети вашей SIP-системы.

image

3. Задайте аудиокодеки (проверено на G722).

image

4. Настройте громкость:

  • Speakerphone Volume громкость динамика;
  • Speakerphone Ring Volume громкость звонка;
  • Broadcast Output Volume чувствительность микрофона.

image

5. Задайте параметры доступа к внешнему SIP-серверу.

Данные SIP-клиента, для подключения к серверу:

  • Phone number имя пользователя;
  • Display name имя, отображаемое при звонке;
  • Authentication Name имя пользователя для регистрации на SIP-сервере;
  • Authentication Password пароль пользователя для регистрации на сервере;
  • Activate включить / отключить SIP-профиль.

Данные сервера:

  • SIP Proxy Server Address IP-адрес сервера;
  • SIP Proxy Server Port порт.

image

6. Настройте параметры DTMF-тонов:

  • DTMF Type тип DTMF-тона;
  • DTMF SIP INFO Mode тип обработки кнопок звездочка (*) и решетка (#).

image

Нажмите кнопку Apply. При успешном подключении к SIP-серверу должен отобразиться статус аккаунта Registered.

7. Помимо номерного набора данная модель поддерживает вызов с кнопки. Для вызова с клавиатуры необходимо набрать: звездочка (*), номер абонента, звездочка (*).

Настройте вызов абонента при помощи кнопки:

  • Hot Key режим набора заранее заданного абонента (панель с клиентом i3Pro);
  • Value 1 основной номер;
  • Value 2 резервный номер;
  • Line линия SIP.

image

8. Настройте код для DTMF-тонов:

  • Calling Password код для активации реле через SIP-клиент iRidium.

image

Подробные отчеты по тестированию и настройке других устройств можно изучить на iRidium Wiki. Там же можно посмотреть сравнительные видео качества динамиков и микрофона панели по отношению к планшетам iPad Air 2 и iPad Pro.

Примечание


Для более качественной работы устройств необходимо через web-интерфейс настроить громкость микрофона и динамика устройства, стандартные значения задаются в диапазоне (1-9). Рекомендуемое значение для i31S, i33V, i20S, i32V 5. Для моделей i10, i12-01P, i16V рекомендуются значения 6-7.

Работа в iRidium Studio


1. Создайте панельный проект.
2. Добавьте драйвер SIP и настройте его.

image

На скриншоте выше красным выделены самые важные настройки:

  • Host необходимо ввести IP-адрес вызывной панели (по умолчанию 192.168.1.5);
  • Port порт вызывной панели (по стандарту SIP всегда 5060);
  • SIP ID username SIP-аккаунта;
  • Password password SIP аккаунта;
  • Use SIP TONE true, генерировать SIP-сообщения тонального набора;
  • Use DTMF Tone false, не генерировать обычные сообщения тонального набора;
  • Codec PCMU true, активация аудиокодека G.711;
  • Codec PCMA true, активация аудиокодека G.711a;
  • Codec H264 true, активация видеокодека H.264.

Остальные кодеки следует отключить (false).

3. Добавьте графические элементы на экран панели и настройте их.

image

4. Добавьте скрипт в проект:

outdoor_station_number = 0101010100; // topological code of IPerVoice panel
var SIP = IR.GetDevice(SIP); // name of SIP driver
var action = CALL; // default action
ButtonAction = IR.GetItem(Page 1).GetItem(Button_action);
LabelName = IR.GetItem(Page 1).GetItem(Label_name);
LabelNumber = IR.GetItem(Page 1).GetItem(Label_number);
SwitchVideo = IR.GetItem(Page 1).GetItem(Switch_video);

IR.AddListener(IR.EVENT_START,0,function()
{
// display the SIP video
IR.GetItem(Page 1).GetItem(Video).GetState(0).Image = sip_image://;
});

IR.AddListener(IR.EVENT_TAG_CHANGE, SIP, function(name, value) {
if (name == STATUS) {
var flagReady = (value == On Hook... || value == Incoming Call...);
ButtonAction.Enable = flagReady;
var flagTalk = (value == Talking...);
IR.GetItem(Page 1).GetItem(Button_door).Enable = flagTalk;
IR.GetItem(Page 1).GetItem(Button1).Enable = flagTalk;
IR.GetItem(Page 1).GetItem(Button2).Enable = flagTalk;
IR.GetItem(Page 1).GetItem(Button3).Enable = flagTalk;
IR.GetItem(Page 1).GetItem(Button4).Enable = flagTalk;
IR.GetItem(Page 1).GetItem(Button5).Enable = flagTalk;
IR.GetItem(Page 1).GetItem(Button6).Enable = flagTalk;
IR.GetItem(Page 1).GetItem(Button7).Enable = flagTalk;
IR.GetItem(Page 1).GetItem(Button8).Enable = flagTalk;
IR.GetItem(Page 1).GetItem(Button9).Enable = flagTalk;
IR.GetItem(Page 1).GetItem(Button0).Enable = flagTalk;
IR.GetItem(Page 1).GetItem(Button_asterisk).Enable = flagTalk;
IR.GetItem(Page 1).GetItem(Button_octothorp).Enable = flagTalk;
var flagConnect = (value == Dialing... || value == Trying... || value == Ringing... || value == Talking...
|| value == Not Found... || value == Not Acceptable... || value == Not Available... || value == Service Unavailable...);
IR.GetItem(Page 1).GetItem(Button_cancel).Enable = flagConnect;
SwitchVideo.Enable = !flagConnect;
if (value == Incoming Call...) {
action = ANSWER;
LabelName.Text = SIP.GetFeedback(INCOMING CALL NAME);
LabelNumber.Text = SIP.GetFeedback(INCOMING CALL NUMBER);
}
if (value != Incoming Call... && value != Talking...) {
action = CALL;
LabelName.Text = "---";
LabelNumber.Text = outdoor_station_number;
}
var flagShow = (flagReady || flagConnect || flagTalk);
LabelName.Visible = flagShow;
LabelNumber.Visible = flagShow;
}
});

function Talk() {
SIP.SetFeedback(NUMBER, outdoor_station_number); // when calling number is required
SIP.Set(action, SwitchVideo.Value); // call or answer, audio or audio+video
}

5. Настройте графические элементы для взаимодействия с драйвером SIP и скриптом.

Настройка кнопки для открытия двери


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

1. Создайте новый скрипт
2. Добавьте в него следующее:

function SIPsendtone1(){
var SIPdevice1=IR.GetDevice(SIP);
SIPdevice1.Set(SEND TONE, 10); // отправка *
SIPdevice1.Set(SEND TONE, 5);// отправка 5
SIPdevice1.Set(SEND TONE, 0);// отправка 0
}

3. Создайте кнопку и привяжите к ней вызов данного скрипта.

Демо-проект


Скачать демо-проект можно на iRidium Wiki.

В проекте для панели имеются:
  • дисплей, на котором в реальном времени отображается видео с видеокамеры панели,
  • клавиатура для набора номера,
  • кнопка вызова/ответа,
  • кнопка отмены,
  • кнопка открытия двери,
  • отображение текущего статуса,
  • отображение данных абонента (имя, номер),
  • настройки громкости динамика и микрофона панели i3 pro.

image

Подробную техническую консультацию можно получить в компаниях АйПиМатика и Иридиум.
Подробнее..

Сберлампочки

10.06.2021 20:10:36 | Автор: admin
Если бы кто-то сказал мне лет пять назад, что СберБанк начнёт производить лампочки, я бы подумал, что это шутка.
Но вот на дворе 2021 год и в продаже появились умные лампы Sber. Разумеется, я их протестировал.




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

Сейчас в продаже есть две модели ламп Сбер груша SBDV-0019 E27 9 Вт 806 лм и свечка SBDV-0020 E14 5.5 Вт 470 лм.
И та и другая лампа стоит 990 рублей.



Лампы управляются по Wi-Fi из приложения, а также с помощью голосовых ассистентов и систем умного дома. Лампы можно включать и выключать, регулировать их яркость (диммировать), изменять цветовую температуру света и цвет освещения (лампы оснащены пятью типами светодиодов: тёплыми, холодными, красными, зелёными, синими).

Я измерил параметры света ламп в разных режимах: на максимальной, средней и минимальной яркости, в режимах самого тёплого, нейтрального, самого холодного, красного, зелёного и синего света.

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



У ламп довольно высокие индексы цветопередачи CRI(Ra) 82-87.

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

Лампа-груша Sber SBDV-0019 в режимах белого света при максимальной яркости потребляет 8.7-8.8 Вт и даёт 785-931 лм в зависимости от цветовой температуры. Эта лампа способна заменить лампу накаливания, мощностью 75-85 Вт. На минимальной яркости в режиме самого тёплого света лампа даёт 50 лм (6% от максимальной яркости). В цветных режимах лампа потребляет 3.9-5.2 Вт и даёт 71-291 лм в зависимости от цвета.





Лампа-свечка Sber SBDV-0020 в режимах белого света при максимальной яркости потребляет 4.9-5 Вт и даёт 446-496 лм, это замена лампе накаливания 50 Вт. Минимальная яркость 6%, потребление в цветных режимах около 1 Вт, световой поток 8-26 лм.





В лампах используются тёплые светодиоды с цветовой температурой 2700K и холодные 6100-6200K, поэтому цветовая температура регулируется в диапазоне 2700 6100-6200K.

В режиме нейтрального белого света яркость у лампы-груши падает на 5% при снижении напряжение питания до 201 В, у лампы-свечки до 207 В. Если напряжение в сети опустится ещё ниже, яркость упадёт, но лампы не начинают мерцать. Замечу, что для умных ламп это очень хорошие показатели большинство умных ламп других брендов начинают мерцать уже при снижении напряжения ниже 220 В.

Лампы построены на платформе Tuya, поэтому можно использовать как фирменное приложение Сбер Салют, так и любые совместимые с этой платформой приложения.

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



А ещё лампочками можно управлять голосом через смарт-дисплей SberPortal и пульт ТВ-приставки Sber Box (приставка должна быть включена, телевизор может быть выключен). С помощью голосовых команд можно настраивать таймер или создавать отложенные команды, например включи лампу в семь вечера или установи яркость торшера 1% в полночь. Полный список голосовых команд есть тут.

Лампы Сбер продаются как на сайте SberDevices, так и в Озон, Wildberries, М.Видео и других магазинах.

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

2021, Алексей Надёжин
Подробнее..

Что такое умный термостат?

16.06.2021 12:16:05 | Автор: admin

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

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

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

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

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

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

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

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

Мы решили выбрать народный микроконтроллер 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 и аналогичных, будет возможность подписаться на сторонние топики и за счёт этого собрать свой вариант интерфейса Панели на основе заранее заготовленных нами шаблонов. Такие топики могут содержать как информацию с датчиков, так и управляющие топики для кнопок, реле и тому подобных исполняющих устройств. Также, можно будет связать кнопку и запуск/остановку какого-либо сценария.

Варианты вывода нескольких устройств на экранВарианты вывода нескольких устройств на экран

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

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

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

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

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

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

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

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

Подробнее..

Категории

Последние комментарии

  • Имя: Murshin
    13.06.2024 | 14:01
    Нейросеть-это мозг вселенной.Если к ней подключиться,то можно получить все знания,накопленные Вселенной,но этому препятствуют аннуннаки.Аннуннаки нас от неё отгородили,установив в головах барьер. Подр Подробнее..
  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru