Prípadová štúdia: LoRaWAN pre samosprávu – meranie a diaľkové odpočty spotreby elektriny

Predstavte si obec alebo menšie mesto, ktoré spravuje desiatky objektov: obecný úrad, škola, škôlka, kultúrny dom, športový areál, knižnica, technické služby, čerpacie stanice, verejné osvetlenie, nájomné priestory. Každý z týchto objektov má svoju spotrebu elektriny – a každý z nich môže byť zdrojom úniku financií, ak chýba prehľad. Kým účtovníctvo vidí faktúry raz za mesiac (a často s oneskorením), technické oddelenie potrebuje vedieť „čo sa deje teraz“. V skutočnosti sa veľa problémov neprejaví okamžite haváriou, ale tichým nárastom spotreby: zle nastavená technológia, nefunkčné časovače, preťažené zariadenie, porucha kompenzácie jaloviny, zbytočne bežiace osvetlenie, ventilácia či kúrenie.

Táto prípadová štúdia opisuje realistický scenár nasadenia LoRaWAN v samospráve so zameraním výhradne na meranie a diaľkové odpočty spotreby elektriny. Cieľom nie je „smart city pre leták“, ale systém, ktorý prinesie:

• pravidelné dáta o spotrebe (denné/hodinové profily),

• alarmy pri anomáliách a výpadkoch,

• zníženie nákladov a rýchlejšie riešenie porúch,

• kvalitný podklad pre investície (FVE, batérie, regulácia, modernizácia).

1) Východiskový stav: keď máte faktúry, ale nemáte kontrolu

Obec (nazvime ju Obec X) spravovala približne 45 objektov a infraštruktúrnych bodov s vlastným elektromerom alebo podružným meraním. Spotreby sa sledovali najmä cez:

• faktúry od dodávateľa,

• manuálne odpočty v niektorých objektoch,

• občasné „operatívne“ meranie prenosným analyzátorom pri probléme.

Problémy, ktoré sa opakovali:

Neviditeľné víkendové a nočné straty

Najčastejší scenár: škola alebo športovisko mali počas víkendov a nocí spotrebu vyššiu, než by dávalo zmysel. Nie vždy to bola porucha – často len zle nastavený časový program, zabudnuté osvetlenie, server alebo technológia bežiaca v režime „24/7“.

Energetické špičky bez vysvetlenia

Niekedy sa spotreba v určitý deň prudko zvýšila, no nikto nevedel prečo. Keď sa na to prišlo z faktúry, bolo neskoro. Obec potrebovala vedieť:

• kedy sa to stalo,

• na ktorom objekte,

• či sa to opakuje,

• či to bola jednorazová udalosť alebo nový trend.

Údržba „až keď to zhorí“

Elektrické rozvádzače, technológie, čerpadlá a verejné osvetlenie sa riešili až vtedy, keď sa niečo pokazilo alebo prišla sťažnosť. Chýbala prevencia založená na dátach.

Obec zvažovala riešenie cez mobilných operátorov (SIM v každom meracom bode), no pri desiatkach bodov vychádzala prevádzka dlhodobo draho a nepružne. Rozhodla sa preto vybudovať LoRaWAN sieť a pripojiť na ňu energetické merania.

2) Prečo práve LoRaWAN

LoRaWAN nie je náhrada internetu ani technológia na veľké dáta. Je to sieť pre IoT senzory: malé správy, dlhý dosah, nízka spotreba.

Kľúčové dôvody rozhodnutia:

• Bez SIM kariet: obec nechcela platiť mesačné paušály za každý bod.

• Dlhý dosah: pokrytie obce stačilo vyriešiť niekoľkými bránami (gateway).

• Prenik signálu: rozvádzače, pivnice a technické miestnosti boli často lepšie pokryté než pri iných riešeniach.

• Škálovanie: obec nechcela riešiť len elektrinu – ale začať ňou, a neskôr pridať ďalšie oblasti (voda, osvetlenie, ovzdušie). LoRaWAN to umožňuje bez zmeny infraštruktúry.

3) Ciele projektu a KPI (ako obec merala úspech)

Aby projekt neskončil ako „zaujímavá hračka“, Obec X si stanovila konkrétne ciele:

1. Získať hodinové alebo denné profily spotreby pre najdrahšie objekty (škola, športovisko, ČOV, úrad).

2. Zaviesť alarmy:

   • výpadok napájania,

   • neštandardná nočná spotreba,

   • prekročenie prahovej hodnoty výkonu/spotreby.

3. Znížiť čas od detekcie problému po zásah (zo „mesiacov“ na dni alebo hodiny).

4. Zlepšiť rozpočtovanie a plán investícií (FVE, batéria, regulácia) na základe reálnych dát.

KPI, ktoré sledovali:

• počet zachytených anomálií za mesiac,

• percento objektov s hodinovým profilom,

• počet servisných zásahov „vopred“ (pred sťažnosťou),

• odhad úspor po optimalizácii režimov (napr. osvetlenie, ventilácia).

4) Architektúra riešenia: čo všetko bolo potrebné

4.1 LoRaWAN brány (gateway)

Najprv sa riešilo pokrytie: obec mala členitý terén a niekoľko problémových miest (nízko položené objekty, technické šachty). Zvolil sa koncept:

• 1 hlavná brána na vyššom bode (strecha obecného úradu),

• 1 doplnková brána pri športovom areáli,

• 1 brána v okrajovej časti obce pre redundanciu.

Cieľom nebolo „mať signál všade na hrane“, ale mať spoľahlivý príjem pre kritické body a zároveň redundanciu (ak jedna brána vypadne, správy zachytí druhá).

4.2 Sieťový server a platforma

Obec zvažovala cloud aj vlastné riešenie. Rozhodla sa pre model, kde:

• správa zariadení je centralizovaná,

• dáta sú k dispozícii cez dashboard,

• alarmy idú e-mailom/SMS (alebo integráciou na interný systém),

• existuje export do Excelu/CSV pre účtovníctvo a analýzy.

Kľúčové bolo, aby systém nebol „len grafy“, ale aby mal alarmy a zodpovednosti: kto reaguje na aký typ problému.

4.3 Meracie body (elektromery a prevodníky)

V praxi existovali tri typy meraní:

1. Hlavný elektromer objektu (tam, kde bol prístup k dátam cez rozhranie)

2. Podružné meranie (napr. samostatná technológia v objekte)

3. Meranie rozvádzačov verejného osvetlenia (spotreba a stav)

Najčastejšie sa použili elektromery s rozhraním Modbus RS485 alebo impulzný výstup S0. Na tieto rozhrania sa pripojil LoRaWAN „dátový uzol“ (prevodník), ktorý:

• pravidelne čítal energiu (kWh),

• voliteľne čítal výkon (kW) alebo prúd (A),

• posielal správy v intervaloch.

5) Pilotná fáza: rýchly test v teréne

Obec začala pilotom s 8 meracími bodmi:

• Obecný úrad (hlavný elektromer)

• Škola (hlavný elektromer)

• Športový areál (hlavný elektromer)

• Kultúrny dom (hlavný elektromer)

• ČOV (hlavný elektromer)

• 2× rozvádzač verejného osvetlenia

• 1× podružné meranie technológie (čerpadlo/ventilácia)

Čo sa nastavilo hneď na začiatku

• odosielanie spotreby každú hodinu pre najdôležitejšie objekty,

• odosielanie spotreby 1× denne pre menej kritické body,

• alarm pri výpadku napájania,

• alarm pri neštandardnej nočnej spotrebe (napr. medzi 22:00–05:00).

Prvé zistenia z pilotu (už v prvých týždňoch)

1. Škola mala v noci stabilnú „základnú“ spotrebu vyššiu, než sa čakalo.
   Po preverení sa ukázalo, že časť osvetlenia a ventilácie mala chybný časový režim.

2. Športový areál mal nepravidelné špičky.
   Z dát sa dalo presne určiť, v aké dni a v akom čase vznikajú. Následne sa spojili s prevádzkou a upravili režim ohrevu vody a osvetlenia.

3. Rozvádzač verejného osvetlenia ukázal anomáliu v spotrebe jednej vetvy.
   V teréne sa našiel problém so zariadením v jednej časti (neštandardná záťaž). Bez dát by sa to riešilo len „keď niečo prestane svietiť“.

Pilot tak potvrdil dve veci: pokrytie a kvalitu dát. Zároveň ukázal, že najväčší prínos nie je v „odpočte“, ale v profiloch a alarmoch.

6) Ostré nasadenie: z 8 bodov na desiatky

Po pilote obec rozšírila systém na ďalšie objekty. Nasadenie sa robilo v vlnách, aby sa zvládla inštalácia aj zmena procesov.

6.1 Segmentácia podľa dôležitosti

Objekty rozdelili na tri kategórie:

• Kritické: škola, ČOV, športovisko, úrad
  -> hodinové dáta + alarmy

• Stredne dôležité: kultúrny dom, knižnica, vybrané technické objekty
  -> denný profil + vybrané alarmy

• Menej dôležité: sklad, menšie objekty, nájomné priestory s nízkou spotrebou
  -> denný alebo týždenný prehľad (podľa potreby)

Tým sa optimalizovala aj prevádzka siete (nie všetko musí posielať dáta rovnako často).

6.2 Nastavenie alarmov (kde sa rodí prínos)

Obec si postupne vypilovala alarmy tak, aby neboli „otravné“. Najlepšie fungovali:

• Alarm pri výpadku napájania (kritické objekty)

• Nočná spotreba nad prah (najmä školské budovy a športoviská)

• Dlhodobý trend (napr. 7-dňový priemer rastie)

• Špičky výkonu (ak to meranie podporovalo – dôležité pri dimenzovaní a odhaľovaní problémov)

Kľúčom bolo, že alarmy mali vlastníka: konkrétnu osobu alebo tím, ktorý reaguje.

7) Výsledky po 3–6 mesiacoch: čo sa reálne zmenilo

7.1 Prehľad a „energia ako dashboard“

Najväčšia zmena bola psychologická: energie prestali byť „faktúry“, ale stali sa živým systémom. Technické oddelenie videlo spotreby v grafoch, porovnania týždeň na týždeň a rýchlo identifikovalo odchýlky.

7.2 Rýchle zásahy namiesto neskorých prekvapení

Problémy, ktoré by sa inak riešili až po faktúre, sa riešili do pár dní:

• zlé časovače,

• nesprávne nastavené režimy osvetlenia,

• zbytočne bežiace zariadenia.

7.3 Lepšie rozpočtovanie a argumenty pre investície

Obec mohla pripraviť podklady:

• kde má zmysel FVE (kedy je najvyššia spotreba),

• kde je vysoký „nočný základ“ a čo s tým,

• kde sú špičky výkonu a treba riešiť technológiu.

7.4 Úspory (ako sa prejavili)

Úspory sa neukázali ako „jedna veľká bomba“, ale ako séria menších zlepšení:

• úpravy časových režimov,

• vypínanie nepotrebných okruhov,

• zníženie zbytočnej prevádzky technológií,

• rýchlejšie odstránenie porúch.

Práve tento „súčet malých úspor“ bol pre rozpočet najdôležitejší – a najmä udržateľný.

8) Čo sa ukázalo ako najdôležitejšie (lessons learned)

8.1 Nepodceniť výber meracieho bodu

Najlepšie výsledky mali objekty, kde sa meralo nielen „kWh za deň“, ale kde bol dostupný aspoň hodinový profil. Podružné merania (napr. len technológia) boli niekedy ešte hodnotnejšie než hlavný elektromer, lebo ukázali konkrétnu príčinu.

8.2 Alarmy musia byť zmysluplné

Ak alarm pípne 20× a nikto nevie, čo s tým, systém sa ignoruje. Keď však alarm znamená konkrétny problém a má zodpovedného človeka, systém sa stáva každodenným nástrojom.

8.3 LoRaWAN nie je na „sekundové dáta“

Najčastejšia chyba na začiatku: posielať dáta príliš často. Správne je nastaviť periodicitu rozumne (hodina/deň) a posielať extra správy pri udalosti (výpadok, prekročenie prahu).

8.4 Najväčšia hodnota je v procesoch

Technológia je len polovica. Druhá polovica je:

• kto pozerá dashboard,

• kto rieši alarmy,

• ako sa robí servisný zásah,

• ako sa zmeny dokumentujú.

9) Ako môže vyzerať „ideálny“ balík pre obec

Ak by sme zhrnuli najlepšiu prax pre samosprávu, ktorá chce začať s elektrinou:

1. Pilot na 5–10 bodov (škola, úrad, športovisko, ČOV + 1–2 rozvádzače VO)

2. Hodinové profily pre kritické objekty, denné pre ostatné

3. Alarmy: výpadok + nočná spotreba + dlhodobý trend

4. Jednoduchý dashboard: top 10 objektov podľa spotreby, grafy, porovnanie týždeň/týždeň

5. Proces reakcie: kto rieši alarm, ako sa uzatvára incident

6. Priebežné rozšírenie o podružné merania tam, kde sa objaví problém

Záver

Táto prípadová štúdia ukazuje, že LoRaWAN v samospráve nie je len o „smart nálepke“, ale o veľmi praktickej kontrole nad spotrebou elektriny. Keď obec získa hodinové alebo denné profily, alarmy a jednoduché porovnania, dokáže zachytávať problémy včas, robiť malé, ale trvalé optimalizácie a lepšie plánovať investície.

Najväčšia výhoda LoRaWAN v tomto kontexte je, že umožní vybudovať vlastnú sieť bez SIM kariet a s nízkymi prevádzkovými nákladmi – a následne na ňu pripájať ďalšie merania a služby podľa toho, čo obec najviac potrebuje.