Comments 98
Как мне кажется, именно по этому "Я точно знаю, что RS-485 на заводах есть. И искренне надеюсь, что заводским связистам не придёт в голову «светлая» мысль: «Та-а-ак, сеть мы построили, опрос работает, а давайте попробуем опросить через LoRaWAN вон тот увесистый датчик с кучей метрик…». " заводы и строят сеть на базе WiFi, а не на лоре. Вложившись один раз в инфраструктуру ты получаешь в разы лучшее и производительное решение которое потянет все хотелки. А строить одну сеть под микродатчики, потом строить еще одну сеть под под задачи которые лора не вытягивает так себе решение. Больше похоже на распил бюджета.
Я думаю тут все же от задачи зависит. Если куча датчиков раскиданы территориально, да еще в местах с негарантированным питанием (есть и такие, даже на заводах), стоит присмотреться к чему-то типа Лоры)
Так на датчики, в 99%, тоже питание требуется. Дальний радиоканал конечно хорошо, но именно чтобы информационный кабель не тащить.
Плюс Лоры, что многие датчики с ней могут работать от батарейки. Не все, но много. Ту же температуру померить - много электричества не надо. А вот модуль, скажем, GSM резко увеличит размер батареи.
На нашей практике это как правило сухие контакты, датчики температуры, уровнемеры и т.п. они питаются от того же источника, все в одном.
Так и есть, есть территория завода. Но всегда есть что-то вокруг и достаточно далеко, но оптимально для лоры. Водозаборные узлы, водосбросные узлы, удаленные ТП откуда нужно все пара параметров раз в пару часов и реже и до лоры это были страдания. Одна организация питания могла сводить на нет всю затею.
Непонятно - как в итоге коммунальщики решили проблему с перегрузкой сети LoRa?
Можно ли перенести общение со счетчиком по его сложному протоколу на сторону микроконтроллера, а по LoRa изредка передавать только одно/два значения - показания самого счетчика?
Тут, конечно, возникает проблема - прошивка становится заточенной строго под определенные марки счетчиков, но это лучше, чем бросать готовую систему.
Да, можно и такие системы делают. Но это боль. У вас получается зоопарк прошивок, которые нужно создавать и поддерживать. При этом. объем данных, которые генерит тот же теплосчетчик довольно существенный, если мы качаем, скажем, месячный архив. Даже в ужатом виде пропихивание - это боль.
Коммунальщики по итогу применяют гибридную систему. Теплосчетчик лучше подключить проводом и воткнуть в подъездный коммутатор. А вот какой-нибудь водосчетчик из темноты подвала можно и Лорой. Там импульсный выход, нет питания и тянуть туда провод нецелесообразно.
Я конечно с бытового уровня смотрю, но судя по тому что в современных счётчиках чаще всего находится симка, видимо ЖКХ пошло по пути NB-IoT или чего-то подобного.
Не знаю почему, но большая часть историй, которые я слышал, даже здесь не спотыкалась. Экспериментаторы брали в качестве теста электросчетчик «Меркурий-230». Особенность протокола «Меркурия» в том, что он весьма немногословен и один из немногих реально работает через Лору через прозрачный канал.
Итак, ура! Мы попробовали, и у нас получилось. LoRaWAN может и RS-485! Вот здорово!
Это «здорово» длится до первой «Энергомеры» с её тяжеловесным протоколом. Вот там энтузиазм начинает спадать. Дальше идут «Караты», «Взлёты» и прочие обитатели подвалов наших многоэтажек. И выясняется, что Лора их не тянет вообще.
классический импортозамес, гораздо правильнее было не только внедрять лору в счётчики но и сами счётчики делать под использование лоры, двустороннее движение хотя и сложнее (и дороже) но с куда большим шансом привело бы к успеху.
мне кажется если сделать счётчик с некоторы унимерсальным интерфейсом на который можно повешать любой из возможных обработчиков lora/zigbee/ble/gsm/wifi/etc который не просто будет передавать собранное с интерфейса счётчика а обрабатывать в неободимый удобоваримый для протокола вид и отдавать только полезные данные это будет устройство которое быстро окупится и будет желанно многим (как минимум потому что кроме передачи показаний для ЖКХ служб можно будет и для себя их собирать через homeassistant/zabbix/etc)
Ну вот сейчас все к тому и идет. Но рынок ЖКХ не самый поворотливый. И зоопарк из протоколов там пошел традиционно. Сейчас в рамках 522-фз худо-бедно стандартизировали электричество и то вопросов там больше, чем ответов. Внедрение ФЗ проходит на редкость тяжко.
В Москве целый дом перевели на водосчетчики с проводом и Коробочкой. В коробочке батарейка литиевая размера 373 и плата. Видимо, это и была лора. Говорят, обещали жильцам, что не надо будет показания передавать и все согласились. Не знаю, передали ли ли они реально показания, но проект не взлетел, счётчики заменили на обычные по износу
Тяжело, потому что нет заинтересованной стороны. Проблема как ни странно в слишком дешёвых ресурсах )) . Считайте: счетчик, установка, регулярная замена / поверка, создание инфраструктуры и ее обслуживание.
С другой стороны - каждый может платить за ресурс по нормативу.
На примере холодной воды ~ 2000 руб. В ГОД!
Со счетчиком возможно чуть меньше. А возможно и наоборот, больше - если любишь под душем постоять. Где финансовый смысл установки счетчика, даже обычного?
Подозреваю, что в ЖКХ счетчики уже давно установлены, и менять их, чтобы добавить LoRa, коммунальщики не захотят.
Плюс, в некоторых случаях, к примеру, если счетчики стоят в подвале, удобней все счетчики подключить проводами к одному устройству, от которого один антенный провод пойдет на улицу.
Есть парочка "но":
1) лично я (и мне кажется я далеко не один такой) с удовольствием поменял бы счётчик на другой с zigbee независимо от того что об этом думает жкх
2) про счётчики в подвале я конечно слышал, но в живую не встречал (подозреваю что такое есть только в паре городов россии вроде москвы, но как известно "москва не россия"), но вот лично на моём примере проблемой будут счётчики электричества распологающиеся в общем коридоре, расстояние до них такое что zigbee просто не дотянется
3) вы забываете про ижс где возможностей, а главное желания, "апгрейда" сильно больше
У счётчиков есть межповерочный интервал, 5-16лет, и часто стоимость поверки больше стоимости нового счётчика, поэтому в теории обновление счётчиков должно быть регулярным. На практике правда счётчики электроэнергии много где ещё дисковые...
99% счетчиков все таки обновляются. Дисковые я вижу в базе данных своей по абонентам, но это единичные какие-то случаи.
Была статья, что цифровые счётчики считают потребление приборов с импульсными бп в пользу сбытовой компании. Но теперь ее е могу найти, и даже ее следов. Так что дисковый счётчик это хорошо
Это колхозная чушь. Дисковый "хорош" тем что он со временем начинает недоучитывать и собственно за свет надо меньше платить. У современных такой проблемы нет, поэтому и разные слухи начинают распускать.
Для неверующих всегда есть поверки и экспертизы.
Вы не из чиновников, случаем? Счетчик поверен, значит врать не может (с)
Вам никто не мешает в параллель поставить любое устройство измерения любого изготовителя из любой страны. Или в этом случае уже будет мировой заговор/рептилоидиы?
Заговора действительно нет, тема подробно исследована.
Возможно есть обратная проблема, домашние аналитики измеряют ток на входе блока питания компьютера, там 1 ампер мультиметр показывает. Они умножают 1*220 и думают что комп потребляет 220Вт. Но потребление идет в пики сетевого напряжения, а это 311В и реальное потребление 311Вт. Дисковые счетчики могут не корректно отрабатывать импульсы тока, которыми потребляет импульсный блок питания, когда конденсатор после диодного моста заряжается за 1 мС по 100 раз в секунду, током в пике 10А.
Все ведут себя по разному, исследование
Через это и в других странах проходят. Классический пример одного из наших клиентов - хотели поставить BLE-beacon-ы на огнетушитили, чтобы автоматически узнать, когда какой-нибудь из них использовали. Взяли трекер на LoRa, чтобы с симками не мучаться, который регулярно посылает BLE-адреса, которые видно поблизости. Но проблема в том, что огнетушителей десяток, в полезной нагрузке хватает места для может половины их них, да и по очереди их послать тоже особо не получается.
мне кажется если сделать счётчик с некоторы унимерсальным интерфейсом на
который можно повешать любой из возможных обработчиков
lora/zigbee/ble/gsm/wifi/etc
Привет, коллега. Перед тем как поработать недолго буквально напротив вас, работал на заводе в том же городе, там так и поступили - производят счетчики с ИК-портом, на который уже навешиваются адаптеры - GSM, USB, RS-485. LoRa и другие протоколы насколько мне известно, тоже в разработке. Пока что производство небольшое, производят нишевые продукты и на Российском рынке их найти тяжело, но работа идет, возможно скоро появятся. Если вы про то чтобы стандартизировать сам протокол счетчик<->адаптер и выбраться из проприетарной ямы, я лично не вижу этого в сколь либо обозримом будущем, могу если интересно в личку расписать причины.
От себя скажу, что будущее вижу все же за NB-IoT. Беда в том, что в нашей стране это связано с неповоротливыми сотовиками. А сам стандарт весьма неплох и универсален.
Проблема не с операторами, а с законами. Государство осознанно и целенаправленно усложнило до предела использование NB-IoT. Если в ЖКХ еще можно продавить эти вездесущие симки, то на предприятиях никто возиться с ними не будет. Будут строить Wi-Fi сети и правильно сделают. Не говоря уже о частных лицах.
У сотовиков ограничен диапазон номеров и количество активных устройств. Если стандарт подразумевает изменение формата GSM связи, тогда нормально.
Будущее за Matter :)
Да что то он все никак не взлетит, Thread который для него базовый уже лет 7 существует, по сути столько же сколько и Lora и NB-IoT, а каких то заметный достижений про него не слышно. Уверен что там полно своих проблем и подводных камней.
Ну и чипы для Thread и Lora можно возить только по серым схемам. С лорой понятно что это американская, по для Thread в подавляющем числе чипы тоже американские. У китайцев он в ESP32 заявлен, но Espressif с РФ перестали работать. Нормально только NB-IoT можно возить
Про Лора и счетчики электроэнергии - очень метко. Аплодирую стоя. И да, мы тоже через это прошли.
А чем плохо, если счётчик будет передавать данные по силовой линии?
А где я что-то сказал про силовую линию? ) Это тоже решение. Но мне интересна ваша реализация - по силовой - какой подбор оборудования?
Были же проекты эзернет овер пауэр лайн? Даже адаптеры такие продавались для розетки
Тут сразу вопросы к высоковольтной линии. Если она у нас нормальная, то решение рабочее. Увы, часто линии ближе к конечным потребителям это мрак и скрутки. И вот по таким сетям пауэрлайны работают по схеме "повезет-не повезет".
Одно дело - дома. Другое надо передать данные на сервер. Есть решения PLC, но я не знаю насколько они используются в жизни. Поэтому и спросил - знаете ли вы такое оборудование? Не в теории, а вот прям массово используемое.
Статье не хватает конкретики.
Какая реальная медианная дальность у LoRa получалась? С какими антеннами, с какой модуляцией, с какой полосой?
Забавно что все тесты LoRa направлены на то чтобы показать на какое максимальное расстояние она работает. А реально интересно на каком минимальном расстоянии она уже не работает.
У меня получалось перестать принимать LoRa уже с 500 м в здании. (SX1261, 868 МГц, spreading factor - 7, bandwidth - 125 кГц, coding rate 4/5, +22 dBm на штыревую антенну )
По сути LoRa с полосой 250-125 кГц мало чем отличается от современного IEEE 802.15.4
Я довольно подробно останавливался на этом вопросе в своем цикле статей про Лору. Если грубо, то в городе на антенну Радиал 10 dBi уверенно получаем пару километров. Но это на SF12. Дальше магия. Где-то и на SF7 заведется, где-то на 5 км пробьет. Понятно, что магии никакой там нет и просто везде разные радиоусловия. Но просчитать их все не представляется возможным. Так что при проектировании исходим из радиуса в 2 км, а потом по факту корректируем. Но как показывает практика - коррекции минимальные.
Как показывает официальный документ от Semtech AN1200.22 при модуляции LoRa: 125 kHz BW, SF = 8 (3.125 kb/s) дистанция с потерями в 10% будет чуть больше 1.5 км в условиях современного города.
А у вас модуляция SF12. Это пару сотен байт в сек на всю! сеть. Т.е. это уже и сетью назвать трудно.
У меня подозрение, что таких же результатов можно добиться применяя простейшие радиомодули с более длинным кодом для Direct Sequence Spread Spectrum (DSSS)
Сейчас как раз микроконтроллеры появились способные длинные коды обрабатывать.
Забавный факт: если датчики размещены в длинной девятиэтажке, то намного выгодней ноду LoRa ставить у подвального окна дома напротив. Дальность Lora на практике ограничивается только толщиной слоя препятствий. Также пытался работать с отраженным сигналом, но 433 МГц ни от домов, ни от верхних слоев атмосферы не удалось отразить.
Дальность может быть и 0 метров, если кто-то займет частоту. Радиохулиган например может небольшим передатчиком положить каналы Lora на 5 км вокруг. Передавать самый короткий пакет поочередно по всем частотам и каналы окажутся заняты. Тут даже нарушения нет, нужно человеку передать личные архивы на 3 метра и он это делает. И удобней ему на крыше в этот момент стоять. Канал общий для всех, имеет право формально.
Очевидно дальности 0 быть не может. И что такое небольшой передатчик?
Если верить википедии, то портативные джаммеры могут глушить что-либо только на 15 м
У Lora есть свои уязвимости. Достаточно исказить 1 бит информации, контрольная сумма не сходится, процесс передачи повторяется заново. То есть нам не нужно постоянно передавать сигнал, достаточно кратковременной передачи. Передатчик слабый 10-100 мВт всего, если расположен в каком-то подвале, в эфир будет пробиваться может и менее 1 мВт, заглушить его очень просто, особенно если задаться целью. Перехватить запрос и выдать тот самый 1 бит в момент передачи ответного сигнала. И вмешиваться можно не с 15 метров, а с 5-10 километров. А может и далее с направленной антенной.
Да ваша мысль не нова. Перехватчики брелков так и работают.
Но если учесть повторные посылки , скачущие частоты, направленные антенны, избыточность кодирования, исправляющие коды, и прочие проблемы, то задача становится не такой простой.
Не глушат же друг друга Bluetooth, Wi-Fi, Zigbee, 6LoWPAN хотя все толкутся на одних и тех же частотах и работают совершенно хаотично и независимо друг от друга.
Передатчик 10-100 мВт будет как капля в море. Его самого заглушат, так что он себя слышать не будет.
Еще как глушат, но там скорости на порядки выше, поэтому там это не острая проблема. А когда у вас несколько десятков байт передаются 2-3 секунды, то вероятность с чем то зацепиться или словить помеху сильно выше
Я бы сказал пытаются глушить. Ну не реально простой безделушкой заглушить весь диапазон в районе 2.4 ГГц. Эт в радиусе пары метров только возможно. А то бы в зоне известно чего никакие беспилотники не летали бы.
И вы забываете, что глушить собираетесь сеть, а не дивайс. В какой момент работает именно дивайс, который хотите заглушить вы не знаете. Если только не находитесь от него в паре метров. Но это уже читинг.
глушить собираетесь сеть
Специфическую сеть со своими уязвимостями.
Если только не находитесь от него в паре метров.
Направленная антенна и даст имитацию расстояния в пару метров даже при работе с километра.Ждем когда передатчик у потребителя начнет работать и сразу включаем помеху на пару миллисекунд, искажая передаваемый бит.
Можно сразу и сеть положить, направленной антенной на базовую станцию Lora направить и сигнал забьет маломощные передатчики абонентских устройств.
Тут проблема не в RS-485 как таковом, а в том, что передают те же ТЭКОНы, КАРАТы, ТСТ и иже с ними. А передают они архивы. Часовые, суточные, месячные. Объемы там не бог весть какие, но сотни байт. А когда это идет по часа и пара десятков энергоконтроллеров разом начинает архивы сливать...
Кстати, мы эти данные снимали еще году этак в 97-м :-) Потом спрос на подключение энергоконтроллеров к системе ЛДСС упал - они идут сразу в комплекте с GSM модемом и данные сливаются по другим каналам.
А если еще лифтовые контроллеры. От простейших УБДЛ до навороченных импортных. Там тоже куча параметров, стек отказов и т.п.
Короче говоря, когда этим занимался, мы остановились на связке UDP + RS-485. Ставится IP шлюз (на участок - несколько расположенных рядом домов). У него два 485-х порта. К одному цепляется MOXA транслирующая пакеты в UDP и дальше уже на диспетчерскую, на второй - нужное количество УСО (устройство сопряжения с объектом) к которым уже подключаются конечные устройства.
На диспетчерской стоит некий сервер ("микроядро" в нашей терминологии) который с одной стороны работает с IP шлюзами по UDP, а с другой к нему по TCP подключаются интерфейсные клиенты (рабочее место диспетчера, интерфейсы аварийных бригад, еще что там потребуется). Все это шустро и стабильно работает (нормальная нагрузка на диспетчерскую - 300-500 лифтов плюс охрана служебных помещений и еще ряд устройств типа контроля систем дымоудаления и т.п., это где-то около 20-ти IP шлюзов по 10-30 УСО на каждом).
Особенность RS-485 в том, что там объёмы данных резко превышают то, на что рассчитана LoRaWAN. Там в обе стороны ходят разные пакеты, там в ответ на запрос может прилететь целый архив существенного веса.
Эээ... А что мешает взять только то, что нужно из архива и послать по LoRaWAN?
Точнее, попытка пропихнуть какой-то из протоколов RS-485 через Лору в режиме прозрачного канала.
Нафига зачем такие извращения?
А что мешает взять только то, что нужно из архива и послать по LoRaWAN?
А теплоконтроллер так работает - вываливает весь архив целиком. Там ХВС, ГВС, Тепло, электричество. Архивы по потреблению, плюс еще мгновенные значения по запросу - давление в ХВС, температура и давление в ГВС, Температур на входи и выходе и давление в системе теплоснабжения, напряжения по каждой фазе по электричеству.
Но проблема еще в том, что "ЖКХ" это не только энергоконтроллеры, но еще много чего. Та же диспетчеризация (без которой дом не примут в эксплуатацию) - ЛДСС (Лифтовая Диспетчерская Связь и Сигнализация). А это данные с лифтового контроллера (там как минимум положение кабины лифта в шахте + состояние дверей шахты + голосовая связь с кабиной + кнопка вызова из кабины, опционально - датчик пола в кабине ну и собственно с контроллера куча данных - скорость движения кабины, температура двигателя и еще что-то).
Плюс всякие "допы" в виде охраны служебных помещений (машзал лифта, электрощитовая, подвал), видеонаблюдение, дублирование пожарной сигнализации с контролем срабатывание систем дымоудаления (клапаны, вытяжка), освещение подъездов...
Очень много всяких разнородных устройств. И с большинством придется работать "что застройщик поставил" - никто вам лифт менять не будет только потому что вы с ним работать не умеете. Просто найдут другую систему, которая умеет.
При этом УК, которая обслуживает дома, может держать одну диспетчерскую на все. А дома раскиданы по всему городу - два дома там, три дома тут + еще что-то в городах-спутниках. И в сумме там набирается одних лифтов несколько сотен. Не считая всего остального.
И сигналы должны моментально пролетать - застряла барышня в лифте, кнопку вызова нажала - у диспетчера сразу появляется сообщение. А дальше он уже подключает соотв. линию ГГС (в нашем варианте это VoIP до IP шлюза, дальше проводами уже) и успокаивается барышню что скоро принц на белом коне ее из заточения вызволит.
Мы, собственно, эту тему начали поднимать еще в 93-м. Тогда разрабатывали замену древним пультам ПД-32 (которые на лампочка-кнопочках). Тогда диспетчерские еще локальные были - обходились 485-ми каналами на все. Потом все это разрослось, да и инет стал доступен везде. Перешли на 485 на "кустах" (IP-шлюз + подключенные к нему УСО) и UDP от шлюза к диспетчерской.
LoRa — это, образно, труба определённого диаметра (в зависимости от настроек) — по этой трубе невозможно «пропустить» Ниагарский водопад данных. Поэтому просто принимаете кучу данных и пускаете по этой трубе только такой объём, какой она может пропустить.
Правда для этого программист должен написать логику моста между устройством и «базой», куда передаются данные (и обратно). По-другому — никак.
Я в курсе как оно работает.
Но дело тут вот в чем. На уровне канала УСО-конечное устройство ставить Лору будет крайне дорого т.к. устройств там слишком много (тысячи на одну диспетчерскую). И навешивать дополнительный девайс поверх обычного датчика типа "сухой контакт" это избыточно - проще напрямую подключить его к УСО проводом.
Вешать Лору на уровне УСО - IP-шлюз уже не получится - слишком большой трафик, ширины канала не хватит. Не говоря уже об уровне IP-шлюз - диспетчерская. Там еще и расстояния могут быть в десятки километров.
Так что в данном конкретном применении Лора не подходит, увы. Не потому что оно плохое, а потому что оно не для того.
Проблема 485-го интерфейса (и не только 485-го, но и 232-го, например) в счётчиках - не в объемах данных, а в том, что он очень энергопрожорливый для батарейного питания. А если есть внешнее питание (как в тех же счётчиках) - все преимущества ЛоРы исчезают, т.к. есть более удобные интерфейсы связи.
Если взять почти любую статью про Лору - всегда идёт мешанина понятий. Что есть Lora и что такое LoraWAN. И то что описывается как "минусы" - это просто ограничения стандарта.
Также я вижу частичное непонимание технологии/стандарта:
"Опрашивать" устройства - некорректно. Условный счётчик должен сам раз в какой-то интервал слать данные. В ответ можно ему отправить какие-то настройки, но и то не обязательно.
Пытаться покинуть мост какого-то протокола поверх лораван - такой же костыль, как UART поверх BLE.
Про счётчики и разнообразие их протоколов - тут два варианта решения: либо писать обработчик под каждый либо просто при установке передатчика менять и счётчик на какую-то одну модель (лучше две, конечно, разных вендоров). Но это все ещё на этапе бизнес-плана нужно смотреть.
Я думаю, большинство авторов все же понимают отличие LoRa от LoRaWAN. Просто немного мешают слова, чтобы не повторять один и тот же термин.\
Формально соглашусь. Опять же это как посмотреть. Опрос приборов учета - устоявшийся термин. Имеется ввиду, собирать с них информацию. Техническая реализация уже несколько детали и тут каждый сам решает где внутренний инженер переходит во внутреннего душнилу)
Часто приходим на то, что есть. Но да, если бы все было продумано заранее, все было б клево. И нефиг много моделей счетчиков. Два завода на всю Россию и клепать стандартные решения. Но так это не работает)
Пытаться покинуть мост какого-то протокола поверх лораван - такой же костыль, как UART поверх BLE.
Однако такие костыли сейчас самый горячий тренд.
Возьмём протокол Thread. Он работает поверх 6LoWPAN, а тот поверх такого же медленного как LoRa протокола IEEE 802.15.4. Ну так это реализаций IPv6. А в пакетах IPv6 вы можете передавать пакеты TCP, а в пакетах TCP вы можете передавать пакеты TLS, а в пакетах TLS можете передавать пакеты MODBUS (те самые, которые по RS485 передаются) или снова уйти на пакеты GRE в VPN и продолжить цепочку вложенностей.
Кстати на BLE тоже есть маппинг TCP/IP. Это не костыль, а нормальный мапинг. Там все сжатия хидеров сделаны как надо. Сам TCP родился когда скорости были 2400 байт в сек. Там все очень оптимально с точки зрения инкапсуляции.
Не, ну вообще всё несколько не так, 802.15.4 даст аж 250 кбит/с, сказка по сравнению с LoraWan, и см. соседний коммент с размерами пакетов - в предельном случае, из 41 байта вычтем 20 на заголовок TCP, остается слишком мало для дальнейших вложенностей. То, что TCP родился, когда скорости были низкие, не значит, что MTU были низкие - даже в 1969 было доступно около 8000 бит.
Правда, 6LoWPAN определяет layer для фрагментации пакетов, так что в теории можно хоть полные 1280 байт передавать - но на практике это сильно увеличит потери пакетов.
LoRaWAN нормально работает в ЖКХ. Взрывного роста, как все ожидали в 2018-2019 годах, нет, но внедрения есть и их количество растет. В приборах КАРАТ есть все необходимые решения для работы в сетях LoRaWAN.
В основном по LoRaWAN собирают данные с водосчетчиков и квартирных теплосчетчиков. Архивы этих приборов укладываются в размер одного пакета. Базовую станцию лучше всего ставить не на самом объекте, а на соседнем или на столбе перед зданием. Основной момент при выборе места установки базовой станции - как можно меньшее количество перекрытий от базовой станции до прибора учета. При установке на крыше можно получить покрытие "вниз" от 2 до 7-9 этажей (зависит от материала объекта). В современных домах установка на крыше - самый плохой вариант.
С общедомовых приборов тоже можно собирать полные архивы. Тут от 1 до 2 пакетов на подсистему. Подсистема учета тепла - 2 пакета. ХВС - 1 пакет. ГВС - 1 или 2 пакета (зависит от количества учитываемых параметров). Но для общедомовых приборов учета все же лучше применять другие каналы связи.
Старые электросчетчики (не под 522 постановление) так же нормально работают по LoRaWAN.
А пытаться втиснуть в узкий канал LoRaWAN протокол Mod-Bus в прозрачном режиме - плохая затея. На столе с одним прибором работать будет. Сеть с десятками приборов уже нормально работать не будет.
"Простой пример. Нам требуется замер температуры в производственном помещении. Очевидно, что нам не нужно измерять её постоянно." почему очевидно? с точностью до наоборот. wifi датчики мало того что позволяют передавать любые обьемы данных в режиме реального времени, с задержкой несколько ms, так еще и обратная связь присутствует, и возможность удаленной настройки.
FPVшники летают на LoRA на 100+ километров без особых проблем, а там поток данных довольно большой.
В зданиях с железобетоном всё, кончено, несколько сложнее...
Если с самого начала разобраться в технологии - не нужно проходить весь этот путь.
Самое красивое решение когда
Прошивка под конкретный прибор учета и передача минимума - например текущее показание электросчетчика. И не пытать протащить ВСЁ (Тарифные расписания, профили мощностей и тд).
Даже не пытаться накатить опрос с сервера
Забыть про прозрачный радиоканал
Соблюдать все правила по монтажу
Если нужна история - запрашивайте с сервера lorawan, а не пытайтесь выгружать с устройства
Про реалтайм забудьте - опрашивайте самое частое раз в сутки.
И тогда решение на лоре будет идеальным. Все будет работать как швейцарские часы!
Поставили БС, раскидали на лоре водосчетчики, электросчетчики, теплосчетчики, датчики протечки по подвалам и тд. (С учетом как написал выше!!!) И все будет работать замечательно! Вы будете иметь все показания. Историю и анализ сделаете уже на своем сервере, а не на устройстве.
Со временем эти датчики росли, менялись, становились всё современнее. «Сименс» и «Эмерсон» приучили нас, что датчик может работать и без проводов, и в целом ряде случаев такое оправданно. Конечно, в случае этих гигантов речь шла об их собственных проприетарных протоколах, но сути это не меняет.
Фигню однако несете. Датчики без проводов у Siemens и Emerson - это датчики с поддержкой WirelessHART, который ну вот совсем не проприетарный.
Напишите пожалуйста, как это вы "опрашиваете счётчик электричества по импульсному выходу" ?
В подробностях, если можно ))
Подключаем СИ-11 к импульсному выходу счетчика, забиваем в ПО вес импульса и опрашиваем) Раз в сутки, если память не изменяет. Там главное полярность не перепутать, для счетчика ЭЭ это важно.
Ага, то есть вы опрашиваете всё же не электросчетчик, а регистратор импульсов. Понятно, спасибо ))
Раз вы работаете с этим изделием, то может подскажете - способно ли оно работать безо всякой LoraWan, а просто с Лорой? Скажем, в одноранговой сети?
Импульсный выход подразумевает наличие какого-то регистратора импульсов. Есть счетчики со встроенным Лора-модулем, но использовать для передачи данных импульсный выход на внутренний передатчик - это реально извращение) Конечно, там взаимодействие ведется по более высокоуровневым протоколам.
Импульсный выход - это либо от бедности (дешево и сердито, можно поставить в самые бюджетные модели) либо от невозможности подвести питание (водосчетчик в подвале. Импульсный выход можно реализовать механически без всяких батареек и 220).
Не совсем понял ваш вопрос про "просто Лора". Лора - это физический уровень передачи данных, модуляция и ее принципы. Примерно как медный кабель и спецификация передачи сигналов по нему. Что вы будете по ним передавать - это уже следующий уровень, канальный. Там может быть LoRaWAN, может какая-нибудь проприетарщина. Но там что-то должно быть) Вы же не можете передать сигнал ПРОСТО по медному кабелю. Вам все равно нужен какой-то протокол, хотя бы морзянка)
Под "просто Лорой" я имею в виду примерно такой девайс: https://aliexpress.ru/item/1005003280185425.html
Или такой: https://aliexpress.ru/item/1005002876816168.html
То есть - никакой "ванны" поверх. Она мне не нужна.
А протокол, естественно, будет свой. Ну или тот, который предлагается вот этим СИ-11. Он же там есть какой-то? (Можно где-то почитать?)
И да, электросчётчиков только с импульсным выходом - вокруг меня большинство. И менять их на другие, ради того, "чтобы этим электрикам не бегать" - никто не будет ))) Поэтому ищу разные варианты. Увидел ваш - потому и спрашиваю...
Глянул варианты ваших девайсов. Там у них либо LoRaWAN, либо проприетарщина, одно из двух)
В СИ-11 используется классическая LoRaWAN.
Я не очень понимаю ваш комментарий про "ванну поверх". Есть ощущение, что мы не сходимся в терминологии. LoRaWAN - это просто протокол канального уровня, один из. Вы сами пишите, что протокол нужен. Чем вам LoRaWAN не вариант?
Электросчетчики сейчас будут массово менять в рамках 522-ФЗ. Процесс уже запущен. Можете подробнее прочитать про этот закон в моих статьях)
Да понятно почему он разочарует кого угодно. Вот я неспешно проектирую свой протокол. Для 802.15.4, у которого MTU 128 байт, на 6LoWPAN при ухищрениях остается 60-80 байт, а в худшем случае - 33 байта UDP payload. С этим прекрасно можно жить. А дальше я полез в RFC 8376 почитать про новейшие веянияе, и вот лора:
Note that, in the case of the smallest frame size (19 octets), 8
octets are required for LoRa MAC layer headers, leaving only 11
octets for payload (including MAC layer options). However, those
settings do not apply for the join procedure -- end devices are
required to use a channel and data rate that can send the 23-byte
Join-Request message for the join procedure.
...
The long-term AppKey is directly used to protect the Join-Accept
message content, but the function used is not an AES-encrypt
operation, but rather an AES-decrypt operation. The justification is
that this means that the end device only needs to implement the AES-
encrypt operation. (The counter-mode variant used for payload
decryption means the end device doesn't need an AES-decrypt
primitive.)
The Join-Accept plaintext is always less than 16 bytes long, so
Electronic Code Book (ECB) mode is used for protecting Join-Accept
messages. The Join-Accept message contains an AppNonce (a 24-bit
value) that is recovered on the end device along with the other Join-
Accept content (e.g., DevAddr) using the AES-encrypt operation. Once
the Join-Accept payload is available to the end device, the session
keys are derived from the AppKey, AppNonce, and other values, again
using an ECB mode AES-encrypt operation, with the plaintext input
being a maximum of 16 octets.Это же адище! И каким идиотом надо быть, чтобы в XXI веке проектировать протокол с юнитом меньше одного блока AES и MAC менее 4 байт? Это от "S in IoT stand for Security" ?
Более того, мне сказали "Тебе как бы не надо разбираться, тебе надо ендпоинт в амазоновском облаке приготовить для данных и подписать договор с локальным лора-провайдером, за тебя всё сделают", и:
Lev Serebryakov, [21 Mar 2023 17:03:42]
Я имею ввиду, что как бы их архитектура (и бизнес-модель по совместительству) выглядит не так, что ты купил 100500 датчиков и один хаб (который тот же чип на деле внутри имеет) и собрал собственную полностью сеть датчиков. Это был бы простой случай - всё под одним управлением, и шифрование может быть очень простое по архитектуре, так как и датчик и то, куда он отправляет пакет (хаб) и обработчик на сервере - все одного хозяина. Но нет. Они планируют такое использование:
В городе (ну, в некоторой местности) есть N (где N - маленькое, 1-2-3) коммерческих провайдеров приёмников. И M (десятки) тех, кому собирать данные с их K (тысячи и десятки тысяч) датчиков. N провайдеров не должны видеть данных владельцев датчиков, но должны мочьб переправить эти данные туда, куда при подписании договора владелец датчиков указал. Вот они и навертели несколько слоёв шифрования, что бы владелец сети хабов мог роутить принятое но не мог прочесть пейлоад.
Пардон, но в изменившейся политической обстановке у этого не может быть будущего.
Так что я плюнул и не стал проектировать под лору - пусть кому надо, adaptation layer'ы клепают.
Более того, мне сказали "Тебе как бы не надо разбираться, тебе надо ендпоинт в амазоновском облаке приготовить для данных и подписать договор с локальным лора-провайдером, за тебя всё сделают"
А зачем на отдельно взятом заводе заводить эндпоинт в облаке для отдельно взятого датчика?
Ну изначальная идея была не про заводы а именно про коммунальщиков - когда у тебя датчики по всему городу (больше радиуса их действия) и поддерживать сеть хабов ты не хочешь сам а хочешь это саутсорсить (ведь если датчики на GSM/LTE/5G ты же не поддерживаешь сам сеть базовых станций а пользуешься "провайдерскими", вот так и тут, та же бизнес-модель).
Полагаю, что при одинаковых параметрах радиоканала все протоколы близнецы-братья.
Вот наглядный тест , показывающий что протокол не имеет значение. Определяющим являются характеристики железа и условия связи. (источник https://www.compel.ru/lib/74345)
CC1120 и CC1190 на частоте 868 МГц, LRM, 27 дБм и стандартный комплект антенн;
формат модуляции: GFSK;
полоса пропускания фильтра Rx: 12,5 кГц для компенсации частоты и 7,8 кГц для приема пакетов;
местоположение: Столовая гора, Кейптаун, Южная Африка;
расположение антенны: H1 = 1000 м, H2 = 1 м для 78…98-км теста и 91 м для 114-км теста;
частота: 868 МГц;
тестируемые модули: CC1120 и CC1190, содержащие термокомпенсированные кварцевые генераторы (TCXO) на 32 МГц;
LNA = 0x03, расширенный фильтр данных включен;
бюджет канала = 27 + 2,1 + 2,1 – (-126,5) = 158 дБ;
проведено три теста на расстояниях: 71 км, 98 км и 114 км.
Не соглашусь. Конечно, прям чуда от математики ждать не стоит и все же FEC никто не отменял. Очень важно какой алгоритм восстановления информации вы используете и сколько у вас передается избыточной информации в канале. Самое наглядное подтверждение - Wi-Fi, который в разных радиоусловиях на порядки может менять скорость передачи. Делает он это за тем, чтобы выдержать требуемое расстояние.
WiFi - это неудачный пример. Полоса пропускания приемника WiFi 20 MГц, а полоса пропускания приемников BLE, LoRaWan,ZigBee не более 1MГц. Т е потенциально WiFi имеет 20 кратный запас по скорости обмена и корень квадратный из 20 меньший бюджет приемника по отношению сигнал/шум. Поэтому либо быстро ехать, либо красивые шашечки на двери авто.
А если уж сравнивать математику при прочих равных - а это BLE, LoRaWan,ZigBee и им подобное, то тут все братья-близнецы, но BLE 5.1 - лучше, быстрее, дальше, меньше и дешевле.
Напомню, что Wi-Fi бывает разный. У него полоса может быть от 5 до 160 МГц. И если уж на то пошло - у Лоры полоса 125 кГц, т.е. в 8 раз меньше мегагерца. Но дело не в этих цифрах, а в избыточности кодирования, которая всегда повышает стабильность. В разумных пределах, конечно, по повышает.
Повторю то, что сказал ранее. Надо сравнивать равноценное железо. некорректно сравнивать WiFi с Лорой ble и им подобным.
Если сравнивать равноценные по железу т е BLE, LoRaWan,ZigBee, то они отличаются в основном стоимостью железа. Математика у них существенно не отличается. Делаете полосу уже, помех меньше, связь медленнее. Причем здесь избыточность кодирования?
Спор же о том, можно ли при одинаковом железе и модуляции что-то вытянуть протоколом. Вот, я пытаюсь выразить мысль - можно. Чудес не будет, но есть разные лайфхаки, когда протокол повышает стабильность передачи. И главный лайфхак - это FEC. Чем больше избыточной информации в сигнале, тем проще его восстановить, даже если в процессе передачи была утеряна часть сведений.
Я точно знаю, что RS-485 на заводах есть. И искренне надеюсь, что заводским связистам не придёт в голову «светлая» мысль: «Та-а-ак, сеть мы построили, опрос работает, а давайте попробуем опросить через LoRaWAN вон тот увесистый датчик с кучей метрик…»
Скажите, а какое отношение связисты (хоть заводские, хоть какие) имеют к RS-485? И, вообще, к датчикам?
LoRa one love. Почему стандарт разочаровал коммунальщиков, но зашёл на заводах