Lektion 2.3 Iotnodes och nätverksprotokoll - Från NB-IoT till BLE

LoRaWAN är den vanligaste enhetstypen som används i moderna långdistans-IoT-nätverk. Vi gick igenom hur man lägger till och hanterar dem i Lektion 1.1: Lägga till LoRaWAN-enheter.

I denna lektion utforskar vi hur man lägger till olika typer av enheter i systemet, kategoriserade efter det transportprotokoll de använder. De flesta av dessa läggs till via enhetstypen Generic. Vi belyser också de underliggande fysiska eller nätverkstekniska lagren som vanligtvis förknippas med varje protokoll, för att hjälpa dig förstå vilka enheter som kommunicerar via MQTT, HTTP, TCP, UDP, CoAP och andra vanliga gränssnitt.

IoT-stacken - nätverksteknik

Vanliga fysiska protokoll och deras transportprotokoll

Tabellen nedan mappar de fysiska/nätverksprotokollen till de transportprotokoll de vanligtvis använder.

Fysiskt/nätverksprotokoll	Typiskt transportprotokoll	Exempel på enheter
NB-IoT	MQTT, CoAP, UDP	Smarta mätare, tillgångsspårare, miljösensorer
LTE Cat-M1 (Cat-M)	MQTT, CoAP, UDP	Wearables, fordonsspårare, industrisensorer
LoRaWAN	MQTT	Gateways, miljösensorer, smarta mätare
WiFi	HTTP, MQTT, TCP	Smarta hemenheter, kameror, smarta uttag, termostater
Ethernet	HTTP, MQTT, TCP	Industriella styrenheter, PLC:er, gateways
BLE / Bluetooth	Gateway till MQTT/HTTP/CoAP	Wearables, beacons, smarta lås, medicinska enheter
Zigbee, Zwave, Matter	Gateway till MQTT	Hemautomation
CoAP	UDP, CoAP	Resursbegränsade sensorer och aktuatorer, smarta mätare, smarta byggnadsenheter
Rå TCP	TCP	Industriella enheter, gateways, kameror, anpassade IoT-enheter

Vissa enheter använder lättviktiga eller resursbegränsade protokoll som CoAP över UDP eller BLE, som ofta kräver en gateway för att översätta deras meddelanden till MQTT, HTTP eller TCP för integration med plattformen. Detta säkerställer att även enheter med låg effekt eller kort räckvidd kan kommunicera tillförlitligt med molnsystem eller andra nätverksanslutna tjänster.

På liknande sätt implementeras protokoll som LwM2M - Lightweight Machine-to-Machine vanligtvis på NB-IoT- eller Cat-M1-enheter och använder CoAP över UDP för kommunikation, vilket ofta kräver en LwM2M-server för att hantera enhetsregistrering, datarapportering och fjärrhantering. IoT-plattformen inkluderar en LWM2M-server men är för närvarande endast tillgänglig på särskild begäran.

Horisontell IoT-integration

The platform - Horizontal IoT integration
↑
├─ LwM2M (Device Management & Telemetry)
↑
Application Protocols
├─ HTTP (REST API)
├─ MQTT (Pub/Sub)
├─ CoAP (REST for resource-constrained devices)
Transport
├─ TCP ← HTTP, MQTT, Raw TCP, LwM2M (over TCP)
└─ UDP ← CoAP, raw UDP, LwM2M (over UDP/CoAP)
Network
└─ IP Internet Protocol, responsible for addressing and routing data packets regardless of medium
Link / Physical medium
├─ Ethernet
├─ Wi-Fi
├─ LTE/NB-IoT/LTE-M/5G
├─ LoRaWAN
└─ Bluetooth / BLE / Z-Wave / ZigBee

Diagrammet ovan illustrerar den horisontella integrationen av IoT-enheter i IoT-plattformen.

• Applikationsprotokoll som HTTP, MQTT och CoAP används av enheter för att kommunicera med plattformen, beroende på deras kapacitet och begränsningar.
• Transportprotokoll (TCP eller UDP) bär dessa meddelanden över nätverket, där TCP används för pålitliga anslutningar (HTTP, MQTT, LwM2M) och UDP för lättviktiga eller resursbegränsade protokoll (CoAP, rå UDP, LwM2M över UDP).
• Nätverkslagret (IP) hanterar adressering och routing, vilket säkerställer att data når rätt destination oavsett underliggande fysiskt medium.
• Länk-/fysiska lagret-teknologier inkluderar Ethernet, WiFi, LTE/NB-IoT/LTE-M/5G, LoRaWAN, samt kortdistansprotokoll som Bluetooth/BLE, Z-Wave eller ZigBee.

Denna struktur visar hur plattformen stödjer ett brett spektrum av enheter och protokoll, vilket möjliggör sömlös integration över heterogena IoT-nätverk.

Generisk nod

Det finns två huvudsakliga kategorier av connectors som krävs för att lägga till enheter baserade på ovanstående protokoll i plattformen:

• Enheter som använder en global generisk connector
• Enheter som kräver en specifik connector

Enheter som kräver en generisk connector kan endast läggas till om du har åtkomst till den connectorn - antingen tillhandahållen under lektionen eller skapad av dig. Att sätta upp specifika enhetsconnectors kräver åtkomst till motsvarande enhet eller fjärrsystem för korrekt konfiguration. För mer information, se Lektion 2.8: Connectors.

Enhetstypen Generic är den mest flexibla enhetstypen i Yggio, kapabel att ta emot data via olika typer av protokoll. Den möjliggör integration av vilken enhet som helst som kan sända data via transportprotokoll som HTTP (inkl. REST API), MQTT, CoAP, UDP eller rå TCP och som kan identifieras med en unik identifierare. Exempel inkluderar NB-IoT-enheter, Cat-M-enheter, BLE, WiFi-enheter, TCP/IP-enheter (som kameror eller gateways), eller olika webbtjänster som skickar data till Yggio.

Enhetstypen Generic används också för att skapa virtuella noder, som kan fyllas med data från översättare eller Flows. Det är en mycket mångsidig integration.

Identifierare som stöds

Varje generisk enhet identifieras med ett unikt ID, som kan baseras på flera identifierare som stöds:

Identifierarens namn	Beskrivning
secret	En sträng mellan 8 och 128 tecken, som endast innehåller A-Z, 0-9, -, ., _
imei	International Mobile Equipment Identity, 15-siffrigt nummer
tag	Valfri sträng
serialNumber	Valfri sträng
sensorId	Valfri sträng

Steg för att lägga till en generisk enhetstyp

Skapa enhetsnoden via enhetslistan (eller via API:et, följ Lägga till enheter i Yggio):

1. Navigera till Devices i den övre panelen.
2. Klicka på New Device i det övre högra hörnet.
3. Välj Single Mode.
4. Välj Generic i rullgardinsmenyn och klicka på Continue.
5. Ange den unika secreten för enheten och klicka på Continue.
6. (Valfritt) Tilldela ett device model name, klicka sedan på Continue eller Skip.
7. (Valfritt) Lägg till en översättare genom att klicka på +Add Translator, eller Skip.
8. Ange ett enhetsnamn och (valfritt) beskrivning, plats eller kontextuella parametrar, klicka sedan på Add Device.

Observera: Om du vill använda en annan identifierare än "secret" måste du för närvarande använda Swagger och utföra en PUT /iotnodes-förfrågan på noden efter att den skapats.

HTTP-generiska noder

Låt oss börja lektionen med att lägga till en standardgenerisk nod med secret som identifierare. Observera att denna secret fungerar som en API-nyckel och måste hållas konfidentiell. Data i en HTTP-nod kan uppdateras med hjälp av en HTTP POST-förfrågan - antingen från en IoT-enhet, ett externt datasystem eller direkt via verktyg som curl, Postman, Node-RED, eller någon liknande applikation som kan skicka HTTP POST-förfrågningar.

curl -sS https://beta.yggio.net/http-push/generic?identifier=secret \
-H 'content-type: application/json' \
-d @- <<EOF
{
  "secret": "SUPERSECRETAPIKEY",
  "temperature": 22,
  "data": "any",
  "informationArray": [1, 2, 3],
  "anObject": {
    "nestedValue": "is allowed"
  }
}

MQTT-generiska noder

MQTT-noder används vanligen för att ta emot data från olika typer av enheter och system. Processen för att skapa MQTT-noder är enkel men kräver viss förtrogenhet med Swagger API-gränssnittet. Logga in på Swagger med ditt användarnamn och lösenord, eller använd en token från gränssnittet.

Steg för att skapa en MQTT-nod

1. Skapa en Basic Credential Set Använd Swagger-gränssnittets endpoint för att skapa en ny Basic Credential Set. Denna kommer att användas som autentiseringsuppgifter för att prenumerera på MQTT-data.

2. Skapa ett Reserved MQTT Topic Använd Swagger-gränssnittets endpoint för att skapa ett Reserved MQTT Topic. Detta är det topic som fjärrenheten eller systemet ska publicera data på. Viktigt: Topicet måste börja med yggio/generic/v2/.

3. Konfigurera fjärrsystemet Ställ in följande parametrar på fjärrenheten eller systemet:

   • URL: mqtt.beta.yggio.net
   • Port: 8883
   • Autentiseringsuppgifter: Använd din Basic Credential Set
   • Topic: Ditt reserverade MQTT-topic
   • Version: 3.11 eller 5.0

När data börjar publiceras skapas en ny MQTT-enhet automatiskt med namnet: MQTT-[Ditt reserverade MQTT-topic].

Följ stegen ovan för att skapa en MQTT-nod, använd sedan ett verktyg som MQTT Explorer eller Node-RED för att publicera testdata och verifiera att det fungerar korrekt.

Observera

• Du behöver inte reservera undertopics under ditt huvudtopic.
• Om du publicerar till undertopics kommer de automatiskt att publiceras som ett objekt på din huvudnod.
• Du kan använda AdditionalDeviceUpdate i en översättare för att propagera data till andra noder.
• Denna teknik används vanligen när din huvudsakliga MQTT-topic-enhet fungerar som en gateway.

CoAP-generiska noder

CoAP-protokollet använder UDP som transportlager istället för TCP som HTTP och MQTT, vilket gör det lättviktigt och väl lämpat för resursbegränsade IoT-enheter. Till skillnad från TCP etablerar UDP inte bestående anslutningar, så CoAP implementerar sina egna mekanismer för meddelandetillförlitlighet, kvitteringar och omsändningar.

För CoAP-noder krävs en CoAP-connector. Varje plattformsserver bör inkludera en generisk CoAP-connector som standard. Om du inte har åtkomst till en, kontakta din tekniska supportrepresentant för att begära en.

När åtkomst har beviljats, skapa en generisk nod och använd prefixet generic_coap_ för din secret (se Node-RED-exemplet nedan). När du skickar data från en IoT-enhet, skicka en POST-förfrågan till: coap://beta.yggio.net:5683/in/generic, inkludera secret och dess värde i JSON-body:n. CoAP-integrationen skiljer mellan data in och out, så URL:en måste inkludera /in/generic/.

1. Fortsätt lektionen genom att skapa en CoAP-enhet. Säkerställ först att du har åtkomst till en generisk CoAP-connector, skapa sedan en motsvarande generisk nod med en secret.

2. Skicka sedan data till noden med antingen en CoAP-kapabel enhet eller ett lämpligt verktyg som kan generera CoAP-förfrågningar.

Observera: Olika tillverkare implementerar CoAP-meddelandeformat på olika sätt. Om din enhets CoAP-meddelande inte kan anpassas till den generiska integrationen kan en specifik integration behövas. Kontakta i så fall ditt tekniska supportteam för att fastställa omfattningen av arbetet som krävs.

Säkerhet:

1. CoAP-meddelanden bör skyddas med DTLS. Certifikat måste installeras både på enheten och på plattformen. Om ett certifikat krävs måste en ny CoAP-connector som inkluderar det skapas.
2. Plattformen stödjer också OSCORE (Object Security for Constrained RESTful Environments), som ger totalsträckesäkerhet på meddelandenivå för CoAP. OSCORE är inte aktiverat som standard-om du behöver det, kontakta ditt tekniska supportteam för att diskutera aktivering och konfiguration.

För mer information om DTLS-certifikat, se avsnittet nedan.

UDP-generiska noder

Dessa noder använder UDP-protokollet direkt. För närvarande är den enda tillgängliga UDP-integrationen för IM Buildings NB-IoT-enheter, eftersom det för närvarande inte finns någon generisk UDP-integration. IM Buildings-enheter använder ett tillverkarspecifikt protokoll för att koda överförd data. Integrationen avkodar payloaden, extraherar sensor-ID:t och dirigerar datan till motsvarande enhet i plattformen.

Så här skapar du en IM Buildings NB-IoT-enhet:

1. Säkerställ att en IM Buildings UDP-connector är tillgänglig på din plattform.
2. Skapa en generisk nod och tilldela ett godtyckligt slumpmässigt värde som dess secret.
3. Lägg till IM Buildings-översättaren
4. Kopiera _id för den nyligen skapade enheten.
5. Öppna Swagger-gränssnittet, navigera till PUT /iotnode/{_id}, och lägg till ett fält med namnet sensorId som matchar din IM Buildings-enhet.
6. Aktivera din IM Buildings-enhet - den kommer nu att börja skicka UDP-data till plattformen.

Additional Device Update

Additional Device Update är när en nod delar data med en annan nod. Denna funktion används vanligen i följande scenarier:

• Avancerade dataflöden: Data rör sig mellan noder i olika konfigurationer (många-till-en, en-till-många eller många-till-många), där varje nod bidrar med en del av bearbetningslogiken. Ett vanligt exempel på detta är beräkning av KPI:er (Key Performance Indicators).

• Kontrollerad dataåtkomst: Inkommande data separeras i flera noder för att hantera åtkomsträttigheter. Detta är nödvändigt när olika delar av datan har olika klassificeringsnivåer. Till exempel kan nätverksanslutning vara relevant för nätverksadministratörer, medan mätvärden endast bör vara synliga för behörig personal.

Virtuella noder

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.

Bilden ovan illustrerar geofence-referensnoder, där tillgångar som går in i och lämnar geofences spåras av översättaren general-geofence.

Säkerhet och certifikat

TLS/SSL-certifikat för MQTT- och HTTP-anslutningar

När plattformen kommunicerar med andra system (som MQTT-brokrar, REST-API:er eller IoT-servrar) via TLS/SSL måste den kunna verifiera och lita på de certifikat som dessa servrar presenterar. I de flesta fall använder servrar certifikat signerade av en publik certifikatutfärdare (CA), som automatiskt litas på. Men när den andra servern använder ett privat eller självsignerat certifikat (t.ex. bakom en brandvägg eller i ett slutet företagsnätverk) krävs ytterligare konfiguration.

Viktiga överväganden för privata certifikat

1. Lita på certifikatet

   • Plattformen måste kunna lita på certifikatet som presenteras av den externa servern. Detta görs vanligtvis genom att lägga till serverns certifikat eller den CA som utfärdade det till plattformens betrodda certifikat.

2. Matchning av servernamn (CN och SAN)

   • Certifikatet måste innehålla korrekt Common Name (CN) eller Subject Alternative Name (SAN) som matchar serverns värdnamn eller IP-adress.
   • CN är den primära identifieraren för servern, medan SAN gör det möjligt att inkludera flera värdnamn eller IP-adresser.
   • Om värdnamnet som plattformen använder för att ansluta inte matchar antingen CN eller någon av SAN-posterna kommer TLS-handskakningen att misslyckas.

3. Ömsesidig TLS (mTLS)

   • Om den externa servern kräver ömsesidig autentisering måste plattformen presentera sitt eget certifikat utöver att lita på servern.
   • Detta säkerställer att båda sidor verifierar varandra innan data utbyts.

4. Certifikatets utgång och förnyelse

   • Privata certifikat har ofta kortare livslängd. Det är viktigt att övervaka utgångsdatum och förnya certifikat i tid för att förhindra kommunikationsavbrott.

5. Testa anslutningen

   • Efter att ha installerat eller litat på ett certifikat, verifiera att plattformen framgångsrikt kan etablera en säker anslutning till servern.

6. Testa säker anslutning

   • För MQTT:

     mosquitto_sub --cafile private-ca.crt -h your.mqtt.server -p 8883 -t test/topic -v

   • För HTTPS:

     curl --cacert private-ca.crt https://your.private.api/health

DTLS-certifikat för CoAP- och UDP-anslutningar

CoAP använder DTLS (Datagram Transport Layer Security) över UDP för att skydda kommunikationen mellan IoT-enheter och plattformen. DTLS ger kryptering, integritet och autentisering - liknande TLS som används i HTTPS - men optimerat för lättviktig, opålitlig transport som UDP. DTLS stödjer flera autentiseringsmetoder:

• X.509-certifikat (vanligast och säkrast)
• Fördelade nycklar (PSK)
• Rå publika nycklar (RPK)

Vid användning av X.509-certifikat måste både CoAP-enheten och plattformen ha matchande och betrodda certifikat installerade.

🔧 Installationsanteckningar

1. Certifikatformat

   • Använd certifikat i PEM- eller DER-format (.pem, .crt eller .der).
   • Säkerställ att certifikatkedjan (enhet, mellanliggande och root-CA) är korrekt konfigurerad om tillämpligt.

2. Skydd av privat nyckel

   • Den privata nyckeln som hör till certifikatet får aldrig delas eller exponeras.
   • Lagra den säkert på enheten (t.ex. i ett secure element eller krypterad lagring).

3. Certifikatmatchning

   • Fältet Common Name (CN) eller Subject Alternative Name (SAN) i certifikatet bör matcha det enhets-ID eller domän som plattformen förväntar sig.
   • Felmatchade identifierare kan orsaka fel i DTLS-handskakningen.

4. Installation på plattformen

   • Importera CA-certifikatet (eller enhetscertifikatet, om självsignerat) till plattformens CoAP-connector-konfiguration.
   • Vissa plattformar kräver att du startar om connectorn efter att nya certifikat har lagts till.

5. Certifikatets utgång och förnyelse

   • Övervaka certifikatets utgångsdatum och etablera en automatisk förnyelse- eller uppdateringsprocess för att förhindra driftstopp.

6. Testning och verifiering

   • Efter installationen, verifiera anslutningen med DTLS-testverktyg (t.ex. coap-client med --dtls-alternativ).
   • Kontrollera loggar för lyckad handskakning och bekräfta krypterad trafik.

coap-client -m get coaps://SERVER_HOST:5684/RESOURCE \
  --cert client-cert.pem \
  --key client-key.pem \
  --cacert ca-cert.pem

--cert → klientcertifikat (om ömsesidig TLS krävs) --key → motsvarande privat nyckel --cacert → CA-certifikat som används för att verifiera servern

Indikator på framgång:

• Verify return code: 0 (ok)
• DTLS-handskakningen slutförs framgångsrikt
• Meddelanden kan utbytas säkert över UDP

Vanliga problem

1. CN/SAN-felmatchning → DTLS-handskakningen misslyckas om certifikatet inte matchar serverns värdnamn eller IP-adress.
2. Obetrodd CA → DTLS-handskakningen misslyckas om servercertifikatet inte är signerat av en betrodd CA.
3. Utgånget certifikat → DTLS-handskakningen misslyckas.
4. UDP-brandväggar → Se till att DTLS-porten (vanligtvis 5683/5684 för CoAPS) är öppen.

Sammanfattning

När en server eller enhet använder privata eller självsignerade certifikat måste plattformen konfigureras för att lita på dessa certifikat för att upprätthålla säker kommunikation. Certifikat måste ha korrekt CN eller SAN som matchar serverns värdnamn, och korrekt certifikathantering-inklusive ömsesidig TLS om det krävs och tidig förnyelse-är avgörande för tillförlitlig och säker drift.

• Använd en DTLS-aktiverad CoAP-klient eller OpenSSL för att testa anslutningar.
• Tillhandahåll korrekt CA- och klientcertifikat.
• Verifiera att handskakningen lyckas och att certifikaten valideras korrekt.
• Kontrollera loggar för CN/SAN-validering och eventuella handskakningsfel.