Как я шатал рынок «умных» домов: часть 2

В первой части мы прошлись по идеологии и проблемам существующих решений. Здесь переходим к самому интересному: концепции, архитектуре и MVP.

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

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

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

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

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

Давайте пройдёмся по слоям снизу вверх.

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

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

Этот слой находится над уровнем сенсоров и актуаторов и выполняет всю «грязную работу» по включению освещения, перекрытию воды и подогреву пола.

Основная задача этого сегмента с точки зрения UX — полностью восстановить текущий опыт использования квартирой: по нажатию на выключатель загорается свет, на термостате можно отрегулировать температуру пола, и так далее. Разница лишь в том, что контроллер также предоставляет возможность для управления извне (сверху).

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

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

Сервер управления — один на всю систему, он же отвечает за всю бизнес-логику и связывание контроллеров друг с другом. Приложение на телефоне взаимодействует также с ним. Этот уровень самый сложный с точки зрения ПО: ведь ради него и строится вся система.

Однако требования по надежности тут не такие высокие, как к контроллерам, ведь сломанный интерфейс приложения не оставит пользователя без света — выключатели на стене всё так же доступны и работают. Пользователь будет недоволен, но не так сильно.

Чтобы вовремя детектировать и предотвращать проблемы с сервером, нам понадобится ещё один уровень, общий для всех систем.

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

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

Знакомый согласился поставить первую версию системы в свою однокомнатную квартиру на этапе ремонта (Ю.П. — огромное спасибо).

Этот MVP особенно важен — в случае неудачи ремонт будут переделывать за мой счет. Поэтому было нужно с первого раза получить боевую работающую систему с надежностью не хуже обычной электропроводки.

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

Наш опыт в промышленной автоматизации дал о себе знать — в качестве контроллеров мы взяли:

В качестве сервера был выбран обычный Raspberry Pi c Home Assistant на борту. Для него были написаны плагины интеграции с контроллерами (HA — открытое ПО, которое на момент MVP только набирало обороты).

Также мы составили подробное ТЗ для электриков:

И так далее.

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

Экшн в подписях к картинкам:

Этот проект мы делали по себестоимости. Монтаж, разработка ПО и интеграция вышли бесплатно, т.к. делались своими силами. Стоимость оборудования, кабелей и доп. затрат на работы ремонтной бригады не превысила 200 т.р.

UX не сломался: гости, не знающие об установленной системе, щёлкали выключатели и пользовались квартирой как обычно. У владельца квартиры появился дополнительный интерфейс и возможность «переводить квартиру в спячку»: выключать свет, теплый пол, перекрывать воду.

В течение 7-8 месяцев работы системы мы столкнулись с двумя проблемами:

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

Это блокер, т.к. портит базовый опыт пользования квартирой.

Сервер управления:
Из-за большого количества данных начали лететь карты памяти.

Были перепробованы самые дорогие и надежные — результат один: от 3 до 9 месяцев. Дальше всё — ошибки про рид-онли память и кирпич.

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

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

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

Update: третья часть