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

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

Так где же в Умном доме есть место для принципа суперпозиции? По моему мнению, есть одно противоречивое место в домашней автоматизации, которое до сих пор не получило ясного ответа. Звучит оно достаточно просто:

Где должен находиться сервер Умного дома, в облаке или в локальной сети?

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

Понятие автоматизации тесно связано с понятием автономности. Естественное и справедливое желание владельца Умного дома стремиться предусмотреть тот случай, когда облачный сервер окажется вне доступа к умным устройствам жилища. Хотя, на практике все мы понимаем, что без Интернета никуда, нас так или иначе разъедает изнутри мысль: А вот если отключат?

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

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

Я не буду утомлять Вас дальнейшей философией и перейду к практическому разрешению этого вопроса, которое я решил оформить в виде проекта SmartESP (SmartESP.net). Суть идеи проекта состоит в том, что сервер Умного дома находится в суперпозиции. Другими словами, программный комплекс может работать как облачный, так и локальный.

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

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

Почему веб-сокеты это плохо? Это плохо потому, что устанавливаемый сокет требует обмена сигналами keepalive. Что это значит? Это значит, что контроллер, находящийся в большинстве случаев за NAT и выступающий инициатором соединения волен требовать ответа сервера, когда ему вздумается. Становится очевидно, что при масштабировании такой системы связи, возникнет ситуация, когда количество сигналов keepalive будет, то густо, то пусто. Получается крайне неэффективный вариант, когда мы должны проектировать систему на худшее стечение обстоятельств, но которые по факту могут быть крайне редки.

Что тогда? Тогда необходим шлюз. Шлюз будет устанавливать единственный канал, может даже тот же веб-сокет, через который будет отправлять суммарные данные контроллеров. Например, есть шлюзы широко известных компаний, которые предоставляют своё закрытое облако, плюс, попутно отказались от стандартного WiFi в пользу BLE. Однако, этот шлюз без облака техногиганта превращается в «кирпич».

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

Да, именно маршрутизатор (роутер) с VPN-соединеним к серверу, где установлен сервис SmartESP, делает прозрачной связь сервера с контроллерами. Именно таким образом, сервер SmartESP осуществляет прямой контроль над всеми контроллерами Умного дома. И самое главное, что теперь не так важно где будет находиться сервер в облаке или в локальной сети. Так или иначе он является инициатором соединения с контроллером, зная его адрес, а является ли данный контроллер «близко» или «далеко», это лишь вопрос маршрута.

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

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

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

Комментарии (37)


  1. tumbler
    01.09.2023 08:16
    +5

    Облачный умный дом - это не только зависимость от провайдера, но и вендор-лок. Сегодня, простите, ваш SmartEsp есть, а завтра небольшой умный поселок превращается в тыкву.


    1. KasDim Автор
      01.09.2023 08:16

      Вы правы. Но, это опыт сегодняшнего дня. Я предложил концепцию парашюта. Если облако становится неудовлетворительным, то проекты моментально стартуют на локальном сервере. Если же речь, о конкретной неприязни к вендору, что же, все схемы контроллеров открыты и основаны на популярной элементной базе. Скажем перепрошивка ESP8266 с помощью ESPEasy и установка Home Assistant, всегда доступна. То есть, здесь нет hardware+software vendor lock. Следовательно, превращение в тыкву отменяется.


  1. Jury_78
    01.09.2023 08:16
    +6

    По мне так слишком витиевато и похоже на рекламу.


    1. dabrahabra
      01.09.2023 08:16

      Текст писал ChatGPT


    1. KasDim Автор
      01.09.2023 08:16

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


  1. Pavel7
    01.09.2023 08:16
    +4

    Хотя, на практике все мы понимаем, что без Интернета никуда

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

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

    та идея проекта SmartESP

    Из статьи не особо понятно, в чём именно эта идея, а картинки и дистрибутив на сайте ведут в 404 (https://smartesp.net/en/software/ https://smartesp.net/en/api/store/?file=SmartESP1.0.4.zip)


    1. KasDim Автор
      01.09.2023 08:16

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


      1. Razoon
        01.09.2023 08:16

        А в чем, собственно, проблема в качестве сервера использовать одноплатный компьютер? HA вполне уверенно помещается на условной малинке даже третьего поколения, уже не говоря о четвертом. Более того, вместе с малинкой мы получаем и встроенный Bluetooth и возможность воткнуть ZigBee свисток в свободный порт USB. Плюс GPIO Гребёнка позволяет делать массу интересного для умного дома. В наше время, на первый план выходит приватность и безопасность, все стараются отказаться от всяческих облаков и вендорлоков, ибо после всем известных событий, нам уже в полной мере показали чего эти облачные технологии стоят. Вы же предлагаете по сути то же облако, но типо отечественное (хотя скорее всего, не очень) и с возможностью установить его кусочек у себя(такой себе cloud@customer) но это не решает задачу предотвращения доступа третьих лиц к моим данным, а так же задачу прекращения доступа меня самого к этому самому клауду. Во всей этой ситуации, уже давно нет никакой суперпозиции, все давно определились с тем, что сервер умного дома должен располагаться внутри контура этого самого дома, и быть полностью тебе подконтролен.


        1. KasDim Автор
          01.09.2023 08:16

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


          1. Razoon
            01.09.2023 08:16
            +1

            Каждый выбирает для себя единственно верный путь, для аудитории представленной на этой площадке, единственно верный путь это собственный сервер, о чем вам, уже неоднократно тут сказано. Остальное, буду считать софистикой.


      1. Pavel7
        01.09.2023 08:16
        +1

        Но, есть ключевой нюанс, если Вы не находитесь в доме 24/7, то как не крути, но Вам надо знать в моменты отсутствия: что там дома?

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

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

        Очевидно, что даже в приведённом вами примере, локальный сервер надёжнее. Могу только повторить единственный плюс облачного сервера - простота.


        1. ptr128
          01.09.2023 08:16

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

          Я бы сказал даже недалеко от дома. В деревне у меня WiFi от модема на столбе метров на 200 хреначит.


        1. KasDim Автор
          01.09.2023 08:16

          Очевидно, что даже в приведённом вами примере, локальный сервер надёжнее. Могу только повторить единственный плюс облачного сервера - простота.

          Напомню, мы обсуждали изначально тезис "Интернет нужен в любом случае"


          1. ptr128
            01.09.2023 08:16

            Не совсем так. Обсуждалась удаленная доступность сервера. А она может быть реализована не только через резервный канал на старом смартфоне, но и через SMS на/c него же, и через mesh сеть, и через CB/КВ модем, или даже через Iridium, VSAT и т.п.

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


  1. kasiopei
    01.09.2023 08:16

    Недавно отключали свет. Узнал что сотовой вышки нет бесперебойника. Темно и связи нет. Какие могут быть облака?! Зачем вам облачная отказоустойчивость? В случае поломки домашнего сервера дом станет тупым и все. Вы не потеряете ничего.


    1. kekoz
      01.09.2023 08:16

      При моём прямом или косвенном участии построено несчётное количество “сотовых вышек” для всех наших ОпСоСов, и уверяю — не бывает “сотовых вышек” без “бесперебойников”. Но поскольку аккумуляторы у “бесперебойников”, применяемых на абсолютном большинстве наших “сотовых вышек”, внешние, они — естественно — являются лакомной целью воров. И их таки прут “по чёрному”.

      А сейчас ещё по понятным причинам есть их (аккумуляторов) ощутимый дефицит.


      1. ptr128
        01.09.2023 08:16

        Откуда дефицит, если не секрет? Свинца в РФ что-ли мало стало? Никель для таких целей мало пригоден. Литий, если нет ограничений по объему и массе - нерентабельно. За год десяток-другой циклов от силы наберется. А через 5-7 лет все равно менять как свинец, так и литий.


  1. evilsprut
    01.09.2023 08:16
    +2

    >> Где должен находиться сервер Умного дома, в облаке или в локальной сети?
    В реальности такого вопроса не стоит от слова совсем. Во-первых задержка до удалённого сервера будет бесить. Даже когда сервер дома, задержек с zigbee а тем более wifi хватает. А во-вторых куча точек отказа добавляется. Интернет не оплатил - умный дом умер, кто-то перебил кабель провайдера, выкатили кривой апдейт в облако и прочие проблемы, нет уж, спасибо.


    1. KasDim Автор
      01.09.2023 08:16

      Вы правы. Однако, есть и факт существования облачных сервисов. И даже у них есть достаточное число пользователей. Значит на их стороне тоже правда. Столкновение двух правд и есть диалектический вопрос.


      1. Razoon
        01.09.2023 08:16

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


        1. KasDim Автор
          01.09.2023 08:16

          Простите, но Вы хотите меня всё время отсортировать по признаку "свой" или "чужой" ))) Я не тот и не тот. Моя идея именно уйти от радикализации идей облачного или локального сервера.


          1. Razoon
            01.09.2023 08:16

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


    1. lex899
      01.09.2023 08:16

      Во-первых задержка до удалённого сервера будет бесить.

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


  1. Mitya78
    01.09.2023 08:16

    Всё думаю, есть ли смысл рассказать как у нас устроено.

    Дело в том что никакой это не rocket science, да и дом-то не умный (я таких и не видел), но сделано с размахом и развивается.

    Одно использование контроллеров S7-1500 чего стоит, плюс в связке с Crestron.


  1. Dremkin
    01.09.2023 08:16

    Я в своей системе сделал локальный сервер. Пользуюсь больше 5 лет, всякое бывало )) много раз перелазил через забор, т.к. ворота не открывались) но это все ерунда, ничего критичного. И вот я пришел к выводу, что без управления с инета можно спокойно пережить какое-то время, главное - продублировать функции через физические кнопки (у меня кнопки могут нажиматься от 1 до n - и выполняются определенные действия).


    1. ptr128
      01.09.2023 08:16

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


  1. punilki
    01.09.2023 08:16
    +1

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


    1. KasDim Автор
      01.09.2023 08:16

      Я согласен с Вами. Наверное поэтому и реализовал у себя режим автономности "последний рубеж". То есть, предполагается, что даже с локальным сервером или с роутером или с сетью может что-либо произойти. Поэтому в самом контроллере, есть примитивный способ задать некие пороговые значения. В этом случае, если сервер (локальный или облачный не имеет значения) не обращается к контроллеру в течении какого-то заданного времени, то контроллер берет управление на себя. Скажем так, некий автопилот, который совершит мягкую посадку, до возобновления связи.


  1. ptr128
    01.09.2023 08:16

    Прочитал. Ничего не понял. Если речь о VPN на роутере, то удаленный сервер, по сути, уже в локальной сети. Так же как ноутбук можно в офисе воткнуть в локальную сеть, а вне офиса поднять VPN и оказаться в локальной сети офиса через него. И даже конфигурацию не надо править. Получили по dhcp на сетевой адаптер реквизиты локальной сети - прекрасно. Получили что-то иное - поднимаем VPN.


    1. KasDim Автор
      01.09.2023 08:16

      то удаленный сервер, по сути, уже в локальной сети

      Это и есть квинтэссенция. Кот одновременно и жив и мертв, а сервер одновременно и в дата-центре и в локальной сети.


      1. ptr128
        01.09.2023 08:16

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


  1. RomanKu
    01.09.2023 08:16

    2 раза перечитал и ничего не понял. Что мешает поставить Home assistant внутри четя и сделать все локально?

    Ну и по конфигурации, зачем настраивать крон на хосте, если можно спокойно завернуть его в docker-compose и получить более стабильную систему из коробки?


    1. KasDim Автор
      01.09.2023 08:16

      Что мешает поставить Home assistant внутри четя и сделать все локально?

      Объем трафика, задержки, другая архитектура, другие отношения у HA с контроллерами.

      Ну и по конфигурации, зачем настраивать крон на хосте, если можно спокойно завернуть его в docker-compose и получить более стабильную систему из коробки?

      Не могу сказать. Из того что я понял, докер не желательно использовать для крон-заданий.


  1. Crazy_Pit
    01.09.2023 08:16

    используя "пару тройку лет" и пережив несколькократное обрушение системы пришел к выводу. что система умного дома должна строиться следующим образом. конечное устройство управляет объектом автономно делясь и получая данные через mqtt. далее же система умного дома управляет и настраивает контролер конечного устройства.. то есть. например в холодильнике у меня стоит есп реле и управляет режимом охлажление оттайки. по mqtt отправляется статистика, состояние и текущая температура, хомассистант строит графики температуры для анализа состояния холодильника. аналогично организован полив теплицы. а вот звонок который состоял из двух устройств кнопки зигби и перепрошитого зигби маршрутизатора от МiHome неоднократно выходил из строя. то сервак сломаю , то свисток зигби неправильно перепрошью. то отвалится кнопка(села батарейка пришлось пересопрягать). . голосовое управление кстати использую от можордомо. по мктт управляется паралельно хомасистенту. и речь где должен находиться сервер не стоит. - только локально


  1. Feeel
    01.09.2023 08:16
    +1

    Идеи не понял...

    Вижу реализацию в лоб: 2 сервера - один локальный, второй облачный, и синхронизация между ними: какие входящие данные (управляющие команды/настройки) свежее по времени, те и используем.

    При чём тут суперпозиция вообще не ясно, но слово прикольное, да.


  1. Coder007
    01.09.2023 08:16
    +1

    Очень интересные размышления. Главное - актуальные. Предлагаю рассмотреть оба варианта, но с другой стороны. Сделать вообще распределенную систему умного дома, в которой локальные контроллеры самостоятельные единицы и не привязаны к софтверной логике, они могут работать не зависимо от локального сервера (при потере связи с ним). Локальный сервер - это больше визуализация и объединение данных + комплексное управление. Облако - в большей мере - это удалённый доступ без каких либо сокетов, которые отвечают за управление, визуализация и ограниченное управление. Как показывает практика промышленной автоматизации - лучше всего иметь распределены системы. Они как правило надёжнее и не влияют на соседние процессы. Это мои мысли, но возможно они будут полезны.


    1. KasDim Автор
      01.09.2023 08:16

      Спасибо за мысли, они интересны. Да, идея распределенности мне импонирует тоже. В одном из комментариев я писал, что сейчас контроллеры имеют свой режим автономности на уровни прошивки. То есть "отвалившись" от связи с локальным или облачным сервером (неважно), они переходят в режим упрощенного алгоритма работы. Да, у меня была мысль, чтобы сделать так чтобы контроллеры всегда могли работать без сервера, если нет связи, то есть дублировали внутри себя полностью все алгоритмы сервера. Но проблема в том, что сервер все-таки нужен потому что: 1) он можем объединять контроллеры в "умную сеть", то есть управлять определенными стратегиями (режимами), которые состоят из совокупности задач, основываясь на показателях других контроллеров; 2) с ним проще создавать Умный дом по частям, от одного контроллера к ста контроллерам; 3) он позволяет легко объединять контроллеры принципиально разных сетей, то есть разных мест (например, контроллер оповещения в доме может дать сигнал о том, что происходит на даче; метеостанции могут собирать данные находясь на существенно расстоянии от зависимого объекта) как если бы они были в одной сети. Есть даже идея о том, что пользователи одного сервера могут предоставлять доступ к показаниям своих контроллеров другим пользователям, которые на их основе могут закладывать переключение режимов работы своих объектов.