Здравствуйте, уважаемые любители Интернета Вещей.


Продолжу цикл статей о нашей сети LoRaWAN. Сегодня расскажу про реальный кейс. Это проект для крупнейшего торгово-развлекательного комплекса в Челябинске. Поделюсь с вами цифрами и решениями по проекту.


В конце статьи расскажу, почему мы выбрали протокол передачи LoRa, а не zigbee. Возможно, кто-то с этим поспорит. Тем интереснее будет обсуждение.





Что имеем:


Запрос от развлекательного комплекса, который расположен в торговом центре «Родник».


Вводные: в комплексе есть несколько точек со своими электрическими счетчиками на каждой. Нужно наладить систему сбора показаний с приборов учета и их передачу по api на сторону клиента.


Какие очевидные сложности для нас при такой постановке задачи?


1 — Нет опыта работы с ТРК. Это не совсем сложность, а скорее особенность этого проекта для нас. Важная.


2 — Клиенту нужна передача данных по api, минуя наш интерфейс.


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



3 — Негативные отзывы коллег. По их словам, работа с ТРК — это сплошная головная боль.


4 — Уникальность проекта, нет примера для подражания.


Все ТРК уникальны. В каждом своя компоновка внутренних помещений, разные материалы для фасадов и «темные углы». Нет какого-то одного образца для подражания и копирования. Все нужно делать с нуля.


Что сделали:


Начали с радиопокрытия.


ТРК «Родник» — крупный шопинг-центр Челябинска. Масштабы передает фото в начале статьи.


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


По административным причинам поставить базовую станцию внутри комплекса нельзя. Ближайшая возможная для установки точка — в километре от самого комплекса. Причем оборудование там уже есть. Ставить новую базовую станцию не нужно.
Между комплексом и базовой станцией — прямая видимость.


Характеристика здания:


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



Фасад:



Окна:



Двери внутри комплекса:



Еще двери:



Оборудование клиента стояло в техпомещении.


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


Возможно ли это?
Практика показала, что вполне.


Обследование:


Для работы использовали обычный радиомодуль СИ-11.
Инженер просто ходит и периодически проводит его активацию. Далее подтягиваются значения уровня сигнала (RSSI) и сигнал/шум (SNR) с сервера и делается оценка.
У компании Вега есть специализированное устройство ТС-1 (тестер сети).



Мы с ним не подружились. Устройство не видит сеть там, где она есть, врет по уровням. Пожалуй, пока это единственный продукт Веги, который нам не пошел.


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


Для большинства помещений хватило установки СИ-11.
На 1 счетчик — 1 час работы бригады из 2-х человек вместе с установкой и настройкой. Точное количество подключенных счетчиков указать не могу (коммерческая тайна), но их много. Мы были удивлены количеству. Счет на десятки.


Поначалу наши радиомодули активировались на SF=12 (как и предусматривает логика). Мы с большим интересом наблюдали за их качественными параметрами, думали, что связь будет на грани. Но нет, пакеты ходили стабильно и без потерь. RSSI местами достигал -100 дБм.


Когда включился ADR, некоторые радиомодули снизили SF с 12 до 10-11. Радиоусловия это позволяли. Параметры связи на SF=10 держатся на уровне RSSI = -110 дБм, SNR колеблется в районе нуля.


Про «темные углы»:


Без них не обошлось.
В одном месте СИ-11 упорно не хотел выходить на связь. Тогда задействовали СИ-21.





Это тот же СИ-11, только с внешней антенной. Очень удобная штука, в комплекте поставляется плоская антенна с двусторонним скотчем. Методом подбора нашли наилучшее расположение антенны и просто наклеили ее на стену… Работает!


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


А что дальше?


Мы добились хождения пакетов.


Честно признаюсь, я был приятно удивлен результатами. По отзывам коллег слышал, что внутри ТРК проект без indoor базовой станции работать не будет, а у нас получилось. Это приятно.


Пару слов про API


Запрос клиента на api решили просто. Клиент получает данные сервера через веб-сокет. Что он с ними делает дальше — не нашего ума дела.
Сервер позволяет настроить систему таким образом, что клиент видит информацию только со своих датчиков.


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


Делаем выводы.
Все ли ТРК нам по плечу?


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


Первый шаг оказался успешен. Но работа с другими ТРК показала, что расслабляться не стоит.


Главные проблемы, на мой взгляд:


1) Каждый ТРК уникален. Какой-то может иметь сквозную подземную парковку с хорошими проходами в магазины и атриум. С такими просто. Другие — это настоящие каменные мешки с крошечными стеклами и оборудованием в подвале. Это уже беда.


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


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



А zigbee нам не подошел
Так получилось, потому что:



1) Построить mesh-сеть в этом ТРК мы не могли. Не было возможности равномерно распределить датчики по периметру комплекса. Радиомодули находились в удаленных друг от друга местах. Между ними — стекло и бетон. Mesh-сеть в такой ситуации навряд ли поднялась бы.


2) В самом ТРК нашей сети нет. Связаться с ближайшей базовой станцией не получится из-за ее удаленности от здания.


3) Мы хотели сделать все максимально просто и с наименьшими затратами. Поэтому выбрали LoRa. Она подошла идеально.



На этом все. Я рассказал, как мы сделали реальный проект для ТРК. Описал сложности, задачи и наш опыт их решения. Пояснил, почему решили работать на протоколе LoRa.
Будет интересно услышать мнение про этот кейс от специалистов и тех, кто в теме Интернета вещей.



Архив прошлых статей:
#1. Введение > #2. Покрытие > #3. Зоопарк приборов учета > #4. Проприетарность > #5. Активация и безопасность в LoraWAN > #6. LoRaWAN и RS-485
> #7. Девайсы и перекупы> #8. Немного про частоты

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


  1. firedragon
    08.10.2018 09:52
    +1

    Всегда смущала мода пихать все в радио канал. Почему данные со счетчика не перекинуть по проводке до хаба и дальше отправить по оптике или GSM до центра обработки?


    1. Interfer Автор
      08.10.2018 10:20

      1) Оптики у нас в ТРК нет.
      2) Какой смысл использовать GSM, если мы имеем свой гарантированный канал радиосвязи?
      3) Мы постарались прикрепить максимум материалов, чтобы вы оценили размер ТРК. Стащить кучу проводов к хабу там задача малореальная. Даже если это удастся технически, затраты будут просто капитальные. Через Лору дешевле.


      1. shoorick
        08.10.2018 22:18

        крупнейшего торгово-развлекательного комплекса в Челябинске

        А «Горки» и «Алмаз» не крупнее?


        1. Interfer Автор
          09.10.2018 07:27

          Горки точно нет, насчет Алмаза уже не так уверен. В любом случае, Родник если и не самый большой, то второй по размерам)


      1. sim31r
        09.10.2018 05:06

        LoRa гарантированный канал радиосвязи? Любой желающие легально может включить 8 передатчиков на 8 LoRa каналах, передающих непрерывно поток данных и сеть LoRa будет загрушена в радиусе ~5 км. Кому-то хочется файлы передавать по сети, и с точки закона все равны, телеметрия и мультимедиа канал. Надо только уточнить по допустимому времени работы, иногда указывается 5-10% время активное ко времени пассивному.
        Частотный диапазон там ограничен, кроме злоумышленника может жилой дом рядом перейти на сеть LoRa и передавать непрерывно данные со счетчиков, забив эфир.


        1. Interfer Автор
          09.10.2018 07:35

          Скоро будет статья про последние изменения в частотном законодательстве.
          Круглосуточно спамить вы сможете, но это не по закону. По закону от 0,1 % до 10 % времени в эфире, в зависимости от поддиапазона.

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

          Что же касается других абонентов без злого умысла — да, так и будет. Число устройств будет расти и в эфире скоро всем станет тесно. Но уже расширяют границы дозволенных частот. Будет примерно как с вафлей. Сейчас в многоквартирном доме в 2,4 творится просто ад. И что, никто не работает? Да работают, пусть не так эффективно, но в целом хватает. Плюс — есть пятерка.


          1. sim31r
            09.10.2018 11:49

            Согласен. Число абонентов будет расти, диапазон пока свободен и привлекателен этим. Но каждая статья на Хабре будет привлекать всё больше пользователей ))
            Даже при времени работы 0.1% тысяча абонентов как-раз плотно займут канал. Впрочем для телеметрии хватит вполне.
            Хорошо бы тут упомянуть о какой-то культуре пользования каналом, передавать минимум информации, на минимальной мощности, чтобы не мешать окружающим.


          1. hobogene
            09.10.2018 14:39

            По закону от 0,1 % до 10 % времени в эфире, в зависимости от поддиапазона.


            Кажется, иногда все-таки 100% :-)


            1. Interfer Автор
              09.10.2018 20:19

              Ссылку на нормативный документ?


              1. hobogene
                09.10.2018 20:50

                Сам жду, пока в какой-нибудь юридической базе актуальная редакция появится.


              1. hobogene
                09.10.2018 21:00

                А не, появилось.
                www.consultant.ru/cons/cgi/online.cgi?req=doc&base=EXP&n=652036&rnd=65F54082882AD50FBFC6C908A2A7CA1F&from=527972-4#00012731402012002846

                868.7 — 869.2. на 25 мВт никаких ограничений на рабочий цикл. На 100 мВт — 10% или LBT.


  1. Elgens
    08.10.2018 10:16

    мда, я бы бегал с перфоратором тащил бы по зданию rs-485 ))))
    ухахах…


    1. Interfer Автор
      08.10.2018 10:21

      Во-во. Тот случай, когда по радио всем проще)


    1. Makc_K
      08.10.2018 16:08

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


      1. sim31r
        09.10.2018 11:54

        Можно активные репитеры ставить, проблема с КЗ ушла бы. Да и второй раз такую проблему найдете намного быстрее )) Сложнее когда одно из устройств сходит с ума и начинает спамить в общую шину непредсказуемо.


        1. Makc_K
          09.10.2018 11:59

          Сложнее когда одно из устройств сходит с ума и начинает спамить в общую шину непредсказуемо

          Это проблема для любого канала и протокола связи.


  1. Makc_K
    08.10.2018 16:03

    Буквально на днях общался с разработчиками системы для учёта энергоресурсов. Довольно известных. На вопрос получения данных с приборов учёта (счётчики, расходомеры и т.д.). Они используют ТОЛЬКО API приборов, даже, если производитель может предоставить OPC сервер. Объясняют тем, что при использовании программной прослойки теряется метрологическая составляющая полученных данных.
    Что интересно, в нашей области деятельности (газ) применение OPC технологии наоборот всячески приветствуется и рекомендуется на уровне отраслевых регламентирующих документов.


    1. hobogene
      08.10.2018 20:12

      Что-то забавное они про метрологию говорят. Если всерьез вопросом занимаются, им все равно систему через метролога прогонять. И на этом этапе все «потерянное» можно «найти».


  1. EugeneT
    08.10.2018 16:44

    Мы делали на zigbee от ЭФФА. Внутри там чип от Rexenta, документирован очень хорошо. Сбор показаний написали на коленке. Провода в ТРЦ работают не очень, потому что арендаторы часто меняются и помещения перепланируются, делятся, сливаются. Как следствие, счетчики гуляют как те кошки.
    По масштабам у нас не Родник конечно, но тоже немаленький. На сегодня подключено 220 приборов к трем координаторам.


    1. hobogene
      08.10.2018 20:14

      А зачем вам три сети?


  1. LumberJack
    08.10.2018 16:49

    А если какой-нибудь радиогубитель частоту заспамит, данные до потребителя дойдут?


    1. Interfer Автор
      08.10.2018 17:03

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

      А новая прошивка от Веги позволяет не терять пакеты с данными даже если в конкретный час связь не состоялась.


      1. lenz1986
        08.10.2018 23:33

        вроде как с ней все проще, можно на ней же самой преамбулой просто молотить в эфир, тогда она всегда будет считать что канал занят, точнее 8-ю преамбулами


        1. hobogene
          08.10.2018 23:42

          каналЫ :-) И, как выяснилось, можно даже четырьмя обойтись, а то и двумя, если полосу пошире взять.
          Хотя со всеми этими способами есть свои тонкости.


      1. hobogene
        08.10.2018 23:41
        +1

        >дадут ли вам надзорные органы долго спамить в 868.

        Вы прекрасно знаете, что куча контор работает на EU868. И никакие «люди в черном» за ними пока не приходят :-) Так что дадут.
        Ну и про отсутствие duty cycle limitations в полумегагерце частот тоже знаете.


        1. Interfer Автор
          09.10.2018 07:40

          Я имел ввиду именно ситуацию с глушением канала каким-нибудь передатчиком Ватт на 50. Если будете делать это в 868, то я думаю, быстро заинтересуются.

          С EU868 иная ситуация. Там народ работал своими крошечными (25-100 мВт) мощностями и никому особо не мешал. И, как показали события 11 сентября сего года, решили выбрать несколько иной путь. Сейчас EU868 частично легализован. Возможно, легализуют полностью.

          Насчет отсутствия duty cycle, очевидно, в 868,7-869,2 — первый раз слышу) По моей информации там сейчас 10%. Раньше 1% был)


          1. hobogene
            09.10.2018 14:35

            Насчет отсутствия duty cycle, очевидно, в 868,7-869,2 — первый раз слышу


            А мне кажется, мы даже с Вами это обсуждали на одном другом сайте. По спеке-то 1%. А по разрешению ГКРЧ — 100%.
            Последние изменения добавили работу на 100 мВт с DC 10%. На 25 мВт все так же 100%.

            Сейчас EU868 частично легализован. Возможно, легализуют полностью.

            Ну, mandatory channels не разрешены. И не похоже, чтобы разрешили, там уже вполне серьезные заинтересованные лица против. Не LoRaWAN'ом единым страна живет-то.


            1. Interfer Автор
              09.10.2018 20:24

              Да, было дело) Но я все же ссылаюсь на это свежевыпеченное решение. minsvyaz.ru/uploaded/files/prilozhenie-12-k-reshenyu-gkrch-18-46-03-1.pdf

              Честно — пока только изучаем его и ищем подводные камни. По мне, так формулировка на наши спорные полмегагерца теперь трактуется именно как 10 процентов занятия эфира на ЭИИМ не более 100мВт. Если вы мне укажете, как можно занять весь эфир на 25 мВт буду признателен. Кроме шуток.


              1. hobogene
                09.10.2018 20:51

                В этой бумажке вот непонятно, дополнения или изменения. А вот заявку, на базе которой это решение принято, мне пересказывали :-)


          1. hobogene
            09.10.2018 14:37

            Я имел ввиду именно ситуацию с глушением канала каким-нибудь передатчиком Ватт на 50. Если будете делать это в 868, то я думаю, быстро заинтересуются.


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


            1. Interfer Автор
              09.10.2018 20:21

              А зачем молотить в эфир преамбулами?) Злоумышленники)


              1. hobogene
                09.10.2018 20:52

                Недоброжелатели и правонарушители — все-таки не одно и то же.


          1. Thar0l
            09.10.2018 20:26

            Если верить ГКРЧ, то последний раз 868,7-869,2 МГц присутствует в приложении 11 (устройства любого назначения) к решению от 28 апреля 2008: 23.rkn.gov.ru/docs/23/GKRCH08-24-01-001.doc и там о duty cycle не сказано, только выходная мощность.



    1. sim31r
      09.10.2018 05:10

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


      1. szelga
        09.10.2018 07:41

        там жилые дома довольно далеко.


        1. Interfer Автор
          09.10.2018 07:42

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


      1. hobogene
        09.10.2018 14:31

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


        1. sim31r
          10.10.2018 13:23

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


          1. hobogene
            10.10.2018 13:29

            который передается до 13 секунд,

            Это откуда такая цифра?


            1. sim31r
              10.10.2018 14:21

              Автор исследовал Lora на предмет максимальной дальности, и вроде как с его настройками скорости обмен данными занимал 13 секунд. Там скорости ~2400 бит/с и менее, передать кадр 200 байт весьма долго, это не WiFi многомегабитный.
              www.youtube.com/watch?v=-7OmGcjkO_Y&t=0s&list=PLCbcCJDLvTuJSVg9IqiBu9yR8akk0Sj91&index=51


              1. hobogene
                10.10.2018 15:01

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


                1. sim31r
                  10.10.2018 15:05

                  LoRa вообще далеко не идеальна, не самый лучший способ использования частотного ресурса. Стриж кажется более качественным в этом плане, узкополосный сигнал, больше каналов в том же частотном ресурсе
                  strij.tech/publications/tehnologiya/lpwan-strij-lora.html


                  1. hobogene
                    10.10.2018 16:26

                    Так и UNB неидеальна во всех своих изводах. Равно как и все остальные технологии. На конкретную задачу надо смотреть и под нее подбирать.

                    Только не подумайте, что я апологет LoRa. Там даже больше недостатков, чем «Стриж» и его производные знают :-)


                  1. hobogene
                    10.10.2018 16:28

                    Стриж кажется более качественным в этом плане, узкополосный сигнал,


                    Чисто попридираться: узкополосный у LoRa. У «Стрижа» — сверхузкополосный.


  1. x893
    08.10.2018 18:01

    Можно и шлюз поставить размером с СИ-21 и передавать с него на сервер.
    Софта может у этого продавца нет, но его можно и сделать самому.


    1. hobogene
      08.10.2018 23:44

      Это Вы какой-нибудь single channel имеете в виду?


      1. x893
        09.10.2018 00:20

        Обычный шлюз. На RAK831 + RPi Z (или STM32). Размер с пачку сигарет. Отправлять можно через ту же LORA. Только разместить правильно — что бы и сенсоры его видели и он видел базовую станцию. Конечно немного сложнее, чем взять готовые. Можно добавить отдельный LORA модуль с большим усилением и направленной антенной на базу. А для сенсоров на стене можно взять антенны, которые только полусферой излучают.


        1. hobogene
          09.10.2018 00:30

          Не совсем идею тогда понял. Зачем вот в данном случае эта конструкция? Которая, кстати, требует нормального питания?


          1. Interfer Автор
            09.10.2018 07:43

            А еще направленную антенну уж тогда проще разместить на самой базе.
            В целом, тоже не совсем понял идею.


          1. x893
            09.10.2018 10:17

            Сенсоры не видят базу.
            Сенсоры видят промежуточный шлюз. Шлюз видит базу. Конечно с направленной ещё больше дальность.


            1. Interfer Автор
              09.10.2018 10:35

              Чем, в вашем понимании, шлюз отличается от базы в архитектуре LoRaWAN?


              1. x893
                09.10.2018 11:20

                только софтом (переделанным packet_forwarder'ом).


                1. hobogene
                  09.10.2018 14:29

                  Короче, репитер для аплинков Вы предлагаете сделать. Можно, но реально непонятно, зачем нужно. И там уж на packet forwarder надо переделывать тогда, а написать приложение, которое от него будет по UDP пакеты получать и тут же по UDP же его просить отправить их обратно в эфир.
                  Но раз уж все равно там нормальное питание, можно и сразу на этом устройстве на сотовый модем разориться и не придумывать чудес таких.


                  1. x893
                    09.10.2018 17:29

                    Да — репитер.
                    Был у меня вариант и с GSM/LTE аплинком (совсем просто делается) и с NB-IoT (не в России). В общем-то ничего сложного и чудес никаких.


                    1. hobogene
                      09.10.2018 20:53

                      Однажды понадобятся даунлинки в классе А с четкими таймингами, и тут уже и будут чудеса :-)


                      1. x893
                        09.10.2018 23:55

                        Когда был GSM чудеса уже были и с аплинком и с даунлинком. Решенная проблема. Исходники то есть на github.


                        1. hobogene
                          10.10.2018 00:14

                          Исходники чего? Как вы передадите таймстемп с репитера нетворк серверу?


                          1. x893
                            10.10.2018 01:53

                            Исходники packet_forward. В случае с медленным аплинком логика работы немного другая. При получении пакета шлюз сразу его отправляет ACK, если есть down pack, то он отправляется устройству. Принятый пакет попадает в очередь на шлюзе. Пакеты из очереди отправляются на network server и при получении ACK от NS удаляются из очереди. Если приходит от NS down package, то оно попадает в очередь для последующей отправки устройству. Если пакеты приходят в пределах по времени, то всё работает как обычно.


                            1. hobogene
                              10.10.2018 02:41

                              Я не вижу, где в Вашем тексте репитер-то.

                              А с медленным backhaul для начала стоит задержку для первого окна выкрутить на максимум в 15 секунд. С джойном, правда, не поможет, но и Ваша схема тоже не очень поможет.

                              При получении пакета шлюз сразу его отправляет ACK,


                              Вот эту фразу не понял совсем.


                            1. hobogene
                              10.10.2018 02:45

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


  1. hobogene
    08.10.2018 19:59

    Не сочтите за критиканство, но десятки устройств — это, как раз, не особо много. Именно поэтому ZigBee вам бы там особо и не подошло.

    RSSI Вы приводите — это то, что на БС видно, я так понимаю?


    1. Interfer Автор
      08.10.2018 20:01

      Ну, RSSI мы формально видим на сервере. Но смысл вы поняли правильно.
      ZigBee бы потребовал некого контроллера, который смотрел бы во вне через какой-то шлюз, к примеру тот же 4g. Это как минимум.


      1. hobogene
        08.10.2018 20:05

        Ну да, я имел в виду, что вы не считывали те условные попугаи, которые возвращает чип на конечном устройстве, с самого устройства. Мало ли, что «Вега» в прошивку там добавила…

        А мощность какая выходная? Без деталей, на уровне «спортивно»/«не спортивно» :-)


      1. hobogene
        08.10.2018 20:08

        ZigBee там много, чего мог потребовать, в зависимости от ситуации. Одними батарейными устройствами бы не обошлись, например (я не про шлюз, тот уж точно не на батарее).


  1. hobogene
    08.10.2018 20:19

    >Методом подбора нашли наилучшее расположение антенны и просто наклеили ее на стену

    Кстати, не очень идея. Про наклеить на стену. Боюсь, отчасти поэтому там и связь на грани.


    1. Interfer Автор
      09.10.2018 07:44

      Методом проб и ошибок) Но в том месте правда яма какая-то. Для одного датчика не критично, если бы их было много таких, то пересматривали концепцию. Скажем, установили на БС секторную антенну.