Lektion 1.1 Lägga till LoRaWAN-enheter
Att lägga till iotnodes i Yggio är grunden. Det finns tre huvudtyper av iotnodes:
- Devices: Representerar en fysisk enhet, normalt en sensor eller en aktuator.
- Virtual Node: En logisk nod som används i dataflödet för att hålla någon typ av tillstånd eller indirekt representera en fysisk enhet - till exempel en geofence, en WiFi-beacon, en beräknad nod eller en simulerad enhet.
- Services: Data som kommer från externa tjänster som OpenWeatherMap eller Nordpool (elprisdata).
Lägg till en LoRaWAN-enhet
LoRaWAN är den vanligaste enhetstypen som används i moderna långdistans-IoT-nätverk, här är hur du lägger till en i IoT-plattformen.
- Gå till Devices och tryck på "New Device".
- Välj Single Mode.
- Välj LoRaWAN som enhetstyp och fortsätt.


-
Välj en Connector. Vilka fält som finns tillgängliga kan variera beroende på connector. Du bör använda OTAA - Over the air activation 99 % av gångerna.
- Device Profile bör helst matcha din sensors LoRaWAN-nätverksversion, vanligtvis LoRaWAN version 1.0.4 plus regionala parametrar. Om inte kan det uppstå anslutnings- eller join-problem.
- DevEUI är ditt enhets-ID.
- AppKey är din krypteringsnyckel.
Du får LoRaWAN-versionen, DevEUI och AppKey från enhetstillverkaren. Fortsätt när du är klar.
Beroende på vilken connector som används kommer IoT-plattformen automatiskt att provisionera den nya enheten till LoRaWAN-servern. Detta förenklar användarupplevelsen, eftersom det inte behövs att manuellt lägga till enheten i LoRaWAN-servern också. Denna automatiska provisionering stöds för:
- ChirpStack v3
- ChirpStack v4
- Actility / Netmore ThingPark
- Netmore
- TTN - The Things Network
För Actility och Netmore är det också möjligt att importera de enheter som connectorn har åtkomst till. För detaljer om det, se Connectors
Om du behöver lägga till många enheter, prova batchinstallation med hjälp av en CSV-fil.
-
För Device Model Name, välj vilken typ av sensor du har, detta används för att sätta rätt avkodningsöversättare.
-
På nästa skärm läggs en översättare till automatiskt. Normalt behöver du inte ändra detta. Du kan lägga till fler översättare här, eller senare genom att välja enheten i listan Devices och klicka på Translators, eller genom att använda funktionen Select Many.

-
Ange ytterligare detaljer:
- Name
- Description (valfritt)
- Icon (valfritt)
- Pictures (valfritt) - om du använder en telefon kan du ta ett foto direkt
- Contextual parameters (valfritt)
-
Konfigurera enheten
Efter att en enhet har lagts till kan den behöva konfigureras för att rapportera data med önskat tidsintervall.
För LoRaWAN-enheter kan detta göras direkt genom att navigera till LoRaWAN Control och skicka en konfigurations-downlink. Alternativt kan flera enheter konfigureras samtidigt med Select Many → Configure.
Den specifika konfigurations-downlinken beror på enheten och måste hämtas från tillverkarens dokumentation. Till exempel, för en Sensative Strip kan du använda verktyget Strips Configuration för att snabbt definiera enhetens beteende och generera en downlink-payload.
- Lägg till övervakning och larm
Det är ofta användbart att lägga till en larmöversättare. Denna logik övervakar inkommande data för tröskelvärdesbrott och kan variera från enkla kontroller till avancerade övervakningsregler.
För mer detaljer, se Lektion 1-3 Larmvyer. Du kan också konfigurera larm för flera enheter samtidigt via Select Many → Edit Translators.
- Ta bort enheter
Viktigt:
Om en Actility / Netmore ThingPark-, ChirpStack- eller Netmore-LoRaWAN-enhet raderas från Yggio kommer den som standard även att raderas och avvecklas från LoRaWAN-servern. För att undvika detta, se till att välja bort raderingsåtgärden när du blir tillfrågad i bekräftelsedialogen.

För att ta bort en enhet, hitta den i enhetslistan och klicka på den. På fliken General, klicka på Delete. I bekräftelsepopupen, bekräfta raderingen. Om du vill behålla enheten i LoRaWAN-servern, avmarkera rutan Delete external.
För att ta bort flera enheter, använd Select Many, markera enheterna som ska tas bort, Select Action -> Delete. Bekräfta i popupen att du vill radera enheterna, om du vill behålla enheterna i LoRaWAN-servern, avmarkera rutan Delete external.
- Fråga
- Svar
Vad är LoRaWAN Dev EUI?
DevEUI är det unika ID som identifierar en specifik LoRaWAN-enhet på nätverket.
En mer detaljerad förklaring är följande: DevEUI (Device EUI) är en globalt unik 64-bitars identifierare som tilldelas varje LoRaWAN-enhet. Den fungerar som ett serienummer på nätverksnivå och säkerställer att varje enhet kan identifieras unikt i ett LoRaWAN-nätverk.
- Tilldelas av tillverkaren (baserat på IEEE EUI-64-adressutrymmet)
- Kan inte ändras av användaren
- Krävs för enhetsaktivering (OTAA eller ABP)
Exempel:
70-B3-D5-7E-F0-00-AB-12
- Fråga
- Svar
Vad är LoRaWAN App Key?
AppKey (Application Key) är en 128-bitars hemlig nyckel som används i LoRaWAN för att säkert autentisera och kryptera kommunikationen mellan en enhet och nätverksservern. Den spelar en avgörande roll under OTAA (Over-The-Air Activation) genom att härleda sessionsnycklar som skyddar dataintegriteten och konfidentialiteten.
- 128-bitars (16-byte) kryptografisk nyckel
- Känd endast av enheten och nätverksservern
- Används för att generera sessionsnycklar under OTAA
- Måste alltid hållas hemlig och aldrig delas offentligt
Exempel:
2B7E151628AED2A6ABF7158809CF4F3C
- Fråga
- Svar
Vad är LoRaWAN Join/App Eui-nyckeln?
JoinEUI (tidigare kallad AppEUI) är en 64-bitars identifierare som anger vilken Join Server som ansvarar för att hantera en enhets aktivering. Under OTAA (Over-The-Air Activation) talar JoinEUI om för nätverksservern vart join-förfrågan ska vidarebefordras så att sessionsnycklar kan härledas säkert.
- 64-bitars identifierare
- Sätts av enhetstillverkaren eller nätverksoperatören
- Pekar på den Join Server som används under aktiveringen
- Krävs för OTAA i vanliga LoRaWAN-installationer
Alla LoRaWAN-nätverk implementerar inte en separat Join Server. Vissa, som ChirpStack, håller join-proceduren och nyckelhanteringen helt inom själva nätverksservern. I dessa fall ignoreras JoinEUI/AppEUI, eftersom det inte finns något behov av att dirigera join-förfrågningar till en extern Join Server. Istället hanterar servern autentisering och härledning av sessionsnycklar direkt.
Exempel:
70-B3-D5-7E-F0-00-00-01
- Fråga
- Svar
Kan en LoRaWAN-gateway se innehållet i ett meddelande?
Nej - en LoRaWAN-gateway kan inte se innehållet i ett meddelande. En gateway fungerar bara som en transparent brygga mellan slutenheter och nätverksservern. Den tar helt enkelt emot LoRa-radiosignaler, omvandlar dem till IP-paket och vidarebefordrar dem till nätverksservern.
-
Totalsträckekryptering: Enhetsmeddelanden krypteras på applikationslagret med hjälp av sessionsnycklar (härledda från AppKey). Endast nätverksservern (och applikationsservern, beroende på nyckelseparation) kan dekryptera dem.
-
Gatewayens roll: Gatewayen vidarebefordrar bara paket. Den har inte åtkomst till krypteringsnycklarna och kan därför inte tolka payloaden.
Kort sagt: en gateway ser bara metadata (signalstyrka, frekvens, tidsstämpel etc.) men inte det faktiska meddelandeinnehållet.
- Fråga
- Svar
Vad är skillnaden, för- och nackdelarna med OTAA jämfört med ABP?
LoRaWAN definierar två huvudsakliga metoder för enhetsaktivering: OTAA (Over-The-Air Activation) och ABP (Activation By Personalization). Båda avgör hur en enhet ansluter till nätverket och får sina sessionsnycklar.
OTAA (Over-The-Air Activation) - Dynamisk och säker aktiveringsmetod
- Enheten skickar en join request (med DevEUI, JoinEUI etc.) till nätverket
- Nätverket svarar med en join accept och sessionsnycklar härleds med hjälp av AppKey
- Sessionsnycklarna är unika och kan ändras vid varje join
- Mer säker och rekommenderas för produktion
Fördelar:
- Starkare säkerhet (nya sessionsnycklar vid varje join)
- Enklare enhetshantering över flera nätverk
- Stödjer roaming och omnyckling
Nackdelar:
- Kräver join-procedur (något längre uppsättningstid)
- Enheten måste vara inom räckhåll för ett nätverk för att slutföra join
ABP (Activation By Personalization) - Statisk och förkonfigurerad aktiveringsmetod
- Sessionsnycklar (AppSKey, NwkSKey) och DevAddr sätts manuellt i enheten
- Ingen join request/response utförs
- Enheten kan börja sända omedelbart
Fördelar:
- Enklare och snabbare (ingen join behövs)
- Fungerar även om enheten inte kan nå nätverket för en join
Nackdelar:
- Sessionsnycklarna ändras aldrig (svagare säkerhet)
- Svårare att hantera enheter i stor skala
- Inget stöd för roaming
- Mer sårbar om nycklar läcker ut
Sammanfattning:
- Använd OTAA när det är möjligt för säkerhet och flexibilitet
- Använd ABP endast i särskilda fall (t.ex. mycket begränsade enheter, testuppsättningar)
- Fråga
- Svar
Vad är LoRaWAN Device Profile och regionala parametrar?
Device Profile En device profile definierar funktionerna och konfigurationen för en LoRaWAN-slutenhet i ett nätverk. Den säkerställer att nätverksservern vet hur enheten kommunicerar och vilka funktioner den stödjer.
En device profile innehåller normalt:
- LoRaWAN-version (t.ex. 1.0.3, 1.1.0)
- Revision av regionala parametrar (t.ex. RP002-1.0.3)
- Maximal EIRP (sändningseffektgränser)
- Stöd för Class-B / Class-C (enhetens driftlägen)
- Maximal meddelandestorlek (per datahastighet)
Denna profil gör att nätverksservern korrekt kan tolka enhetens beteende och tillämpa rätt inställningar.
Regionala parametrar LoRaWAN opererar i olika frekvensband beroende på region (EU868, US915, AS923 etc.). De regionala parametrarna definierar hur LoRaWAN-protokollet anpassas för varje regulatorisk domän.
De specificerar saker som:
- Frekvensplaner (upplänks- och nedlänkskanaler)
- Datahastigheter (spridningsfaktorer)
- Maximal sändningseffekt
- Gränser för duty cycle eller dwell time
- Kanalmaskinställningar (för regioner som US915 eller AU915)
Varje enhet måste följa de korrekta regionala parametrarna för att vara förenlig med lokala radioregleringar och säkerställa interoperabilitet.
Kort sagt:
- Device Profile definierar vad enheten kan göra.
- Regionala parametrar definierar hur enheten måste fungera i sin specifika frekvensregion.
- Fråga
- Svar
Vad händer om man använder en liten felmatchning av LoRaWAN Device Profile och regionala parametrar för en enhet?
Effekter av felaktig Device Profile eller regionala parametrar (liten felmatchning)
Om device profile eller de regionala parametrarna är något felaktiga (till exempel region A istället för B):
- OTAA-join-förfrågningar kan misslyckas eller lyckas intermittent.
- Vissa upplänks- eller nedlänksmeddelanden kan gå förlorade.
- Kommunikationen blir överlag opålitlig, även om enheten kommer att verka fungera mesta tiden.