Манифест разработчика умных систем: 15 принципов

    Мы предлагаем вашему вниманию статью Владислава Зайцева (vvzvlad), приглашенного гостя нашего блога. Владислав давно занимается темой «умных домов», и обобщив свой опыт, он предлагает следующие основные принципы дизайна такого рода систем.

    Сегодня я хочу поговорить с вами об «умных» домах в частности и IoT-устройствах в целом. Но это будет не обычная статья: тут не будет железок, ссылок на производителей, кусков кода и репозитариев на гитхабе. Сегодня мы будем обсуждать нечто более высокоуровневое — принципы, по которым организуются «умные» системы.

    image

    Продолжая читать статью, вы соглашаетесь с тем, что вас устраивает следующий disclaimer.

    Собственно, сам disclaimer
    1. Все эти пункты касаются только потребительских IoT-систем (читай «умных домов»). Тех, что человек может купить в магазине и установить без привлечения специализированных инсталляторов/интеграторов.
    2. Часть этих принципов не применима к промышленным системам (там свои требования и принципы), а также, к системам, где есть отделённые от пользователя эксплуатанты (например, умный дом, который устанавливается и обслуживается специально обученными людьми).

      Также часть принципов не применима к системам уровня «игрушка для гиков», к самодельным и open-source системам, у которых нет единого product owner.
    3. И, конечно, всё написанное ниже — это исключительно моё мнение, основанное на моём многолетнем опыте. Вы имеете право не соглашаться с ним.



    Умный дом — это система, которая берёт на себя часть повседневных забот человека. Отсюда следует первый и самый основной принцип:

    1. Умный дом должен облегчать жизнь и делать её проще.


    Умный дом — система для жизни, а не игрушка для гиков. Любые системы, пользоваться1 которыми сложнее, чем обычными выключателями — не умный дом.

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


    Второй по важности принцип касается того, как пользователь взаимодействует с системой:

    2. Хороший пользовательский опыт важнее функциональности.


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

    2.1. Удобные интерфейсы лучше кастомизируемости.


    Не понимаете, как сохранить и кучу функций, и простой интерфейс? Запихиваете все функции подряд в надежде, что пользователь сам разберётся, что ему надо? Вон из профессии!
    Не понимаете, как совместить удобство и кучу настроек? Пожертвуйте настройками. Любая функциональность будет круче, чем обычный выключатель, а вот излишняя сложность легко заставит пользователя вернуться к выключателю.

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

    2.2. Качество реализованных функций важнее их количества.


    Мало надежного, но проверенного функционала лучше, чем много, но работающего кое-как.
    Один из механизмов, закреплённых в человеческой психике эволюцией — более активная реакция на отрицательные стимулы. Отрицательные факторы важнее положительных: пропустить приближение опасного хищника гораздо страшнее, чем не заметить и не съесть вкусный фрукт на дереве. Если в вашей системе нет каких-то функций, это не страшно, это всего лишь отсутствие положительного стимула. А вот функция существующая, но работающая плохо — это отрицательный стимул: он запоминается легче и помнится дольше.

    2.3. Внедрение системы не должно снижать привычную скорость работы.


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

    Современное железо работает с очень высокой скоростью. Нет проблемы достичь частот в десятки мегагерц на микроконтроллерах и как минимум десятков килобит в секунду даже по радиоканалу. Если вы в этих условиях не можете сделать систему, задержек в работе которой пользователь не ощущает — вон из профессии!

    2.4. Система не должна ломать уже сформированные привычки пользователя.


    Ваша система — лишь небольшой кусочек жизни человека. Время жизни человека превышает срок эксплуатации системы в лучшем случае в пару раз, а в худшем — на порядок. Ваша система уйдёт так же, как и придёт, а жизнь человека продолжится. И в этой жизни у человека есть сформированные привычки касаемо предпочтительной яркости света, местоположения выключателей, как ему удобно включать свет и управлять климатом у себя дома.

    Нельзя пытаться насильно менять эти привычки. Предлагать — можно. Заставлять — нельзя.
    Нельзя сказать пользователю «теперь ты будешь включать свет с телефона — это стильно, модно, молодёжно». Это нарушение данного принципа и нескольких других.

    А что же делать?

    2.5. Система должна приносить новый опыт, а не пытаться заменять старый.


    Если вы считаете, что ваш способ управления системами дома лучше, чем старый, предложите его пользователю. Если это действительно удобнее, он сам выберет новый (да, разным людям подходят разные способы). Всё, что вы можете (и должны) сделать — предоставить ему выбор.



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

    3. Пользователя нельзя ограничивать в доступной ему логике.


    Если пользователь хочет при повышении температуры в комнате включать чайник3, дайте ему возможность делать это. Должна быть исключена ситуация, когда для совершения определенного действия нет ни физических, ни программных ограничений, но оно недоступно, потому что разработчик подумал «это никому никогда не потребуется».

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


    Если у вас есть устройства разных версий с разными протоколами, позаботьтесь о том, чтобы пользователь об этом знал только в реально необходимых случаях, когда без этого не обойтись. Если вы можете избавить пользователя от получения специальных знаний, пусть и ценой времени разработчиков, сделайте это. Разработчик потратит два дня, а тысяча пользователей по часу. Сорок восемь часов против тысячи? Ответ очевиден.

    Как тебе спится, Джон — серийный программист?

    3.2. Устройства с одинаковыми функциями должны управляться одинаково.


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



    Мы все живём в физическом мире. Тело и мозг человека сформированы для взаимодействия с физическими предметами. Отсюда принцип:

    4. Физические устройства управления лучше виртуальных.


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

    Другое дело, что выключатель должен размещаться именно в нужном месте. Отсюда ещё одно важное правило:

    5. Радио лучше проводов.


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

    5.1. Плохое радио хуже проводов.


    Хорошее радио — это такое, которое позволяет не задумываться о том, на каком расстоянии от центрального контроллера надо размещать устройства. Хорошее радио — это протоколы с mesh-сетью: ZigBee, Z-Wave, 6LoWPAN и так далее.

    Все остальные варианты — это плохое радио. Wi-Fi — плохое радио. Самодельные протоколы отдельных фирм (их знают самодельщики под названием «433 МГц», хотя они могут быть и на других частотах, и очень сильно отличаться друг от друга) — плохое радио.

    Wi-Fi плох тем, что на его основе невозможно сделать полноценные «спящие» устройства, и сложно сделать автоматическую настройку, а также проблемами совместимости с другими Wi-Fi устройствами в доме. Простые самодельные протоколы плохи тем, что зачастую не содержат в себе ни контроля доставки, ни шифрования, ни доступных спецификаций. Ни то, ни другое не имеет mesh-маршрутизации, что часто оборачивается проблемами вида «а я не могу в тот угол выключатель поставить — слишком далеко от передатчика».



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

    6. Ремонт, обновление, обслуживание и диагностика должны быть простыми.


    В B2B всё понятно: есть пользователь, есть разработчик, а есть эксплуатант — человек или организация, которые знают, как устроена система, и могут с ней работать на профессиональном уровне. Никто не требует от бухгалтера знания программирования под 1C, этим занимается специальный человек. И никто не требует от человека, который арендует офис, понимания, как в нём работает вентиляция — его дело сказать: «У нас в офисе душно».

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

    6.1. Устройство должно либо работать, либо не работать. Третьего не дано.


    Вероятность работы, частичная работа и неправильная работа недопустимы. Нельзя допускать ситуаций, в которых ваше устройство работает через раз или не работает один раз из десяти. Если вы считаете, что ваше устройство функционирует неправильно, стоит отключить его вообще — для безопасности и для сохранения положительного пользовательского опыта. Заменять устройство неприятно, но лучше заставить пользователя заменить его, чем формировать мнение «работает через раз» о системе. Система должна быть в строго определённом состоянии: если она сломалась, значит, она не работает, если она не сломалась, значит, она работает.

    Если вы твёрдо уверены, что деградация функциональности допустима, всё равно стоит предупредить об этом пользователя внятным сообщением: «Обнаружен выход из строя второго канала диммера. Необходимо заменить диммер. Продолжить использовать первый канал диммера? Да/Нет»

    6.2. Заменить сломанное устройство должно быть легко.


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

    Нельзя даже сказать «новый датчик может установить только наш специалист», потому что, очевидно, с развитием вашей системы специалистов не хватит на миллионы возможных пользователей, а значит, в какой-то момент начнутся проблемы. Конечно, пользователь не будет ремонтировать устройства сам, но при поломке он должен иметь возможность их заменить.

    6.3. Понятные сообщения.


    Если что-то пошло не так, пользователь должен знать об этом, и знать, что именно пошло не так.
    Нельзя сказать пользователю «Ошибка #45», подразумевая, что это сообщение поймёт только сотрудник техподдержки. Ему надо сказать: «Устройство не отвечает. Попробуйте перезагрузить его, привязать заново или обратиться в сервис. Ошибка #45».

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

    6.4. Отсутствие лишней информации в сообщениях.


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

    Не надо показывать пользователю сотню однотипных сообщений: «связь с устройством потеряна», «связь с устройством восстановлена». Решите наконец: либо это критичная проблема, и о ней надо сообщить правильным образом — «Неустойчивая связь с устройством», — либо, раз связь получилось восстановить, это не важная информация, и показывать её не надо4.

    6.5. Для обслуживания не должны быть необходимы специальные знания и оборудование.


    Даёте пользователю возможность обновлять прошивку — пусть она обновляется просто нажатием пары кнопок. И делаться это будет или через стандартный интерфейс (USB/BT/Wi-Fi), или не упоминайте в пользовательской документации об обновлении прошивки с помощью SPI-программатора вообще.

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

    6.6. Система не должна требовать постоянного обслуживания.


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

    6.7. В системе должна быть возможность обновления или расширения.


    Затраты на расширение системы должны расти линейно. Новый блок должен обходиться в стоимость нового блока.

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

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

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

    7. Самодостаточность: внешние сети — это опция, а не необходимость.


    Система, в которой команды ходят только через внешний сервер — плохая система. Вы можете сколько угодно хвастаться удобными интерфейсами, модными приложениями и крутыми нейросетями, но это всё неважно, если у пользователя вместе с падением интернета пропала возможность включить свет в туалете. Разработчик, ты правда считаешь такую систему хорошей?
    А если серьезно, то не очень понимаю, почему этот пункт — это не само-собой разумеющаяся штука. Завязывая систему на внешний сервер вы создаете точку отказа с надежностью обычного сервера, но одновременно для всех ваших пользователей. Внешние сервисы это круто, они позволяют расширить функционал, но не должны быть единственным вариантом оперативного управления. Дополнительного канала управления, резервного хранения, анализа данных — сколько угодно.

    8. Централизованность: отсутствие центрального хаба ограничивает доступную логику.


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

    Децентрализованная система — это когда выключатель говорит лампочке «включись», а датчик температуры при понижении этой самой температуры сам включает обогреватель. Распределённая система проигрывает централизованной просто потому, что такая система хорошо существует только в рамках самой простой парадигмы взаимодействия устройств — «устройство управляет другим устройством». Как только сложность системы возрастает, такая система порождает больше вопросов, чем ответов. Если датчиков температуры несколько, то обогреватель должен принимать команды от всех? Или сам должен опрашивать датчики? А если надо принимать решение о включении на основе тенденции, где хранить данные архива? На каждом обогревателе? А не жирно? На каждом устройстве? И гонять трафик при каждом запросе? А где хранить и как изменять логику? А если логика включает внешние элементы? А как хранить логику на «глупых» устройствах? А как её обновлять?

    Все эти вопросы исчезают, если смириться и признать необходимость центрального хаба как точки взаимодействия данных и места хранения пользовательской логики. Пусть все устройства будут «глупыми», способными отдавать данные и принимать команды, а задача по хранению архивных данных, обработке этих данных, принятию решений и взаимодействию с внешними сервисами ляжет на тот самый центральный контроллер.

    Децентрализованность, кстати, можно сохранить, пусть и частично: ничто не мешает при отсутствии ответа от хаба посылать команды напрямую, как fail-safe режим. Логики не будет, но зато свет включить будет возможно.



    9. Система не должна производить потенциально опасные действия без подтверждения или уведомления пользователя.


    Пока мы не живём в мире, где программист ответственен за ущерб, причиненный его программой (хорошо на эту тему написано тут), в программах будет много ошибок. Они будут и в софте умного дома. Единственная возможность, при которой эти ошибки не будут приводить к катастрофическим последствиям — это ограничение самостоятельных действий системы. Потенциально опасные действия должны совершаться как минимум с ведома пользователя, а лучше с его подтверждения. Свет включать можно автоматически: баг в программе приведёт к тому, что пользователь будет разбужен ночью или получит счёт на лишние сто рублей в конце месяца. Неприятно, но вряд ли опасно. Например, включать автоматически воду, если нет механизмов, гарантированно отключающих её при потопе — нельзя. А вот выключать воду — можно, так как это не опасное действие.

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

    10. Система должна иметь возможность самоконтроля и самодиагностики.


    Настоящий разработчик умных систем должен быть немного параноиком. Нельзя доверять интернету, он может пропасть. Нельзя доверять коду, в нем могут быть баги. Может быть, хотя бы железу можно доверять? Нет. Нельзя доверять своему железу. Реле может залипать, симисторы самопроизвольно открываться, предохранители перегорать. Наконец, пользователь может включать киловаттный чайник в розетку, рассчитанную на 100 Вт. Нужны датчики напряжения, тока, температуры. Вышла температура за пределы? Выключаем всё, отправляем предупреждение. Вышел ток за пределы — выключаем. Отключили реле, а на выходе всё еще есть напряжение? Уведомление. Включили, а напряжения нет? Уведомление!

    11. Система должна иметь возможность ручного управления.


    И даже при всех этих параноидальных штуках, все равно будет ситуация, когда проверки не справились, и у вас что-то сломалось. Выключатель в комнате, роутер, центральный хаб. А свет в туалете пользователю включить хочется. Какой вывод?

    Всегда должна быть кнопка, которой можно сделать «закат солнца вручную». Которой можно включить или выключить свет ВОТПРЯМЩАС. Потому что новый хаб привезут завтра, выключатель можно купить новый чуть позже, а свет в комнате хочется выключить именно этим вечером, чтобы спокойно поспать.

    12. Разработчики и хакеры настолько же важны, как и обычные пользователи.


    Обычные пользователи сделают вам кассу, а хакеры6 — придумают новые функции. Производитель не сможет и не должен разработать все сценарии использования системы, так как заведомо не обладает знаниями во всех областях и не может оценить эффект от разработки подобных направлений. Вполне возможно, что вашей управляемой розеткой окажется безумно удобно управлять термостатом самогонного аппарата, потому что в библиотеке решений есть PID-регулятор, и теперь все самогонщики массово покупают ваши системы. Пример несколько надуманный, но основной посыл в том, что ценой некоторых усилий стоит создавать комфортную среду для хакеров, потому что они добавляют движущей силы вашей системе.

    13. Открытость: система должна иметь API для интеграции с другими системами.


    Вы не сможете покрыть своими устройствами все потребности клиентов. Всегда будут устройства, которых нет у вас, но есть у других производителей. Или есть у вас, но у других производителей лучше. Или вы будете таким производителем, у которого единичное устройство лучше всех. Для подключения вашей системы к другим необходим открытый и хорошо задокументированный API. Если у вас нет API, вы отказываете пользователям в возможности построения гетерогенных систем. Такое не могут позволить себе даже компании — самые ярые сторонники проприетарного аппаратного и программного обеспечения.

    14. Документированность: документация — такая же важная часть системы, как код и железо.


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

    И наконец, последний принцип (но далеко не последний в плане важности):

    15. Самодостаточность и самоподдерживаемость: система должна продолжать работать, даже если компания работать прекратила


    Человек живет 70-90 лет, система у него дома — 5-10 лет (в лучшем случае), а компании зачастую меньше. Не стоит делать систему, возможность работы с которой вы утащите за собой в могилу. Пожалейте пользователей. Проектируйте систему так, чтобы работа с ней была возможна, даже если компания и разработчики давно канули в Лету.

    Привязка нового устройства происходит с получением токена с сервера разработчика? Сделайте кнопку «Пропустить получение токена». При первом включении системы надо обновить прошивку с сайта? Сделайте так, чтобы при недоступности сайта заливалась дефолтная прошивка. И так далее.



    В этой статье я попытался описать весь опыт использования, работы и проектирования таких систем, сжатый в 15 основных принципов. Часть из них может показаться надуманными, часть — спорными (и это нормально), часть — банальными (и это тоже нормально).

    Но если вы задумались хотя бы над одним из них, значит, статья писалась не зря.

    Сноски и комментарии


    1. Говоря «пользоваться», я имею ввиду не процесс настройки, а процесс обычного взаимодействия с системой.
    2. Обратите внимание, я говорю не «задержка должна быть такой же», а «пользователь не должен заметить». Практика показывает, что человек не замечает задержки примерно до 300 мс.
    3. Возможно, он вырос в средней Азии и считает, что лучшее средство от жары — горячий зеленый чай.
    4. Разумеется, когда я говорю «информацию показывать не надо», это означает, что не стоит присылать пользователю сообщение об этом каждый раз. Её надо показывать по запросу пользователя — при нажатии кнопки «показать логи» или «показать отладочную информацию». Не надо считать пользователей идиотами, но надо уважать их время.
    5. Конечно, невозможно спроектировать систему, которая поддерживала бы бесконечное количество устройств. Ограничения будут всегда, но задача разработчика сделать так, чтобы они не играли роли в 99% случаев. Ограничение в шесть датчиков — неприемлемо. Сто-двести устройств в одной сети — достаточное количество для большинства пользователей умных домов.
    6. Я говорю о хакерах в первоначальном значении этого слова, по RFC1983, а не как о взломщиках.
    Samsung
    101,00
    Компания
    Поделиться публикацией

    Комментарии 38

      +6
      Насколько эти правила просты и очевидны, настолько хреново реализуются в реальной жизни. И, если честно, не могу понять причину этого факта. Можно взять любое правило из этого манифеста и плакать горючими слезами вспоминая практический опыт работы с «умными» системами.
      P.S. Мой личный опыт относится в основном к промышленным системам, про которые автор упомянул в дисклеймере, но чёрт возьми, разработчики! почему нельзя и в промышленности думать о людях при разработке?
        0
        Коротко — потому что в промышленности пользователи и заказчики — разные люди. Хорошо это или плохо — отдельный вопрос.
        0
        Я думаю что успехи персональных устройств, типа смартфонов, базировались на том, что пользователю даровалось успешное пользование компьютерным устройством (ранее ему не доступным), если он запомнит сценарий — тапай сюда, слайдери тут и тп. В домашней автоматизации все немного по другому — дом это уже устоявшиеся пользовательские привычки.
        Одному важно следить за затемнением перед сном, другому начхать, третьему важно видеть напряжение в сети( это я о себе) и задействованных потребителей, а четвертому нужно выключать утюги забытые.
        Отсюда многообразие, от многообразия — большие вложения в устройство, которое сможет охватить большое кол-во потребителей. Большие вложения, влекут высокую цену и непривлекательность для масс-маркет.
        В промке все немного похоже на дом, плюс, добавляются пропиетарные интересы компаний производителей, конкуренция однако…
        Плюс никто не отменял наследственность — всегда проще расти базируясь на уже созданном решении, даже если оно уже «слегка выпало из времени»…
          +2
          Автор, да то что вы написали применимо ко всему. Например к программированию. Или к дизайну например. Другое дело, что всем на это плевать)
          Да, плевать. Да, всем. Читающий — тебе на это тоже плевать) Иногда ты этого хочешь, но сам ты для этого ничего не сделал. И ты сидишь и ждешь, пока тебе это сделают другие, правда же?
          Выводы.
            +4
            Я согласен с общим посылом поста, но есть несколько размышлений. Во-первых есть довольно странная тенденция подмены понятий, к примеру в самом начале «потребительских IoT-систем (читай «умных домов»)». Так уж сложилось, что потребительские IoT-системы, что бы это ни значило, не равно «умные дома». Умные дома были баз-вордом в 90е и некоторое время позже, но даже в те времена их значение сильно зависело от рынка. К примеру, в Европе, основным упором было рациональное использование энергоресурсов (до этого был домотикс, как автоматика, а потом уже разумный дом) при сохранении потребительских свойств, поэтому основные технологии строились вокруг инженерных систем, в северной америке умные дома ассоциировались с мультирумами и прочими AMX и Crestron, а в той же Корее и Японии, в виду культурных и медицинских особенностей (забота о старшем поколении, которое живет долго) и вовсе дала толчок развитию умных домов геронтоматика (была когда-то попытка создать такой термин). Интернет вещей не может иметь смысла без двух компонентов: вещей и интернета. В противном случае это не интернет вещей. Это автоматика, автоматизированные системы, что угодно.

            Конечно это давняя проблема размытия термина до его окончательного формирования, но все же. Почему я говорю о не совпадении этих вещей, да потому что я вот уже 15 лет пользуюсь этими самыми умными системами. И именно системами, а не подменяющими их функции свистелками, разработанные маркетологами, а не инженерами. Призыв делать понятные, удобные интерфейсы дело очень правильное, однако, мне хотелось бы напомнить формулировку бритвы Оккама в прочтении Эйнштейна: «Всё следует упрощать до тех пор, пока это возможно, но не сверх того». Знаете, вот у меня приточно-вытяжная вентиляция с роторным рекуператором и 10 зонами управления переменным расходом воздуха. Ну вот никак я с помощью милых сердцу современников Nest, я не заставлю это работать, а вот с помощью EIB/KNX это трудится уже больше 10 лет, и работает совместно с парой котлов, кучей насосов и прочих треходовых клапанов. Всегда можно списать на нарушение дисклеймера, но я хочу сказать, что я не подвержен профессионально деформации и даже не притащил домой ни Profibus, ни LON, ни даже довольно удобный Modbus (какой-то из десятков диалектов). Это вполне бытовая система, разработанная лидерами рынка инженерии эпохи назад по меркам ИТ. А вот движение и развитие систем согласно вашему манифесту, может привести к достижению локального минимума удобства и уверенности в том, что все что сложнее вкручивания лампочки невозможно для пользователя.

            Соглашусь с тем, что есть классы устройств (чаще всего не систем), которые должны быть простыми: умная лампочка, умный выключатель, умный пылесос, умные шторы и тд. А вот система отопления умного дома — это уже более осмысленная вещь, ровно как и правильное проектирование сети электроснабжения. Излишнее упрощение может приводить к очень неприятным последствиям.

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

            Хотелось еще и про API написать, в контексте первых пунктов манифеста, но уже и так много букв

            Ну и в копилку позитивного восприятия, очень меня улыбнул КДПВ: дерзко в блоге Samsung фоточку линейки Aqara/Mijia Xiaomi публиковать. С удовольствием пользуюсь их устройствами в дополнение к инженерным Siemens (включая швейцарский SBT), ABB, Jung, Bosch, Buderus (хотя они уже тоже Bosch)

              0
              но я хочу сказать, что я не подвержен профессионально деформации и даже не притащил домой ни Profibus, ни LON, ни даже довольно удобный Modbus (какой-то из десятков диалектов)

              Одно то, что вы знаете эти названия, уже свидетельствует в пользу нарушения дисклеймера :)
              А если серьезно, то граница применимости части пунктов в этой статье как раз пролегает по «умение сделать что-то большее, чем вкрутить лампочку/поменять розетку». Просто потому, что я говорю про потребительский рынок. Сложная приточка — это не консьюмерский рынок, и все. Начиная с того, что ее установка несколько сложнее замены лампочек и розеток, и стоит немного больше лампочек и розеток, и заканчивая тем, что такая система нужна довольно малому проценту людей.
                0
                такая система нужна довольно малому проценту людей

                Объективно нужна она как раз всем, только не все об этом знают и ещё меньше готовы платить.

                А вообще согласен по всем пунктам, кроме радио. Провод был, есть и будет есть лучше для всего более-менее стационарного, будь то компьютерная периферия или выключатель лампочки.
              0

              Спасибо, что описали манифест по которому у меня разработан и работает мой "Умный Дом". Теперь осталось на основе этого манифеста привести примерную топологию и выбор компонентов.
              Кстати, один момент в манифесте не учтен и я бы предложил его добавить в дополнение к разделу 6:
              Еще на этапе проектирования должна быть заложена доступность системы на уровне 99,9% и выше. Это означает, что при любой, даже самой страшной поломке, система не должна переставать работать на большее время, чем 8 часов в течении года. Это время включает и ремонт контроллера и бэкапы и апдейты. Поэтому надо обеспечивать а) горячий или холодный резерв, б) автоматические бэкапы, в) возможность быстрого перезапуска системы самим пользователем на резервном железе, без ожидания приезда специалиста.

                0
                Ну, на самом деле, мне кажется, это излишне. Сделать-то можно, но это добавит сложности и стоимости системы, а плюсов для многих пользователей это прибавит незначительно.
                  0
                  На самом деле — это не так. На самом деле все как раз работает по манифесту, или же подобным манифестам. И всегда будет работать только по ним. Док-во?) Легко.
                  Оглядитесь вокруг. Все что сделано вокруг — ИСКУССТВЕННО УСЛОЖНЕНО. Именно так. Потому что проще делать как было 100 лет назад. А еще проще как делали 1000 лет назад)
                  Но зачем-то, на длинных временах все это усложнили. Да, проще прибить гвоздями три кривых доски. Но почему-то грандиозно заморочились, применили лютую химию, физику и даже математику, и всем выдали очуменной [я еще раз подчеркиваю] ОЧУМЕННОЙ СЛОЖНОСТИ шкафчики. В обычных шкафчиках применены сотни технологий. Зачем это?) Это же сложно!
                  Тут момент в том, что вы к этому привыкли и считаете уже как должное. Но отбери у вас эти шкафчики и выдай вам три доски сколоченных гвоздями — вы же начнете вопить, не так ли?))
                  Так прибавляет эти самые плюсы для пользователей искусственное усложнение? Вы же пишите что незначительно прибавляет? А выясняется что очень даже значительно, ага?

                  Выводы:
                  На короткую перспективу вы правы.
                  Но на длинную перспективу — абсолютно не правы.

                  Мир только и делает, что катастрофически усложняет сам себя, только лишь затем, что бы в итоге было проще, надежнее, понятнее, геморроя меньше, проблем меньше, и да, не забывайте про искусство, и оно тоже учитывается)
                  ВСЕ ЭТО ВОЗМОЖНО, ЕСЛИ СОБЛЮДАТЬ ПОДОБНЫЕ МАНИФЕСТЫ НА ДЛИННОЙ ПЕРСПЕКТИВЕ, и по-другому никак. Ничего другого пока не придумали.

                  И да, еще момент. На длинную перспективу работают 5%, а на короткую 95%))))) И это тоже нормально. Выбор за вами) Или вы делаете однодневки. Или же делаете как бы пафосно оно не прозвучало, да пусть — «вещи» мирового масштаба) Выбирайте. Вас никто ни к чему не принуждает вовсе.
                    0
                    Ммм… Понимаете, какая штука: если сейчас начать делать шкафчики из графена, со встроенной климатикой, которая поддерживает температуру для каждого продукта индивидуально, и системой распознавания этих продуктов, это будет круто, без сомнения. Но стоить будет как чугунный мост, и не будет нужно 99% людей. Да и оставшемуся проценту не особо нужно будет, просто им денег за это будет не так жалко.
                    Хотя безусловно, я уверен, что через 100 лет такого рода технологии будут восприниматься как само-собой разумеющееся, и будут входить в чек-лист по выбору мебели для кухни средней семьи: «Пункт 25. Шкафы должны быть оборудованы зонной климатикой, а в мусорке должен быть установлен компактор».

                    Но это будет достигнуто только тогда, когда стоимость этой климатики будут достаточно незначительна по сравнению со стоимостью всей мебели. Именно поэтому сейчас у нас на кухне шкафчики с дверками, шурупами и сотней технологий: потому что стоимость этого шкафчика не сильно отличается от трех досок с гвоздями. Цена и того, и того на вторичном рынке часто меньше стоимости перевозки этого на другой адрес.
                    Но эти шкафчики по такой цене не появились по мановению волшебной палочки или после написанию манифеста. Их появлению предшествовала долгая эволюция материалов, инженерных подходов, подходов к управлению производством, взглядов людей, которые эти шкафчики покупают, наконец.
                    Смешно думать, что написание в этом манифесте тезиса «надо обеспечить отказоустойчивость 99,9%» сразу эту отказоустойчивость обеспечит. Надо ориентироваться на возможности рынка, как в плане производства устройств, так и в плане покупательной способности. И заложить избыточную по меркам рынка надежность, пребывая в полной уверенности, что это именно то, что надо людям, и за что они готовы платить больше, чем конкуренты — верный способ прогореть.
                      0
                      Ммм… Понимаете, какая штука
                      Понимаю) Но я не пишу манифестов, и многое не учитываю, в писанине. А на самом деле я ВСЕ учитываю, я ж специалист теории информации. Другое дело, что описать сразу и все — невозможно. Но разве «в природе» это что-то меняет?) Оно как двигалось только в одном направлении — т.е. по манифестам — так и будет двигаться.

                      Напишите проще, даже можете добавить в манифест, если хотите. Ну что-то типа того: юзайте уже известные, дишовые и проверенные технологии, и на основании уже «железобетонного» городите новые. Другое дело, что поиск из сонма имеющихся технологий наиболее подходящщих для поделок — это не тривиальная задача конечно же, ну так это детали)
                      Смешно думать, что написание в этом манифесте тезиса «надо обеспечить отказоустойчивость 99,9%» сразу эту отказоустойчивость обеспечит.
                      Смешно. И не смешно. Объяснюсь. Это ж манифест у вас) Не стесняйтесь. Пишите как оно ДОЛЖНО быть. И да, 99.9% — это смешно)))) Не стоит так писать. Надо писать 100%. Ибо 99.9 в периоде — это прошлый век. Уже прошлый. ДА, ПРОШЛЫЙ. Нынешний век — это век криптографии. А как «всем известно» [впрочем опять же далеко не всем], любая система отказоустойчивая на 100% только в одном случае — если она криптографически отказоустойчивая и это математически доказано) Смотрите, у вас есть винчестер, как бы вы не корячили наработку на отказ и прочее-прочее-прочее «прошлого века» — ничо не выйдет) Вы получите 99.99..., но применив криптографию — вы и получаете «винчестер самсунг» 100% отказоустойчивый) Я не про то, что он не ломается, я про другое. Я про то, что данные «туда-сюда» на винт перемещаются с помощью пары глобальных технологий. «Старые» технологии отказоустойчивости — это 99.9, новые, как раз таки доводящие «систему» до 100% — это криптография) И без криптографии никак. Хотите 100 — только криптография, без вариантов. Но это никак не отменяет старых глобальных и великолепных технологий, типа наработок на отказ и т.д.

                      Вырисовывается еще один пункт в таком случае. Что-то типа: объединяйте технологии, юзайте их совместно) И на самом деле, я даже примеры знаю и много — даже казалось бы необъединимое — можно объединить, и получаются в итоге такие грандиозные «штукенции», что диву даешься)) Но конечно же это все нетривиально, а в итоге просто)

                      И еще момент: есть теория типов, ну или логика высших порядков, или теория абстракций — называйте как хотите.
                      Так вот я бы обозначил следующее: все что не делается, должно в итоге описываться меньшим кол-вом абстракций, чем было «до». Про сложность абстракций я ничего не говорю. Вообще ничего. Сложность абстракций должна быть соизмеримой. Я говорю про их кол-во.
                      На пальцах: для юзера что-то описывалось пятью абстракциями, вы искусственно усложнили, и в итоге это усложненное стало описываться тремя абстракциями, причем реализацию усложнения юзер конечно же не видит. Для юзера было пять, стало три. Причем эти «юзерские» абстракции по сложности должны быть соизмеримы. В итоге для юзера выйдет проще? Да! Отчасти похоже на ооп не так ли?) А так и должно быть. Действуйте)

                      Вообще, теория простого и сложного — это «краеугольный камень» этого всего)) Попытайтесь объяснить что это. Не все это понимают к сожалению. И, возможно, непонимание этого — и приводит к невменяемым поделкам в итоге. И да, теория простого и сложного — это как раз таки пункт номер ноль вашего манифеста. А все остальное что вы написали — это «всего лишь» следствие пункта 0. Забавно же?)
                0
                Для пользователя радио хуже проводов, прежде всего в плане уязвимости к взлому. Все помнят историю с заражение вирусом лампоче Philips Hue. Известный производитель, протокол из списка «Хорошее радио» — и целые жилые районы зараженных лампочек. Радио лучше проводов для крупных производителей — в этом случае они получают контроль над устройствами и системами, и для установщиков — можно предложить развёртывание системы быстрее и дешевле. Как показывает практика — чем дальше тем больше объектами взлома становится сравнительно простая пользовательская электроника, и лучшая защита — физическое ограничение доступа. Все компоненты умных систем нуждаются в питании. Для датчиков питание может быть батарейным, но замена десятков батареек — сомнительное удовольствие. А если есть провода питания — по ним же может выполняться обмен данными, есть множество реализаций, и для высоковольтного питания, и для низковольтного. Радио — это полезная опция, позволяющая быстро нарастить систему, но лучше всего, когда у всех устройств с радио есть проводные аналоги, тогда при очередном ремонте их можно заменить на них.
                  0
                  Не смотря на то, что я в своем комментарии написал что провода лучше радио, но позволю себе не согласиться с аргументами. Раз уж мы говорим про IoT, а значит есть связь с интернетом, то степень защиненности внешнего канала становится критичнее, чем радио. Поясню. Шифрование того же ZigBee стойкое настолько, насколько вообще возможно, при условии ограничения доступа к координатору сети. А вот что за прошивка внутри этой лампочки никому по сути не известно. Будет ли она корректно проверять сертификаты производителя при скачивании очередной прошивки? Думаю, это риторический вопрос. То есть наиболее очевидный вектор атаки на самом деле, как мне представляется, это все же не полевой канал связи, а инфраструктура доставки обновлений или ваш внешний канал и система OTA в принципе. Когда мы говорим о IoT, мы автоматически так или иначе в сети. Пусть через фаерволы, и абсолютно не важно мы используем шлюзы или туннели для доставки протокола до управляющего устройства. Мы не изолированы с этим нужно либо смириться, либо не использовать IoT, а возвращаться к старой доброй автоматике в категорированных сетях.
                    0
                    Однако, защитить от взлома одно устройство с достаточными для защиты ресурсами существенно проще, чем зоопарк простых устройств, некоторые из которых просто не имеют достаточной вычислительной мощности или достаточно энергии в батарее для применения стойких алгоримов шифрования. И если даже имеют на сегодняшний день — через несколько лет используемый в них алгоритм может оказаться скомпроментированным, а новый они не потянут даже при желании их производителя обновить прошивку, а часто через год-два производители перестают их обновлять.
                      +1
                      О, а сейчас Вы затронули краеугольный камень IoT! Понимаете, творится вообще форменная ерунда. Я сам программист, если что, но когда софтверные компании полезли в эту отрасль… Вот сколько лет эксплуатируется ваша люстра? А выключатель настенный? А что будет через 5 лет с выходом очередной iOS или Android? Цикл поддержки программных продуктов редко когда привышает 5 лет. Да и то, это огого какой LTS. Сколько было deprecated продуктов у Google? Грустно было когда Reader убили, а если следующим будет мой дом? Все же мы помним, что «если хотите использовать Philips Hue с Siri, купите шлюз 2 версии». Ну то есть я никак не понимаю, как голосовой ассистент, который живет в моем телефоне и вооон в том облаке, говорит, что отказывается работать с моей работающей лампочкой (я-то знаю почему, но это в корне неверно)… Думаю, этот как раз проявление того, как ту часть про «удобство пользователя» в этом манифесте можно прочесть неправильно. Мол купи новую версию коробочки и все авто-магически заработает. В этом плане я очень поддерживаю посыл в посте про API, локальность и открытость. Если работает локально и есть API, в худшем случае можно поднять свой локальный сервис.
                    0

                    А типа, если бы эти лампочки были проводные, их никто бы не взломал? С вот многие компьютеры подключены по проводам, но это не мешает их заражать всякими вирусами. ВсЯкие Айпи камеры тоже шпионят, хотя совсем не радио.
                    Это я к тому, что считать радио априори опасным, а провода пюаприори безопасными — неправильно. В первую очередь следует ориентироваться на софт, который крутится в этой железке. Если это неизвестно кем написаный WiFi на линуксе — то вероятность одна. А если это стандартизированный и скртифицированный стек на 8-битном контроллере, зашитый туда на века — это другое. И вероятность взлома совсем не очевидна.

                      0
                      Если бы эти лампочки были проводными — их вряд ли кто-то сломал бы в обход шлюза и файрвола. Со взломом через файрвол бороться проще — не нужно обновлять или заменять несколько десятков недешевых лампочек, достаточно настроить, обновить, или заменить файрвол. И смысла массово взламывать беспроводные лампочки гораздо больше — так создаётся подконтрольная взломщику mesh-сеть, через которую можно взломать нужное удалённое устройство, управлять им, и заметать следы.
                        0
                        Вы прячете идиотизм в криптографии и защите отдельных разработчиков устройств за тезисом «радио ненадежно». Радио настолько же надежно, насколько надежна современная криптография, если эта криптография в ней применяется правильно. Пока никто не взломал, например, AES, и тенденций к этому не предвидится, следовательно, нет особой проблемы построить защищенную сеть на основе радио-протоколов.

                        P.S. Если бы «эти лампочки были проводными», то их и не надо было бы взламывать — ибо то, чем они взяли рынок(легкостью установки системы в любом доме без необходимости прокладывать слаботочку и переделывать ремонт) невозможно сделать на проводных технологиях.
                        Да, я знаю про X10 и иже с ним, но у него есть свои минусы, и как видим, эти минусы достаточно значительны, чтобы не быть особым конкурентом радио.
                          0
                          Я не продвигаю тезис «радио ненадежно». Я утверждаю что радио — это:
                          1) Количество потенциальных точек взлома равное количеству устройств, что всегда менее безопасно чем одна точка. Кроме самих алгоритмов, в которые изначально законодательно заложены бэкдоры, есть ещё реализация, которая может содержать уязвимости вследствие ошибок. И любая экспертиза и сертификация лишь уменьшает вероятность их наличия, но не исключает полностью.
                          2) Как следстве первого, плюс ограниченность ресурсов простых устройств — дополнительные сложности с закрытием выявленных уязвимостей.
                          3) Принципиально большие трудности с обнаружением источника атаки.
                          4) Если, как предлагается в статье, строить сеть как mesh — дополнительный мотив заражения, которое может вызвать проблемы с безопасностью функционирования даже без намерения атакующего.
                          DES считался надёжным 22 года, и был взломан. AES существует ещё не так долго.
                            0

                            И все же вы вводите потребителя в заблуждение:


                            1) Для взлома интересны не абсолютно все радио-реализации, а только те, которые открывают злоумышленнику широкие возможности по внедрению в домашнюю сеть или в жилище. И если вы возьмете тот же Z-wave, то обнаружите, что протокол там настолько ограничен, что максимум, что злоумышленник может сделать — так это подать пару неправильных команд или попытаться зафлудить сеть своим 1мВтным передатчиком. С добавлением шифрования первая возможность уже тоже исключена. Поэтому то, что таким образом получить доступ к удаленным устройствам через лампочку — это больше фантастика, чем реальность. В других аналогичных протоколах ситуация обстоит примерно таким же образом. С Wi-Fi ситуация обстоит, конечно, иначе.


                            2) "в которые изначально законодательно заложены бэкдоры" — можно источник этого тезиса?


                            3) Надеюсь вы понимаете, что ваше утверждение "не нужно обновлять или заменять несколько десятков недешевых лампочек, достаточно настроить, обновить, или заменить файрвол" создает только иллюзию безопасности? А иначе никто бы не заставлял нас обновлять домашние и рабочие компьютеры по любому чиху, хотя они стоят за десятком различных фаерволов? Поэтому хоть в проводной, хоть беспроводной сети вам все же придется обновлять софт и на IoT устройствах, хотя не исключаю, что многие на это забивают.


                            4) Еще насчет "безопасности" проводов — уже много лет заметна тенденция шифрования интернет трафика — HTTPS и прочее, даже если он передается по проводам. И на это есть определенные и логичные причины. И вот представьте, что у вас проводная IoT сеть. Если к ней подключится злоумышленник и если шифрования у вас нет — то можно сказать, что все, приехали. А вот если вы начнете шифровать, то возможно ваши устройства это уже не потянут по ресурсам. В каком направлении вы представляете будущее движение в этом случае? Вы думаете, что в этом случае беспокоиться не о чем? "Файервол все разрулит и от всего защитит?"

                              –1
                              1) В случае, если цель взлома — доступ в домашнюю сеть, радио-реализации создают дополнительный вариант взлома — через шлюз (центральный контроллер) вариант Z-wave, Z-wave plus, вполне пригоден для этого, поскольку предусматривает возможность обновления прошивок устройств по воздуху, и может обеспечить скорость передачи данных до 100кбит/с. Для этого нужно, чтобы реализация этого протокола в шлюзе имела уязвимость, позволяющую выполнить произвольный загруженный код. Но гораздо большую опасность представляет изменение поведения исполнительных устройств умного дома, как при помощи выдачи им команд, так и при помощи их полной несанкционированной перепрошивки. Самый простой пример: если злоумышленник хочет похитить человека — он может выманить его из дома в определённое место рядом с домом простым миганием захваченных им «умных лампочек» которое разбудит его среди ночи, и побудит выйти посмотреть что с ними случилось, причём сделать это он может захватив контроль над контроллером умного дома на другом конце жилого района, и перепрошив через него множество лампочек в этом районе, создав таким образом mesh-сеть. Побочным эффектом этого может оказаться нарушение функционирования множества систем «умный дом», для которых эти лампочки были ретрансляторами. Есть варианты и похуже. Если злоумышленник обнаружит, что в каком-то из потенциально опасных механизмов умного дома есть возможность при помощи модифицированной прошивки выполнить опасные для людей действия, которые, вследствии ошибки при проектировании или серийном производстве (например, при некачественном копировании или подделке), не будут блокированы чисто аппаратной защитой — последствия могут быть очень печальны.
                              2) об этом напишу позже.
                              3) «обновлять домашние и рабочие компьютеры по любому чиху» нужно потому, что они обмениваются данными с удалёнными внешними устройствами напрямую. С устройствами умного дома ситуация иная — обычно они управляются через центральный контроллер, который не передаёт им никаких команд без преобразования. Это практически исключает возможность внедрения кода или неавторизованного управления такими устройствами напрямую из интернета, через штатный канал управления, без взлома контроллера. В случае с Ethernet остаётся вероятность взлома через разные дополнительные и сервисные каналы, но она перекрывается файрволом.
                              4) Интернет трафик нуждается в шифровании потому что он идёт непонятно через какие каналы и оборудование, и может быть перехвачен или подменен во множестве мест. Пользователь даже не может быть уверен что он не передаётся по беспроводному каналу на каком-то из участков. Если физическое ограничение доступа ненадёжно — шифрование нужно и для проводного подключения. Но ситуация с массовым вирусным заражением целого района в этом случае возникнуть не может — физический доступ нужен отдельно к каждой домашней сети.
                                0
                                С устройствами умного дома ситуация иная — обычно они управляются через центральный контроллер, который не передаёт им никаких команд без преобразования. Это практически исключает возможность внедрения кода или неавторизованного управления такими устройствами напрямую из интернета, через штатный канал управления, без взлома контроллера. В случае с Ethernet остаётся вероятность взлома через разные дополнительные и сервисные каналы, но она перекрывается файрволом.

                                Ваши слова расходятся с реальной практикой производителей в этой области. Практически все IoT устройства с Ethernetом на борту, будь то выключатель, реле или лампочка, сегодня частенько лазят в интернет за новыми прошивками, а многие еще и требуют подключения к "облаку" производителя, чтобы заработало управление с телефонов и других гаджетов через фирменные приложения "из любой точки земли". И делают они это не через какой-то центральный контроллер, а напрямую, залазя в интернет своими слабенькими процессорами. Взламываем облако и получаем доступ ко всем этим устройствам сразу и никакой домашний фаервол не спасет.

                                  0
                                  Если устройство не может работать без подключения к «облаку» — оно не очень-то вписывается в само понятие «умный дом», это отдельное устройство, которое по сути не может полноценно работать в системе. Но чаще есть несколько вариантов интерфейса, и тогда выход в интернет можно перекрыть файрволом. А лампочки с Ethernet гугл вообще не нашел.
                                    0
                                    Если устройство не может работать без подключения к «облаку» — оно не очень-то вписывается в само понятие «умный дом»

                                    Озвучьте же свое понимание термина «умный дом», а то оно у вас как-то отличается от общепринятого.
                                      0
                                      Моё понимание концепции умного дома совпадает с вашим манифестом за исключением тезиса о беспроводных решениях. Умный дом — это система, автоматизирующая управление оборудованием дома. Как любая система она должна быть связной.
                                        0
                                        Так а где в «системе, автоматизирующей управление оборудованием дома» есть пункт о том, что это не может работать через облако?

                                        «Умный дом» — это очень базовое понятие, которое можно обсуждать и корректировать только на том же самом, базовом, низком уровне. Вносить туда определения с более высоких уровней — неправильно.

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

                                        Так и с умным домом — пытаться туда пропихнуть «работу локально» приводит к разбеганию термина: когда один понимает УД как систему, работающую локально, второй как систему, которая дает возможность удаленного управления, третий по другому, и все три срутся на тему «вот ваш дом на самом деле не умный, а мой умный».

                                        Жесткое определение термина «умный дом» как «система, берущая на себя часть рутинных действий по управлению домом» это как раз попытка провести четкую границу, с которой большинство вменяемых людей согласны. Не согласны только те, кто называет умным домом лампочки, управляемые с телефона, но на то я и уточнил: «вменяемых».
                                        И если мы все-таки протащим в это определение что-то про автономию, мы сделаем только хуже: не автономные системы есть, и широко применяются. Нельзя отбирать у них право называться умным домом только потому, что они неправильно спроектированы(из-за непонимания принципов, в погоне за привязкой пользователей или потому что разработка проще, не суть важно), потому что это отрицательно скажется на самой возможности диалога: вместо объяснения «почему твой умный дом спроектирован не самым лучшим образом и как это исправить» получится монолог «твой дом не умный, а тупой, и даже не спорь со мной».
                                          0
                                          Так а где в «системе, автоматизирующей управление оборудованием дома» есть пункт о том, что это не может работать через облако?
                                          Система в целом может работать через облако, и это даже не противоречит концепции одного интерфейса как средства улучшения защищённости от взлома, если речь идёт о высокуровневых функциях и взаимодействии с внешним миром, удалённом управлении — в этом случае функции защиты доверяются производителю, у него для этого больше возможностей. Это плохая система в плане надёжности и защиты от самого производителя, если не предусмотрена возможность полноценой автономной работы. Но вот прямое управление через облако каждым отдельным устройством — совсем другое дело — в этом случае система виртуальная, не защищённая, и может развалиться в любой момент. Можно ли виртуальный умный дом называть умным домом? Наверное можно, но с большой натяжкой.
                                            0
                                            Эх. Не поняли.
                    +1
                    На мой взгляд, единственно правильная система связи — по проводам электросети. Любое устройство умного дома требует сетевого питания, и связь должна быть по этим же проводам. Только очень ответственные потребители, имеющие свой источник резервного питания (котел, система безопасности), могут иметь и резервный радиоканал. Радиоканал могут иметь и датчики, но стоит очень хорошо подумать, прежде чем применять такие. А еще лучше подумать в сторону фотовольтических элементов. Система которая раз в месяц требует новую батарейку, скорее всего окажется неработоспособной в итоге.
                      +1
                      Домашняя автоматизация и началась с них (проводов электросети). Тот же X10 с 1975, кстати, прямые его потомки до сих пор активно продаются. Общеевропейские стандарты автоматики тоже использовали электороводку как базовую среду передачи данных (как один из вариантов, который также включал IR, 433 и видую пару), но на практике это все было сопряжено с большим количеством сложностей по фильтрации потока данных на границе квартиры или дома. Да и просто с межфазной коммуникацией. Хотя, при современных чипах эти потоки могут быть вполне хорошо зашифрованы, но ведь по сути мы получаем такое же радио, но без свободы кнопочку положить на тумбочку и перенести на стол с ноутбуком, но с ворохом технических сложностей, отлично описаных в статьях про качество проектирования электроустановочных изделий. Понимаете, одна CR2032 (которой как показала практика хватает более чем на год) вас точно не убьет. Да и вообще, притянуть к датчику открытия окон или к датчику движения 230В как-то уж слишком избыточно. Знаете, я как раз пошел по обратному пути. У меня все ответственные актуаторы, сенсоры и контроллеры подключены проводами, а вот всекие улучшалки и дополнительные удобства по воздуху. Даже если будет заглушен весь диапазон частот, в худшем случае не включится автоматом свет в каком-то коридоре. А вот про котлы, защита от подалов, замерзания и вовсе должна работать автономно даже в случае пропадения шины данных (да, у меня шинная топология, но это не так важно). В том же BACnet, отлично расписаны и реализованы системы уровней контроля и работы автоматики. В случаях разрывов связи между PLC, модулями, датчиками и тп расплачиваться можно только эффективностью управления, а не физической безопасностью людей или имущества. Поэтому это системы созданные инженерами для инженеров. Какую бы фигню не навводил оператор на диспетчерском пульте — опасность заморозки калорифера будет выше по приоритету и плевать на желание оператора или пользователя, а если есть сработка противопожарной сигнализации, то плевать на замерзание теплоносителя в медных трубках
                      +2
                      Спасибо, буду использовать как чек-лист.
                        +1
                        Есть спорные моменты.
                        Но по сути под каждым пунктом подписываюсь!
                        Много разных систем автоматизации попробовал у себя дома, и промышленных и самоделок собственной разработки, приживались только те, о существовании которых домочадцы либо не догадывались, либо которые не отличались от обычных.
                        Например «Умный свет»
                        Теща, с женой как всегда клацают выключателями, совсем не задумываясь проводами он прицеплен или по радио. А я время от времени переключаю им свет в кухне через веб интерфейс, сидя у себя в кабинете. А всякие навороты со сценариями освещения и дистанционным контролем и управлением, остается чисто моей «игрушкой». Но всем особенно понравился функционал, «выключить весь свет» щелчком выключателя возле входной двери. Наверно только голосовое управление способно создать приемлемую альтернативу, простому выключателю. Но тут пока принцип надежности управления не позволяет делать его основным.
                          +1
                          В моей практике в пределах квартиры голосовое управление редко когда себя оправдывает при условии достаточного количества выключателей в правильных местах(выходы, с обеих сторон кровати и тд), а вот за городом — это да. Сказать Сири «Включи свет на улице» удобно, потому что идти в дом далеко бывает. Групповое выключение света физическим выключателем самый удобный способ, особенно, если выключатель на стене и никуда не двигается — работает автоматизм не задумываясь.
                          +2
                          Отличный манифест, подписываюсь.
                          Но похоже полностью ни одна система ему не соответствует. Поэтому у меня пока нет умного дома в доме.
                            0
                            Пункт 9.
                            Получить бодрящие 220 Вольт при замене лампочки — хорошо, а включить водяной кран, без обвешивания датчиками затопления — плохо?
                            Как то первый абзац неаккуратно сформулирован.
                            Со вторым абзацем соглашусь.
                              0
                              Замена лампочки — это осознанное действие пользователя(ну, как правило). Залез пальцем в патрон — ну, сам виноват.
                                0
                                Обычно замена/очистка происходит при обесточенном светильнике.

                                Тогда необходимо добавить пункт 16: Чек-лист на каждое событие; и Пункт 17: Полный свод событий и действий пользователя.
                                Данные материалы должны присутствовать на пластиковых листах, в зоне действия всех датчиков.

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое