- PVSM.RU - https://www.pvsm.ru -
Мы предлагаем вашему вниманию статью Владислава Зайцева(vvzvlad [1]), приглашенного гостя нашего блога. Владислав давно занимается темой «умных домов», и обобщив свой опыт, он предлагает следующие основные принципы дизайна такого рода систем.
Сегодня я хочу поговорить с вами об «умных» домах в частности и IoT-устройствах в целом. Но это будет не обычная статья: тут не будет железок, ссылок на производителей, кусков кода и репозитариев на гитхабе. Сегодня мы будем обсуждать нечто более высокоуровневое — принципы, по которым организуются «умные» системы.
Продолжая читать статью, вы соглашаетесь с тем, что вас устраивает следующий disclaimer.
1 [2] которыми сложнее, чем обычными выключателями — не умный дом.
Любая новинка должна тестироваться на соответствие этому принципу. Если она не облегчает жизнь, и вы не понимаете, как сделать так, чтобы она облегчала, ей не место в умном доме. Вы можете попробовать представить её как обучающую систему.
Грош цена крутому инструменту, которым нельзя нормально пользоваться. Удобные и надежные устройства с ограниченным функционалом имеют больше шансов на успех, чем сложные изделия на «все случаи жизни».
Не понимаете, как сохранить и кучу функций, и простой интерфейс? Запихиваете все функции подряд в надежде, что пользователь сам разберётся, что ему надо? Вон из профессии!
Не понимаете, как совместить удобство и кучу настроек? Пожертвуйте настройками. Любая функциональность будет круче, чем обычный выключатель, а вот излишняя сложность легко заставит пользователя вернуться к выключателю.
То же самое относится и к качеству работы. Кнопка, которая просто включает свет, лучше, чем регулирующий яркость слайдер, который иногда глючит:
Мало надежного, но проверенного функционала лучше, чем много, но работающего кое-как.
Один из механизмов, закреплённых в человеческой психике эволюцией — более активная реакция на отрицательные стимулы. Отрицательные факторы важнее положительных: пропустить приближение опасного хищника гораздо страшнее, чем не заметить и не съесть вкусный фрукт на дереве. Если в вашей системе нет каких-то функций, это не страшно, это всего лишь отсутствие положительного стимула. А вот функция существующая, но работающая плохо — это отрицательный стимул: он запоминается легче и помнится дольше.
2 [3] между щелчком обычного выключателя и включением света, он не должен заметить её и в вашей системе.
Современное железо работает с очень высокой скоростью. Нет проблемы достичь частот в десятки мегагерц на микроконтроллерах и как минимум десятков килобит в секунду даже по радиоканалу. Если вы в этих условиях не можете сделать систему, задержек в работе которой пользователь не ощущает — вон из профессии!
Ваша система — лишь небольшой кусочек жизни человека. Время жизни человека превышает срок эксплуатации системы в лучшем случае в пару раз, а в худшем — на порядок. Ваша система уйдёт так же, как и придёт, а жизнь человека продолжится. И в этой жизни у человека есть сформированные привычки касаемо предпочтительной яркости света, местоположения выключателей, как ему удобно включать свет и управлять климатом у себя дома.
Нельзя пытаться насильно менять эти привычки. Предлагать — можно. Заставлять — нельзя.
Нельзя сказать пользователю «теперь ты будешь включать свет с телефона — это стильно, модно, молодёжно». Это нарушение данного принципа и нескольких других.
А что же делать?
Если вы считаете, что ваш способ управления системами дома лучше, чем старый, предложите его пользователю. Если это действительно удобнее, он сам выберет новый (да, разным людям подходят разные способы). Всё, что вы можете (и должны) сделать — предоставить ему выбор.
3 [4], дайте ему возможность делать это. Должна быть исключена ситуация, когда для совершения определенного действия нет ни физических, ни программных ограничений, но оно недоступно, потому что разработчик подумал «это никому никогда не потребуется».
Если у вас есть устройства разных версий с разными протоколами, позаботьтесь о том, чтобы пользователь об этом знал только в реально необходимых случаях, когда без этого не обойтись. Если вы можете избавить пользователя от получения специальных знаний, пусть и ценой времени разработчиков, сделайте это. Разработчик потратит два дня, а тысяча пользователей по часу. Сорок восемь часов против тысячи? Ответ очевиден.
Как тебе спится, Джон — серийный программист?
Пользователь не обязан знать, что клапан для воды управляется одними командами, а кран — другими. Если и тот и другой управляют водой в трубе, то они оба должны иметь на пользовательском уровне одинаковые интерфейсы: «открыть воду» и «закрыть воду».
Любые, даже самые лучшие приложения на телефоне с виртуальными кнопками управления проигрывают обычному физическому выключателю в нужном месте.
Другое дело, что выключатель должен размещаться именно в нужном месте. Отсюда ещё одно важное правило:
Проводные системы обладают надёжностью, но только радиосвязь позволяет установить новый выключатель или реле для светильника не делая ремонт заново. И перенести, если вам наскучило предыдущее место. Но у этого принципа есть и свои исключения:
Хорошее радио — это такое, которое позволяет не задумываться о том, на каком расстоянии от центрального контроллера надо размещать устройства. Хорошее радио — это протоколы с mesh-сетью [6]: ZigBee, Z-Wave, 6LoWPAN и так далее.
Все остальные варианты — это плохое радио. Wi-Fi — плохое радио. Самодельные протоколы отдельных фирм (их знают самодельщики под названием «433 МГц», хотя они могут быть и на других частотах, и очень сильно отличаться друг от друга) — плохое радио.
Wi-Fi плох тем, что на его основе невозможно сделать полноценные «спящие» устройства, и сложно сделать автоматическую настройку, а также проблемами совместимости с другими Wi-Fi устройствами в доме. Простые самодельные протоколы плохи тем, что зачастую не содержат в себе ни контроля доставки, ни шифрования, ни доступных спецификаций. Ни то, ни другое не имеет mesh-маршрутизации, что часто оборачивается проблемами вида «а я не могу в тот угол выключатель поставить — слишком далеко от передатчика».
В B2B всё понятно: есть пользователь, есть разработчик, а есть эксплуатант — человек или организация, которые знают, как устроена система, и могут с ней работать на профессиональном уровне. Никто не требует от бухгалтера знания программирования под 1C, этим занимается специальный человек. И никто не требует от человека, который арендует офис, понимания, как в нём работает вентиляция — его дело сказать: «У нас в офисе душно».
Грамотное решение о покупке системы основывается на расчете совокупной стоимости владения, которая складывается из цены системы и расходов на ее эксплуатацию.
В системах, которые человек использует у себя дома, всё сложнее. Там эксплуатант и пользователь — одно и то же лицо, и вдобавок зачастую не обладающее необходимыми знаниями о системе. К сожалению, таковы ограничения потребительского рынка. Отсюда следующие принципы:
Вероятность работы, частичная работа и неправильная работа недопустимы. Нельзя допускать ситуаций, в которых ваше устройство работает через раз или не работает один раз из десяти. Если вы считаете, что ваше устройство функционирует неправильно, стоит отключить его вообще — для безопасности и для сохранения положительного пользовательского опыта. Заменять устройство неприятно, но лучше заставить пользователя заменить его, чем формировать мнение «работает через раз» о системе. Система должна быть в строго определённом состоянии: если она сломалась, значит, она не работает, если она не сломалась, значит, она работает.
Если вы твёрдо уверены, что деградация функциональности допустима, всё равно стоит предупредить об этом пользователя внятным сообщением: «Обнаружен выход из строя второго канала диммера. Необходимо заменить диммер. Продолжить использовать первый канал диммера? Да/Нет»
Система должна быть модульной. Если у пользователя ломается датчик, ему должно быть необходимо заменить только датчик. Нельзя требовать менять реле вместе с пультом управления, потому что оно, видите ли, привязывается к нему на этапе производства.
Нельзя даже сказать «новый датчик может установить только наш специалист», потому что, очевидно, с развитием вашей системы специалистов не хватит на миллионы возможных пользователей, а значит, в какой-то момент начнутся проблемы. Конечно, пользователь не будет ремонтировать устройства сам, но при поломке он должен иметь возможность их заменить.
Если что-то пошло не так, пользователь должен знать об этом, и знать, что именно пошло не так.
Нельзя сказать пользователю «Ошибка #45», подразумевая, что это сообщение поймёт только сотрудник техподдержки. Ему надо сказать: «Устройство не отвечает. Попробуйте перезагрузить его, привязать заново или обратиться в сервис. Ошибка #45».
Нельзя обнаружить, что устройство не отвечает (если у вас есть возможность это сделать), и не сказать об этом пользователю. Получать сообщение о проблемах не очень приятно, но гораздо неприятнее понять, что устройство не работает уже неделю, именно в тот момент, когда оно вам срочно понадобилось.
Но в то же время не надо вываливать на пользователя отладочные дампы и многострочные логи. Информация либо нужна пользователю, как в предыдущем пункте, потому что она включает сведения о том, что именно пошло не так, либо не нужна, если эта дополнительная информация непонятна, потому что адресована не ему.
4 [7].
Даёте пользователю возможность обновлять прошивку — пусть она обновляется через стандартный интерфейс (USB/BT/Wi-Fi), или не упоминайте в пользовательской документации об обновлении прошивки с помощью SPI-программатора вообще.
Нельзя требовать от пользователя рассчитывать битовые маски для конфигурации устройства, если эта конфигурация требуется в обычной эксплуатации.
Если раз в месяц у исполнительного блока слетает привязка, и пользователю надо лезть к люстре и привязывать его заново — это плохая система. Если в выключателе надо менять батарейки раз в два месяца — это плохая система. Даже средний срок необходимости обслуживания каждого устройства в полгода — плохо: уже для двадцати устройств в доме пользователю придётся предпринимать какие-то действия в среднем каждые девять дней.
Затраты на расширение системы должны расти линейно. Новый блок должен обходиться в стоимость нового блока.
5 [8].
Не должно быть ситуации, когда новая прошивка датчика может работать только с новой версией управляющего блока.
Такие ограничения положительно влияют на прибыль, заставляя пользователей покупать новые устройства, но это дорога в ад — потеряв доверие пользователей из-за подобных трюков, вы потеряете гораздо больше, чем могли бы заработать.
Система, в которой команды ходят только через внешний сервер — плохая система. Вы можете сколько угодно хвастаться удобными интерфейсами, модными приложениями и крутыми нейросетями, но это всё неважно, если у пользователя вместе с падением интернета пропала возможность включить свет в туалете. Разработчик, ты правда считаешь такую систему хорошей?
А если серьезно, то не очень понимаю, почему этот пункт — это не само-собой разумеющаяся штука. Завязывая систему на внешний сервер вы создаете точку отказа с надежностью обычного сервера, но одновременно для всех ваших пользователей. Внешние сервисы это круто, они позволяют расширить функционал, но не должны быть единственным вариантом оперативного управления. Дополнительного канала управления, резервного хранения, анализа данных — сколько угодно.
Однако, не стоит бросаться и в другую крайность — пытаться сделать систему децентрализованную, а потому абсолютно надежную.
Децентрализованная система — это когда выключатель говорит лампочке «включись», а датчик температуры при понижении этой самой температуры сам включает обогреватель. Распределённая система проигрывает централизованной просто потому, что такая система хорошо существует только в рамках самой простой парадигмы взаимодействия устройств — «устройство управляет другим устройством». Как только сложность системы возрастает, такая система порождает больше вопросов, чем ответов. Если датчиков температуры несколько, то обогреватель должен принимать команды от всех? Или сам должен опрашивать датчики? А если надо принимать решение о включении на основе тенденции, где хранить данные архива? На каждом обогревателе? А не жирно? На каждом устройстве? И гонять трафик при каждом запросе? А где хранить и как изменять логику? А если логика включает внешние элементы? А как хранить логику на «глупых» устройствах? А как её обновлять?
Все эти вопросы исчезают, если смириться и признать необходимость центрального хаба как точки взаимодействия данных и места хранения пользовательской логики. Пусть все устройства будут «глупыми», способными отдавать данные и принимать команды, а задача по хранению архивных данных, обработке этих данных, принятию решений и взаимодействию с внешними сервисами ляжет на тот самый центральный контроллер.
Децентрализованность, кстати, можно сохранить, пусть и частично: ничто не мешает при отсутствии ответа от хаба посылать команды напрямую, как fail-safe режим. Логики не будет, но зато свет включить будет возможно.
Пока мы не живём в мире, где программист ответственен за ущерб, причиненный его программой (хорошо на эту тему написано тут [9]), в программах будет много ошибок. Они будут и в софте умного дома. Единственная возможность, при которой эти ошибки не будут приводить к катастрофическим последствиям — это ограничение самостоятельных действий системы. Потенциально опасные действия должны совершаться как минимум с ведома пользователя, а лучше с его подтверждения. Свет включать можно автоматически: баг в программе приведёт к тому, что пользователь будет разбужен ночью или получит счёт на лишние сто рублей в конце месяца. Неприятно, но вряд ли опасно. Например, включать автоматически воду, если нет механизмов, гарантированно отключающих её при потопе — нельзя. А вот выключать воду — можно, так как это не опасное действие.
Этот принцип не утверждает, что обязательно необходимо запретить автоматическое управление всеми обогревателями, котлами, печами, чайниками и тому подобными вещами. Речь, скорее, о том, что, если вы уж делаете потенциально опасное устройство с программным управлением, позаботьтесь о том, чтобы его опасность не вышла на пользовательский уровень: в управляемом чайнике должны быть «железные» цепи, отключающие его при перегреве; ванна, которая наливается сама, должна иметь датчики затопления; утюг должен иметь возможность отключения, но включаться обратно только при нажатии «железной» кнопки, и так далее.
Настоящий разработчик умных систем должен быть немного параноиком. Нельзя доверять интернету, он может пропасть. Нельзя доверять коду, в нем могут быть баги. Может быть, хотя бы железу можно доверять? Нет. Нельзя доверять своему железу. Реле может залипать, симисторы самопроизвольно открываться, предохранители перегорать. Наконец, пользователь может включать киловаттный чайник в розетку, рассчитанную на 100 Вт. Нужны датчики напряжения, тока, температуры. Вышла температура за пределы? Выключаем всё, отправляем предупреждение. Вышел ток за пределы — выключаем. Отключили реле, а на выходе всё еще есть напряжение? Уведомление. Включили, а напряжения нет? Уведомление!
И даже при всех этих параноидальных штуках, все равно будет ситуация, когда проверки не справились, и у вас что-то сломалось. Выключатель в комнате, роутер, центральный хаб. А свет в туалете пользователю включить хочется. Какой вывод?
Всегда должна быть кнопка, которой можно сделать «закат солнца вручную». Которой можно включить или выключить свет ВОТПРЯМЩАС. Потому что новый хаб привезут завтра, выключатель можно купить новый чуть позже, а свет в комнате хочется выключить именно этим вечером, чтобы спокойно поспать.
Обычные пользователи сделают вам кассу, а хакеры6 [10] — придумают новые функции. Производитель не сможет и не должен разработать все сценарии использования системы, так как заведомо не обладает знаниями во всех областях и не может оценить эффект от разработки подобных направлений. Вполне возможно, что вашей управляемой розеткой окажется безумно удобно управлять термостатом самогонного аппарата, потому что в библиотеке решений есть PID-регулятор, и теперь все самогонщики массово покупают ваши системы. Пример несколько надуманный, но основной посыл в том, что ценой некоторых усилий стоит создавать комфортную среду для хакеров, потому что они добавляют движущей силы вашей системе.
Вы не сможете покрыть своими устройствами все потребности клиентов. Всегда будут устройства, которых нет у вас, но есть у других производителей. Или есть у вас, но у других производителей лучше. Или вы будете таким производителем, у которого единичное устройство лучше всех. Для подключения вашей системы к другим необходим открытый и хорошо задокументированный API. Если у вас нет API, вы отказываете пользователям в возможности построения гетерогенных систем. Такое не могут позволить себе даже компании — самые ярые сторонники проприетарного аппаратного и программного обеспечения.
Какое бы у вас не было крутое железо, и какой бы классный софт вы не написали, это не будет иметь значения, если пользователь не разберётся с тем, как вашу систему запустить и как с ней работать. Хорошая документация — это такая, при работе с которой у пользователя не возникает и мысли об обращении в поддержку или негативной оценки умственных возможностей разработчика. Написать такую документацию практически невозможно, но надо к этому стремиться.
И наконец, последний принцип(но далеко не последний в плане важности):
Человек живет 70-90 лет, система у него дома — 5-10 лет (в лучшем случае), а компании зачастую меньше. Не стоит делать систему, возможность работы с которой вы утащите за собой в могилу. Пожалейте пользователей. Проектируйте систему так, чтобы работа с ней была возможна, даже если компания и разработчики давно канули в Лету.
Привязка нового устройства происходит с получением токена с сервера разработчика? Сделайте кнопку «Пропустить получение токена». При первом включении системы надо обновить прошивку с сайта? Сделайте так, чтобы при недоступности сайта заливалась дефолтная прошивка. И так далее.
1. [11] Говоря «пользоваться», я имею ввиду не процесс настройки, а процесс обычного взаимодействия с системой.
2. [12] Обратите внимание, я говорю не «задержка должна быть такой же», а «пользователь не должен заметить». Практика показывает, что человек не замечает задержки примерно до 300 мс.
3. [13] Возможно, он вырос в средней Азии и считает, что лучшее средство от жары — горячий зеленый чай.
4. [14] Разумеется, когда я говорю «информацию показывать не надо», это означает, что не стоит присылать пользователю сообщение об этом каждый раз. Её надо показывать по запросу пользователя — при нажатии кнопки «показать логи» или «показать отладочную информацию». Не надо считать пользователей идиотами, но надо уважать их время.
5. [15] Конечно, невозможно спроектировать систему, которая поддерживала бы бесконечное количество устройств. Ограничения будут всегда, но задача разработчика сделать так, чтобы они не играли роли в 99% случаев. Ограничение в шесть датчиков — неприемлемо. Сто-двести устройств в одной сети — достаточное количество для большинства пользователей умных домов.
6. [16] Я говорю о хакерах в первоначальном значении этого слова, по RFC1983 [17], а не как о взломщиках.
Автор: Влад
Источник [18]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/302454
Ссылки в тексте:
[1] vvzvlad: https://habr.com/users/vvzvlad/
[2] 1: #fn-1
[3] 2: #fn-2
[4] 3: #fn-3
[5] мозг: http://www.braintools.ru
[6] mesh-сетью: https://ru.wikipedia.org/wiki/%D0%AF%D1%87%D0%B5%D0%B8%D1%81%D1%82%D0%B0%D1%8F_%D1%82%D0%BE%D0%BF%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F
[7] 4: #fn-4
[8] 5: #fn-5
[9] тут: https://felixit.blog/2018/08/23/pro-otvetstvennost/
[10] 6: #fn-6
[11] 1.: #t-1
[12] 2.: #t-2
[13] 3.: #t-3
[14] 4.: #t-4
[15] 5.: #t-5
[16] 6.: #t-6
[17] RFC1983: https://tools.ietf.org/html/rfc1983
[18] Источник: https://habr.com/post/424131/?utm_source=habrahabr&utm_medium=rss&utm_campaign=424131
Нажмите здесь для печати.