В 2019 году я был на очередной конференции по IoT и до гостиницы меня подвозил местный коллега. По пути мы обсуждали умное ЖКХ и, конечно же, коснулись LoRaWAN. Коллега сказал фразу, которая надолго мне запомнилась: «Мне кажется, будто рынок сопротивляется внедрению Лоры».
Да, в 2019-м именно так всё и было. Лору тогда попробовали внедрить в ЖКХ и в промышленности. Проекты строили с огромным упорством, взлетали они тяжело, часто сразу падали. После общего подъёма и веры в тему IoT парой лет ранее столкновение с реальностью воспринималось болезненно. Но уже тогда я потихоньку начал признаваться себе: не будет Лоры в каждом утюге. Очень уж ограничен круг её использования. А всякие NB-IoT и Wi-Fi 6 её просто добьют.
Каково же было мое удивление, когда в 2022 году технология обрела вторую жизнь! Несколько крупных игроков (ММК, Сибур) начали развёртку сети на своих заводах.
В этой статье я расскажу, почему LoRaWAN потерпела неудачу, а теперь снова в деле, и что с ней делать, чтобы не было мучительно больно за потраченные усилия.
В своих статьях я не раз останавливался на специфике применения стандарта LoRaWAN. Как и у любой технологии беспроводной связи, у неё есть и плюсы, и минусы. Из плюсов сразу вспоминаем:
Высокая дальность. 2 км в плотной городской застройке и до 10 км в лесу.
Высокая помехозащищённость.
Высокая криптозащищённость.
Передатчик может несколько лет жить от батарейки при условии не слишком частых выходов в эфир.
Можно быстро и относительно дёшево развернуть свою сеть.
Минусы тоже весомые:
Переданная информация измеряется буквально десятками байт. Попытка пропихивать через LoRaWAN существенные объёмы информации — весьма сомнительная идея.
Буквально несколько полос частот в поддиапазоне 868 МГц. При больших объёмах устройств или слишком частых выходах на связь можно положить эфир.
Как видите, технология весьма специфичная. Для чего она может нам подойти? Ну, к примеру, опросить раз в сутки несколько тысяч водосчётчиков в жилом комплексе. Подойдёт она для такого решения? Вполне.
Или провести опрос системы контроля трубопровода. Там раз в час нам надо передать всего один параметр — сопротивление между трубой тепломагистрали и её изоляцией. В среднем городе около 400 точек контроля, они разбросаны довольно хаотично, и в местах их установки нет питания и часто нет связи. Подойдёт решение на LoRaWAN для такой задачи? Более чем.
А если у нас несколько тысяч датчиков, каждый из которых замеряет и передаёт какой-то один свой параметр? Я встречал производства, напичканные датчиками температуры, давления, вибрации. И здесь Лора вполне к месту, она с лёгкостью уделывает своих конкурентов в этой нише. Wi-Fi не может похвастаться такой же дальнобойностью и помехозащищенностью. NB-IoT мог бы составить конкуренцию, но с ним другая беда — административная.
Т. к. NB-IoT — это надстройка над сотовой связью, то для любой работы с ним нужен мобильный оператор. И хорошо ещё, когда он есть. Если же завод стоит в таком месте, где нет сотовой связи (или конкретно NB-IoT), то построить её своими силами (читай — построить private LTE) — это для России очень длинный и тяжёлый квест.
ZigBee имеет совсем иную топологию и в определённых моментах может заменить Лору, но надо смотреть на конкретную задачу.
Что же случилось тогда, в 2019-м, что рынок стал Лоре сопротивляться?
Компания идет, например, в ЖКХ. Планирует опрашивать приборы учёта. Строит свою сеть LoRaWAN. Пробует опросить счётчик воды. Работает!
Пробует опросить счётчик электричества по импульсному выходу. Работает!
Понимает, что надо учиться опрашивать счётчики по RS-485. Именно этот интерфейс помогает доставать информацию из самых важных счётчиков — тепла и части электричества.
Особенность RS-485 в том, что там объёмы данных резко превышают то, на что рассчитана LoRaWAN. Там в обе стороны ходят разные пакеты, там в ответ на запрос может прилететь целый архив существенного веса. Нет. Речь не идёт о гигабайтах нагрузки — килобайты там. Но ведь помним, что Лора рассчитана лишь на десятки байт?
Итак, наша условная компания пришла к тому, что надо как-то опрашивать устройства по RS-485. Провод? Сотовая связь? Зачем? Ведь мы же построили отличную беспроводную сеть — сеть интернета вещей, сеть будущего!
И начинается шаманство. Точнее, попытка пропихнуть какой-то из протоколов RS-485 через Лору в режиме прозрачного канала.
Не знаю почему, но большая часть историй, которые я слышал, даже здесь не спотыкалась. Экспериментаторы брали в качестве теста электросчетчик «Меркурий-230». Особенность протокола «Меркурия» в том, что он весьма немногословен и один из немногих реально работает через Лору через прозрачный канал.
Итак, ура! Мы попробовали, и у нас получилось. LoRaWAN может и RS-485! Вот здорово!
Это «здорово» длится до первой «Энергомеры» с её тяжеловесным протоколом. Вот там энтузиазм начинает спадать. Дальше идут «Караты», «Взлёты» и прочие обитатели подвалов наших многоэтажек. И выясняется, что Лора их не тянет вообще.
То есть тянет, если очень напряжётся, если выставить огромные тайминги, если не перегружать сеть и прочие вещи. Но вот как будто не для этого её делали.
Путь, о котором я рассказываю, прошли почти все интеграторы LoRaWAN, в том числе и мы. Что обидно — он у всех был как под копирку, даже история с «Меркурием» повторялась раз за разом.
Кому-то удавалось сделать верный вывод: Лора имеет очень ограниченное применение и очень узкий круг задач. Вне этого круга её использовать не надо. Даже если уже построили сеть. Даже если эта сеть большая.
А ещё дальность оказалась не такая, как в рекламных буклетах, — там в городе обещали все 5 километров. В общем, как-то всё сошлось в одной точке.
2019 год — это момент, когда прошёл энтузиазм.
Как LoRaWAN пришла в промышленность
Лору бросились развивать в основном телекомы и поставщики оборудования для телекомов. Так уж вышло, что они почти не пересекались c крупными промпредприятиями и не знали, как туда заходить. Потребовалось время, чтобы Лора пришла на промку. Кроме того, промышленность вообще очень консервативная область и в обычных условиях новинки там внедряются и обкатываются долго.
Впрочем, датчики там были всегда. На многих крупных заводах ещё лет тридцать можно было найти прообраз интернета вещей. К примеру, замер температуры печи или вибродиагностика станков были и в 90-е. Аббревиатуре АСКУЭ несколько десятков лет (привет олдам-энергетикам от ЦТ-5000). Но тогда это были просто датчики, измерители, системы контроля. «Вещами интернета» они станут позже.
Со временем эти датчики росли, менялись, становились всё современнее. «Сименс» и «Эмерсон» приучили нас, что датчик может работать и без проводов, и в целом ряде случаев такое оправданно. Конечно, в случае этих гигантов речь шла об их собственных проприетарных протоколах, но сути это не меняет.
Дальнейшую историю вы знаете. Ни «Сименса», ни «Эмерсона» в нашей стране сейчас официально нет. А потребность есть.
Промышленники обратили свой взор на доступные и относительно открытые протоколы.
Как я уже писал выше, из самого популярного — Wi-Fi часто не даёт нужной дальности и стабильности.
Надо понимать, что проекты под заводы весьма скрупулёзно просчитываются. К примеру, на челябинской «Трубодетали» вполне успешно действует сеть датчиков на Wi-Fi. Но для функционирования этой сети им пришлось строить довольно сложное радиопокрытие. На мой взгляд, их техническое решение неоптимально и можно было решить вопрос проще. Однако не стану обсуждать и осуждать коллег, — возможно, я не знаю каких-то вводных, от которых они отталкивались.
NB-IoT требует работы с сотовым оператором. Вы не можете вот так взять и построить сеть у себя на территории. Она либо у вас там уже есть — и тогда нужен договор с оператором. Либо у вас её там нет. Тогда нужно убеждать оператора её построить или заключить с ним договор на использование частот и развернуть privateLTE. Я даже не знаю, что хуже. Оба варианта длинные и тяжёлые.
Различных проприетарных протоколов тоже хватает. Но грамотные люди понимают, что чем менее распространён протокол, тем сложнее обслуживать сеть в будущем.
Задачи же, которые ставятся предприятием, часто прямо подходят под Лору. Раз в час получить информацию с датчика, буквально одно число, несколько байт. Возможно, получить аварийный пакет, что значение вдруг вышло за заданные пределы. И… и всё. Большего и не требуется.
Простой пример. Нам требуется замер температуры в производственном помещении. Очевидно, что нам не нужно измерять её постоянно. По сути, нужно знать два главных момента: среднюю температуру на длительном промежутке и критические отклонения. Это легко решается датчиком на Лоре. Он отправляет информацию, скажем, раз в час, кроме того, предусмотрен режим тревоги, когда при резком изменении температуры отправляется внеочередное тревожное сообщение.
Вдруг оказалось, что Лора идеально подходит для решения этих задач. Именно потому на многих заводах сейчас активно строят Лора-сети. Я этому очень рад, ибо ещё с 2017 года один из самых больших LoRa-энтузиастов у нас в стране.
Но.
Я точно знаю, что RS-485 на заводах есть. И искренне надеюсь, что заводским связистам не придёт в голову «светлая» мысль: «Та-а-ак, сеть мы построили, опрос работает, а давайте попробуем опросить через LoRaWAN вон тот увесистый датчик с кучей метрик…».
Комментарии (71)
dmitryrf
08.12.2022 11:57+7Можно опрашивать счётчики локально, а через Лору отправлять только необходимый минимум, но это существенно усложняет прошивку устройства, да.
Interfer Автор
08.12.2022 12:25Мне кажется, тупиковый путь. В свое время мы им тоже было пошли, но это боль держать зоопарк разных прошивок. Все-таки скрипт опроса со стороны сервера - это удобнее и логичнее.
dmitryrf
08.12.2022 14:34+14Если хватит флэша, можно впихнуть всё сразу. Можно загружать процедуру опроса удалённо через Лору или другие каналы. Да сложно, но прозрачный канал и опрос с сервера через Лору — это совсем сову на глобус, Лора изначально проектировалась под совсем противоположную задачу.
iliasam
08.12.2022 12:03+6Непонятно - как в итоге коммунальщики решили проблему с перегрузкой сети LoRa?
Можно ли перенести общение со счетчиком по его сложному протоколу на сторону микроконтроллера, а по LoRa изредка передавать только одно/два значения - показания самого счетчика?
Тут, конечно, возникает проблема - прошивка становится заточенной строго под определенные марки счетчиков, но это лучше, чем бросать готовую систему.Interfer Автор
08.12.2022 12:27Да, можно и такие системы делают. Но это боль. У вас получается зоопарк прошивок, которые нужно создавать и поддерживать. При этом. объем данных, которые генерит тот же теплосчетчик довольно существенный, если мы качаем, скажем, месячный архив. Даже в ужатом виде пропихивание - это боль.
Коммунальщики по итогу применяют гибридную систему. Теплосчетчик лучше подключить проводом и воткнуть в подъездный коммутатор. А вот какой-нибудь водосчетчик из темноты подвала можно и Лорой. Там импульсный выход, нет питания и тянуть туда провод нецелесообразно.
MUTbKA98
08.12.2022 14:31+6Ну не такая уж и боль, да, это некоторая работа, но не такая уж и сложная. Зато результат будет нормальный и без болей.
Evengard
08.12.2022 12:29Я конечно с бытового уровня смотрю, но судя по тому что в современных счётчиках чаще всего находится симка, видимо ЖКХ пошло по пути NB-IoT или чего-то подобного.
13werwolf13
08.12.2022 12:14+2Не знаю почему, но большая часть историй, которые я слышал, даже здесь не спотыкалась. Экспериментаторы брали в качестве теста электросчетчик «Меркурий-230». Особенность протокола «Меркурия» в том, что он весьма немногословен и один из немногих реально работает через Лору через прозрачный канал.
Итак, ура! Мы попробовали, и у нас получилось. LoRaWAN может и RS-485! Вот здорово!
Это «здорово» длится до первой «Энергомеры» с её тяжеловесным протоколом. Вот там энтузиазм начинает спадать. Дальше идут «Караты», «Взлёты» и прочие обитатели подвалов наших многоэтажек. И выясняется, что Лора их не тянет вообще.
классический импортозамес, гораздо правильнее было не только внедрять лору в счётчики но и сами счётчики делать под использование лоры, двустороннее движение хотя и сложнее (и дороже) но с куда большим шансом привело бы к успеху.
мне кажется если сделать счётчик с некоторы унимерсальным интерфейсом на который можно повешать любой из возможных обработчиков lora/zigbee/ble/gsm/wifi/etc который не просто будет передавать собранное с интерфейса счётчика а обрабатывать в неободимый удобоваримый для протокола вид и отдавать только полезные данные это будет устройство которое быстро окупится и будет желанно многим (как минимум потому что кроме передачи показаний для ЖКХ служб можно будет и для себя их собирать через homeassistant/zabbix/etc)Interfer Автор
08.12.2022 12:29Ну вот сейчас все к тому и идет. Но рынок ЖКХ не самый поворотливый. И зоопарк из протоколов там пошел традиционно. Сейчас в рамках 522-фз худо-бедно стандартизировали электричество и то вопросов там больше, чем ответов. Внедрение ФЗ проходит на редкость тяжко.
Didimus
09.12.2022 09:06В Москве целый дом перевели на водосчетчики с проводом и Коробочкой. В коробочке батарейка литиевая размера 373 и плата. Видимо, это и была лора. Говорят, обещали жильцам, что не надо будет показания передавать и все согласились. Не знаю, передали ли ли они реально показания, но проект не взлетел, счётчики заменили на обычные по износу
izh-vii
09.12.2022 10:27Тяжело, потому что нет заинтересованной стороны. Проблема как ни странно в слишком дешёвых ресурсах )) . Считайте: счетчик, установка, регулярная замена / поверка, создание инфраструктуры и ее обслуживание.
С другой стороны - каждый может платить за ресурс по нормативу.
На примере холодной воды ~ 2000 руб. В ГОД!
Со счетчиком возможно чуть меньше. А возможно и наоборот, больше - если любишь под душем постоять. Где финансовый смысл установки счетчика, даже обычного?
iliasam
08.12.2022 12:33+2Подозреваю, что в ЖКХ счетчики уже давно установлены, и менять их, чтобы добавить LoRa, коммунальщики не захотят.
Плюс, в некоторых случаях, к примеру, если счетчики стоят в подвале, удобней все счетчики подключить проводами к одному устройству, от которого один антенный провод пойдет на улицу.13werwolf13
08.12.2022 13:33+2Есть парочка "но":
1) лично я (и мне кажется я далеко не один такой) с удовольствием поменял бы счётчик на другой с zigbee независимо от того что об этом думает жкх
2) про счётчики в подвале я конечно слышал, но в живую не встречал (подозреваю что такое есть только в паре городов россии вроде москвы, но как известно "москва не россия"), но вот лично на моём примере проблемой будут счётчики электричества распологающиеся в общем коридоре, расстояние до них такое что zigbee просто не дотянется
3) вы забываете про ижс где возможностей, а главное желания, "апгрейда" сильно больше
SdrRos
08.12.2022 15:35+2У счётчиков есть межповерочный интервал, 5-16лет, и часто стоимость поверки больше стоимости нового счётчика, поэтому в теории обновление счётчиков должно быть регулярным. На практике правда счётчики электроэнергии много где ещё дисковые...
sim31r
08.12.2022 16:4199% счетчиков все таки обновляются. Дисковые я вижу в базе данных своей по абонентам, но это единичные какие-то случаи.
Didimus
09.12.2022 09:08-1Была статья, что цифровые счётчики считают потребление приборов с импульсными бп в пользу сбытовой компании. Но теперь ее е могу найти, и даже ее следов. Так что дисковый счётчик это хорошо
jaha33
09.12.2022 10:15Это колхозная чушь. Дисковый "хорош" тем что он со временем начинает недоучитывать и собственно за свет надо меньше платить. У современных такой проблемы нет, поэтому и разные слухи начинают распускать.
Для неверующих всегда есть поверки и экспертизы.
Didimus
09.12.2022 10:48Вы не из чиновников, случаем? Счетчик поверен, значит врать не может (с)
jaha33
09.12.2022 11:27Вам никто не мешает в параллель поставить любое устройство измерения любого изготовителя из любой страны. Или в этом случае уже будет мировой заговор/рептилоидиы?
sim31r
09.12.2022 14:33Заговора действительно нет, тема подробно исследована.
Возможно есть обратная проблема, домашние аналитики измеряют ток на входе блока питания компьютера, там 1 ампер мультиметр показывает. Они умножают 1*220 и думают что комп потребляет 220Вт. Но потребление идет в пики сетевого напряжения, а это 311В и реальное потребление 311Вт. Дисковые счетчики могут не корректно отрабатывать импульсы тока, которыми потребляет импульсный блок питания, когда конденсатор после диодного моста заряжается за 1 мС по 100 раз в секунду, током в пике 10А.
dunkelfalke
08.12.2022 13:31+1Через это и в других странах проходят. Классический пример одного из наших клиентов - хотели поставить BLE-beacon-ы на огнетушитили, чтобы автоматически узнать, когда какой-нибудь из них использовали. Взяли трекер на LoRa, чтобы с симками не мучаться, который регулярно посылает BLE-адреса, которые видно поблизости. Но проблема в том, что огнетушителей десяток, в полезной нагрузке хватает места для может половины их них, да и по очереди их послать тоже особо не получается.
Interfer Автор
08.12.2022 12:30От себя скажу, что будущее вижу все же за NB-IoT. Беда в том, что в нашей стране это связано с неповоротливыми сотовиками. А сам стандарт весьма неплох и универсален.
Sensimilla
08.12.2022 15:41+2Проблема не с операторами, а с законами. Государство осознанно и целенаправленно усложнило до предела использование NB-IoT. Если в ЖКХ еще можно продавить эти вездесущие симки, то на предприятиях никто возиться с ними не будет. Будут строить Wi-Fi сети и правильно сделают. Не говоря уже о частных лицах.
Barnaby
08.12.2022 16:44Будущее за Matter :)
jaha33
09.12.2022 09:22Да что то он все никак не взлетит, Thread который для него базовый уже лет 7 существует, по сути столько же сколько и Lora и NB-IoT, а каких то заметный достижений про него не слышно. Уверен что там полно своих проблем и подводных камней.
Ну и чипы для Thread и Lora можно возить только по серым схемам. С лорой понятно что это американская, по для Thread в подавляющем числе чипы тоже американские. У китайцев он в ESP32 заявлен, но Espressif с РФ перестали работать. Нормально только NB-IoT можно возить
Vorchun
08.12.2022 14:29+2Про Лора и счетчики электроэнергии - очень метко. Аплодирую стоя. И да, мы тоже через это прошли.
Didimus
09.12.2022 09:10А чем плохо, если счётчик будет передавать данные по силовой линии?
Vorchun
09.12.2022 09:13А где я что-то сказал про силовую линию? ) Это тоже решение. Но мне интересна ваша реализация - по силовой - какой подбор оборудования?
Didimus
09.12.2022 09:37Были же проекты эзернет овер пауэр лайн? Даже адаптеры такие продавались для розетки
Interfer Автор
09.12.2022 09:45Тут сразу вопросы к высоковольтной линии. Если она у нас нормальная, то решение рабочее. Увы, часто линии ближе к конечным потребителям это мрак и скрутки. И вот по таким сетям пауэрлайны работают по схеме "повезет-не повезет".
Didimus
09.12.2022 10:03Если провод используется как волновод, то скрутки не должны быть непреодолимым препятствием
Vorchun
09.12.2022 10:53Одно дело - дома. Другое надо передать данные на сервер. Есть решения PLC, но я не знаю насколько они используются в жизни. Поэтому и спросил - знаете ли вы такое оборудование? Не в теории, а вот прям массово используемое.
Indemsys
08.12.2022 14:44+1Статье не хватает конкретики.
Какая реальная медианная дальность у LoRa получалась? С какими антеннами, с какой модуляцией, с какой полосой?Забавно что все тесты LoRa направлены на то чтобы показать на какое максимальное расстояние она работает. А реально интересно на каком минимальном расстоянии она уже не работает.
У меня получалось перестать принимать LoRa уже с 500 м в здании. (SX1261, 868 МГц, spreading factor - 7, bandwidth - 125 кГц, coding rate 4/5, +22 dBm на штыревую антенну )
По сути LoRa с полосой 250-125 кГц мало чем отличается от современного IEEE 802.15.4
Interfer Автор
08.12.2022 15:35+2Я довольно подробно останавливался на этом вопросе в своем цикле статей про Лору. Если грубо, то в городе на антенну Радиал 10 dBi уверенно получаем пару километров. Но это на SF12. Дальше магия. Где-то и на SF7 заведется, где-то на 5 км пробьет. Понятно, что магии никакой там нет и просто везде разные радиоусловия. Но просчитать их все не представляется возможным. Так что при проектировании исходим из радиуса в 2 км, а потом по факту корректируем. Но как показывает практика - коррекции минимальные.
Indemsys
08.12.2022 17:28+1Как показывает официальный документ от Semtech AN1200.22 при модуляции LoRa: 125 kHz BW, SF = 8 (3.125 kb/s) дистанция с потерями в 10% будет чуть больше 1.5 км в условиях современного города.
А у вас модуляция SF12. Это пару сотен байт в сек на всю! сеть. Т.е. это уже и сетью назвать трудно.
У меня подозрение, что таких же результатов можно добиться применяя простейшие радиомодули с более длинным кодом для Direct Sequence Spread Spectrum (DSSS)
Сейчас как раз микроконтроллеры появились способные длинные коды обрабатывать.Interfer Автор
09.12.2022 09:46У нас гибридная модуляция. Есть модули на SF12, но их не много. Это не ADR а своя довольно уникальная и оригинальная система оптимизации сети.
Stratum
08.12.2022 15:40+1Забавный факт: если датчики размещены в длинной девятиэтажке, то намного выгодней ноду LoRa ставить у подвального окна дома напротив. Дальность Lora на практике ограничивается только толщиной слоя препятствий. Также пытался работать с отраженным сигналом, но 433 МГц ни от домов, ни от верхних слоев атмосферы не удалось отразить.
sim31r
08.12.2022 16:48+1Дальность может быть и 0 метров, если кто-то займет частоту. Радиохулиган например может небольшим передатчиком положить каналы Lora на 5 км вокруг. Передавать самый короткий пакет поочередно по всем частотам и каналы окажутся заняты. Тут даже нарушения нет, нужно человеку передать личные архивы на 3 метра и он это делает. И удобней ему на крыше в этот момент стоять. Канал общий для всех, имеет право формально.
Indemsys
08.12.2022 17:08Очевидно дальности 0 быть не может. И что такое небольшой передатчик?
Если верить википедии, то портативные джаммеры могут глушить что-либо только на 15 мsim31r
09.12.2022 11:10У Lora есть свои уязвимости. Достаточно исказить 1 бит информации, контрольная сумма не сходится, процесс передачи повторяется заново. То есть нам не нужно постоянно передавать сигнал, достаточно кратковременной передачи. Передатчик слабый 10-100 мВт всего, если расположен в каком-то подвале, в эфир будет пробиваться может и менее 1 мВт, заглушить его очень просто, особенно если задаться целью. Перехватить запрос и выдать тот самый 1 бит в момент передачи ответного сигнала. И вмешиваться можно не с 15 метров, а с 5-10 километров. А может и далее с направленной антенной.
Indemsys
09.12.2022 12:00Да ваша мысль не нова. Перехватчики брелков так и работают.
Но если учесть повторные посылки , скачущие частоты, направленные антенны, избыточность кодирования, исправляющие коды, и прочие проблемы, то задача становится не такой простой.
Не глушат же друг друга Bluetooth, Wi-Fi, Zigbee, 6LoWPAN хотя все толкутся на одних и тех же частотах и работают совершенно хаотично и независимо друг от друга.Передатчик 10-100 мВт будет как капля в море. Его самого заглушат, так что он себя слышать не будет.
jaha33
09.12.2022 12:15Еще как глушат, но там скорости на порядки выше, поэтому там это не острая проблема. А когда у вас несколько десятков байт передаются 2-3 секунды, то вероятность с чем то зацепиться или словить помеху сильно выше
Indemsys
09.12.2022 12:23Я бы сказал пытаются глушить. Ну не реально простой безделушкой заглушить весь диапазон в районе 2.4 ГГц. Эт в радиусе пары метров только возможно. А то бы в зоне известно чего никакие беспилотники не летали бы.
И вы забываете, что глушить собираетесь сеть, а не дивайс. В какой момент работает именно дивайс, который хотите заглушить вы не знаете. Если только не находитесь от него в паре метров. Но это уже читинг.sim31r
09.12.2022 14:26глушить собираетесь сеть
Специфическую сеть со своими уязвимостями.
Если только не находитесь от него в паре метров.
Направленная антенна и даст имитацию расстояния в пару метров даже при работе с километра.Ждем когда передатчик у потребителя начнет работать и сразу включаем помеху на пару миллисекунд, искажая передаваемый бит.
Можно сразу и сеть положить, направленной антенной на базовую станцию Lora направить и сигнал забьет маломощные передатчики абонентских устройств.
Indemsys
09.12.2022 15:23Что-то много хлопот получается.
А начинали-то с простенького любительского джаммера.
В этом и есть фишка современных протоколов - обременить хакера слишком большими затратами.
Никто не стремится сделать полностью непрошибаемые решения.
daggert
08.12.2022 17:02habr.com/post/649163/#comment_24022643 — мой тест прошлого года, когда именно дальность тестировал и он меня радовал. В этом году обслуживал цеха… все грустно. 80м цех — не всегда проходит в зоне прямой видимости из-за машин различных. Пришлось ставить извращения различные.
SpiderEkb
08.12.2022 18:05+2Тут проблема не в RS-485 как таковом, а в том, что передают те же ТЭКОНы, КАРАТы, ТСТ и иже с ними. А передают они архивы. Часовые, суточные, месячные. Объемы там не бог весть какие, но сотни байт. А когда это идет по часа и пара десятков энергоконтроллеров разом начинает архивы сливать...
Кстати, мы эти данные снимали еще году этак в 97-м :-) Потом спрос на подключение энергоконтроллеров к системе ЛДСС упал - они идут сразу в комплекте с GSM модемом и данные сливаются по другим каналам.
А если еще лифтовые контроллеры. От простейших УБДЛ до навороченных импортных. Там тоже куча параметров, стек отказов и т.п.
Короче говоря, когда этим занимался, мы остановились на связке UDP + RS-485. Ставится IP шлюз (на участок - несколько расположенных рядом домов). У него два 485-х порта. К одному цепляется MOXA транслирующая пакеты в UDP и дальше уже на диспетчерскую, на второй - нужное количество УСО (устройство сопряжения с объектом) к которым уже подключаются конечные устройства.
На диспетчерской стоит некий сервер ("микроядро" в нашей терминологии) который с одной стороны работает с IP шлюзами по UDP, а с другой к нему по TCP подключаются интерфейсные клиенты (рабочее место диспетчера, интерфейсы аварийных бригад, еще что там потребуется). Все это шустро и стабильно работает (нормальная нагрузка на диспетчерскую - 300-500 лифтов плюс охрана служебных помещений и еще ряд устройств типа контроля систем дымоудаления и т.п., это где-то около 20-ти IP шлюзов по 10-30 УСО на каждом).
smart_alex
08.12.2022 19:29+6Особенность RS-485 в том, что там объёмы данных резко превышают то, на что рассчитана LoRaWAN. Там в обе стороны ходят разные пакеты, там в ответ на запрос может прилететь целый архив существенного веса.
Эээ... А что мешает взять только то, что нужно из архива и послать по LoRaWAN?
Точнее, попытка пропихнуть какой-то из протоколов RS-485 через Лору в режиме прозрачного канала.
Нафигазачем такие извращения?SpiderEkb
09.12.2022 18:41А что мешает взять только то, что нужно из архива и послать по LoRaWAN?
А теплоконтроллер так работает - вываливает весь архив целиком. Там ХВС, ГВС, Тепло, электричество. Архивы по потреблению, плюс еще мгновенные значения по запросу - давление в ХВС, температура и давление в ГВС, Температур на входи и выходе и давление в системе теплоснабжения, напряжения по каждой фазе по электричеству.
Но проблема еще в том, что "ЖКХ" это не только энергоконтроллеры, но еще много чего. Та же диспетчеризация (без которой дом не примут в эксплуатацию) - ЛДСС (Лифтовая Диспетчерская Связь и Сигнализация). А это данные с лифтового контроллера (там как минимум положение кабины лифта в шахте + состояние дверей шахты + голосовая связь с кабиной + кнопка вызова из кабины, опционально - датчик пола в кабине ну и собственно с контроллера куча данных - скорость движения кабины, температура двигателя и еще что-то).
Плюс всякие "допы" в виде охраны служебных помещений (машзал лифта, электрощитовая, подвал), видеонаблюдение, дублирование пожарной сигнализации с контролем срабатывание систем дымоудаления (клапаны, вытяжка), освещение подъездов...
Очень много всяких разнородных устройств. И с большинством придется работать "что застройщик поставил" - никто вам лифт менять не будет только потому что вы с ним работать не умеете. Просто найдут другую систему, которая умеет.
При этом УК, которая обслуживает дома, может держать одну диспетчерскую на все. А дома раскиданы по всему городу - два дома там, три дома тут + еще что-то в городах-спутниках. И в сумме там набирается одних лифтов несколько сотен. Не считая всего остального.
И сигналы должны моментально пролетать - застряла барышня в лифте, кнопку вызова нажала - у диспетчера сразу появляется сообщение. А дальше он уже подключает соотв. линию ГГС (в нашем варианте это VoIP до IP шлюза, дальше проводами уже) и успокаивается барышню что скоро принц на белом коне ее из заточения вызволит.
Мы, собственно, эту тему начали поднимать еще в 93-м. Тогда разрабатывали замену древним пультам ПД-32 (которые на лампочка-кнопочках). Тогда диспетчерские еще локальные были - обходились 485-ми каналами на все. Потом все это разрослось, да и инет стал доступен везде. Перешли на 485 на "кустах" (IP-шлюз + подключенные к нему УСО) и UDP от шлюза к диспетчерской.
smart_alex
09.12.2022 18:55LoRa — это, образно, труба определённого диаметра (в зависимости от настроек) — по этой трубе невозможно «пропустить» Ниагарский водопад данных. Поэтому просто принимаете кучу данных и пускаете по этой трубе только такой объём, какой она может пропустить.
Правда для этого программист должен написать логику моста между устройством и «базой», куда передаются данные (и обратно). По-другому — никак.
SpiderEkb
11.12.2022 10:12Я в курсе как оно работает.
Но дело тут вот в чем. На уровне канала УСО-конечное устройство ставить Лору будет крайне дорого т.к. устройств там слишком много (тысячи на одну диспетчерскую). И навешивать дополнительный девайс поверх обычного датчика типа "сухой контакт" это избыточно - проще напрямую подключить его к УСО проводом.
Вешать Лору на уровне УСО - IP-шлюз уже не получится - слишком большой трафик, ширины канала не хватит. Не говоря уже об уровне IP-шлюз - диспетчерская. Там еще и расстояния могут быть в десятки километров.
Так что в данном конкретном применении Лора не подходит, увы. Не потому что оно плохое, а потому что оно не для того.
Hlad
09.12.2022 09:32Проблема 485-го интерфейса (и не только 485-го, но и 232-го, например) в счётчиках - не в объемах данных, а в том, что он очень энергопрожорливый для батарейного питания. А если есть внешнее питание (как в тех же счётчиках) - все преимущества ЛоРы исчезают, т.к. есть более удобные интерфейсы связи.
tklim
09.12.2022 09:48+2Если взять почти любую статью про Лору - всегда идёт мешанина понятий. Что есть Lora и что такое LoraWAN. И то что описывается как "минусы" - это просто ограничения стандарта.
Также я вижу частичное непонимание технологии/стандарта:
"Опрашивать" устройства - некорректно. Условный счётчик должен сам раз в какой-то интервал слать данные. В ответ можно ему отправить какие-то настройки, но и то не обязательно.
Пытаться покинуть мост какого-то протокола поверх лораван - такой же костыль, как UART поверх BLE.
Про счётчики и разнообразие их протоколов - тут два варианта решения: либо писать обработчик под каждый либо просто при установке передатчика менять и счётчик на какую-то одну модель (лучше две, конечно, разных вендоров). Но это все ещё на этапе бизнес-плана нужно смотреть.
Interfer Автор
09.12.2022 09:52Я думаю, большинство авторов все же понимают отличие LoRa от LoRaWAN. Просто немного мешают слова, чтобы не повторять один и тот же термин.\
Формально соглашусь. Опять же это как посмотреть. Опрос приборов учета - устоявшийся термин. Имеется ввиду, собирать с них информацию. Техническая реализация уже несколько детали и тут каждый сам решает где внутренний инженер переходит во внутреннего душнилу)
Часто приходим на то, что есть. Но да, если бы все было продумано заранее, все было б клево. И нефиг много моделей счетчиков. Два завода на всю Россию и клепать стандартные решения. Но так это не работает)
Indemsys
09.12.2022 12:37Пытаться покинуть мост какого-то протокола поверх лораван - такой же костыль, как UART поверх BLE.
Однако такие костыли сейчас самый горячий тренд.
Возьмём протокол Thread. Он работает поверх 6LoWPAN, а тот поверх такого же медленного как LoRa протокола IEEE 802.15.4. Ну так это реализаций IPv6. А в пакетах IPv6 вы можете передавать пакеты TCP, а в пакетах TCP вы можете передавать пакеты TLS, а в пакетах TLS можете передавать пакеты MODBUS (те самые, которые по RS485 передаются) или снова уйти на пакеты GRE в VPN и продолжить цепочку вложенностей.
Кстати на BLE тоже есть маппинг TCP/IP. Это не костыль, а нормальный мапинг. Там все сжатия хидеров сделаны как надо. Сам TCP родился когда скорости были 2400 байт в сек. Там все очень оптимально с точки зрения инкапсуляции.
gridmal
09.12.2022 09:48+1LoRaWAN нормально работает в ЖКХ. Взрывного роста, как все ожидали в 2018-2019 годах, нет, но внедрения есть и их количество растет. В приборах КАРАТ есть все необходимые решения для работы в сетях LoRaWAN.
В основном по LoRaWAN собирают данные с водосчетчиков и квартирных теплосчетчиков. Архивы этих приборов укладываются в размер одного пакета. Базовую станцию лучше всего ставить не на самом объекте, а на соседнем или на столбе перед зданием. Основной момент при выборе места установки базовой станции - как можно меньшее количество перекрытий от базовой станции до прибора учета. При установке на крыше можно получить покрытие "вниз" от 2 до 7-9 этажей (зависит от материала объекта). В современных домах установка на крыше - самый плохой вариант.
С общедомовых приборов тоже можно собирать полные архивы. Тут от 1 до 2 пакетов на подсистему. Подсистема учета тепла - 2 пакета. ХВС - 1 пакет. ГВС - 1 или 2 пакета (зависит от количества учитываемых параметров). Но для общедомовых приборов учета все же лучше применять другие каналы связи.
Старые электросчетчики (не под 522 постановление) так же нормально работают по LoRaWAN.
А пытаться втиснуть в узкий канал LoRaWAN протокол Mod-Bus в прозрачном режиме - плохая затея. На столе с одним прибором работать будет. Сеть с десятками приборов уже нормально работать не будет.
Interfer Автор
09.12.2022 09:53Я не спорю, что внедрения есть. У нас это прекрасно работает. Но, как раз, в определенной нише. В 2018 все надеялись пихать ее в любой утюг)
Franzmul
09.12.2022 10:42"Простой пример. Нам требуется замер температуры в производственном помещении. Очевидно, что нам не нужно измерять её постоянно." почему очевидно? с точностью до наоборот. wifi датчики мало того что позволяют передавать любые обьемы данных в режиме реального времени, с задержкой несколько ms, так еще и обратная связь присутствует, и возможность удаленной настройки.
blind_oracle
09.12.2022 12:04+1FPVшники летают на LoRA на 100+ километров без особых проблем, а там поток данных довольно большой.
В зданиях с железобетоном всё, кончено, несколько сложнее...
alk120
09.12.2022 12:13Если с самого начала разобраться в технологии - не нужно проходить весь этот путь.
Самое красивое решение когда
Прошивка под конкретный прибор учета и передача минимума - например текущее показание электросчетчика. И не пытать протащить ВСЁ (Тарифные расписания, профили мощностей и тд).
Даже не пытаться накатить опрос с сервера
Забыть про прозрачный радиоканал
Соблюдать все правила по монтажу
Если нужна история - запрашивайте с сервера lorawan, а не пытайтесь выгружать с устройства
-
Про реалтайм забудьте - опрашивайте самое частое раз в сутки.
И тогда решение на лоре будет идеальным. Все будет работать как швейцарские часы!
Поставили БС, раскидали на лоре водосчетчики, электросчетчики, теплосчетчики, датчики протечки по подвалам и тд. (С учетом как написал выше!!!) И все будет работать замечательно! Вы будете иметь все показания. Историю и анализ сделаете уже на своем сервере, а не на устройстве.
renat85
Как мне кажется, именно по этому "Я точно знаю, что RS-485 на заводах есть. И искренне надеюсь, что заводским связистам не придёт в голову «светлая» мысль: «Та-а-ак, сеть мы построили, опрос работает, а давайте попробуем опросить через LoRaWAN вон тот увесистый датчик с кучей метрик…». " заводы и строят сеть на базе WiFi, а не на лоре. Вложившись один раз в инфраструктуру ты получаешь в разы лучшее и производительное решение которое потянет все хотелки. А строить одну сеть под микродатчики, потом строить еще одну сеть под под задачи которые лора не вытягивает так себе решение. Больше похоже на распил бюджета.
Interfer Автор
Я думаю тут все же от задачи зависит. Если куча датчиков раскиданы территориально, да еще в местах с негарантированным питанием (есть и такие, даже на заводах), стоит присмотреться к чему-то типа Лоры)
MegaZel
Так на датчики, в 99%, тоже питание требуется. Дальний радиоканал конечно хорошо, но именно чтобы информационный кабель не тащить.
Interfer Автор
Плюс Лоры, что многие датчики с ней могут работать от батарейки. Не все, но много. Ту же температуру померить - много электричества не надо. А вот модуль, скажем, GSM резко увеличит размер батареи.
sim31r
GSM модуль при включении 1 раз в час или реже, тоже много энергии не потребит. Но больше чем Lora конечно. И в режиме ожидания много потребляет, если нужен такой режим.
SukhovPro
На нашей практике это как правило сухие контакты, датчики температуры, уровнемеры и т.п. они питаются от того же источника, все в одном.
SukhovPro
Так и есть, есть территория завода. Но всегда есть что-то вокруг и достаточно далеко, но оптимально для лоры. Водозаборные узлы, водосбросные узлы, удаленные ТП откуда нужно все пара параметров раз в пару часов и реже и до лоры это были страдания. Одна организация питания могла сводить на нет всю затею.