Сервер для умного дома. Выбор оборудования
Видеонаблюдение, камеры и FFmpeg
Ох уж эти камеры. Боль и страдание еще год назад. Невероятные мучения и поиски камер и программ. Это все касается Home Assistant, как одной из самых популярных систем для умного дома.
Проблема заключалась в том, что для того, чтобы камера была доступна из умного дома, ее поток необходимо было декодировать. В качестве декодирующей программы используется FFmpeg. И вот тут есть нюанс. Ресурсов процессора компьютера может не хватать для адекватного декодирования, и вы будете получать дергающуюся картинку с низким разрешением, если вообще вам удастся что-то получить.
Для того, чтобы исправить эту ситуацию, используют аппаратное ускорение за счет графического процессора. Просто потому, что они шустрее (не зря криптовалюты майнятся видеокартами).
И вот тут есть интересные нюансы. Для Raspberry Pi 3 model B+ есть готовые инструкции по сборке FFmpeg с аппаратным ускорением. Для Rock64 тоже есть готовые решения. И все. Для всех остальных вариантов готовых решений по сборке FFmpeg с аппаратным ускорением нет. Например, те же одноплатники на базе процессоров Amlogic, которые практически ничем не отличаются от телевизионных приставок, не имеют готового решения по сборке FFmpeg. Просто потому, что приставки работают на Android, а не на Linux, и все разработанные решения сделаны под Android.
Что касается самосборных компьютеров, новых и не очень неттопов и других «нетрадиционных» платформ, то там все зависит от того, есть ли сборка FFmpeg под конкретный графический процессор (он же GPU). Если есть, то вам повезло. Если вы смогли найти видеокарту, для которой все есть — вообще замечательно.
Потому что для работы HomeBridge и получения видео с камер в HomeKit — это обязательное условие. Что касается остальных систем, то в том же Home Assistant решили проблему проще — декодирование производится в HLS, который проигрывается уже с помощью ресурсов браузера, на котором изображение просматривается. То есть требований к аппаратному ускорению на сервере умного дома уже не так много. Как дела обстоят у других разработчиков — мне неизвестно, но врядли лучше.
Поэтому выбор «железа», для вашего контроллера умного дома, должен осуществляться с пониманием того, какую систему вы хотите использовать и в каком виде вам нужны камеры.
Какой сервер выбрать для Умного дома
Сердцем Умного дома выступает сервер — который собирает информацию от всех устройств и отдает им различные команды
Производители оборудования для Умного дома часто делают собственные сервера для своих устройств. Ключевой минус таких серверов — это невозможность подключить к ним оборудование других брендов.
Некоторые производители отказываются от производства сервера и предлагают пользователям вариант облачного сервера. Минус такого варианта — зависимость от интернета.
Системам Умного дома (MajorDoMo и другие), которые позволяют подключать оборудование разных брендов, необходим физический сервер.
Что важно?
На выбор сервера для Умного дома обычно влияет несколько факторов:
- цена
- мощность
- надежность
Сразу уберем из наших вариантов промышленные сервера — это как минимум дорого.
В целом в качестве сервера для Умного дома можно использовать любой компьютер на Windows или Linux.
Многие пользователи MajorDoMo (и других систем Умного дома) используют для своего Умного дома обычные:
- персональные компьютеры (PC)
- нетбуки
Основной плюс такого варианта — это можно использовать свой старый компьютер в качестве Умного дома. Системы для создания Умного дома обычно не требовательны к железу, поэтому запустятся на многих старых компьютерах и буду стабильно функционировать.
Мы и сами используем старые PC и нетбук на нескольких наших тестовых системах 🙂
Но если покупать новый PC специально в качестве сервера — получается все же дороговато.
Кроме того, большой минус использования PC/нетбука в качестве сервера — это размер.
Если у вас есть специальное техническое помещение где вы можете поставить компьютер или нетбук — замечательно. Мы же предпочитаем делать аккуратный серверный шкаф и размещать сервер и все контроллеры там.
Оптимальное решение
И тут на помощь приходит такая замечательная вещь как одноплатный компьютер.
Рынок одноплатные компьютеров стал активно развиваться с 2011-2012 гг., когда был выпущен британский одноплатник Raspberry Pi. Первые же эксперименты показали что Raspberry отлично подходит в качестве сервера Умного дома, популярность которого начала также расти в 2011-2012 гг.
Основные плюсы использования одноплатных компьютеров в качестве сервера Умного дома:
- очень небольшая цена — от 20 USD в Китае до 50-70 USD в магазинах СНГ
- по техническим характеристикам отлично подходит для Умного дома
- надежность
- небольшой по размерам
Фото одноплатника
Самые популярные одноплатные компьютеры для создания Умного дома:
В качестве бонуса
По ссылке вы можете посмотреть что используют в качестве сервера текущие пользователи MajorDoMo.
Поделитесь в соц сетях
Умный дом (Самое начало) — ч.2 / Habr
Это продолжение статьи: Умный дом (Самое начало) — ч.1
Вся информация написана с упором на личный опыт, никаких «диванных» домыслов.
Теперь возвращаемся к теме.
Как говорилось ранее, ядро системы должно размещаться в каком-то изолированном от жильцов месте, а что, собственно, это ядро из себя представляет с аппаратной точки зрения? Конечно же сервер. Да-да, сервер, не Ардуино, не РазБери, не роутер с OpenWrt, а именно сервер. Почему? Потому что производительность, а ещё потому, что все Ардуины и пр. изделия созданы для того, чтобы обучать школьников/студентов программированию микроконтроллеров и работе с периферией. Эти устройства изначально не предназначены для развертывания полноценного готового и стабильно работающего решения. Точнее нет, развернуть-то можно, но на свой страх и риск. А вообще, если уж совсем грубо выразиться, то это конструктор для взрослых, типа как Lego Mindstorms, только чуть сложнее. Я ни в коем случае не имею ничего против этих устройств, просто у каждого свои задачи. Не знаю как кто, а лично я бы не доверил управления газовым котлом конструктору Lego.
Но под словом «сервер» я подразумеваю не стойку как в ДатаЦентре, набитую blade`ами, а какой-нибудь небольшой сервачок. Нам ведь нужно управлять домом, а не вычислять сворачиваемость белков, правда?
Сервером может быть небольшой mini-ITX компьютер с двухядерным процессором типа D525 и 2Гб оперативной памяти. Это решение обойдётся приблизительно в $200.
Это эдакое маленькое красивое решение. Если захотите развернуть на этом сервере media-хранилище, то можно воткнуть по USB внешний диск объёмом ~3Тб.
Если под сервер заложено денег по-больше, то можно взять HP microserver, типа вот такого:
www.citilink.ru/catalog/computers_and_notebooks/servers_and_net_equipments/servers/753329
у него есть потенциал для роста, но кого-то могут не устроить габариты.
Цена около $280 за стартовый комплект (двухядерный процессор, 2Гб оперативной памяти и один SATA диск на 250Гб)
Ставить что-то больше и мощнее особого смысла нет, т.к. этого железа хватит с головой.
По возможности ищите железо с USB 2.0 (ещё лучше: USB3).
Так же будет плюсом, если в качестве системного диска будет использоваться SSD-накопитель. Это даст хороший прирост к скорости загрузки ядра умного дома. Например ядро моего умного дома загружается (с SSD) не дольше загрузки обычного бытового Wi-Fi роутера — включил и пользуйся.
Для настройки сервера временно понадобится клавиатура и монитор (чтобы развернуть ОС, остальная настройка будет производиться удаленно).
Нельзя забывать и про сеть.
По возможность до всех стационарных сетевых устройств (компьютеры, медиаплееры, сетевые принтеры и камеры) лучше заранее проложить витую пару. Для коммутации лучше использовать коммутаторы (свитчи) с портами Gigabit Ethernet.
Для подключения к сети провайдера можно использовать любой роутер с Wi-Fi, но к его внутренним портам ничего кроме вышеописанного коммутатора/-ов лучше не подключать.
Вообще на Wi-Fi старайтесь не рассчитывать, особенно когда дело коснется передачи потока медиаданных (видео/звук) — могут быть задержки и провалы.
В общем, схема подключения должна быть приблизительно такая:
Шнурок, полученный от провайдера, вы подключаете к WAN-порту своего роутера, а к LAN порту подключаете свой коммутатор.
В свою очередь, к коммутатору Вы подключаете все остальные сетевые устройства.
Почему так? Чтобы исключить «падение» всей сети, если, например, Ваш не совсем удачно купленный роутер внезапно зависнет. В момент перезагрузки роутера все подключенные к нему устройства потеряют связь, и если вы смотрели на медиаплеере видео с сетевого хранилища, подключенного к роутеру, то просмотр, как Вы понимаете, прервётся. Приятного мало.
Если Ваш дом большой, то, возможно, для полного покрытия беспроводной сетью всего жилища понадобятся повторители сигнала. Не надейтесь, что Вы купите самый дорогой Wi-Fi роутер и он «пробьет все» ваши железобетонные перегородки. Лучше взять роутер «по-проще», и к нему пару/тройку повторителей.
Программное обеспечение
Я рекомендую на сервере разворачивать в качестве системной ОС Debian Linux без графической системы. Почему его, а не, скажем, Ubuntu? Ну, во-первых, Ubuntu в основном ставят те, кому нужна система X-window, а зачем нам на headless-сервере графика? Кто и что там будет разглядывать? А во-вторых, Ubuntu, по-сути, это и есть Debian, только со всякими свистелками/перделками, которые Вы доставить можете и сами (я на это надеюсь, т.к. без этих навыков самостоятельно разворачивать «Умный дом» не совсем правильно). Но если Вы привыкли к чему-то другому (например семейство RedHat, или Slackware), то делайте на том, что Вам ближе и понятнее. В конце-концов, Вам же всё это настраивать.
Из программного обеспечения я думаю правильно установить Samba (большинство бытовых плееров с сетью на борту с этим могут работать) и NFS (не игра Need For Speed, а Network File System). NFS Вам пригодится, если Вы дома используете MacOS или Linux на своих компьютерах/плеерах. Вроде даже говорят, что NFS меньше грузит процессор чем Samba, но лично мне кажется, что в масштабах дома едва ли получится создать большую нагрузку.
Если у Вас есть т.н. Smart-телевизоры, то возможно придётся разворачивать UPnP- и DNLA-серверы, т.к. большинство «умных телевизоров» не понимают ни Samba, ни NFS.
Для развёртывания связки DNLA/UPnP я рекомендую обратить свой взор на проект PMS (PlayStation3 Media Server), который когда-то вырос из медиасервера, развёрнутого на платформе взломанной игровой приставки PlayStation3. Проект разросся и мутировал в UMS (http://www.universalmediaserver.com/). Установка достаточно простая, лучше прочитать актуальную информацию по установке на сайте проекта.
Я проверял PMS и UMS с транскодингом — всё работало без нареканий. Даже при использовании в качестве медиаплеера приставки Xbox360 (у неё специфичный профиль работы с UPnP): всё работало.
Есть ещё один UPnP сервер: PlexMediaServer (https://plex.tv/), но, признаться честно, его работу с транскодингом на Xbox360 проверить не удалось, т.к. я к тому времени уже приставку продал. В целом Plex — очень мощный и функциональный, возможно даже некоторым он покажется избыточно функциональным, но на Smart-телевизорах работает и вроде никто не жалуется.
Сам я UPnP особо и не использую, т.к. телевизоры у меня старые, не Smart, и оснащены плеерами Dune, которые великолепно работают с хранилищем видео/музыки (по Samba), расположенным в ядре умного дома, но на всякий случай Plex всё же работает и всегда рад обслужить какого-нибудь android-клиента.
Если Вы любите качать видео с торрентов, то на ядро умного дома можно поставить Transmission — приложение для скачивания с torrent-трекеров. Transmission может работать без графической системы и управляться через web-интерфейс или с помощью Transmission-remote (приложение для удалённого управления закачками). Ставится с репозитариев linux-дистрибутивов
Кроме Media-компоненты кто-то наверняка захочет, чтобы умный дом что-то озвучивал голосом или принимал и обрабатывал голосовые команды. Например, Вы говорите: «Избушка, какая температура на улице?», а система отвечает Вам голосом Милляра: «Ух-ху-ху! На улице 25 градусов ниже нуля. Полезай ко мне в печку, погрей свои косточки».
Так вот, учитывая концепцию «Изолированного и самодостаточного умного дома» (про которую говорилось в первой части), всякие поделки на базе сервисов Google Voice или Yandex Voice API нужно отметать. Делайте систему по-нормальному, не по-голодрански. Я, конечно, понимаю, что жителям крупных регионов, трудно себе представить отсутствие интернета в доме, равно как трудно представить, что Google может быть недоступен, но… до августа 1945-го японцы тоже не могли себе представить, что всего одна бомба может уничтожить целый город.
Парни из Lizard Squad показали всему миру, что идеальных сервисов не существует: PlayStationNetwork компании Sony и сеть Microsoft из-за массированной DDos-атаки лежали 4 дня, а в некоторых регионах и на 5-й день наблюдали недоступность этих сервисов. Не исключено, что появятся какие-нибудь Blizzard Division и задосят Google/Yandex, потому доверять online-сервисам не нужно. Ну или если Вы на эти сервисы всё же рассчитываете, то проектируйте Ваш умный дом так, чтобы, в случае разрушения Глобальной Сети функционал Вашей системы не нарушился.
Что бы не происходило в мире, Ваш умный дом должен «… работать, работать, и работать» (из рекламы батареек).
Это же относится ко всяким сервисам типа Openremote или Fibaro: типа, сконфигурируй свой сервер с любой точки мира, а он подхватит все настройки и тут же заработает так, как надо тебе. Но как Вы будете настраивать тот же недешёвый Fibaro если сервис будет «лежать» под DDos целый месяц? Как Вы добавите на свой контроллер новый димер? Полезете настраивать его локально. Значит все эти сервисы Вам просто не нужны. Делайте своё, сразу и наверняка. Чтоб ни что не омрачило Вашу жизнь в среде Вашего прекрасного дома.
Теперь ещё одна часть умного дома, которая, возможно, будет Вам нужна:
Видеонаблюдение
Если Вы будете делать видеонаблюдение, то я рекомендую использовать не аналоговые камеры, а сетевые (IP-камеры) с питаем через Ethernet (PoE). Эти камеры дают хорошую картинку (нередко HD/FullHD) и с ними легче строить систему архивирования.
Кроме камер Вам может понадобиться NVR (Network Video Recorder) — это такая «коробочка», отвечающая за получение и сохранение изображения с камер.
В вопросе организации NVR как раз ещё одним плюсом будет, если Вы ядро своего умного дома построите на Linux-сервере. Весь функционал NVR можно развернуть прямо на нём. А вот если ядром является Ардуино, Расбери или подобные контроллеры, то функционал NVR они не потянут, потому что просто не хватит производительности.
У кого фантазии не хватило на то, чтобы придумать как это реализовать, то могу подсказать проект «Moment Video Server» (http://momentvideo.org/). Это не реклама.
Эти люди делают очень толковый и производительный видео-сервер, в т.ч. и с функцией NVR. Система условно-бесплатная и можно поставить на свой сервер версию, поддерживающую ограниченное количество устройств.
Установка простая:
Дёргаете установочный архив:
wget http://momentvideo.org/dist/moment_14-04-29_linux32.tar.gz
или
wget http://momentvideo.org/dist/moment_14-04-29_linux64.tar.gz
(если у Вас 64-разрядная ОС)Распаковываете:
tar -C /opt -xzf moment_14-04-29_linux32.tar.gz
В результате создастся директория: /opt/moment
Конфигурация производится правкой файла moment.conf
Подробнее о настройке читайте на сайте авторов: http://momentvideo.org/doc.ru.html
Запуск сервера осуществляется командой:
/opt/moment/bin/moment
По-умолчанию в браузере открываете h t t p: // ip-сервера: 8080/moment/
и увидите страничку сервера Moment.
Я с этой штукой поигрался и всё же построил что-то своё.
Если Вы хотите делать не NVR, а систему записи по движению, то камеры выбирайте такие, которые поддерживают MJPG (он же MotionJPEG), на них эта задача решается очень просто: установкой и правильной настройкой приложения «Motion» из репозитария linux-дистрибутивов.
Когда я строил свою систему видеонаблюдения, то ввел понятия «Оперативный архив» и «Долговременный архив».
В оперативном архиве лежат записи за текущий день — это удобно, если хочется быстренько глянуть «что там да как», а долговременный архив — это архив с категориями по годам, месяцам и дням. Долговременный архив синхронизируется с облаком глубокой ночью, а оперативный архив пишется на диск и в облако в реальном времени. Оперативный архив в облаке будет нужен, если злоумышленники проникнут в дом и кроме ценностей вынесут/разрушат ядро умного дома.
В кабинете оперуполномоченного Вы просто зайдёте в своё облако и просмотрите все записи камер до момента их отключения.
Ещё один вариант: скрытое сетевое хранилище, куда будет вестись синхронизация video-архивов. Самое главное, чтобы это хранилище было спрятано в надёжном тайнике, так, чтобы злоумышленники его не нашли.
UPS, конечно же, должен держать не только ядро умного дома, но и стему PoE ваших камер.
Вместо заключения
Всё описанное выше можно построить на двухядерном процессоре Atom с 4 Гигабайтами оперативной памяти, мало того, я это построил и использую в своём доме. Cделать ядро умного дома собственными руками, без использования решений с ограниченным функционалом. Самое важное: чёткий план, грамотно поставленная инженерная задача и прямые руки.
Вот теперь всё. На вой взгляд, для самого начала и для осознания приблизительных масштабов работы, этой информации должно хватить.
Возможно я вспомню что-то ещё, и если информации наберётся достаточно, то напишу следующую статью.
Спасибо всем за внимание.
С наступающими вас праздниками, уважаемые читатели! Счастья вам и вашим близким, мир вашему дому!
P.S. Очень-очень внимательно вычитывать текст времени не было, поэтому если будут вопиющие опечатки/описки — сообщайте и я поправлю.
1.4. Какой сервер выбрать для Умного дома — MajorDoMo
Сердцем Умного дома выступает сервер — который собирает информацию от всех устройств и отдает им различные команды
Производители оборудования для Умного дома часто делают собственные сервера для своих устройств. Ключевой минус таких серверов — это невозможность подключить к ним оборудование других брендов.
Некоторые производители отказываются от производства сервера и предлагают пользователям вариант облачного сервера. Минус такого варианта — зависимость от интернета.
Системам Умного дома (MajorDoMo и другие), которые позволяют подключать оборудование разных брендов, необходим физический сервер.
Что важно?
На выбор сервера для Умного дома обычно влияет несколько факторов:
- цена
- мощность
- надежность
- размер
Сразу уберем из наших вариантов промышленные сервера — это как минимум дорого.
В целом в качестве сервера для Умного дома можно использовать любой компьютер на Windows или Linux.
Многие пользователи MajorDoMo (и других систем Умного дома) используют для своего Умного дома обычные:
- персональные компьютеры (PC)
- нетбуки
Основной плюс такого варианта — это можно использовать свой старый компьютер в качестве Умного дома. Системы для создания Умного дома обычно не требовательны к железу, поэтому запустятся на многих старых компьютерах и буду стабильно функционировать.
Мы и сами используем старые PC и нетбук на нескольких наших тестовых системах 🙂
Но если покупать новый PC специально в качестве сервера — получается все же дороговато.
Кроме того, большой минус использования PC/нетбука в качестве сервера — это размер.
Если у вас есть специальное техническое помещение где вы можете поставить компьютер или нетбук — замечательно. Мы же предпочитаем делать аккуратный серверный шкаф и размещать сервер и все контроллеры там.
Оптимальное решение
И тут на помощь приходит такая замечательная вещь как одноплатный компьютер.
Рынок одноплатные компьютеров стал активно развиваться с 2011-2012 гг., когда был выпущен британский одноплатник Raspberry Pi. Первые же эксперименты показали что Raspberry отлично подходит в качестве сервера Умного дома, популярность которого начала также расти в 2011-2012 гг.
Основные плюсы использования одноплатных компьютеров в качестве сервера Умного дома:
- очень небольшая цена — от 20 USD в Китае до 50-70 USD в магазинах СНГ
- по техническим характеристикам отлично подходит для Умного дома
- надежность
- небольшой по размерам
Фото одноплатника
Самые популярные одноплатные компьютеры для создания Умного дома:
- Raspberry Pi
- Orange Pi
- Banana Pi
- CubieBoard
- и другие.
В качестве бонуса
По ссылке вы можете посмотреть что используют в качестве сервера текущие пользователи MajorDoMo.
виды и для чего он нужен
Сервер умного дома – это «мозг» системы управления. Он реализует и поддерживает работу всей сети. Генерирует и посылает необходимые сигналы на контроллеры, которые отвечают за управление датчиками, сигнализацией, климат-контролем, прочими функциями и режимами, заложенными в программное обеспечение.
Виды сервера
Управление умного дома осуществляется с сервера. Он может быть централизованным (стационарным) и децентрализованным (может работать удаленно).
Серверная стойка умного дома класса De Luxe
Основные требования к серверу:
- Стабильная работа.
- Обязательное резервирования данных.
- Контроль версий ПО.
- Возможность обновления и доработки функционала.
- Быстрая наладка в случае сбоя.
Стационарный сервер, который поставляется в комплекте для умного дома, стабилен и имеет широкий функционал, но также имеет некоторые недостатки. Это и стоимость, и необходимость установки дублирующего устройства, на случай выхода из строя основного прибора. Главным недостатком можно считать невозможность управления системой на расстоянии.
Сервер и web-сервер умного дома среднего объекта
С появлением планшетных ПК и смартфонов, стало возможным управление различными приборами дистанционно, что значительно упрощает жизнь. Если установить управление умным домом на базе сервера с удаленным доступом, то взаимодействие с системой станет на порядок более эффективным.
Платформа Raspberry Pi 2 для построения веб-сервера умного дома
Web сервер для умного дома — это микро, планшетный компьютер или смартфон. Платформой для него может быть любое устройство с большим объёмом оперативной памяти (Raspberry Pi 2 или Raspberry Pi 3, AC500-eco, Arduino), мощным процессором и возможностью выхода в сеть Интернет. Web сервер в составе системы умный дом обеспечивает визуализацию управления через браузер.
Веб сервер для умного дома работает по простому принципу. Мобильное устройство выступает в качестве основного ядра, дистанционно отправляющего командные сигналы. Программное обеспечение, которое можно купить или прописать самостоятельно, превращает Android, Linux или Windows устройства в диспетчерскую станцию, взаимодействующую с контроллерами по wifi. Преимущества блока web умный дом в том, что можно не только управлять системами в доме, но и производить любые операции извне. Также возможна настройка на расстоянии и хранение данных на облаке.
Интерфейс управления умным домом
Функционирование системы невозможно без интерфейса (универсального средства управления). Принцип его работы базируется на возможности выхода в интернет, то есть это программная платформа, позволяющая комплексно управлять всеми домашними автоматизированными системами. Также интерфейс умного дома обеспечивает информационное взаимодействие и поддержку рабочего состояния. Такая система совместима с любым ПК или смартфоном с различными платформами.
Интерфейс умного дома создается для каждого пользователя индивидуально
В современной системе умный дом web интерфейс делают модульной архитектуры, построен на PHP, CSS и JavaScript. ПО прописано в плагинах UI как html или css, расположенных в ресурсах DLL. Их можно добавлять или менять по своему усмотрению. Примерная структура интерфейса выглядит так:
- Стартовая страница на рабочем столе. На ней в виде значков отображаются все элементы управления.
- Плагины содержат разделы, подразделяющиеся на системные (для работы с настройками) и пользовательские (для непосредственного управления функциями).
Самостоятельное создание веб интерфейса для управления умным домом осуществляется с помощью специальных онлайн конструкторов с готовым пакетом данных.
Как сделать сервер для умного дома
Самостоятельно сделать сервер достаточно просто. В корпус неиспользуемого компьютера (желательно брать модель от 2006 года выпуска) монтируется в порядке очередности:
- блок электропитания;
- кулер с пониженным производством шума;
- материнская плата с современным процессором;
- оперативная память, соответствующая требованиям процессора;
- несколько жестких дисков (желательно NAS-систему) и контроллер sata;
- сетевая карта с поддержкой host режима;
- модуль wifi.
Комплектация может видоизменяться в зависимости от требований. Далее следует настройка сервера с использованием полнофункциональных сервисов (подойдет система Linux) и установка программного обеспечения.
Самостоятельная сборка сервера для умного дома под названием AVRobot
Для того, чтобы сделать веб сервер для умного дома, достаточно установить в ПК или смартфон соответствующее программное обеспечение, взаимодействующее с управляемыми системами (датчиками, отвечающими за работу климат контроля, включения света и т. д.).
Умный дом без облачного сервера
Напишу про момент, который лично для меня является очень важным.
Мне не нравится, когда любая техническая система работает через внешний сервер. Будь то видеонаблюдение, устройство IoT или контроллер домашней автоматики.
Любой контроллер сети Z-Wave при первом запуске попросит зарегистрироваться, введя адрес электронной почты, и дальше будет работать через облако, приложение будет подключаться к учётной записи на сервере. Разумеется, будет возможна работа и напрямую, можно не регистрироваться, но тот же Fibaro будет напоминать о необходимости регистрации достаточно часто.
Почему мне не нравится работа через облако:
- Работоспособность системы зависит от работы сервера
- Безопасность системы зависит от безопасности сервера
- Работоспособность системы зависит от того, не заблокируют ли в России сервер
- Работоспособность системы зависит от наличия интернета в доме
- Все мои действия в системе логгируются и обрабатываются на сервере
Нет, я не считаю это своей паранойей. Это в чистом виде надёжность работы системы и её безопасность. Я считаю, что то, что касается домашней автоматизации процессов, должно оставаться дома, а не на сервере, тем более, находящемся в другой стране.
Сейчас общей тенденцией является вывод всего в облака, то есть, хранение всего-всего на сервере. Это удобно пользователю — с любого устройства в любой точке мира можно ввести пароль и получить доступ к своей информации и всем домашним устройствам. И не надо думать о настройке безопасности домашней сети, о VPN, даже о статическом IP адресе, как и о понятии IP адреса вообще. И я не говорю, что это небезопасно. Производитель оборудования своим «добрым именем» гарантирует нам отсутствие возможности доступа к аккаунту сторонних лиц и бесперебойную работу серверов.
Но, одно дело, когда мы даём доступ к охранной системе конкретной фирме (ЧОПу), с которым подписали договор, а другое — когда фирма находится в другой стране, и в России у неё даже представительства нет. У нас уже был прецедент блокировки на некоторое время серверов Xiaomi, разумеется, можно заблокировать таким образом хоть Amazon, хоть Apple.
Всё, что связано с голосовым управлением, откажется работать без интернета. И даже связь между устройствами в одной сети может происходить через интернет, например, Amazon Echo будет обращаться к системе Sonos не по прямому IP адресу, а через учётную запись Sonos (нужно указать логин и пароль для настройки), аналогично происходит обращение, например, к метеостанции Netatmo у контроллера Fibaro Home Center.
Поэтому завязывать управление системой на сторонние серверы мне кажется идеей достаточно неудачной. Но в системах управления от Apple, Google, Amazon, Xiaomi и прочих подобных всё работает только так.
Системы на центральном контроллере (он же ПЛК), как правило, ни к какому серверу не цепляется вообще. Это относится к системам на Beckhoff, Овен и EasyHomePLC, к системам KNX, к контроллеру WirenBoard. И, я считаю, свидетельствует о некоем «профессионализме» этих систем. Да, работать немного сложнее: нужно озаботится безопасностью удалённого доступа, настроить VPN или статический IP адрес, обновлять прошивку при необходимости вручную. Но зато связь пользовательской программы и контроллера будет прямой, без посредников. И безопасность удалённого доступа определяется настройками вводного роутера. Можно вообще запретить контроллеру запросы во внешнюю сеть, и всё будет отлично работать.
8,133 просмотров всего, 2 просмотров сегодня
Home Assistant или еще один «мозг» для проекта типа «Умный Дом» / Habr
Добрый день, уважаемый читатель. На днях довелось мне поиграться с многим уже известной игрушкой от Google – Google Home. Штука хорошая — обзор ее я делать конечно не буду. В чуланеЧитая буржуйские форумы (справедливости ради, нужно отметить, человек я повернутый на автоматизации и IoT), обратил внимание на доселе мне неизвестное нечто, что называют Home Assistant (HASS), эту систему умельцы-то и прикручивают к GH.
В двух словах о самой платформе:
Система написана на Python, последний релиз был 29 января, текущая версия: 0.37.0
Поддерживаемые ОС:
- Windows 10
- Mac OS X
- Ubuntu 14.04
- Raspbian (Raspberry PI)
- iOS App – beta
Поддерживаемые компоненты: 545 шт., включая почти все TV/AV receivers, Broadlink, ZigBee, iCloud, Yandex TTS и многое, многое другое.
Для запуска, подключения и настройки компонентов, выключателей, сценариев, групп, триггеров совершенно не обязательно знать Python, но нужно хоть немного знать yaml.
«Чёйта вдруг?» — подумаете вы.
Отвечаю: настройка всего вышеперечисленного (существующих компонентов) осуществляется исключительно через YAML файл (“configuration.yaml”).
Установка простая – останавливаться на ней и расписывать все шаги смысла не имеет, к тому же у проекта имеется шикарное сообщество, готовое помочь в трудную минуту (Eng). (все ссылки дополнительно помещу в подвале, как предписывает устав)
Будьте готовы, что установка занимает немало времени, на моей RPi 3 общее время (без Raspbian) заняло около часа.
После завершения заветного wget
, я приступил к изучению платформы. Установка HASS производится в директорию: /home/homeassistant
. Нас же интересует /home/homeassistant/.homeassistant/configuration.yaml
.
По умолчанию в конфиге присутствует такой компонент:
# Автоопределение устройств
discovery:
Если у вас в сети имеются такие устройства:
- Google Chromecast
- Belkin WeMo switches
- Philips Hue
- Netgear routers
- Plex media server
- Panasonic Viera
- Roku media player
- Sonos Speakers
- Yamaha media player
- Logitech media server (Squeezebox)
- DirecTV
Они будут обнаружены автоматически и отображены в основной (и пока единственной) группе «Home».
Компонент «http»:
# Включение доступа к frontend
http:
# Убрать тэг комментария и выставить пароль (recommended!)
#api_password: YOUR_PASSWORD
Как абсолютно справедливо отмечено на портале — HIGHLY recommended – из соображений безопасности.
После успешного изменения конфигурационного файла, необходимо перезапустить сервис. Для этого есть два пути:
1) Использовать shell команды:
~ $ sudo systemctl stop home-assistant.service
~ $ sudo systemctl start home-assistant.service
или сразу
~ $ sudo systemctl restart home-assistant.service
2) Выполнить перезапуск из GUI: Развернуть гамбургер, в подвале “Developer Tool” открыть “Services”, в выпадающем списке “Domain” выбрать «homeassistant», в выпадающем списке “Service” – «Restart» и нажать кнопку «CALL SERVICE».
Обращу ваше внимание, что frontend использует кэширование, во время перезапуска или остановки сервиса, страница полностью доступна для просмотра, однако никаких действий осуществить не представляется возможным.
Как только запущен рестарт сервиса, либо через shell либо через GUI, в нижней части экрана отобразится поле показывающее текущий статус сервиса.
Как только сервис поднимется, страница автоматически обновится и поле исчезнет. Если в конфиг закралась ошибка, сервис так и не запустится.
Что необходимо сделать в таком случае:
1) Открыть лог файл: ~/.homeassistant/ home-assistant.log
Записи в логе довольно структурированы, с зачастую, указанием номером строки в configuration.yaml в которой возникла ошибка.
2) Решить проблему указанную в логе
3) Запустить сервис командой выше из консоли
Мы задали пароль, мы выставили (если по какой-то причине не было по умолчанию) автоопределение оборудования, пришло время зайти на портал:
http://IP-Address:8123
8123 — порт по умолчанию.Первый запуск HASS
Что позволяет сделать HASS с ресивером:
Нам доступны: Источник, Громкость, Без Звука (при прослушивании аудио записей, доступны кнопки управления треками).
Теперь же, более подробно рассмотрим yaml-ку. Я привожу несколько расширенную версию, на базе которой будет проще понять какие возможности у HASS есть, а также, возможно, поможет вам в настройке собственного окружения.
configuration.yamlhomeassistant:
# Название окружения запущенного HASS
name: Дом
# Координаты для Зоны Дом*, а также для расчета рассвета и заката
latitude: _REDACTED_
longitude: _REDACTED_
# Высота над уровнем моря – для расчета рассвета и заката
elevation: 0
# 'metric' измерения в метрической, 'imperial' - имперской
unit_system: metric
# Часовой пояс: http://en.wikipedia.org/wiki/List_of_tz_database_time_zones
time_zone: Europe/Moscow
# К описанию элемента customize вернемся позже. Здесь - подключение файла в котором описан компонент
#customize: !include customize.yaml
# Включение frontend GUI. Чтобы скрыть, необходимо закомментировать
frontend:
# Проверка доступных обновлений
updater:
reporting: no
# Отслеживание изменений показателей подключенных устройств и компонентов
logbook:
# Отслеживание закатов и рассветов по гео-координатам и высотой над уровнем моря
sun:
# надиктовывание команд из фронтенд GUI
conversation:
# отслеживание истории показателей
history:
# Автоопределение совместимых устройств
discovery:
# Настройка доступа к ФронтЕнду:
http:
api_password: _REDACTED_
# ssl_certificate: _REDACTED_ # SSL опционально
# ssl_key: _REDACTED_
# base_url: _REDACTED_
# trusted_networks:
# - 127.0.0.1
# - _REDACTED_/24
# ip_ban_enabled: True
# login_attempts_threshold: 5
Зона Дом* — HASS позволяет создавать зоны (локации) по миру, стране, городу (где угодно) на основе гео-координат, для использования их в последующем при создании «автоматизаций» (automation) и оповещений (notify).
Забегая вперед, HASS поддерживает интеграцию с сервисом Telegram, на базе которого я реализовал оповещение, но об этом чуть позже.
Далее нужно отредактировать конфиг файл, перезапустить сервис HASS, перейти на Web страницу и посмотреть, что получилось.
Теперь приступим к первой автоматизации (далее automation). В качестве первой automation, предлагаю рассмотреть «Будильник». Для реализации этой задачи нам не обязательно иметь аудио или видео устройства в сети. Однако, в примере, я покажу использование ресивера в качестве самого будильника.
Задача
Пробуждать в назначенное время, включением AV ресивера, с нарастанием громкости. По истечению определенного времени, синтезировать текст в речь и оповещать просыпающихся о текущей погоде за окном, дабы оделись в соответствии с погодными условиями, также отправка сообщения в Telegram, с информацией о погоде.
Ресурсы
- Raspberry Pi
- Home Assistant
- Сеть (wired/wireless) с выходом в Internet
- VLC
- AV Ресивер (опционально)
- Telegram
- Telegram Bot
- Yandex SpeechKit Cloud
- OpenWeatherMap
Реализация
Для начала нам нужно создать бота в Telegram, для его подключения к нашему проекту. В интернете много инструкций о там, как зарегистрировать собственного бота, поэтому описывать данный процесс не буду. Лишь по ходу описания, буду заострять ваше внимание на важных моментах.
Итак, у нас есть свой Бот. Для его подключения к HASS необходимо в configuration.yaml
прописать следующее:
# Telegram Notifier
notify:
- name: NOTIFIER_NAME (имя которое впоследствии будет использоваться для идентификации компонента ‘notify’ - eng)
platform: telegram
api_key: ABCDEFGHJKLMNOPQRSTUVXYZ
chat_id: YOUR_CHAT_ID
Однако если планируете добавить несколько сервисов оповещения, лучше использовать вложенный файл. Значительно упрощает читаемость конфигурационного файла.
О том как это сделать будет написано ниже.
Как видно из комментариев, нам необходимо API выданное нам для Бота, а также, Chat ID. Для того, что бы его получить Chat ID, нужно написать вашему Боту хотя бы одно сообщение, после чего открыть страницу с адресом:
https://api.telegram.org/bot*API*/getUpdates.
Где *API* — API выданное вам.
В результате вы получите некий JSON, в котором нас интересует следующее:
{"<b>id</b>":<b>123456789 </b>…}
Значение ID нам и нужно.
Далее, подключим компонент отвечающий за синтезирование текста — SpeechKit Cloud Yandex.
Для этого нам необходимо зарегистрироваться и пройти несколько несложных шагов настройки.
Выбрать из подключаемых сервисов API SpeechKit Cloud и получить ключ.
В configuration.yaml
внести следующую запись:
tts:
- platform: yandextts # Определение платформы по работе с компонентом TTS
name: yandextts # Имя компонента, для использования в последующем
api_key: 'API к SpeechKit'
language: 'ru-RU' # Язык произносимой фразы – по умолчанию ru
codec: 'mp3' # Формат генерируемого аудио файла
voice: 'jane' # Голос диктора
emotion: 'good' # Настроение диктора
speed: '1' # Скорость речи
Пояснения и варианты параметров доступны на сайте Яндекс.
Теперь у нас есть аж два сервиса по оповещению, но нам «маловато будет», придется добавить еще один: VLC.
Так как я изначально использовал Raspberry PI, VLC я устанавливал простой командой:
sudo apt-get install vlc
Далее, нужно настроить параметры звука на Raspberry — устройство воспроизведения по умолчанию и проделать нехитрую манипуляцию с правами доступа пользователя, который был создан при установке HASS AIO (All-In-One).
sudo usermod -a -G audio homeassistant
Команда добавляет пользователя в группу audio.
В configuration.yaml
вносим строку:
media_player: !include media_player.yaml
В родительской папке создаем файл:
media_player.yaml
где будут храниться все настройки для медиа устройств которые мы будем подключать.Вносим следующие настройки:
- platform: yamaha
name: Yamaha_671
zone: 2
# Определяем кастомные элементы управления - опционально
commands:
turn_on:
service: media_player.turn_on
turn_off:
service: media_player.turn_off
volume_up:
service: media_player.volume_up
volume_down:
service: media_player.volume_down
customize: # изменяем отображение на frontend данного устройства
media_player.yamaha_671:
hidden: true # скрываем устройство yamaha_671 - зона основная (Main)
- platform: vlc
name: vlcmp # название нашего плеера VLC
У моего ресивера имеется две зоны воспроизведения (Main, Zone 2). В примере я использую второю.
Все дополнительные компоненты подключены. Можем переходить к настройке самого элемента будильника.
Добавим в конфигурационный файл строку:
## Input Boolean
input_boolean: !include input_boolean.yaml
Создаем файл в родительской папке:
input_boolean.yaml
Вносим следующие строки:
alarmweekday: #создаем переключатель - Будить только в рабочие дни
name: Рабочая неделя
initial: on # Значение по умолчанию
icon: mdi:calendar
Как видно из названия yaml, мы подключаем компонент типа «Выключатель». Единственное что мне кажется дополнительно стоит описать это icon. Мы можем использовать любые иконки из библиотеки MDI.
Для выставления времени можно использовать компоненты:
input_slider
input_select
Один представляет собой выбор из списка. Другой слайдер. Я воспользовался удобным в настройке слайдером.
В configuration.yaml
прописываем:
## Input Slider
input_slider: !include input_slider.yaml
Как уже завелось в родительской папке создаем файл:
input_slider.yaml
Далее заполняем его:
alarmhour:
name: Часы
icon: mdi:timer
initial: 8 # значение по умолчанию
min: 0 #Минимальное значение
max: 23 #Максимальное значение
step: 1 #Шаг изменения
alarmminutes:
name: Минуты
icon: mdi:timer
initial: 40
min: 0
max: 59
step: 1
И еще одну нехитрую штуку нам предстоит сделать: сенсор.
В конфиге прописываем:
sensor: !include_dir_merge_list sensors
Эта команда означает, что брать следует все файлы из папки sensors. В свою очередь, в папке sensors создаем yaml файл с названием:
alarmclock.yaml
. Настройка alarmclock.yaml
:- platform: template
sensors:
alarm_time:
friendly_name: 'Будильник '
value_template: '{{ states.input_slider.alarmhour.state | int }}:{% if states.input_slider.alarmminutes.state|length == 1 %}0{% endif %}{{ states.input_slider.alarmminutes.state | int }}'
Тут интереснее. Появляется некий template. Этот компонент позволяет всячески управлять данными других компонентов HASS. В данном примере, мы создаем сенсор и заполняем его данными из слайдеров будильника, принудительно приводя значение к int и добавляя «0» если «длина» минут == 1. Более подробно о возможностях можно узнать на портале HASS.
Нам потребуется еще один сенсор — погодные условия.
Среди всех доступных компонентов типа weather мой выбор пал на OpenWeatherMap Sensor. В папке sensors необходимо создать файл weather.yaml
и наполнить его следующим:
- platform: openweathermap
api_key: *API*
latitude: *latitude*
longitude: *longitude*
monitored_conditions:
- weather
- temperature
- wind_speed
- humidity
- clouds
- rain
- snow
Как не трудно заметить, нам потребуется для интеграции API от OWM. API бесплатное, и получить его можно зарегистрировавшись на портале. Сохраняем, закрываем, идем дальше.
Выключатели, слайдеры и сенсоры для будильника мы создали. Только чего ж включать, если самого будильника пока нет?
Приступим к созданию automation.
В configuration.yaml
прописываем:
## Automation for: alarmclock...
automation: !include_dir_merge_list automation
Это значит, что будут подгружены все файлы из папки automation. Теперь создаем в родительской директории папку «automation».
Создаем файл: alarmclock.yaml
И приступаем к заполнению.
Так как у меня используется инкрементирование громкости каждую секунду — файл большой. Я приведу самые необходимые строки, остальное можно настроить по аналогии.
Automation для Будильника- alias: 'Будильник '
trigger:
platform: template
value_template: '{{ states.sensor.time.state == states.sensor.alarm_time.state }}' # Определение тригера.
condition: # Условия
condition: or
conditions:
- condition: and
conditions:
- condition: state
entity_id: input_boolean.alarmweekday
state: 'on'
- condition: time
weekday:
- mon
- tue
- wed
- thu
- fri
- condition: state
entity_id: input_boolean.alarmweekday
state: 'off'
action: # Действия
- service: notify.NOTIFIER_NAME
data_template:
title: Доброе утро, Дружище! =)
message: "Просыпайся, на работу пора! За окном сейчас {{ states('sensor.owm_temperature')|int }} °C."
- service: media_player.turn_on # Включаем медиа плеер
entity_id: media_player.yamaha_671_zone_2 # Указываем, какой именно медиа плеер нас интересует
- service: media_player.volume_set # Устанавливаем громкость
data:
entity_id: media_player.yamaha_671_zone_2# Указываем, какой именно медиа плеер нас интересует
volume_level: '0.20' # Значение параметра Громкость
- service: media_player.select_source # Выбираем источник
data:
entity_id: media_player.yamaha_671_zone_2
source: NET RADIO
- delay: 00:00:10 # Пауза
- service: media_player.volume_set # Устанавливаем громкость
data:
entity_id: media_player.yamaha_671_zone_2
volume_level: '0.25'
- delay: 00:00:01 # Пауза
- service: media_player.volume_set # Устанавливаем громкость
data:
entity_id: media_player.yamaha_671_zone_2
volume_level: '0.30'
# Тут было много повторяющихся блоков с растущим значением громкости каждую секунду
- delay: 00:00:01
- service: media_player.turn_on # Включаем опять, вдруг выключен. (В идеале лучше выносить в отдельный automation)
entity_id: media_player.yamaha_671_zone_2
- service: media_player.select_source
data:
entity_id: media_player.yamaha_671_zone_2 # Выбираем источник - теперь это вход Audio 2 - именно к нему подключен RPi
source: AUDIO2
- service: media_player.volume_set
data:
entity_id: media_player.yamaha_671_zone_2
volume_level: '0.70'
- delay: 00:00:01
- service: tts.yandextts_say # Вызываем Яндекс
data_template:
message: "Любезный сударь! Извольте выслушать краткую сводку новостей о погоде. За окном сейчас {{ states('sensor.owm_temperature')|int }} градусов." # Указываем какой текст нам необходимо синтезировать
entity_id: media_player.vlcmp # Указываем, какой медиа плеер должен воспроизвести поток
language: 'ru-RU'
«Ура! Заработало!». Но чтобы все сделать красиво, предлагаю совершить еще одно несложное действие. Создать группы (вкладка на фронтенде).
Создаем файл group.yaml
в родительской папке. В конфиге ссылаемся на него:
group: !include group.yaml
И приступаем к заполнению
group.yaml
.Настройка отображения созданных элементов# Определяем какие вкладки и элементы будут отображаться во frontend, а также, что будет отображаться на основной вкладке.
default_view:
view: yes
entities:
- group.AlarmClock
- sensor.alarm_time
- sensor.owm_cloud_coverage
- sensor.owm_condition
- sensor.owm_humidity
- sensor.owm_rain
- sensor.owm_snow
- sensor.owm_temperature
- sensor.owm_wind_speed
#Определяем какие элементы входят в состав группы
alarmclock:
name: Будильник.
entities:
- sensor.alarm_time
- input_slider.alarmhour
- input_slider.alarmminutes
- input_boolean.alarmweekday
#Вкладка (tab) описываем состав вкладки.
AlarmClock:
name: Будильник
view: yes
entities:
- group.alarmclock
Настала пора сохранить все наши настройки, перезапустить сервис и посмотреть, что получилось!
На данный момент у меня подключены следующие компоненты:
TV, AV Ресивер, роутер TP-Link, ведется отслеживание устройств, оповещение меня и жены, когда кто-то из нас пришел\вышел из дома, автовключение ресивера, когда кто-то появляется дома первый, выключение устройств при выходе всех из дома, временно: Broadlink + Livolo Switch.
Развитие
- Подключиться к DIY выключателям света
- Попытаться подключиться к кофемашине и чайнику
- Сделать кнопки у кровати для более простого выключения будильника!
- Создать более оптимальные «автоматизации»
Дорогой читатель, я благодарен тебе, за твое бесценное время! Если к HASS будет живой интерес, опишу и другие возможности с примерами. До новых встреч!Список литературы