Varför behövs strukturerad rådata?

Data är väl data, det är väl bara att köra?! Svaret på den frågan kan absolut vara ett ja. Men ibland är det ett nja… å ganska ofta är det ett nej…

Data kommer från många olika källor och ser ut på många olika vis, beroende på en mängd olika faktorer som olika standarder, vad det är för data, hur den ska skickas och var den skickas (för den kan ju också anpassas för mottagaren).

Som exempel nedan (eftersom jag önskar ha det här som en liten bakgrundsförklaring till den som önskar fördjupa sej lite mer i just den här frågeställningen för en beskrivning av ett kommande projekt) kommer jag att beskriva principen (inte den tekniska aspekten) av data hämtad från M-bus-mätare via Gateway och levereras till en mottagande punkt som sparar datan som strukturerad rådata. Eftersom jag håller mej på en principiell nivå kommer det att sliras hej vilt på tekniska sanningar, som förenklas så hänsynslöst att det nästan blir teknisk lögn. Men förhoppningsvis blir det kanske både begripligt och en smula underhållande för dej som faktiskt väljer att ta dej tid att läsa denna nörderiprosa.

De tekniska komponenterna som jag kommer vidröra är:

sensor i mätare,
mätare,
kommunikationsväg till gateway,
gateway,
kommunikationsväg till tolk,
tolk,
och sist databas där den strukturerade rådatan kommer sparas.

För att förvirra lite, så börjar jag mitt i listan med gateway. I det här exemplet så är det i Gateway allt börjar. Och genomgående i den här förklaringsmodellen vill jag att du tänker dej att det i varje pryl och längs varje kommunikationsväg och varje teknisk komponent, så finns det små människor som utför ett jobb. De sitter vid sina skrivbord eller rör sej längs sina förutbestämda rutter och bär med sej små papperslappar med information på.

Så vi börjar hos administratören i Gatewayn. Den sitter framför ett skrivbord med ett ständigt flöde av informationslappar. Till sin hjälp har administratören:

två listor,
en penna,
en klocka,
två telefoner,
och två stämplar.

Klockan är en helt vanlig klocka. Den visar datum och tid. That’s it. Inga konstigheter. Den ena stämpeln är också högst ordinär. Den har ett förinställt värde, nämligen skrivbordets nummer, så sitter administratören vid skrivbord 42007 så är den ena stämpeln inställd med värdet 42007. Så när den pressas mot ett papper, boom, siffrorna 42007 dyker plikttroget upp. Varje gång. Skulle skrivbordet istället heta 42042, ja, då står det 42042 på avtrycket den stämpeln lämnar.

Den andra stämpeln är däremot lite magisk. När administratören tar den i sin hand inför stämplingen och kastar ett öga på klockan, ja, då stället stämpeln automatiskt in sej på aktuellt datum och klockslag. Står det 24:e December, 2025, kl. 15.00, ja, då står det också det på avtrycket som stämpeln lämnade ifrån sej just då. Men en stund tidigare på dagen så lämnade stämpeln ifrån sej den aktuella tiden som var då, låt oss säga 24:e December, 2025, kl. 13.15. Och skulle den användas just nu, när jag sitter och skriver detta, ja då skulle stämpelns avtryck säga 2:a April, 2026, kl. 21.54.

Pennan är en helt vanlig penna. Går att skriva på vanligt papper med. Kan också användas för att göra små snabba uppställningar i marginalen på något papper om det behövs göras en uträkning, men de flesta administratörer är duktiga på huvudräkning och behöver sällan göra marginalberäkningar. Förresten, en sak är ju lite speciell med den här pennan. Den behöver aldrig vässas eller fyllas på med stift eller bläck. Och varje gång den används lämnar den ifrån sej tydliga linjer.

De två listorna? Jo, en lista berättar vilka mätare som finns längs ena kommunikationsvägen från Gatewayn. Och den andra listan berättar vem som vill ha vilken information och hur ofta den ska skickas ut längs den andra kommunikationsvägen. Det är också här telefonerna kommer in i bilden. Ena telefonen används för att ringa till sej ett bud som springer längs kommunikationsvägen mellan gateway och mätare, den andra telefonen för att ringa till sej ett bud som springer längs den andra kommunikationsvägen till tolken.

Administratören i gatewayn ser att det strax börjar närma sej kvart över och alltså strax dags att skicka iväg värde till Mottagare 1 som ska ha värden var 15:e minut. Därför ringer administratören till sej en budbärare som ska springa längs kommunikationsvägen mellan Gateway och Mätare. Det kan vara via en sladd, exempelvis M-bus, eller trådlöst (då antar jag att budbäraren har någon slags flygfarkost) och med lite olika protokoll eller språk (Zigbee, LoRa, BACnet, etc). Hur som helst, budet rings in och skickas iväg för att samla in lappar (data) från mätarna! Budet springer iväg längs sin förutbestämda rutt och kommer till en administratör i varje mätare. Bortsett från telefonerna, är de utrustade med samma saker som sin kollega vid skrivbordet i Gatewayn. De har en magisk tid-och-datumstämpel som följer deras klocka (som i den bästa av världar visar samma tid-och-datum som nere Gatewayn) och en statisk stämpel som visar vad deras skrivbord heter. Just det, de har ju inga listor heller. Däremot har de en eller flera kollegor som också sitter i mätaren men som har andra arbetsuppgifter, och eftersom de jobbar så nära varandra behöver mätarens administratör ingen lista för att hålla koll på dem. Så när budet från Gatewayn kommer samlar mätarens administratör snabbt in informationen från sina kollegor, sammanställer på ett papper, stämplar med sina två stämplar och lämnar över till budet.

Kollegorna i mätaren kan ha lite olika arbetsuppgifter och sköta dem på lite olika sätt, därför kan det stå lite olika på lapparna som administratören i mätaren skickar ifrån sej.

Det kan till exempel i temperaturmätare 13377307 finnas två olika sensorer. Varje sensor har en egen individ som läser av. Båda avläsarna har i just den här mätaren en enkel arbetsuppgift i att läsa av när de får en fråga och rapportera vad det står på just deras sensor i det ögonblicket. Den ena sensorn mäter temperatur och den andra luftfuktighet. Så på den lappen administratören lämnar i från sej står det så här:

Mätare: 13377307
Tid: 22.13, 2 April 2026
Temperatur: 22,1°C
Luftfuktighet: 39,5%

Budets nästa hållplats är en mätare som bara mäter temperatur, men som är av ett annat fabrikat än den första och har lite annan funktionalitet. Istället för att arbetaren vid sensorn bara läser av på förfrågan har den här arbetaren som arbetsuppgift att läsa av sensorns värde var 6:e minut och varje gång den får en fråga om temperaturen, så lämnar den ifrån sej värdena till sin administratör.

Administratören har dessutom uppgiften att hålla rätt på avläsningarna som kommer och packa om informationen så att den presenteras med ett nuvärde (det senaste som kommer), medelvärdet av den senaste timmen (de senaste 10 värdena) och det senaste dygnet (de senaste 240 värdena).

Eftersom det kommer ett bud var 15:e minut och frågar om informationsleverans, så blir det två eller värden som svar från arbetaren som sitter vid sensorn (X:00, X:06 och X:12 vid 15 över leverans, X:18 och X:24 vid 30 leveransen, X:30, X:36 och X:42 vid 45 leveransen och X48 och X:54 vid 00 leveransen).

Nu fick administratören tre värden från avläsaren och de var 18,2, 19,6 och 19,2. Det värdet som är skrivet sist är alltid det senaste. Därför packar administratören om informationen på sin lapp och skriver så här:

Mätare: 46021980
Tid: 2 April 2026, 22.13.
Temperatur1: 18,2°C (nuvärdet = senaste värdet)
Temperatur2: 19,1°C (medelvärdet den senaste timmen, eller de 10 senaste mätningarna)
Temperatur3: 20,6°C (medelvärdet det senaste dygnet, eller de 240 senaste mätningarna)

Värt att notera här är att paranteserna bara är förklaring och inget som står med på informationslappen och att den här tillverkaren har försett sin administratör i mätaren med en tidsstämplare som skriver informationen i en annan ordning än den förra.

Sist ut på budets informationsinsamlingsrutt är en helt annan typ av mätare, en vattenmätare som till skillnad från de två föregående som rapporterar någon typ av värde som är momentana (i stunden), så har den här ett räkneverk som hela tiden räknas upp (eller ner, ifall mätaren är monterad baklänges). Det råkar vara samma tillverkare som den andra temperaturmätaren, vilket i det här fallet också innebär att deras tidsstämplare ger informationen på samma sätt på båda mätarna. (Vilket tyvärr inte är någon garanti att det alltid är så.) Hos vattenmätarens administratör hämtar budet upp en lapp med följande information:

Mätare: 17012009
Tid: 2 April 2026, 22.13.
Mätarställning: 43721,67

När budet kommer fram till administratören i Gatewayn ringer denna på ett bud att hämta kvart över försändelsen och sammanställer informationen på följande vis:

Gateway: 42007 (stämplat)
Tid: 22.14, 2 April 2026 (stämplat)
Mätare: 13377307
Tid: 22.13, 2 April 2026
Temperatur: 22,1°C
Luftfuktighet: 39,5%
Mätare: 46021980
Tid: 2 April 2026, 22.13.
Temperatur1: 18,2°C
Temperatur2: 19,1°C
Temperatur3: 20,6°C
Mätare: 17012009
Tid: 2 April 2026, 22.13.
Mätarställning: 43721,67

En gateway av ett annat fabrikat, eller med andra informations-ompacknings-regler skulle kunna ha presenterat informationen så här (med mätarens tidsstämpel bortrensad och temperaturerna sampackade):

Gateway: 42007
Tid: 22.14, 2 April 2026
Mätare: 13377307
Temperatur: 22,1°C
Luftfuktighet: 39,5%
Mätare: 46021980
Temperatur: 18,2°C, 19,1°C, 20,6°C
Mätare: 17012009
Mätarställning: 43721,67

(Som extra kuriosa kan nämnas att en gateway kan spara ett visst antal mätvärden, alltså ett visst antal lappar från respektive mätare och lägga dem på hög på skrivbordet. Så skulle ett bud inte dyka upp som förväntat och hämta informationen finns det oftast kvar en viss tid. Skulle det däremot gå för länge så slängs lapparna, för det mesta enligt principen understa (äldsta) kastas först.)

När budet kommer och hämtar informationslappen för transport till tolken är det viktigt att administratören har packat informationen på ett språk som budbäraren förstår (MQTT, API, etc). Den nya budbäraren springer sedan med informationslappen till en mottagande tolk. Hos tolken kommer det samtidigt fram två olika meddelanden som ser ut så här:

Gateway: 42007
Tid: 22.14, 2 April 2026
Mätare: 13377307
Tid: 22.13, 2 April 2026
Temperatur: 22,1°C
Luftfuktighet: 39,5%
Mätare: 46021980
Tid: 2 April 2026, 22.13.
Temperatur1: 18,2°C
Temperatur2: 19,1°C
Temperatur3: 20,6°C
Mätare: 17012009
Tid: 2 April 2026, 22.13.
Mätarställning: 43721,67

och så här:

Gateway: 54006
Mätare: 25311803
1:23,6, 22,3
2:44,1, 43,9
3:68,33
Mätare: 23021973
Mätarställning: 5431528,33
Mätare: 18041954
Mätarställning: 46791,13
Tid: 2 April 2026, 22.13

Den mottagande administratören i Tolken behöver nu ha ett register för att förstå vad den ska göra med meddelandena. Registret behöver innehålla lite olika saker som vad det är för typ av mätare, modell, fabrikat, etc, för att kunna göra rätt tolkningar. Administratörens uppgift är att titta på de inkommande informationslapparna och packa om dem till en förutbestämd form, eller struktur, och på så vis likställa all information som kommer in så att de ser lika ut när de sparas ner. Så här gör denna tolken med den inkommande informationen från de två olika leveranserna:

Gateway: 42007 <– nyckel för att tolka resten av informationen
Tid: 22.14, 2 April 2026 <– just detta fabrikatet börjar med klockslag, följt av datum
Mätare: 13377307 <– Mätare av modell x, fabrikat y, ger tolkningsinstruktion 1.
Tid: 22.13, 2 April 2026 <– tolkningsinstruktion 1 –> använd mätarens egen tidsstämpel, format klockslag + datum, sparas.
Temperatur: 22,1°C <– tolkningsinstruktion 1 –> Är temperaturvärde med enhet grader celcius, sparas.
Luftfuktighet: 39,5% <– tolkningsinstruktion 1 –> Är luftfuktighetsvärde med enhet procent, sparas.
Mätare: 46021980 <– Mätare av modell z, fabrikat q, ger tolkningsinstruktion 2.
Tid: 2 April 2026, 22.13. <– tolkningsinstruktion 2 –> använd mätarens egen tidsstämpel, format datum + klockslag, sparas.
Temperatur1: 18,2°C <– tolkningsinstruktin 2 –> Är temperaturvärde i grader celcius, nuvärde, sparas.
Temperatur2: 19,1°C <– tolkningsinstruktin 2 –> Är temperaturvärde i grader celcius, timmedelvärde, ska inte sparas.
Temperatur3: 20,6°C <– tolkningsinstruktin 2 –> Är temperaturvärde i grader celcius, dygnsmedelvärde, ska inte sparas.
Mätare: 17012009 <– Mätare av modell q, fabrikat q –> ger tolkningsinstruktion 3
Tid: 2 April 2026, 22.13. <– tolkningsinstruktion 3 –> använd mätarens egen tidsstämpel, format datum + klockslag, sparas.
Mätarställning: 43721,67 <– tolkningsinstruktion 3 –> mätarställning i kubikmeter, sparas.

De lappar som skrivs om för att sparas ser då ut så här:

Gateway; MätarId; Värde; Tidsstämpel (datum + tid); Enhet; Typ;

42007; 13377307; 22,1;2 April 2026, 22:14; °C; Temp;
42007; 13377307; 39,5;2 April 2026, 22:14; %; Fukt;
42007; 46021980; 18,2; 2 April 2026, 22.13; °C; Temp;
42007; 17012009; 43721,67; 2 April 2026, 22.13; m3; Vatten;

Ovan har strukturerats om och likställts och lämnas nu till databasen för att lagras. Men för att se den fulla styrkan i det ska vi först tolka om det andra meddelandet.

Gateway: 54006 <– nyckel för att tolka resten av informationen, med en gemensam tidsstämpel sist informationspaketet i format datum + tid, använd för alla mätvärden.
Mätare: 25311803 <– Mätare av modell xx, fabrikat zz –> ger tolkningsinstruktion 4
1:23,6, 22,3 <– tolkningsinstruktion 4 –> temperaturvärde i grader celcius, nuvärde först, timmedelvärde sen –> spara nuvärde.
2:44,1, 43,9 <– tolkningsinstruktion 4 –> luftfuktighet i %, nuvärde först, timmedelvärde sen –> spara nuvärde.
3:68,33 <– tolkningsinstruktion 4 –> batteristatus i % –> sparas.
Mätare: 23021973 <– Mätare av modell yy, fabrikat qq –> ger tolkningsinstruktion 5
Mätarställning: 5431528,33 <– tolkningsinstruktion 5 –> vattenmätare med mätarställning i m3 –> sparas.
Mätare: 18041954 <– Mätare av modell yy, fabrikat qq –> ger tolkningsinstruktion 5
Mätarställning: 46791,13 <– tolkningsinstruktion 5 –> vattenmätare med mätarställning i m3 –> sparas.
Tid: 2 April 2026, 22.13 <— gemensam tidsstämpel för alla mätare i informationspaketet.

Gateway; MätarId; Värde; Tidsstämpel (datum + tid); Enhet; Typ;

54006; 25311803; 23,6; 2 April 2026, 22.13; °C; Temp;
54006; 25311803; 44,1; 2 April 2026, 22.13; %; Fukt;
54006; 25311803; 68,33; 2 April 2026, 22.13; %; Batteri;
54006; 23021973; 5431528,33; 2 April 2026, 22.13; m3; Vatten;
54006; 18041954; 46791,13; 2 April 2026, 22.13; m3; Vatten;

När vi nu lägger de här två listorna efter varandra och dessutom grupperar dem efter typ, så kan vi plötsligt börja jämföra olika värden från olika typer av mätare där transportkedjan av mätvärdet ser olika ut och har olika förutsättningar.

Gateway; MätarId; Värde; Tidsstämpel (datum + tid); Enhet; Typ;

42007; 13377307; 22,1;2 April 2026, 22:14; °C; Temp;
42007; 46021980; 18,2; 2 April 2026, 22.13; °C; Temp;
54006; 25311803; 23,6; 2 April 2026, 22.13; °C; Temp;
42007; 13377307; 39,5;2 April 2026, 22:14; %; Fukt;
54006; 25311803; 44,1; 2 April 2026, 22.13; %; Fukt;
42007; 17012009; 43721,67; 2 April 2026, 22.13; m3; Vatten;
54006; 23021973; 5431528,33; 2 April 2026, 22.13; m3; Vatten;
54006; 18041954; 46791,13; 2 April 2026, 22.13; m3; Vatten;
54006; 25311803; 68,33; 2 April 2026, 22.13; %; Batteri;

När vi nu har strukturerat rådatan så att allt är likformigt kan vi sedan börja skapa funktioner och beräkningar på datan. Mer om det i ett annat kapitel. För nu är det dags att runda av den här godnatt-sagan.