LoRaWAN у мультисервісних проєктах: газ, вода та тепло в одній мережі 

Чому мультисервісний підхід стає актуальним

У комунальній інфраструктурі протягом тривалого часу кожен ресурс розвивався окремо. Водоканал займався своїми лічильниками, теплопостачальна організація – своїми вузлами обліку, газова служба – своїми приладами та правилами експлуатації. На рівні процесів це зрозуміло, але на рівні даних така роз’єднаність створює додаткові витрати.

Якщо кожен сервіс будує власний канал зв’язку, з’являються паралельні мережі, різні підрядники, різні платформи та різні правила обслуговування. Для нового житлового комплексу це означає більше інженерних рішень на етапі проєктування. Для муніципалітету – складніше масштабування обліку по районах. Для ОСББ – важче зібрати повну картину споживання та технічного стану будинку.

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

Зростання ринку підтверджує, що такі рішення перестають бути нішевими. За оцінкою IoT Analytics, кількість підключених IoT-пристроїв у світі у 2025 році досягла 21,1 млрд і може зрости до 39 млрд до 2030 року. Для комунальної сфери це означає поступовий перехід від точкових підключень до масового збору даних із розподілених об’єктів.

^{Одна мережа – кілька сервісів}

Як LoRaWAN працює в задачах обліку

LoRaWAN належить до мереж далекого радіуса дії з низьким енергоспоживанням. Для комунального обліку це важливе поєднання: лічильники та радіомодулі часто встановлюють у підвалах, колодязях, технічних шафах, на сходових клітках або в приміщеннях без постійного живлення. Пристрій має передавати невеликі пакети даних і працювати від батареї роками, а не потребувати регулярного обслуговування.

У типовій схемі радіомодуль зчитує дані з лічильника або отримує імпульси з його виходу, а потім передає їх на шлюз. Шлюз підключений до сервера мережі, після чого дані потрапляють у прикладну систему: панель моніторингу, білінг, диспетчерську або систему керування об’єктом. Для кінцевого користувача це виглядає просто: показання з’являються в інтерфейсі без обходу квартир, підвалів чи колодязів.

Сильна сторона LoRaWAN полягає в тому, що один шлюз може обслуговувати велику кількість пристроїв у межах району, житлового комплексу, промислової території або муніципального об’єкта. Водночас мережа може бути приватною: замовник розгортає власні шлюзи та контролює інфраструктуру. Це зручно для проєктів, де важливо керувати покриттям, безпекою та вартістю передавання даних.

Але універсальних мереж без обмежень не існує. Радіосигнал залежить від рельєфу, щільності забудови, матеріалів будівель, глибини встановлення та розташування антен. Тому перед масштабуванням важливо провести радіопланування або пілотний проєкт: перевірити зв’язок у підвалах, технічних приміщеннях, колодязях і на віддалених ділянках. Саме такі точки найчастіше стають критичними для якості проєкту.

Вода: масовий облік і контроль аномалій

Водопостачання – один із найтиповіших сценаріїв для LoRaWAN. Водоміри часто встановлюють масово: квартири, комерційні приміщення, загальнобудинкові вузли, технічні зони, насосні станції, колодязі. Обсяг переданих даних зазвичай невеликий, а частота передавання може бути помірною: наприклад, кілька разів на добу або за заданим розкладом.

Для постачальника води дистанційний облік знижує залежність від ручного передавання показань. Це особливо важливо, коли частина абонентів забуває надсилати дані, доступ до приладів обмежений, а нарахування доводиться будувати на розрахункових значеннях. Автоматичний збір дає змогу частіше бачити фактичне споживання й швидше помічати різкі відхилення.

Для ОСББ і керуючих компаній цінність з’являється на рівні балансу. Якщо сума квартирних лічильників відрізняється від показань загальнобудинкового вузла, це привід перевірити витоки, необліковані підключення, несправні прилади або помилки в даних. Сам по собі LoRaWAN не усуває втрати, але робить їх помітнішими для аналізу.

У водних проєктах до лічильників часто додають датчики протікання, тиску або рівня. Це розширює сценарій від обліку до моніторингу стану мережі. Наприклад, нічне споживання може вказувати на прихований витік, а падіння тиску – на проблему на ділянці. У результаті диспетчер отримує не лише показання, а й ранні ознаки аварійної ситуації.

^{Від обліку до контролю: як LoRaWAN допомагає бачити аномалії у водопостачанні} 

Газ: обережна цифровізація та вимоги до надійності

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

LoRaWAN може бути корисним там, де потрібно регулярно отримувати показання з великої кількості газових приладів без частого доступу до них. Це зменшує кількість обходів абонентів, допомагає скоротити помилки введення та дає постачальнику більш своєчасну картину споживання. Особливо помітний ефект у приватному секторі, котеджних містечках, розподілених об’єктах і житлових комплексах із великою кількістю абонентів.

Водночас важливо не обіцяти того, чого технологія не робить сама по собі. Передавання показань не дорівнює автоматичному керуванню газовою інфраструктурою. Якщо в проєкті потрібні дистанційне відключення, контроль втручання, сигналізація або додаткові функції безпеки, вони мають бути передбачені на рівні сумісних пристроїв, регламентів і допуску до експлуатації.

Для замовника головний критерій – не лише радіус зв’язку, а й надійність даних. Газові показання використовуються в розрахунках, тому важливі захист від втрати повідомлень, коректна ідентифікація пристроїв, журнал подій і можливість інтеграції з обліковою системою. Чим краще продуманий ланцюжок від лічильника до білінгу, тим менше спірних ситуацій виникає на етапі експлуатації.

Тепло: дані для балансу та енергоефективності

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

Міжнародне енергетичне агентство зазначає, що цифровізація підвищує гнучкість систем централізованого теплопостачання: розумні теплолічильники та сучасні засоби керування допомагають точніше узгоджувати попит і пропозицію, використовуючи дані про погоду, споживання та роботу мережі. Для міст і великих житлових комплексів це особливо важливо, оскільки тепло залишається однією з найвитратніших комунальних послуг.

LoRaWAN підходить для передавання регулярних даних із теплолічильників, вузлів обліку та датчиків температури. У житловому комплексі це може бути контроль по корпусах, секціях, індивідуальних теплових пунктах або комерційних приміщеннях. Для теплопостачальної організації – моніторинг розподілених вузлів і порівняння фактичного споживання з розрахунковими моделями.

Для ОСББ така система допомагає краще розуміти, де виникають втрати або дисбаланс. Наприклад, якщо один під’їзд стабільно споживає більше тепла за схожої площі та температури зовнішнього повітря, це привід перевірити налаштування, ізоляцію, циркуляцію або роботу обладнання. Дані не замінюють інженера, але допомагають йому шукати проблему не навмання.

^{Приклад порівняння фактичного споживання тепла за місяць по корпусах/секціях}

Де одна мережа справді вигідніша за кілька

Мультисервісна мережа особливо виправдана там, де щільність пристроїв достатньо висока. Наприклад, у новому житловому комплексі можна заздалегідь передбачити збір даних із квартирних лічильників води, загальнобудинкових вузлів, теплових пунктів, комерційних приміщень і технічних датчиків. Тоді один комплект шлюзів обслуговує кілька завдань, а не лише один вид обліку.

Для муніципалітету подібна логіка працює на рівні району. Якщо мережу розгорнуто для водного обліку, її можна поступово використовувати для інших пристроїв: датчиків затоплення, контролю люків, моніторингу контейнерних майданчиків, вуличного освітлення або технічних об’єктів. Це знижує бар’єр для наступних сценаріїв, оскільки базовий зв’язок уже є.

Для постачальників ресурсів мультисервісність допомагає вибудовувати спільні проєкти. Вода, тепло й газ можуть залишатися в різних облікових системах, але передавання даних може використовувати спільну інфраструктуру зв’язку. Це особливо актуально, якщо експлуатацією мережі займається окремий оператор або якщо муніципалітет створює спільну основу для міських сервісів.

Однак вигода з’являється лише за правильної організаційної моделі. Потрібно заздалегідь визначити, хто володіє шлюзами, хто обслуговує мережу, хто відповідає за якість покриття, як розділяються дані різних служб і як оплачується експлуатація. Без цих домовленостей навіть хороша технологія може стати джерелом суперечок.

Які питання потрібно вирішити до запуску

Перед впровадженням LoRaWAN у мультисервісному проєкті варто починати не з вибору пристроїв, а з карти об’єктів. Де встановлені лічильники? У яких приміщеннях слабкий зв’язок? Які прилади вже мають імпульсні виходи або цифрові інтерфейси? Які дані потрібні щодня, а які достатньо збирати раз на місяць? Ці питання впливають і на обладнання, і на покриття, і на строк служби батарей.

Друге важливе питання – частота передавання даних. Для комерційного обліку часто достатньо регулярних показань за розкладом. Для аварійних датчиків потрібне передавання за подією. Для теплових пунктів може знадобитися частіший моніторинг. Що частіше пристрій передає дані, то вище навантаження на батарею та мережу, тому режими роботи мають відповідати реальному завданню.

Третє питання – інтеграція. Якщо дані залишаються лише в окремій панелі, їхня корисність обмежена. Для постачальника ресурсів важливе передавання в білінг або систему обліку. Для керуючої компанії – вивантаження, звіти та контроль статусів. Для муніципалітету – зведена аналітика по об’єктах і районах. Тому на старті потрібно розуміти, куди потраплять дані і хто з ними працюватиме.

Четверте питання – безпека та розмежування доступу. У мультисервісній мережі можуть передаватися дані різних служб і об’єктів. Тому важливо розділяти ролі користувачів, захищати пристрої від підміни, фіксувати події та контролювати зміни налаштувань. Що більше сервісів працює в одній мережі, то важливішими стають правила управління.

LoRaWAN і NB-IoT: не конкуренти в усіх випадках

У проєктах дистанційного обліку LoRaWAN часто порівнюють із NB-IoT. Таке зіставлення корисне, але не має зводитися до вибору «кращої» технології. LoRaWAN частіше обирають там, де замовник хоче контролювати власну мережу, розгорнути шлюзи на своїй території та підключати велику кількість пристроїв із прогнозованою вартістю передавання даних.

NB-IoT, навпаки, зручний там, де є якісне покриття мобільного оператора і немає бажання будувати власну мережу. Це може бути правильним рішенням для розподілених об’єктів, де встановлення шлюзів економічно не виправдане. За даними GSMA, до листопада 2025 року у світі було запущено 140 комерційних мереж NB-IoT, 129 мереж LTE-M і 269 мобільних IoT-мереж загалом.

На практиці у великих проєктах можлива змішана архітектура. Наприклад, у межах житлового комплексу або району використовується LoRaWAN, а для віддалених об’єктів – NB-IoT. Такий підхід дає змогу обирати зв’язок під умови встановлення, а не під заздалегідь задану технологію.

Для замовника важливіша не назва мережі, а надійність результату: чи збираються показання, чи достатньо покриття в проблемних місцях, чи зрозуміла вартість експлуатації, чи є підтримка пристроїв та інтеграція із системами обліку. Саме ці параметри визначають життєздатність проєкту після пілота.

Як оцінювати результат пілотного проєкту

Пілот LoRaWAN-проєкту має перевіряти не презентаційну картинку, а робочу модель експлуатації. Недостатньо показати, що кілька пристроїв передають дані на екран. Потрібно перевірити зв’язок у складних місцях, стабільність передавання, коректність показань, зручність обслуговування та зрозумілість звітів для тих, хто працюватиме із системою щодня.

Хороший пілот включає різні типи об’єктів: підвал, технічну шафу, колодязь, приміщення з товстими стінами, верхні поверхи, віддалену точку. Якщо мережа має обслуговувати газ, воду й тепло, у пілоті варто перевірити хоча б по одному типовому сценарію кожного ресурсу. Тоді рішення про масштабування буде засноване на даних, а не на припущеннях.

Оцінювати варто не лише технічні показники, а й вплив на процес. Скільки ручних обходів можна скоротити? Наскільки швидше з’являються показання? Скільки помилок ручного введення зникає? Чи можна побачити пропуски зв’язку, низький заряд батареї, спроби втручання або аномальне споживання? Ці питання безпосередньо пов’язані з економікою впровадження.

^{Критерії для масштабування мультисервісного проєкту}

Jooby RDC: від збору показань до контролю відхилень

У мультисервісному проєкті цінність створює не окремий лічильник чи радіомодуль, а весь ланцюжок: вимірювання на об’єкті, передавання даних, контроль стану пристроїв і аналіз відхилень. У цій логіці рішення Jooby RDC можуть використовуватися як інфраструктурний шар для дистанційного обліку газу, води, тепла й електроенергії: сенсори, радіомодулі, гейтвеї та розумні лічильники допомагають збирати дані в мережах LoRaWAN і NB-IoT.

Jooby RDC Dashboard доповнює цей шар робочою панеллю для перегляду показань, контролю пристроїв і аналізу нештатних ситуацій. Для постачальника ресурсів, керуючої компанії або ОСББ це спосіб бачити підключену інфраструктуру в одному інтерфейсі: швидше помічати пропуски передавання даних, спірні показання, ознаки витоків і нехарактерну поведінку обладнання.

LoRaWAN у мультисервісних проєктах корисний там, де потрібно не просто підключити кілька лічильників, а створити стійку основу для збору даних за різними ресурсами. Газ, вода й тепло залишаються різними інженерними системами, але їхні дані можуть передаватися через спільну мережу та використовуватися для обліку, контролю відхилень, планування