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

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

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

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

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

1. Глубокая интеграция — решение не ставится поверх существующего ремонта и электропроводки, а интегрируется в квартиру на этапе ремонта. Это сокращает рынок сбыта, но позволяет выстроить решение «всё-в-одном» и объединить все подсистемы в единую сущность
2. Надежность — из-за глубокой интеграции к системе предъявляются дополнительные требования по безопасности и надёжности. Не стоит экономить на элементах, без которых не возможно базовое функционирование помещения
3. Свобода интерьерных дизайнов — независимость от типов светильников, выключателей и прочих устройств, с которыми взаимодействует пользователь
4. Локальное управление — гарантия приватности и отсутствия «длинных» звеньев в цепи управления
5. Модульность — система должна быть модульной и поддерживать горизонтальное масштабирование: от однокомнатной квартиры до трехэтажного дома
6. Простота установки и настройки — систему может поставить обычный электрик ремонтной бригады с базовым набором инструмента и знаниями
7. Обратная UX-совместимость — должны поддерживаться все существующие сценарии взаимодействия с пользователем
8. Минимум новых интерфейсов — чем меньше новых пользовательских интерфейсов, тем лучше
9. Future-proof — система должна иметь возможность интеграции с текущими и будущими интерфейсами и протоколами
10. Массовый рынок — система должна отвечать запросу большинства, и не дорабатываться под каждого покупателя
    
11. Цена — должна быть приемлемой для современного ремонта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Управление освещением и вентиляцией с приложения на телефоне
• Защита от утечек воды
• Локальное / удаленное управление тёплыми полами
• Гибернация — выключение света, отключение теплых полов и (опционально) перекрытие воды, когда пользователь ложится спать или уходит из квартиры
  

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

• промышленный ПЛК, под который написали программу для управления освещением
• отдельный контроллер управления водой с детекцией утечек
• термостаты с проводным интерфейсом RS-485

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

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

• какие кабели куда тянуть
• какое место оставлять под систему
  
• почему нельзя «как обычно»

И так далее.

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

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

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

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

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

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

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

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

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

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

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

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

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