Grunderna inom IoT

Här hittar du svar på de vanligaste frågorna om Stadshubben. Vi förstår att man kan ha många frågor när det gäller att använda våra tjänster, delta i aktiviteter eller förstå hur allt fungerar i denna dynamiska miljö.

LoRaWAN arkitektur

Stadshuben är i detta sammanhang applikationsservern.

Att välja en sensor

Vi föreslår först och främst Elsys, eftersom de erbjuder hög kvalitet, utmärkt support och bra dokumentation, samt att de är baserade i Sverige. Om man inte kan hitta en Elsys-produkt som uppfyller sina mål är det viktigt att istället välja en produkt med följande egenskaper: hög kvalitet, implementera standardsäkerhet, välstrukturerad dokumentation, bra kundsupport och låg batteriförbrukning.

Att lägga till en nod i Stadshubben

Efter att du har lagt till en nod i Stadshubben, kontrollera Logs för noden i Stadshubben för att se till att statusen är ”Joined” och grön. Därefter kan du aktivera sensorn. När statusen är Joined, granska Messages för noden i Stadshubben för att se om det finns meddelanden där. Ibland skickar sensorn initiala meddelanden som en bekräftelse och de kommer inte att visualiseras i gränssnittet för att de inte innehåller någon data. Sådana meddelanden är endast för att meddela nätverket att den har anslutit framgångsrikt. Efter dessa meddelanden bör data börja strömma in och visualiseras i gränssnittet. Däremot, om du inte får någon data efter en timma kan det bero på flera saker: antingen har du angivit felaktiga nycklar, ingen bra täckning, sensorn har inte aktiverats korrekt, eller det kan finnas ett hårdvarufel. I sådana fall kommer vidare felsökning att vara nödvändig.

Logs

För varje sensor finns det en logg som kallas Logs, där användare kan navigera till den för att se status för operationer för att se om de var framgångsrika, misslyckade eller stötte på problem.

Messages

I Messages kan användare se de obearbetade meddelanden som skickats från enheten till nätverksservern och slutligen till Stadshuben. Dessa meddelanden är i sin råa form och har inte behandlats. De bearbetade versionerna av dessa meddelanden visas i användargränssnittet.

Node Menu

Nodes visar listan över noder, till höger om varje nod finns det en meny med tre punkter som ger flera alternativ:

Categories tillåter klassificering av noder, vilket förenklar processen med snabb filtrering. Det betyder att man kan ange vilken grupp en nod tillhör. Detta kräver dock att de önskade kategorierna skapas i förväg, genom att navigera till Groups kan man skapa kategorier där.
Med Share, en QR-kod kan genereras för att dela en specifik nod med andra. För att lägga till den delade noden kan mottagaren gå till ”Nodes”. På höger sida, bredvid sökfältet, finns en meny med tre punkter. Genom att klicka på den här menyn och sedan välja ”Scan”, de kommer att behöva ge kamerabehörigheter för att kunna använda kameran för att skanna QR-koden och lägga till noden.
Join/Disjoin, den här funktionen ger antingen ”Join” eller ”Disjoin”, beroende på nodens aktuella status. Om noden är i en ”Joined” status kommer alternativet att vara ”Disjoin” och vice versa. Om du väljer ”Disjoin” kopplas noden bort från nätverket samtidigt som dess information behålls i Stadshubben. Alternativet ”Join” tillåter återanslutning till nätverket. Om du vill ta bort eller disjoina en nod, avaktivera sensorn som noden representerar när det är tillämpligt. På liknande sätt, för att joina en nod till nätverket igen, återaktivera sensorn som noden representerar. När en sensor försöker ansluta sig till ett nätverk måste den dynamiskt skaffa de nödvändiga nycklarna för att kommunicera med nätverket. Om sensorn inte återaktiveras kommer den inte att initiera en ny Join Request och kommer att fortsätta att överföra data med sina tidigare konfigurationer, och detta leder till en misslyckad kommunikation med nätverket.
Alternativet Delete gör till att koppla bort noden från nätverket och ta bort dess data från Stadshuben.

Uplink

Det hänvisar till överföring av data från en sensor till ett nätverk. Datan som kommer från en sensor är i HEX vilket innebär att den måste avkodas till ett läsbart format eftersom HEX inte är ett format som kan förstås av människor direkt.

Downlink

Det avser överföring av data från ett nätverk till en sensor. Man skickar Downlink meddelande som innehåller kommandon till en sensor på distans; utan att gå till fältet och ha fysisk tillgång till enheten – till exempel för att konfigurera om en enhet eller ändra en sensors datafrekvens. Data som ska skickas till en sensor måste vara i HEX och man måste konstruera det enligt sensorns dokumentation. Vidare kan man behöva specificera till vilken port datan ska skickas och den informationen finns i sensorns dokumentation.

DevEUI (Device Extended Unique Identifier)

Den är en unik identifierare som tilldelas en sensor, som är en del av ett LoRaWAN-nätverk. DevEUI är en globalt unik identifierare (64-bytes) som används för att identifiera enheten i nätverket och säkerställa att den bara kan kommunicera med behöriga enheter och gateways. Den innehåller 16 HEX-värden, dvs 16 tecken.

AppKey (Application Key)

Den är en nyckel som används för att kryptera dataöverföring som överförs av enheten, för att säkerställa att data skyddas från obehörig åtkomst eller manipulering under överföringen. AppKey används också för att dekryptera dataöverföring för paket som tas emot av enheten, för att säkerställa att data kan läsas och förstås av enheten. AppKey som används i ett LoRaWAN-nätverk krypteras vanligtvis med algoritmen Advanced Encryption Standard (AES). AES är en mycket använd symmetrisk krypteringsalgoritm som kan ge en hög säkerhetsnivå för dataöverföring. AES-algoritmen tar en 128-bytes nyckel. Den innehåller 32 HEX-värden, dvs 32 tecken.

AppEUI (Application EUI)

Den är en unik identifierare som tilldelas en applikation eller grupp av enheter som ingår i ett LoRaWAN-nätverk. AppEUI är en globalt unik identifierare (64-bytes) som används för att identifiera en grupp av enheter som tillhör samma applikation och för att säkerställa att de endast kan kommunicera med behöriga enheter och gateways. Den innehåller 16 HEX-värden, dvs 16 tecken.

DevAddr (Device Address)

Den är en unik 32-bytes nyckel som tilldelas till en sensor och används för att identifiera sensorn i nätverket. Den innehåller 8 HEX-värden, dvs 8 tecken.

NwkSKey (Network Session Key)

Den är en 128-bytes nyckel som används för att kryptera och dekryptera data som överförs av sensorn. Den används också för att generera meddelandeintegritetskoden (MIC – Message Integrity Code) som ingår i paketet för att säkerställa dataintegriteten. Den innehåller 32 HEX-värden, dvs 32 tecken.

AppSKey (Application Session Key)

Den är en 128-bytes nyckel som används för att kryptera och dekryptera data som överförs av sensorn. Den innehåller 32 HEX-värden, dvs 32 tecken.

Aktiveringsmetoder

De nödvändiga nycklarna – beroende på aktiveringsmetoden- tillhandahålls till sensorer av tillverkaren innan de distribueras. Sensorer använder dessa nycklar för autentisering och kryptering/dekryptering av datapaketen. Det innebär att leverantören alltid kommer att förse användaren med de nödvändiga nycklarna.

Over-the-Air Activation (OTAA)

Detta är den vanligaste aktiveringsmetoden som används i LoRaWAN-nätverk. Det innebär att sensorn skickar en JOIN förfrågan till nätverksservern, som sedan verifierar sensorns identitet och auktoriserar den att ansluta sig till nätverket. Den här metoden ger nätverket ansvaret att generera dessa nycklar DevAddr, NwkSKey och AppSKey dynamiskt. För denna metod behöver man följande nycklar: DevEUI, AppKey och AppEUI.

Activation By Personalization (ABP)

Denna metod innebär att sensorn förbereds med nödvändig nätverkskonfigurationsinformation; DevAddr, NwkSKey och AppSKey, innan den distribueras, dvs att informationen programmeras i enheten i förväg. Detta eliminerar behovet för sensorn att skicka en JOIN-förfrågan till nätverksservern, och den kan börja överföra data direkt efter att den har slagits på. Denna metod innebär att dessa nycklar; DevAddr, NwkSKey och AppSKey är statiska; hårdkodade i sensorn, därför kan dessa nycklar inte ändras. För denna metod behöver man följande nycklar: DevEUI, DevAddr, NwkSKey och AppSKey.

Hybrid Activation

Denna metod är en kombination av både OTAA och ABP, enheten kan börja med ABP och sedan byta till OTAA för att få uppdaterade nycklar eller nätverksinformation.

Klasser

LoRaWAN definierar olika klasser av enheter, var och en med sina egna egenskaper och specifikationer som är skräddarsydda för specifika användningsfall. Dessa klasser definierar när sensorn kan öppnas för att ta emot Downlink-meddelanden. Huvudklasserna av LoRaWAN-enheter är:

Class A

Dessa enheter är designade för lågeffekttillämpningar och har vanligtvis en låg arbetscykel, vilket innebär att de tillbringar större delen av sin tid i Sleep-Mode. De vaknar med jämna mellanrum för att leta efter Downlink-meddelande och går sedan i Sleep-Mode igen. Dessa enheter öppnas för att ta emot data endast enligt deras datafrekvens, vilket innebär att de öppnar för att ta emot data exakt när de skickar data. Om deras frekvens är att skicka data var 4:e timme så innebär det att de också öppnar för att ta emot data var 4:e timme.

Class B

Dessa enheter är en förlängning av Class A-enheter och är också designade för lågeffektapplikationer. De har en högre arbetscykel än Class A-enheter. Detta innebär att en sensor öppnar för att ta emot data lite oftare än dess datafrekvens.

Class C

Dessa enheter har en högre arbetscykel än Class A- och B-enheter och lyssnar vanligtvis alltid efter Downlink-meddelande. Dessa enheter har hög energiförbrukning eftersom de ständigt lyssnar på Downlink-meddelanden.

Class S

Dessa enheter liknar Class A-enheter men de kan skicka schemalagda Uplink-meddelande vid specifika tidpunkter, vilket gör att de kan skicka data vid en förutsägbar tidpunkt, vilket minskar behovet av Downlink-meddelande.

SF står för Spreading Factor som är en term som används inom radiofrekvenskommunikation och beskriver en faktor som bestämmer hur mycket Bandwidth en radiosignal ska spridas över. I LoRaWAN är SF mellan SF7 och SF12. Ju högre SF, desto mindre bandbredd krävs för att överföra samma mängd data, men också desto mindre räckvidd har signalen. Ju högre SF desto mer energi kommer enheten att förbruka. LoRaWAN-sensorer avgör vilket SF som ska användas genom en kombination av enhetsinställningar och beslut som görs av nätverksservern. Följande faktorer kan påverka beslutet om vilket SF som ska användas:

Avstånd till basstationen: Ju längre avstånd till basstationen, desto högre SF kan vara lämpligt för att säkerställa en tillräckligt stark signal.
Signalstyrka: Om signalstyrkan är svag, kan en högre SF vara nödvändig för att säkerställa en tillräckligt robust signal.
Bandbreddskrav: Ju högre bandbreddskrav, desto lägre SF krävs.
Batteritid: Högre SF som SF12 brukar ta mer energi jämfört med lägre SF som SF7. Det beror på att en högre SF kräver mer tid för att överföra samma mängd data, och därför kräver det mer energi att överföra. Detta är anledningen till att enheter ofta väljer en lägre SF när batteritiden är en kritisk begränsning, eftersom det är mer energieffektivt. Det är dock viktigt att notera att energiförbrukningen också påverkas av andra faktorer som överföringsstyrkan, datahastigheten och frekvensen av överföringar. För att minimera energiförbrukningen är det bäst att använda den minsta SF som uppfyller kraven på signalkvalitet, räckvidd och datahastighet – om det är möjligt.
Nätverksservern: styr ofta vilket SF som ska användas genom att sända instruktioner till enheten. Enheten kan också fatta beslut baserat på sina inställningar och interna algoritmer, såsom att välja ett lägre SF när bandbreddskrav är höga och ett högre SF när batteritid är en viktig begränsning. Adaptive Rate Algorithm (ADA) är en algoritm som används i LoRaWAN-nätverk för att optimera prestanda och energieffektivitet. ADA anpassar hastigheten på datainsamling och överföring baserat på de faktiska förhållandena i nätverket, inklusive signalstyrka, brusnivå, belastning och tillgängliga resurser. Genom att använda ADA kan sensorer välja den optimala SF för varje överföring, vilket kan hjälpa till att förbättra prestanda och minimera energiförbrukningen. Denna teknik är viktig för att upprätthålla hög prestanda och energieffektivitet i LoRaWAN-nätverk med många anslutna enheter.

RSSI

RSSI står för Received Signal Strength Indicator och är en mätning som anger styrkan på en radiofrekvenssignal som mottas av en enhet. Det är en relativ indikator och mäts vanligtvis i dBm (decibel-milliwatt). Ju högre RSSI-värde, desto starkare är mottagningen av signalen. RSSI används ofta för att bestämma kvaliteten på en radiofrekvenssignal och för att bedöma om en enhet är inom räckhåll för en basstation. Det är också en viktig faktor vid beslut om vilket SF som ska användas i LoRaWAN-nätverk, eftersom lägre RSSI-värden kan kräva en högre SF för att säkerställa en tillräckligt robust signal.

SNR

SNR står för Signal-to-Noise Ratio och är ett mått på förhållandet mellan den önskade signalstyrkan och den bakgrundsbrus (brusnivå) som finns på samma frekvens. Inom LoRaWAN-kommunikation används SNR för att bedöma kvaliteten på en mottagen radiofrekvenssignal och för att avgöra om det är möjligt att erhålla en tillräckligt säker och robust överföring. Ett högt SNR-värde indikerar att det är en hög kvalitet på mottagen signal, medan ett lågt SNR-värde indikerar en svag signal eller hög nivå av bakgrundsbrus. SNR påverkar också valet av SF inom LoRaWAN, eftersom en lägre SNR kan kräva en högre SF för att säkerställa en tillräckligt robust överföring.

Radiolänk kan anses vara BRA när RSSI> -115dB och SNR> -7dB
Radiolänken kan anses vara DÅLIG (räckviddsgräns) när RSSI <= -120 dB eller SNR <= -13dB
Mellan ovanstående 2 fall:

Om RSSI är bra (> -115dB) men SNR dåligt (<= -13dB), det betyder att miljön har hög brusnivå. SNR måste kontrolleras under några dagar för att vara säker på att radiolänken är tillräckligt stabil för att ta emot alla meddelanden.
Om RSSI är dåligt (<=-120dB) men SNR bra (> -7dB), det betyder att enheten förmodligen är långt borta från gatewayen.

Mätvärde:

Det finns två distinkta scenarier för ogiltiga mätvärden:

I det första scenariot stöter vi på en situation där de bearbetade värdena inte överensstämmer med motsvarande rådata. I det här fallet ligger problemet inom själva plattformen, och det är absolut nödvändigt att vi gör en grundlig utvärdering och korrigering av de bearbetade värdena direkt inom plattformen. Detta tyder på att databehandlingen inte är korrekt som förväntat, vilket indikerar ett behov av felsökning och korrigering inom plattformen för att säkerställa att det bearbetade värdet motsvarar dess rådata.
I andra scenariot presenterar det en unik utmaning där rådata som överförs av enheten bedöms vara ogiltiga, det vill säga att de bearbetade värdena som den genererar verkar märkliga men de är korrekta baserat på de tillhandahållna rådata. I det här specifika fallet ligger roten till problemet i hårdvaran, och vår förmåga att ingripa från vår sida är begränsad. Denna begränsning uppstår från den inneboende kopplingen mellan de bearbetade värdena och rådata som skickas av sensorn, som lagras på nätverksservern och även i vår plattform. Det bearbetade värdet härleds direkt från den ursprungliga rådatan. Varje ändring av det bearbetade värdet skulle resultera i en förlust av anpassningen till de underliggande rådata, som vi inte heller kan ändra. Dessutom är upprätthållande av spårbarhet av yttersta vikt för felsökning och säkerställande av datakvalitet. När diskrepanser mellan det bearbetade värdet och rådata uppstår, blir det en formidabel utmaning att spåra källan till dessa avvikelser. Därför är det absolut nödvändigt att göra en utvärdering av hårdvaran i sådana fall, med det yttersta syftet att korrigera eller byta ut efter behov. Det bearbetade värdet är korrekt, men rådata är felaktiga, vilket indikerar ett hårdvaruproblem som kräver uppmärksamhet. I ett sådant scenario finns det inga ändringar som kan göras från plattformssidan.

Bra att veta:

Range and coverage: Sensorernas räckvidd och täckning beror på den specifika miljön där de kommer att användas. Se till att välja sensorer som har en räckvidd och täckning som passar ert mål. Det finns sensorvarianter som kan förstärkas med en extern antenn.
Battery life: LoRaWAN-sensorer är vanligtvis utformade för lågeffektapplikationer, men batteritiden kan variera beroende på sensorn, täckning och dataöverföringsfrekvens. Se till att välja sensorer som har en batteritid som passar ert mål och att sensorerna är verkligen kräver ultralåga effekt. Tänk på att C batterier kan användas eftersom de är mycket billigare än litiumbatterier. Nackdelen är dock att alkaliska batterier inte tål kyla så bra och de tappar snabbt kapacitet när temperaturen går ner. Syftet med sensoranvändningen kommer att avgöra vilken typ av batteri som är bäst för målet.
Durability: Sensorerna ska kunna motstå den specifika miljön där de kommer att användas. Se till att välja sensorer som är designade för de specifika förhållandena för ert mål. Sensorn måste vara designad för att motstå den miljön där den ska installeras. Om sensorn ska användas i utomhusmiljö bör den ha en IP-klassning som är lämplig för väderbeständighet.
Security: LoRaWAN tillhandahåller en säker kommunikationslänk, men man behöver kontrollera att sensorn man köper är kompatibel med de senaste säkerhetsstandarderna och att den använder säkra nycklar.
Quality and Support: Se till att välja en ansedd leverantör som tillhandahåller bra kvalitetsprodukter och support. Detta omfattar garanti och teknisk support.
Compatibility: Se till att sensorerna är kompatibla enheter med nätverket och det finns dekoder för dem i Stadshubben som kan avkoda deras data från HEX till läsbart format. Alternativt kan du kontakta oss, gällande ett stöd för de sensorer som inte har ett befintligt stöd i Stadshubben.
Radio Frequency: Se till att sensorerna stödjer 868 MHz Frequency Bands eftersom LoRaWAN frekvensbandet som används i Europa är 868 MHz Frequency Bands.
Deployment: Innan du installerar din enhet på plats, bör du kontrollera signalstyrkan på den avsedda platsen. Detta kan göras enekelt genom att ta en valfri uppkopplat sensor och åka till den avsedda platsen för att se om du får data i Stadshubben därifrån. Alternativt kan du köpa en LoRaWAN-signaltestare såsom; Adeunis Field Test Device för att kontrollera signalens kvalitet och egenskaper. Observera att flera faktorer kan påverka signalen; till exempel kommer betongväggar att försvåra signalpenetration, och detsamma gäller för källare. Därför är det god praxis att kontrollera signalen innan installation. Inomhusgateways kan användas för att förbättra signaltäckningen i områden där den är svag. Dessa gateways kan förstärkas med externa antenner och anslutas till nätverket med hjälp av data-SIM-kort, vilket eliminerar behovet av en Ethernet-anslutning. En sådan gateway kan de placeras i en IP-klassade box och monteras utomhus. Det finns alltså olika lösningar för scenarier där täckningen är otillräcklig.

Externa verktyg

Det är möjligt att hämta din data och använda den med andra plattformar som PowerBI, Grafana, Tableau, etc. för avancerad analys. Vi erbjuder API:er som möjliggör en flexible integration med externa verktyg.

Begreppsförklaring

Denna lista omfattar de grundläggande termerna och koncepten för Stadshubben, åtföljda av heltäckande förklaringar för var och en:

Node: Termen ”Node” syftar på en konceptuell modell som representerar en fysisk, och konkret enhet, såsom en mätare, sensor, enhet och så vidare. Varje nod tilldelas en unik identifierare, som representeras av en universell unik identifierare (UUID). UUID fungerar som en distinkt och standardiserad identifierare för varje nod, vilket säkerställer att inga två noder delar samma identifieringsvärde. Denna unika identifierare är avgörande för att korrekt identifiera och referera enskilda noder inom systemet och nätverket.

LoRa Profile: En nod kan endast vara länkad till en profil, vilken är en konceptuell modell som betecknar kommunikationsprotokollet som används av den motsvarande enheten. Denna profil ansvarar för att lagra väsentlig enhetsanslutningsinformation, inklusive krypteringsnycklar, enhetens unika identifierare och andra relevanta detaljer. Specifikt för LoRaWAN-protokollet omfattar vanliga parametrar; DevEUI, AppKey och AppEUI. Dessa värden spelar en avgörande roll för att etablera säkra och pålitliga nätverksanslutningar för LoRaWAN-aktiverade enheter.

Brand: Termen ”Brand” betecknar en konceptuell modell som representerar en enhet som rör tillverkningen av fysiska objekt. Varje fysiskt objekt är tillverkat av ett specifikt företag och är associerat med ett varumärke. Brand kan vara länkat till flera modeller. Följaktligen är varje Node associerad med ett enskilt Brand.

Model: Termen ”Model” är en konceptuell modell som representerar ett enskilt objekt av ett specifik Brand, och syftar specifikt på en distinkt och unik modell. Som ett resultat är varje Node uteslutande associerad med en enstaka modell.

Channel: Termen ”Channel” omfattar ett konceptuellt begrepp som betecknar en specifik mättyp, såsom temperatur, fuktighet, flöde, volym och så vidare. En enhet har förmågan att mäta flera och olika mätningar samtidigt. Som ett resultat kan en nod innehålla flera kanaler av samma typ eller olika typer, vilket möjliggör representation av olika mätningar.

Identifier: Varje kanal tilldelas en ”identifier” som motsvarar den variabel av objektet som mäts; i.e. Channel, vilket möjliggör hämtning av mätvärdet. Till exempel har kanalobjektet för temperaturtemperaturen ett fält som heter; identifier, och för att erhålla mätningen av temperaturkanalen kan man använda identifier för att komma åt objektet och erhålla mätvärdet från det.

Offset: En ”Offset” är en funktion som gör det möjligt att särskilja kanaler av samma mättyp från varandra. Detta är särskilt relevant i scenarier där enheter har flera ingångar, och det antas att användaren har anslutit flera externa sensorer av samma mättyp, till exempel. I sådana fall blir det otillräckligt att enbart förlita sig på identifier för att särskilja dessa sensorer, eftersom alla kanaler av samma typ delar samma identifier. Dock kan Offset värdet användas för att differentiera dessa sensorer. Följaktligen skulle den första sensorn ha en Offset av 0, den andra sensorn en Offset av 1 och så vidare. Som ett resultat skulle kanalen som motsvarar mätningen av den första sensorn ha en Offset av 0, och efterföljande mätningar av de andra sensorerna och deras respektive kanaler skulle följa de sekventiella Offset värdena i enlighet därmed.

Unit: En ”Unit” syftar på en fast storlek som tilldelas för att kvantifiera en viss typ av kvantitet. Channels har typiskt en specifik enhet associerad med mätningen de representerar. Det är dock inte obligatoriskt för en kanal att ha en enhet, eftersom vissa kanaler kan ha en Unit som är betecknad som ”Null” när de representerar en räkning eller en kvantitet som inte kräver en specifik enhet.

Joined: Termen ”Joined” betyder att en enhet är kopplad till nätverksservern och rapporterar data. När användare väljer att Disjoina sina noder behåller plattformen den relevanta informationen, vilket förenklar återanslutningsprocessen genom att eliminera behovet av att ange informationen igen. Denna information lagras säkert inom plattformen och säkerställer en sömlös återanslutningsupplevelse för enheten. Statusen Joined är systemets initiala antagande, vilket innebär att när användaren lägger till en nod, antar systemet att användaren har lagt till korrekt information om nycklarna och därför kommer systemet att deklarera statusen som Joined. Om noden inte rapporterar data och statusen är Joined då är det antingen informationen om nycklarna är felaktig, enheten har ett problem eller så har enheten inte aktiverats korrekt, i alla fall betyder det att saken kräver felsökning.

Disjoined: Termen ”Disjoined” antyder att enheten inte är ansluten till nätverket och kommer därför inte att ta emot någon data.

Connector: En Connector är en konceptuell modell som representerar objektet som är ansvarigt för ett unikt flöde av data. I denna modell är en nod kapabel att strömma data genom en enda Connector.

Decoder: En Decoder är JavaScript eller Python kod som används för att konvertera den råa binära datan från en enhet till mänskligt läsbara värden. Denna kod innehåller en algoritm som är utvecklat för den specifika datastrukturen för den aktuella enheten. Med andra ord, en Decoder omvandlar en serie av binära tal som kanske bara förstås av enheten till en form som är begriplig och användbar för människor. Denna konverteringsprocess är avgörande för att förstå data som kommer från IoT-enheter och liknande, vilket gör det möjligt att utvinna värdefull information som temperatur, position, hastighet, etcetera, från en serie av siffror som i sig själv är meningslös utan rätt kontext. Decoder är i allmänhet anpassat till varje enhetsspecifika krav och kan variera kraftigt i komplexitet beroende på vilken typ av data som behandlas. För mer information, se följande länk.

Virtual Channel: En ”Virtual Channel” är en specialiserad kanal som genererar ett nytt mätvärde genom att beräkna det baserat på mätvärdena från en nod. Virtual Channel ger användarna möjligheten att skapa anpassade kanaler för sina Noder. Som ett illustrativt exempel kan vi betrakta ett scenario där en användare har en enhet som rapporterar batterimätningar i volt, men denna information indikerar inte direkt batteriets status. Med hjälp av Virtual Channel kan användaren utveckla en JavaScript kod, kallad en ”Converter,” för att omvandla batterispänningen till en procentandel baserat på enhetens batterispecifikationer. Denna Converter kan sedan laddas upp till Stadshubben. Därefter kan användaren skapa en Virtual Channel med den utvecklade Convertern för Noden i frågan som representerar den nämnda enheten, vilket effektivt presenterar det nya beräknade värdet—nämligen batterinivån representerad som en procentandel. Detta värde härleds från enhetens standardmätning. För mer information, se följande länk.