Att köpa en lorawan temp sensor är enkelt. Att faktiskt få den att skicka tillförlitliga temperaturlarm från en källare med armeradbetong, via en korrekt konfigurerad gateway, till en dashboard som triggar rätt åtgärd, det är ett helt annat projekt.

LoRaWAN-nätverk bygger på en stjärn-av-stjärnor-topologi med fem kärnkomponenter: end devices, gateways, nätverksserver, applikationsserver och join server. Varje lager har sin egen logik och sina egna felpunkter. Hoppar du över planeringsfaserna och börjar med sensorinköp, riskerar du dålig radiotäckning, felaktig gateway-placering och en onboarding-process som fastnar i aktiveringsfel.

Den här guiden behandlar LoRaWAN-driftsättning i befintliga fastigheter som det projekt det faktiskt är, med distinkta faser i rätt ordning. Du får en genomgång av radiotäckningsanalys, gateway-val och placering, sensor-onboarding med OTAA respektive ABP, plattformsintegration och löpande drift. Vi tittar också på när egenutvecklade noder baserade på ESP32 är ett rationellt alternativ. Målet är att du efter genomläsningen kan gå från första täckningskartan till ett levande övervakningssystem utan onödiga omtag.

LoRaWAN-arkitekturens fem byggstenar

LoRaWAN bygger på en stjärn-av-stjärnor-topologi med fem kärnkomponenter som samverkar i en tydlig rollfördelning. Att förstå dessa komponenter innan projektet startar är inte teori för teorins skull: varje beslut du fattar om täckning, gateway-placering och onboarding hänger direkt ihop med hur arkitekturen fungerar.

End devices är de batteridrivna sensorer och mätpunkter som utgör nätverkets ytterkant. En LoRaWAN-temperatursensor för inomhusmiljö sänder till exempel LoRa-modulerade radiomeddelanden uppåt i nätverket utan att vänta på ett tillstånd från gatewayen. Det ALOHA-baserade protokollet innebär att sensorn sänder när den har data, inte när nätverket bjuder in.

Gateways tar emot dessa meddelanden och vidarebefordrar dem direkt till nätverksservern via ethernet, 4G eller WiFi. En gateway utför ingen applikationslogik; den fungerar som en transparent radiobro. I en flervåningsfastighet kan flera gateways fånga exakt samma meddelande från en och samma sensor, vilket i stället för att orsaka problem utnyttjas konstruktivt.

Network Server är nätverkets styrenhet. Den hanterar meddelandededuplikering automatiskt när flera gateways rapporterar samma paket, väljer den bästa upplänken och styr adaptiv dataöverföringshastighet. Det innebär att överlappande gatewaytäckning är en tillgång för redundans, inte ett slöseri med hårdvara.

Application Server tar vid efter nätverksservern och behandlar den avkodade nyttolastdata säkert. Det är här råbytes översätts till fysikaliska värden som grader Celsius eller relativ luftfuktighet, och det är härifrån data görs tillgänglig för plattformar som Sensor-Online via MQTT eller HTTP.

Join Server hanterar registrering och säker aktivering av end devices. Vid OTAA-aktivering är Join Server den komponent som verifierar enhetens identitet och utfärdar sessionsnycklarna. Vid ABP kringgås Join Server, vilket är en av anledningarna till att OTAA konsekvent rekommenderas för produktionsmiljöer.

Dessa fem komponenter bildar tillsammans ett system där varje lager har ett avgränsat ansvar. Det praktiska konsekvensen för ett fastighetsprojekt är att du inte kan optimera gateway-placering utan att förstå hur Network Server hanterar täckningsöverlapp, och du kan inte planera onboarding utan att ha ett klart förhållningssätt till Join Server och aktiveringsmetod. Arkitekturen är alltså inte bakgrundsinformation: den är beslutsramverket för hela driftsättningen.

Fas 1: Radiotäckningsanalys innan du köper ett enda gateway

Med arkitekturen klar är nästa steg att förstå var signalerna faktiskt kan ta sig i din specifika byggnad, innan du beställer en enda gateway.

Byggnadsmaterial är den variabel som förstör de flesta initiala budgetar. Armerad betong dämpar LoRaWAN-signalen med 15-25 dB, tjockt tegel med 10-15 dB, och metallbeklädd fasad eller installationsgolv kan stänga ute signalen nästan helt. I praktiken innebär ett enkelt bjälklag av armerad betong att du förlorar halva din länkbudget i varje våningsplan. Det är inte ett undantag, det är normen i svenska flervåningsfastigheter.

Genomför en site survey innan permanenta beslut

En site survey kräver ingen avancerad utrustning. Placera en temporär gateway på ett strategiskt läge och låt en referenssensor (eller en handhållen enhet med känd sändeffekt) vandra genom byggnaden. Mät RSSI (mottagen signalstyrka) och SNR (signal-brusförhållande) i varje zon enligt beprövad mätmetodik. Tumregel: ett RSSI under -120 dBm eller SNR under -15 dB indikerar att ett permanent monterad sensor på den platsen kommer att ha problem att hålla anslutningen.

Kartlägg problemzonerna explicit: källare, hisschakt, serverrum med metallväggar och parkeringsgarage kräver nästan alltid en dedikerad gateway eller en repeater. Att räkna med att dessa zoner täcks “av sig självt” är det vanligaste misstaget i fas ett.

Spridningsfaktor: räckvidd kostar lufttid

Spreading factor (SF) styr avvägningen mellan räckvidd och överföringshastighet. SF7 ger snabb överföring och kort lufttid, men begränsad räckvidd. SF12 når längre in i problematiska zoner men ökar lufttiden dramatiskt, vilket påverkar batterilivslängd och duty-cycle-budget i EU868-bandet. Notera detta under site survey-fasen: en zon som bara nås med SF12 kan bli en kapacitetsflaskhals vid fler sensorer.

Dokumentera innan du beslutar

Sammanställ täckningskartan i ett kalkylblad med rumskoordinator, uppmätt RSSI/SNR och noterad spreading factor per mätpunkt. LoRaWAN-specifika RF-planeringsverktyg kan visualisera detta, men ett välstrukturerat kalkylblad räcker för de flesta fastigheter. Låset fast gateway-antal och placering först när kartan är klar. Se även vår guide om installation och konfiguration för praktiska råd kring hur du strukturerar dokumentationen inför driftsättning.

Fas 2: Välja och placera rätt IoT gateway

Med täckningskartan klar är nästa beslut hur många gateways du behöver och var de ska sitta.

Antal gateways och vertikal räckvidd

En inomhus IoT gateway räcker ofta för ett enda plan med öppen planlösning, men i flervåningshus begränsar betongbjälklagen signalen avsevärt. Som tumregel behöver du en gateway per 2-3 plan, beroende på bjälklagets konstruktion och armeringstäthet. Inomhusgateways är enkla att installera och underhålla, men antennen pekar i princip horisontellt, vilket gör att signalen försvagas snabbt uppåt och nedåt. En utomhusgateway med extern antenn monterad på fasaden ger betydligt bättre vertikal täckning, eftersom signalen kan nå in i byggnaden på flera plan samtidigt. För höga hus är en kombination av fasadmonterade gateways och kompletterande inomhusenheter i trapphus eller korridorer ofta den effektivaste lösningen.

Backhaul: ethernet, 4G eller WiFi

Hur gatewayen kommunicerar uppåt mot nätverksservern är ett praktiskt installationsbeslut som påverkar driftstabiliteten direkt.

• Ethernet är förstahandsvalet: stabil anslutning, låg latens och inga störningskällor i frekvensområdet.
• 4G/LTE-modem passar när kabelindragning inte är möjlig, till exempel i äldre fastigheter eller utomhusmontage på tak. Prestandan är tillräcklig för LoRaWAN-trafik, som har låga bandbreddskrav.
• WiFi bör undvikas i produktionsmiljöer. Nätverket delar kanal med ett stort antal andra enheter, kanalbyte och autentiseringsproblem skapar periodvis borttappade paket, och det är en felkälla som är svår att felsöka i efterhand.

Antennval

En omnidirektionell antenn täcker 360 grader horisontellt, vilket fungerar bra i öppna kontorsmiljöer. Men för problemzoner som identifierades i fas 1, till exempel ett parkeringsgarage eller en källarlokal, kan en riktad antenn fokusera signalenergin dit den behövs och kompensera för den extra dämpningen.

Frekvensplanering för Sverige

I Sverige används EU868-bandet. Standardkanalerna är 868,1, 868,3 och 868,5 MHz, och ETSI:s duty-cycle-regler begränsar sändningstiden till 1 procent per timme i de flesta subband. Det innebär att sensorer med mycket täta mätintervall kan nå sin duty-cycle-gräns om lufttiden inte beräknats korrekt, vilket är en av de kritiska funktioner att utvärdera redan i planeringsfasen.

Överlappande täckning är en fördel

LoRaWAN bygger inte på exklusiva zoner. Flera gateways kan ta emot samma meddelande från en sensor, och Network Server deduplicerar automatiskt. Överlappande täckning ökar därför redundansen utan att skapa konflikter. Placera gateways med viss överlappning i täckningsgränserna, särskilt i kritiska zoner, så att en gateway som tillfälligt tappar sin anslutning inte skapar ett blindfönster i övervakningen.

Fas 3: Sensor-onboarding med OTAA eller ABP

Med gateways på plats och täckning verifierad är nästa steg att få sensorerna att prata med nätverket. Det är här aktiveringsmetoden avgör hur flexibelt och säkert systemet blir på lång sikt.

OTAA eller ABP: välj rätt från start

OTAA (Over-The-Air Activation) är den metod som rekommenderas av The Things Network och bör vara standardvalet i praktiskt taget alla fastighetsinstallationer. Vid varje anslutning förhandlar sensorn fram unika sessionsnycklar med Join Server, vilket innebär att komprometterade nycklar inte ger permanent åtkomst. Behöver du byta nätverksserver kan enheten återregistreras utan fabriksåterställning.

ABP (Activation By Personalization) hårdkodar sessionsnycklar och DevAddr direkt i enhetsminnet vid tillverkning. Det fungerar i helt slutna, kontrollerade miljöer där nätverksservern aldrig byts, men nackdelarna är konkreta: sessionsnycklar som NwkSKey och AppSKey är statiska under enhetens hela livslängd, och ett nätverksbyte kräver omprogrammering av varje enskild sensor. Välj OTAA från start och undvik det problemet helt.

De tre identifierarnas roll

Varje LoRaWAN-enhet identifieras av tre värden:

• DevEUI: ett globalt unikt 64-bitars enhets-ID, inbränt av tillverkaren, motsvarar ungefär ett MAC-adress
• AppEUI / JoinEUI: identifierar applikationsägaren och styr vilken applikationsserver som tar emot enhetens data
• AppKey: den symmetriska krypteringsnyckel som används för att härleda sessionsnycklar vid OTAA-join; ska aldrig delas i klartext eller skrivas synligt på enhetens utsida

Dessa tre värden finns normalt på ett datablad, en QR-kod eller i ett certifikat som medföljer sensorn vid leverans.

Praktisk onboarding steg för steg

1. Registrera DevEUI, AppEUI och AppKey i plattformen, till exempel Sensor-Online, under respektive enhets konfigurationsprofil.
2. Placera sensorn inom verifierad gateway-täckning och slå på den.
3. Kontrollera plattformens händelselogg: ett lyckat join-accept-meddelande ska synas inom 30 sekunder. Uteblir det är de vanligaste orsakerna en felaktig AppKey eller att sensorn befinner sig utanför gatewaytäckning.
4. Märk sensorn fysiskt med dess position och DevEUI direkt under onboarding. Det sparar betydande tid vid batteribyte och felsökning månader senare.

Sensordata som når plattformen behöver sedan avkodas från råbytes till läsbara värden, en process som hanteras av payload decoders och som hänger tätt samman med integration mot befintliga system. Det är precis vad nästa fas behandlar.

Fas 4: Plattformsintegration och dashboard-konfiguration

När sensorerna väl är onboardade och ansluter korrekt är nästa steg att göra deras data meningsfull i plattformen.

Anslutning till applikationslagret

Sensor-Online tar emot sensordata via MQTT, HTTP-webhooks eller direkt integration med din befintliga nätverksserver, oavsett om det är ChirpStack, TTN eller en privat installation. Det innebär att du inte behöver byta nätverksserver: du kopplar bara in applikationslagret ovanpå det du redan har. Se en översikt av Integrationsmöjligheter med Sensor-Online för att bättre förstå vilka protokoll och system som stöds.

Payload-avkodare per sensormodell

Rå LoRaWAN-data är bytes, inte värden. En temperaturavläsning kan se ut som 0x09C4 i ramverket tills en avkodare tolkar den till 25,0 °C. LoRa Alliance har standardiserat detta i Payload Codec API-specifikationen TS013-1.0.0, och Sensor-Online implementerar avkodare per sensormodell direkt i plattformen. Du anger sensortyp vid onboarding, och plattformen hanterar konverteringen till läsbara fysikaliska enheter som grader Celsius, relativ luftfuktighet eller Pascal.

Larmregler och notifieringar

Konfigurera larmregler direkt i dashboarden när avkodaren är på plats. Ett temperaturlarm som triggas vid avvikelse från ett normalvärde och skickar SMS eller e-post till ansvarig driftpersonal tar under fem minuter att sätta upp. Definiera tröskel, hystereskrav och notifieringskanal, sedan är larmet aktivt.

Logisk enhetshierarki

Organisera enheterna i strukturen fastighet, byggnad, våningsplan, rum. Förutom att ge en tydlig navigationsvy gör hierarkin det möjligt att delegera åtkomst precist: en drifttekniker för fastighet B ser bara sina enheter, inte hela systemet. Rollbaserad åtkomstkontroll på den nivån minskar risken för felkonfiguration och gör revisioner enklare.

Integration mot befintliga fastighetssystem

Om fastigheten redan har ett BMS kan Sensor-Online integreras via öppna API:er eller Modbus/MQTT-bryggor. Det eliminerar dubbel datainmatning och samlar energidata, larm och sensormätningar i en gemensam vy i stället för i separata system.

Verifieringsperiod på 48 timmar

Avsluta driftsättningen med en verifieringsperiod på minst 48 timmar. Kontrollera att varje sensor uppdateras i förväntad takt och att händelseloggen inte visar upprepade join-fel. Sporadiska avbrott som inte syns under en kortare testperiod brukar visa sig inom det tidsfönstret, vilket gör det möjligt att åtgärda täcknings- eller konfigurationsproblem innan systemet tas i normal drift.

Fas 5: Löpande drift, batteristatus och skalning

När dashboarden är konfigurerad och de första 48 timmarna av verifiering är godkända börjar det löpande driftskedet, och det är här långsiktig planering gör skillnad.

Batteritid och kontinuerlig övervakning

En typisk LoRaWAN-sensor har en batteritid på 2 till 10 år, men intervallet är brett av goda skäl. Sändintervall, spreading factor och omgivningstemperatur påverkar alla energiförbrukningen kraftigt. Mätningar visar att SF12 kan kräva upp till 20 gånger mer energi per sändning jämfört med SF7, vilket illustrerar varför parameterkonfigurationen inte är ett engångsbeslut. Övervaka batterinivån kontinuerligt i Sensor-Online så att ett batteri som försvagas inte tystnar tyst utan triggar en tidig varning.

ADR optimerar spreading factor automatiskt

Aktivera Adaptive Data Rate (ADR) i nätverksservern för alla stationära sensorer. ADR låter nätverksservern automatiskt justera spreading factor och sändeffekt baserat på aktuell länkkvalitet, vilket förlänger batteritiden utan manuell inblandning. För en trådlös rumsgivare som övervakar inomhusklimat innebär det att sensorn arbetar på lägsta möjliga energinivå givet sin position i byggnaden.

Kapacitetsplanering och duty cycle

En LoRaWAN-gateway klarar hundratals sensorer vid låg sändfrekvens, men duty-cycle-regelverket i EU868-bandet begränsar sändningstiden till 1 procent per timme i de flesta subband. Om du kortar mätintervallet från 15 minuter till 1 minut multiplicerar du nätverksbelastningen med 15. Gör kapacitetsanalysen innan du ändrar sändintervall i stor skala, inte efteråt.

Underhållsrutin

Schemalägg kvartalsvisa kontroller med tre fasta punkter:

• Uppdatera gateway-firmware och verifiera att säkerhetscertifikat för nätverksservern inte löper ut inom 90 dagar.
• Granska sensorer med lågt SNR i plattformen och åtgärda dessa med omplacering eller tilläggsgateway.
• Kontrollera att join-statistiken inte visar ökande felfrekvens, vilket kan indikera försämrad radiotäckning.

Skalning till fler fastigheter

När verksamheten växer läggs nya gateways och sensorer till i samma Sensor-Online-installation. Befintliga larmregler, hierarkier och integrationer följer med utan omkonfigurering, vilket gör att nästa fastighet driftsätts väsentligt snabbare än den första.

Vanliga fallgropar och hur du undviker dem

Även ett välplanerat nätverk kan spåra ur om ett fåtal vanliga misstag får passera obemärkta. Här är de sex fallgroparna som oftast dyker upp i praktiken, och hur du undviker dem.

Hoppar du över site survey riskerar du blinda fläckar från dag ett. Det vanligaste felet är att anta att en enda gateway täcker hela fastigheten. Armerad betong dämpar signalen med 15-25 dB, och källare, parkeringsgarage och hisschakt skapar zoner där sensorer aldrig ansluter. En enkel site survey med en temporär gateway och en referenssensor avslöjar dessa problem innan kablar dras och sensorer monteras.

ABP-aktivering är en kortsiktig genväg som skapar långsiktiga problem. Hårdkodade sessionsnycklar fungerar tills du behöver byta network server, och då måste varje enhet fabriksåterställas och onboardas på nytt. Välj OTAA från start; sensorn förhandlar fram nya sessionsnycklar automatiskt vid varje anslutning, och ett nätverksbyte kräver ingen omprogrammering av hårdvaran.

Duty-cycle-reglerna i EU868-bandet är inte valfria. Om mätintervallet sätts för tätt utan att lufttiden räknats in kan sensorer tystna periodvis under höglastsituationer. Varje subband tillåter sändning maximalt 1 % av timmen. Beräkna lufttiden för din payload och ditt spreading factor, och bygg in marginalen i intervallsättningen.

Utan ett centralt enhetsregister blir batteribyte ett detektivarbete. DevEUI och AppKey ska dokumenteras i ett register redan under onboarding, kopplat till fysisk position och installationsdatum. Månader senare, när ett batteri behöver bytas, är det skillnaden mellan en fem minuters uppgift och en timmes letande.

Larm som aldrig testats ger falsk trygghet. Konfigurera inte bara larmet, verifiera det. Simulera ett larmtillstånd under driftsättningsfasen och kontrollera att rätt person får rätt notifiering i rätt kanal, vare sig det är SMS, e-post eller en push-notis i plattformen. Det är också det rätta tillfället att testa att mätdata faktiskt kan omvandlas till åtgärdsbara insikter snarare än att bara synas i en dashboard.

BMS-integration tar längre tid än de flesta räknar med. Har fastigheten ett äldre fastighetssystem utan öppna API:er, räkna med minst en till två veckors extra tid för protokollmappning och testning. Inventera befintliga gränssnitt tidigt i projektet, och avsätt en dedikerad integrationsfas i projektplanen i stället för att behandla den som en efterhandsfråga.

ESP32 och LoRaWAN: När egenutvecklade noder passar in

Utöver standardsensorer finns situationer där ingen färdig produkt mäter exakt det du behöver. En ESP32 med integrerad LoRa-modul, till exempel TTGO LoRa32 eller Heltec WiFi LoRa 32, kan i sådana fall fungera som en enkel egenutvecklad end device. Typiska användningsfall är mätning av en proprietär analog signal, styrning av ett äldre relä eller sampling av en sensor med ovanligt elektriskt gränssnitt.

Prototyp kontra produktion

ESP32-baserade noder passar utmärkt för proof-of-concept och pilotprojekt, där flexibiliteten väger tyngre än certifieringskrav. I en produktionsmiljö gäller andra kriterier: certifierade sensorer har genomgått formell LoRaWAN-specifikationstestning enligt LoRa Alliances kravdokument, är CE-märkta och konstruerade för industriklassad driftsäkerhet under långa intervall utan tillsyn. En egenbyggd nod saknar dessa garantier om inte du genomför motsvarande testning själv.

Firmware och EU868-konfiguration

Firmware-biblioteket LMIC (LoRaMAC-in-C) gör OTAA-aktivering möjlig på ESP32 och hanterar LoRaWAN MAC-lagret. Konfigurationen kräver dock noggrannhet: EU868-kanalplanen måste definieras korrekt med standardkanalerna 868,1, 868,3 och 868,5 MHz, och spreading factor ska väljas i relation till faktisk länkkvalitet. ETSI EN300.220 begränsar sändningstiden till 1% duty cycle i de flesta EU868-subband, ett krav som LMIC respekterar om kanalplanen är rätt konfigurerad. Felaktig konfiguration kan ge intermittenta tappade paket som är svåra att felsöka i fält.

Integration med Sensor-Online

Sensor-Online kan ta emot data från egenutvecklade ESP32-noder precis som från certifierade sensorer. Förutsättningen är att payload-formatet är dokumenterat och att en avkodare konfigureras i plattformen för att översätta råbytes till fysikaliska värden. Inför det arbetet är det värt att läsa igenom hur du utvärderar en IoT-övervakningsplattform för att förstå vilka integrationskrav som påverkar valet av lösning på sikt.

Den verkliga kostnaden

För de flesta fastighetsövervakningsprojekt är en färdig LoRaWAN-tempsensor mer kostnadseffektiv totalt sett. Firmware-utveckling, felsökning av duty-cycle-avvikelser och långtidsunderhåll av egenbyggda noder summerar snabbt till fler timmar än prisskillnaden motiverar. Egenutvecklade noder är ett kraftfullt verktyg för rätt nisch, men standardsensorer förblir förstahandsvalet när behovet kan täckas av dem.

Från första täckningskartan till ett levande övervakningssystem

Oavsett om ni börjar med en enstaka byggnad eller ett helt fastighetsbestånd gäller samma princip: ett LoRaWAN-projekt lyckas när faserna genomförs i rätt ordning och inte parallellt.

De fem faserna hänger ihop som ett kedjereaktionsmönster. Täckningsanalysen avgör hur många gateways ni behöver och var de ska sitta. Gateway-placeringen bestämmer vilka sensorer som kan onboardas utan signal problem. Sensor-onboardingen ger plattformen de enheter den ska visualisera. Plattformsintegrationen omvandlar rådata till larm och dashboards. Den löpande driften fångar upp försämringar innan de påverkar verksamheten. Hoppar ni över ett steg tidigt, betalar ni för det sent.

Med rätt förberedelser är resan från nätverksplan till driftsatt sensor kortare och mer förutsägbar än de flesta räknar med. Ett strukturerat projekt med tydlig fas-sekvens eliminerar den omarbetning som annars uppstår när gateways måste flyttas, sensorer omregistreras eller larmregler byggs om från grunden.

Nästa praktiska steg: Boka en genomgång av er fastighetsplan med ett teknikteam som känner till både radioteknik och plattformsintegration. Målet för den första veckan är konkret: en gateway-karta baserad på er byggnadens planlösning och en lista med prioriterade mätpunkter. Det ger hela projektet en stabil grund att stå på.

Sensor-Online är Sveriges ledande leverantör av IoT-lösningar och har erfarenhet av driftsättningar i allt från enskilda kontorsbyggnader till komplexa flerfastighetsbestånd. Vi hjälper er med täckningsanalys, gateway-val och plattformsintegration anpassad till just er fastighet, oavsett var ni befinner er i projektet.

Kontakta oss på info@nodeledge.se eller ring +46(0)500 6000 22 så tar vårt teknikteam hand om detaljerna.

Conclusion

Ett framgångsrikt LoRaWAN-projekt i befintliga fastigheter bygger på ordning och disciplin: täckningsanalysen kommer först, gateway-placeringen följer, och sensorer onboardas först när nätverket är stabilt. Plattformsintegrationen omvandlar rådata till verklig insikt, och löpande drift säkerställer att systemet håller över tid. Hoppar du över ett steg tidigt, betalar du för det sent.

Med rätt fassekvens är vägen från nätverksplan till driftsatt sensor kortare än de flesta förväntar sig. Du får ett övervakningssystem som faktiskt levererar värde, dag ett och år tre.

Redo att ta första steget? Kontakta Sensor-Online på info@nodeledge.se eller ring +46(0)500 6000 22. Vårt teknikteam hjälper dig med täckningsanalys, gateway-val och plattformsintegration, anpassat till just din fastighet.

Frequently Asked Questions

Vad är den största skillnaden mellan OTAA och ABP-aktivering?

OTAA (Over-The-Air Activation) förhandlar fram unika sessionsnycklar vid varje anslutning, vilket gör systemet flexibelt och säkert. ABP (Activation By Personalization) hårdkodar sessionsnycklar direkt i enhetsminnet, vilket fungerar bara i helt slutna miljöer. Om du behöver byta nätverksserver med ABP måste varje sensor programmeras om, medan OTAA tillåter omregistrering utan fabriksåterställning. OTAA rekommenderas därför för praktiskt taget alla fastighetsinstallationer.

Hur mycket dämpning orsakar armerad betong för LoRaWAN-signaler?

Armerad betong dämpar LoRaWAN-signalen med 15-25 dB, vilket i praktiken innebär att du förlorar ungefär halva din länkbudget i varje våningsplan. Tjockt tegel dämpar med 10-15 dB, och metallbeklädd fasad eller installationsgolv kan stänga ute signalen nästan helt. Denna dämpning är normen i svenska flervåningsfastigheter och måste tas med i planeringen från början.

Varför är en site survey så viktig innan man köper gateways?

En site survey avslöjar faktiska radiotäckningsproblem innan du köper hårdvara och gör permanenta installationer. Genom att placera en temporär gateway och mäta RSSI och SNR i olika zoner kan du kartlägga blinda fläckar som källare, parkeringsgarage och hisschakt. Utan site survey riskerar du att installera gateways på fel platser och få systemet som inte täcker de områden du behöver.

Vad är spreading factor och hur påverkar det batterilivslängden?

Spreading factor (SF) styr avvägningen mellan räckvidd och överföringshastighet. SF7 ger snabb överföring och kort lufttid, medan SF12 når längre men ökar lufttiden dramatiskt. Mätningar visar att SF12 kan kräva upp till 20 gånger mer energi per sändning jämfört med SF7, vilket påverkar batterilivslängden kraftigt. Adaptive Data Rate (ADR) kan justera spreading factor automatiskt för att optimera energiförbrukningen.

Vilka är de fem kärnkomponenterna i en LoRaWAN-arkitektur?

LoRaWAN bygger på fem kärnkomponenter: End devices (batteridrivna sensorer), Gateways (transparenta radiobroar), Network Server (hanterar deduplikering och adaptiv datahastighet), Application Server (behandlar avkodad data), och Join Server (hanterar registrering och aktivering). Varje lager har ett avgränsat ansvar, och att förstå dessa är essentiellt för att fatta rätt beslut om täckning, gateway-placering och onboarding.