IoT-інфраструктура для багатоквартирних будинків та ОСББ: від лічильників до управління даними

Спочатку визначити завдання та зони відповідальності

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

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

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

Що показує практика 2025–2026 років

Бездротовий облік уже застосовується у великих інфраструктурних проєктах. У вересні 2025 року група Minol–ZENNER повідомила про підключення десятимільйонного пристрою до своєї мережі LoRaWAN. У квітні 2026 року компанія оголосила про 11 млн активних пристроїв. Це дані однієї групи компаній, а не оцінка всього ринку й не кількість підключених квартир. Такий масштаб свідчить, що технологія використовується далеко за межами пілотних установок.

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

^{Масштаб мережі LoRaWAN}

Обстеження будинку: що перевірити до вибору мережі

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

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

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

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

LoRaWAN чи NB-IoT: вибір за умовами будівлі

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

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

^{Два шляхи передавання показників}

Жодна технологія не гарантує приймання сигналу в будь-якому підвалі. Залізобетон, металеві двері та шафи можуть помітно змінити умови зв’язку. Перевірку проводять з обраним пристроєм безпосередньо в місці монтажу, за зачинених дверей. Рівень звичайного мобільного зв’язку на телефоні не замінює випробування NB-IoT-модуля.

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

Частота передавання: дані для розрахунків і дані для контролю

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

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

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

Водний баланс: як шукати причини розбіжностей

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

Розгляньмо умовний приклад: усі точки споживання враховано, об’єми стосуються одного періоду, а загальнобудинкові потреби не включено до квартирних показників. Ввідний лічильник зареєстрував 1 000 м³, квартирні – 920 м³, окремий лічильник загальних потреб – 30 м³. Залишкова розбіжність становитиме 50 м³, або 5% об’єму на вводі. Це результат прикладу, а не норматив допустимих втрат.

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

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

^{Дистанційний облік води}

Програмна система: як перетворити показники на робочий інструмент

На сервері кожен пристрій необхідно пов’язати з конкретним лічильником, приміщенням та обліковим записом. Під час заміни приладу історія має зберігатися, а нові показники – оброблятися з урахуванням дати заміни та початкового значення. Інакше справна мережа доставлятиме дані, які неможливо коректно використовувати.

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

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

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

Як Jooby RDC вписується в інфраструктуру будинку

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

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

Експлуатація: що станеться після втрати зв’язку

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

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

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

Як оцінити вартість і прийняти результат

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

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

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

Критерії приймання фіксують заздалегідь:

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

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

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