В обычной жизни я не только тестирую оборудование умного дома, но и очень много путешествую. Любимое хобби в поездках – трекинг, особенно в холмистой местности. Ходил я и по лестницам Непала, и по левадам Мадейры, и по козьим тропам Азорских островов. К чему это я? Многим облака кажутся милыми, белыми и пушистыми. Но когда ты поднимаешься по тропе, и тебя после определенной высоты накрывает облако, мало не покажется. Сыро, мокро, противно, а потом еще и скользко. Приходится разворачиваться и спускаться обратно, по скользкой каменистой тропе подниматься нельзя.
В индустрии информационных технологий в 2006 году появились свои облака, которые позволяют не тратиться на собственную инфраструктуру, а буквально в один клик использовать доступные сервисы, расположенные у облачного провайдера. Все очень просто: покупаешь «железку», ставишь приложение на смартфон, указываешь нужные сценарии – и все работает. Но нет ли здесь подвоха? Не станут ли облака препятствием, из-за которого придется разворачиваться и все менять? В этом мне как раз хочется разобраться вместе с читателями.
В первой статье цикла я рассмотрю полезные свойства облаков, расскажу о возможных рисках и приведу примеры. Можно ли пользоваться облаками, не подвергая риску автоматизацию умного дома? И как лучше всего это сделать?
Следующие статьи будут практическими: я закуплю различные железки Aqara и воспользуюсь их частным облаком. А затем я перейду с облака на локальные решения, причем рассмотрю разные варианты: и для «чайников», и для более опытных пользователей.
Почему облако?
Облачные технологии дают несколько преимуществ, позвольте вкратце их напомнить.
- Доступность. Можно обращаться к ресурсам и сервисам облака из любого места, был бы интернет.
- Удобство использования. Покупателю облачного устройства не нужно ничего делать для настройки. Достаточно указать пароль от Wi-Fi, после чего умная розетка подключается к облаку. Управлять устройством можно из браузера или приложения.
- Обновление и резервирование. Облачные сервисы обновляются автоматически. Кроме того, за хранение данных отвечает облачный провайдер. То есть даже если локально какие-то данные будут потеряны (например, статистика), они останутся у провайдера.
- Стоимость. В отличие от локальных решений для облачных устройств никакого контроллера не требуется. Не нужны и локальные хранилища. Можно купить самую дешевую «железку» с микроконтроллером – ее достаточно для работы с облаком. При этом даже дешевые видеокамеры могут дать хорошее качество и функции благодаря облачным технологиям, например, XMEye.
- Масштабируемость. Если требуется дополнительное место для хранения потока облачной видеокамеры — его можно просто докупить. Добавление домашних устройств выполняется предельно просто — все они появятся в приложении после подключения к сети Wi-Fi, дополнительных действий не требуется.
Но позвольте взглянуть с другой стороны: у вас в доме с десяток умных устройств, и вместо передачи информации напрямую друг другу они вынуждены обмениваться данными через интернет. Не кажется ли это бредом? Здесь у читателя должно зародиться первое зерно сомнения в том, что облако нужно использовать всегда и везде.
Выше мы рассмотрели преимущества для клиентов, которые покупают «железки» условно на Ali Express, после чего заполняют ими свой умный дом. Частный пользователь при выборе облачных решений голосует кошельком, ему так дешевле и проще. Но почему крупные вендоры, такие как Сбер или Яндекс, тоже предпочитают облачные решения на базе Tuya или Aqara, например? Почему вместо созданных с нуля интересных железок приходится покупать брендированные китайские устройства с китайским же облаком Tuya? Хотя справедливости ради отметим, что Яндекс и Сбер сейчас переходят на российские серверы и облака.
Пока компания не специализируется узко на умном доме, а рассматривает его как дополнительный сервис, все будет так и происходить. Дополнительные сервисы реализуются в режиме «подешевле и попроще».
Суть проста: с точки зрения первичного входа использовать готовое облако проще и дешевле.
Чтобы сделать свою экосистему, нужно потратить огромные деньги на разработку. Даже в большой компании придется выделить значительные ресурсы, время, все остальное. Яндекс развивают свою экосистему уже несколько лет, но только сейчас запустила отдельное приложение для умного дома. Недавно, кстати, компания выпустила колонку Станция 2 с Zigbee. Сбер в этой теме пока догоняющий, хотя ресурсы здесь не меньше.
По этой причине Сбер и Яндекс для своих экосистем выбрали облако Tuya или Aqara. У Tuya очень развитая платформа: ты можешь стать разработчиком, сделать собственные прошивки и выпустить свое приложение, особых трудозатрат не нужно, поскольку Dev Kit есть. Очень простой, очень быстрый и очень дешевый старт. Именно по этой причине большинство компаний в мире так и поступают.
У Tuya есть свои чипы, можно на них делать, можно на других, вариантов множество. Выпускается все на множестве производств, клиент может прийти на завод и заказать партию под своим брендом.
В результате устройства Сбера добавляются в приложение Tuya с соответствующими идентификаторами. На разработку прошивки ресурсы тоже не требуются, можно взять стандартные прошивки Tuya и заменить ID.
Сырые и противные облака
Чтобы лучше понять риски использования облаков, я просто расскажу о недавних примерах.
Пример 1. Облако Tuya. В свете последних событий Tuya, не желая попасть под вторичные санкции, ограничила доступ к своим сервисам. Была затронута и экосистема Сбер, новые устройства попросту отказались подключаться через приложение «Сбер Салют», хотя старые работали.
Возникли проблемы и у разработчиков, которые используют данную систему. Компания Tuya категорически отказывалась на протяжении многих лет установить собственные серверы на территории России, поэтому основная инфраструктура по-прежнему обитает в Китае со всеми вытекающими: если облако отключить от нашего сегмента, все попросту перестает работать.
К счастью, проблема со Сбером была решена переходом на российское облако, но осадочек остался. Потенциально уязвимы все устройства, которые работают с облачной экосистемой Tuya. А их очень и очень много. Причем это касается устройств и Wi-Fi, и Zigbee, которые подключаются через хабы. Для экосистемы Tuya по-прежнему необходимо рабочее приложение, авторизация и т.д. Если нет уже установленного приложения, то могут возникнуть проблемы – приложение просто не инсталлируется, если оно заблокировано из-за санкций. Конечно, есть альтернативные приложения, которые поддерживают облако Tuya, и они пока работают. Например, Tuya Smart Life. Но если ситуация будет усугубляться, то сервисы могут стать недоступными.
Что может при этом сломаться? Все взаимодействие между устройствами, в том числе подключенными и настроенными. Облачные решения здесь сами по себе порочны, потому что не всегда умеют работать локально. То есть Wi-Fi-лампочка идет в интернет, на какой-то сервер, чтобы получить команду или сообщить о своем состоянии. То же касается Wi-Fi-розетки и других Wi-Fi-устройств, а также периферии Zigbee, которая взаимодействует с Wi-Fi-устройствами.
Конечно, некоторые экосистемы (Сбер) предусматривают дополнительное локальное взаимодействие устройств через Wi-Fi (розеток, ламп и т.д.), поскольку оно работает быстрее. Но насколько долго оно будет работать без доступа в облако – неизвестно. Возможно ли будет добавить новое устройство без облака?
Наихудшая ситуация – когда вся настроенная автоматизация начинает отваливаться. Но в этом и проблема облачных подходов: централизованная аутентификация настроена где-то там в облаке, а устройства находятся здесь.
Пример 2. Insteon. Компания просто взяла и закрылась. Перестал работать сайт, в розничных магазинах – голые стены, техподдержки нет. Устройства и даже хабы просто перестали работать, все сценарии автоматизации отказали. А поскольку протокол проприетарный (его называли конкурентом Z-Wave и Zigbee), то к чему-то другому устройства не переподключить. Компания на рынке была довольно давно, она выпускала широкий ассортимент устройств для умного дома: лампочки, термостаты, розетки, датчики и т.д. Все они работали через фирменное облако и приложение.
Конечно, есть шанс, что можно настроить устройства для локального управления. Какая-то локальная интеграция у них есть, в том же Home Assistant или OpenHab. Теоретически можно взять хаб и настроить локальную работу. Но для настройки необходимо рабочее облако, которого нет. Можно ли выполнить настройку вообще без облака – неизвестно. Здесь пока больше вопросов, чем ответов. Но работы в данном направлении ведутся.
К счастью, проблема Insteon все же была решена: компанию купила группа энтузиастов, которая решила вернуть к жизни хабы и облако.
То, что происходит с пользователями в России, показательно для любой страны. Компания по тем или иным соображениям может ограничить доступ любой категории пользователей. Это может произойти когда угодно и где угодно.
Пример 3. Philips HUE. Из-за санкций компания прекратила поддержку одноименного навыка в доме Яндекса. Поэтому управлять гаджетами Philips Hue через Алису не получится, придется использовать родное приложение. Обидно.
Пример 4. Google Home. Приложение исчезло из магазинов App Store на iOS и Google Play на Android для пользователей РФ. Экосистема Google Home отвечает за управление умными устройствами, в нее интегрируется огромное количество различных устройств, так как подобная интеграция является довольно простой и доступной для разработчиков и производителей. Но за всё время своего существования, управлять устройствами с использованием русского языка через голосового ассистента Google Assistant, который занимался обработкой голосовых запросов к умному дому Google, было практически невозможно. На смартфонах поддержка русского языка еще как-то работала, но с телевизорами на Android уже были проблемы, не говоря уже про умные колонки. Google Home так и не получил широкую популярность из-за конкуренции со стороны русскоязычных сервисов, но все равно обидно.
Пример 5. IBM Watson и Google Cloud. Судя по информации The Register, IBM закрывает платформу Watson для интернета вещей IoT в своем облаке IBM Cloud c 1 декабря 2023. С этой даты доступ к API платформы будет прекращен. Устройства не смогут подключаться к конечным точкам MQTT и HTTP, существующие подключения будут разорваны. Всем клиентам предложено перейти на альтернативные сервисы к этой дате.
Ранее было объявлено о прекращении поддержки IoT сервисов на облачной платформе Google Cloud с августа 2023. Устройства IoT на данной платформе с этой даты не смогут подключаться к мостам MQTT и HTTP.
Обратите внимание, что последний пример IBM и Google не связан с какими-либо санкциями и ограничениями по странам. Просто компаниям так захотелось. А все клиенты, которые за несколько лет успели вложиться в облачную инфраструктуру, останутся ни с чем.
Безопасность. Отдельно стоит вопрос безопасности: разумно ли доверять сторонней компании управление критически важной структурой умного дома? Камерами, отоплением и кондиционированием, освещением, наконец? Банальное отключение интернета может привести к тому, что вся автоматизация перестанет работать, а камеры не будут записывать видео. То же самое может случиться просто потому, что компания не захотела вас обслуживать. Примеры выше. И я еще не затронул проблему хранения персональных данных «где-то там», к которым может получить доступ злоумышленник. И вопрос коммерческого использования накопленных Big Data в интересах компаний.
Вывод простой: когда управление твоим домом зависит от кого-то другого, эта история не про безопасность.
Неужели я предлагаю полностью отказаться от облаков? Отнюдь. Облака сохраняют все преимущества, перечисленные в начале статьи. Они весьма удобны для хранения статистических данных. Например, вряд ли есть смысл хранить историю всех датчиков за несколько лет дома. Но если возникнет желание сравнить потребления тепла в холодную и теплую зиму, то здесь удобно воспользоваться облаком, которое предоставит статистику.
Главный вывод статьи простой: умный дом должен быть локальным. К нему можно добавлять облака, но только опциональные, которые не будут влиять на работу основных сценариев автоматизации.
Путь самурая
У самурая нет цели, у самурая есть путь. Отчасти это верно и здесь, поскольку цель уже была поставлена до нас – автоматизация умного дома. Поэтому мы рассмотрим только путь, а именно как сделать автоматизацию локальной.
Предположим, у вас дома уже есть облачные устройства. Здесь вариантов обычно два: Zigbee или Wi-Fi/Bluetooth.
Zigbee
Куда можно «перепрыгнуть», если человек сидел на облаках Xiaomi или Tuya, например? Желательно, чтобы поменьше «ковыряться».
Я рекомендую перейти на любой OpenSource. Home Assistant или Homebridge для владельцев iPhone (и HomeKit). Есть OpenHAB, есть различные полуготовые решения на основе того же Homebridge. Вариантов много, но все настраивается сравнительно долго.
На ту же первичную настройку Home Assistant уходит 3-4 часа, причем если у человека уже был опыт, знание сценариев и старые конфиги. Новичкам придется потратить выходные или даже больше. Homebridge ставится проще, у знающего человека на него уйдет уже 20 минут.
Если есть «свисток» Zigbee, то можно переключить устройства Zigbee на другие экосистемы с помощью контроллера, но об этом чуть ниже.
Wi-Fi и Bluetooth
Здесь все сложнее, на примере устройств Tuya есть два варианта.
Первый: подключить стороннюю систему «официально» через облако Tuya, но здесь нужна учетная запись разработчика. Это уже само по себе непросто. Нужно получить ключи, которые позволяют подключить все локально. Причем не все «железки» управляются локально.
Второй: перешить на что-нибудь с поддержкой MQTT, типа Tasmota. Но это разбирать, дай бог, если не паять. Нужен UART USB интерфейс, полный DIY. И то если внутри будет ESP, а не их «родной» чип.
Интересно, что устройства Сбера добавляются в приложение Tuya с соответствующими идентификаторами, то есть там нет перепрошивки. ID сменен, все остальное стандартное, как те же прошивки Tuya.
К сожалению, в случае устройств Wi-Fi и Bluetooth простых путей уже нет. Можно ли, например, поднять на роутере облако для оборудования Wi-Fi? К сожалению, нет. Если пользователь заранее не подстраховался и не добавил локальное управление, то сделать ничего не получится.
Кроме того, у той же Xiaomi есть устройства, которые не управляются локально в принципе. Они работают только через облако. Хотя в случае тех же ламп Yeelight можно в настройках включить локальный режим, например.
Для устройств Xiaomi потребуется еще Token, который извлекается из «родного» приложения Mi Home. Именно с помощью Token сервер умного дома общается с устройством. Но чтобы Token появился, устройство необходимо сначала добавить в родное приложение Mi Home через облако.
Контроллер – игла облачного Кощея
Для локального управления устройствами через тот же Home Assistant или Homebridge потребуется контроллер. И здесь я хотел бы остановиться на решении Wiren Board 7. Преимущество контроллера в том, что на нем можно локально реализовать описанные выше сценарии. К Wiren Board выпускается большое число модулей, которые позволяют расширить возможности автоматизации.
Сам по себе контроллер позволяет подключать устройства RS-485 и CAN, «из коробки» поддерживаются протоколы Modbus, MQTT и несколько других. С помощью модулей расширения можно добавить поддержку KNX, Z-Wave и Zigbee. На Wiren Board можно установить Home Assistant, визуальную среду Node-RED или Sprut.Hub.
Контроллер даст локальное решение, которое не будет зависеть от облаков и внешних серверов. При необходимости легко прикручиваются опциональные облачные сервисы, например, голосовое управление через Алису или Марусю. Но, как я и говорил выше, они лишь дополняют умный дом, но не влияют на его базовую автоматизацию.
Заключение: сначала локальное, потом облачное
Иногда простые и дешевые решения таят в себе «подводные камни», о которых узнаешь в самый неподходящий момент. К сожалению, в 2022 году с этим столкнулись многие пользователи облачных сервисов, что можно видеть по приведенным выше примерам. Облачная компания может «умереть» либо ограничить доступ определенным странам, и купленные умные устройства превратятся в тыкву. Можно попытаться что-то реанимировать, но оно вам надо?
Поэтому я рекомендую простое правило: строить локальную экосистему умного дома, а облако добавлять только для дополнительных функций. Конечно, для локального решения придется докупать контроллер, но лучше сразу заплатить за надежность и безопасность, чем решать проблемы в будущем. Тем более если бюджет поджимает, то можно собрать «малинку» за копейки буквально на коленке. Я предпочел «взрослый» контроллер Wiren Board, но решайте сами.
В следующей статье цикла я соберу несколько устройств Aqara в фирменное облако, а затем переведу их на локальный контроллер Wiren Board. Причем сначала я воспользуюсь простым вариантом на оболочке Sprut.Hub, затем рассмотрю Node-RED и скрипты Wiren Board. Придется ли пойти на компромиссы? Будут ли «подводные камни»? Какие преимущества я получу? Все это вы узнаете в ближайшее время.
