Drift

Mätardata kan överföras med antingen MQTT-SN eller LwM2M Send. Protokollen kan inte användas samtidigt, men de kan konfigureras via LwM2M eller Elvaco OTC-appen. Innehållet i överförda data är detsamma oavsett vilket transportprotokoll som väljs. När en överföring av mätardata är schemalagd definieras de data som skickas av det valda meddelandeformatet. Om det finns mätardata i modulen som inte har skickats överförs de enligt den valda återställningsstrategin (First in First out (FiFo) eller Last in First out (LiFo)).

Modulen förlitar sig på mätarens klocka för att hålla tiden. Tiden i mätaren antas vara i lokal lokal tid (ingen sommartid). Vid synkronisering av tid i mätaren med Elvaco OTC-appen används alltid lokal standardtid, även om sommartid är i kraft. Den tidsstämplade mätardata som skickas från modulen kan justeras för att skickas i UTC genom att specificera konfigurationsparametern "UTC offset". UTC-offset kommer att subtraheras från tidsstämpeln före sändning. Om mätaren är i Sverige, som använder CET (Central European Time), bör den ha UTC-offset satt till +60 (+1h). I detta fall skickas kl 12.00 ett telegram med tidsstämpel 11.00 då detta är motsvarande UTC-tid. En mätare i New York (USA) bör ha en UTC-offset på "-300" (-5h) etc. En UTC-offset på "0" betyder att mätartiden används som den är.

Om mätaren är inställd på använd sommartid ignoreras detta av modulen och standardtiden används. Det kan alltså hända att tiden på mätarens display inte matchar tiden i telegrammet eller i Elvaco OTC-appen.

Alla scheman är baserade på en synkronisering med en klocka. Detta indikerar att om ett avläsningsschema på 60 minuter används synkroniseras det ovanpå timmen, så 11:00, 12:00, 13:00 etc. 120 minuter ger 12:00, 14:00, 16:00 etc. När tiden i modulen (eller mätaren) synkroniseras sker en omplanering så att nästa mätaravläsning görs enligt en uppdaterad tid. Synkronisering av mätarklockan kan göras på olika sätt, antingen periodiskt (automatiskt) eller manuellt. Det rekommenderas att använda ett periodiskt tillvägagångssätt för att undvika risken att klockan driver för mycket (hamnar ur synk).

För att hantera fallet där en tidssynkronisering "flyttar tiden" förbi en tidigare planerad avläsning (som 23.58 → 00.02) kommer modulen alltid att göra en avläsning och sändning av ett nytt värde när tiden är synkroniserad. Enheten kommer därför att skicka en extra avläsning som kan maskeras på serversidan.

För att förhindra att många enheter sänder data på exakt samma tid har enheterna en slumpmässig fördröjning innan de överför data. Fördröjningen kan konfigureras via antingen Elvaco OTC-appen och NFC-gränssnittet, eller på distans via ett enhetshanteringssystem.

Avläsningar från mätaren görs alltid varje hel timme, till exempel 11.00 och 13.00. Överföringar kan utföras vid andra tidpunkter men planeras till hela timmar utifrån ett angivet överföringsintervall (T_transmit). Bilden nedan illustrerar detta. Överföringarna planeras vid tidpunkten T₁. Det faktiska T_transmit är en slumpmässig tid mellan (T₁ + T_offset) och (T₁ + T_offset + T_delay).

T_överföring, T_offset och T_dröjsmål är parametrar i produkten.

Villkor

• T_offset + T_dröjsmål<= T_överföring

Detta bör kontrolleras av enheten och OTC-appen.

• Om T_överföring reduceras under T_offset + T_dröjsmål, sedan T_offset ska ställas in på 0 och T _dröjsmål.= T_överföring.

Om data inte kan skickas, exempelvis på grund av nätverksproblem, görs det ett antal försök varefter enheten ger upp och sparar avläsningen som "icke-sänd". Nästa gång en överföring görs kommer data som inte skickats att skickas på nytt (om möjligt). Återsändning kan göras genom FIFO eller LIFO.

Regler för återsändningar inkluderar maximal ålder för data, dataordning, antal återsända data/överföringsintervall.

I läget Anpassat väljer användaren vilka mätarregister som stöds och som modulen ska inkludera i den överförda nyttolasten. Varje valbart register mappas till en bit i bitmasken för överföringsfält för anpassat format (se Anpassat meddelandeformat för tillgängliga register).

När läget Förinställt används beror de data som skickas på det valda meddelandeformatet. CMi6110 har två olika meddelandeformat: Standard och Utökat. En fullständig lista över de poster som ingår i respektive format finns i avsnitt Förinställda meddelandeformat.

Mätarlarm överförs med det valda transportprotokollet, som kan vara antingen MQTT-SN eller LwM2M Send. Innehållet i överförda data är detsamma oavsett vilket transportprotokoll som väljs. När ett larm utlöses följer meddelandet det valda formatet och utökade felkoder läggs till. Om det finns mätardata i modulen som inte har skickats överförs de samtidigt med larmet.

Varje bit i larmmasken är direkt mappad till ett mätarfel. De olika larmmaskerna som används för att styra larmövervakaren har samma mappning. Avsnitten nedan beskriver hur varje bitmask ska hanteras och tolkas.

Tabellen nedan anger tillgängliga mätarfel och hur de mappas till bitmasken.

Med meddelandeformatet Standard kan en typisk nyttolast se ut så här:

046D002A323B0C7837266966040637570A000414EF472000022B0000023BFCFF025B0000025F000002FD170400

0x02FD17 är M-Bus DIF/VIF-indikatorn för felflaggor, och de två efterföljande bytevärdena 0x0400 anger att det finns ett fel. Eftersom M-Bus-kodningen använder LSB läses motsvarande bitmappning som 0x00 04, vilket ger bitarna 0b0000 0000 0000 0100. Det innebär att bit 2 är satt, vilket anger att det finns ett problem med returtemperaturgivaren (se tabellen Tolkning av mätarfel ovan).

Om en nyttolast i stället skickas som ett larmmeddelande ser den liknande ut, men de utökade felkoderna läggs också till i meddelandet:

046D0F2A323B0C7837266966040637570A000414EF472000022B0000023BFCFF025B0000025F000002FD17040002FD180400

0x02FD17 anger återigen felflaggorna, och de två efterföljande bytevärdena 0x04 00 är identiska med exemplet ovan. Eftersom detta meddelande har utlösts som ett larm läggs de utökade felkoderna till i nyttolasten, se 02FD180400. FD18 anger att det är en M-Bus-felmask. Bytevärdena i felmasken avkodas på samma sätt som felflaggorna enligt informationen i tabellen Tolkning av mätarfel ovan.

Modulens systemlogg kan överföras med antingen MQTT-SN eller LwM2M Send. Vilket som används beror på det transportprotokoll som har valts för mätardata. Innehållet i överförda data är detsamma oavsett val. När en systemloggpost med en systemloggnivå som har konfigurerats för överföring lagras i modulen skickas den tillsammans med nästa överföring av mätardata. Alla loggposter som ska skickas men ännu inte har skickats inkluderas.

Oavsett om systemloggen skickas med MQTT-SN eller LwM2M Send struktureras nyttolasten enligt SenML-datamodellen och kodas med CBOR. Själva systemloggmeddelandet lagras som en ASCII-textsträng i SenML-posten.

En fullständig beskrivning av hur SenML/CBOR-paketen kodas finns i avsnitt SenML/CBOR. Exemplet nedan visar ett förenklat sätt att avkoda ett systemloggmeddelande, från den råa nyttolasten till ett läsbart systemloggmeddelande.

Om M-Bus används som meddelandekodningsteknik kommer data att delas in i Data Information Block (DIB) som inkluderar datainformationsfält (DIF-kod), värdeinformationsfält (VIF-kod) och ett datafält (DATA) där den faktiska payloaden är sparad (illustreras i följande bild).

DIB-struktur

Tabellen nedan ger detaljerade exempel på hur data kodas när man använder M-Bus som kodning.

När du använder JSON-meddelandekodning består meddelanden som skickas av ett objekt med en lista med nyckel – värdepar. Exempel på namn för varje värdetyp och enhet presenteras i tabellen nedan. Värdena är kodade som siffror eller strängar och enheterna är kodade som strängar. JSON erbjuder datakodning som är läsbar för människor, på bekostnad av att den inte är lika Compact som exempelvis SenML/CBOR.

Exempel på payload, JSON:

{
"TS":"2025-11-28T20:39Z",
"ID":87654321,
"E":12345.678,
"U":"MWh",
"V":3456.7,
"VU":"m3",
"P":5012,
"PU":"W",
"F":212,
"FU":"l/h",
"FT":80.3,
"TU":"C",
"RT":53.8,
"RU":"C",
"EF":"0x4012"
}

För batteridrivna enheter kan det vara nödvändigt att skicka flera mätningar i samma UDP-ram för att spara energi. För att uppnå detta används SenML (Sensor Measurement Lists) + CBOR (Concise Binary Object Representation) för att definiera en mätlista.

Tanken är att skicka en lista med mätningar, där den första posten innehåller bastiden för alla avläsningar (som endast behöver ange en offset) och ett mätar-id som delas av alla avläsningar. De andra posterna i listan kan innehålla färre avläsningsfält för att spara utrymme. Formatet gör det möjligt att skicka all data för varje avläsning, då lagringen (i termer av byte) blir mindre därför att färre telegram skickas, en del data behöver inte överföras för varje avläsning (som meter-id) och tidsstämplar kan hanteras mer effektivt. SenML/CBOR erbjuder även ett sätt att strukturera listor med avläsningar på ett effektivt sätt.

Elvaco använder SenML/CBOR/M-Bus datarepresentation för att överföra mätardata på ett kompakt och självbeskrivande sätt. Datan som överförs kallas ett paket som innehåller en post per avläsning.

01 83                                      # array(3)
02    A2                                   # map(2)
03       00                                # unsigned(0)
04       61                                # text(1)
05          56                             # "V"
06       02                                # unsigned(2)
07       00                                # unsigned(0)
08    A3                                   # map(3)
09       21                                # negative(1)
10       68                                # text(8)
11          3636363932363337               # "66692637"
12       22                                # negative(2)
13       C1                                # tag(1)
14          1A 691C43A0                    # unsigned(1763460000)
15       08                                # unsigned(8)
16       58 21                             # bytes(33)
17          040637570A000414EF472000022B0000023BFDFF025B0000025F000002FD170400 # "\u0004\u00067W\n\u0000\u0004\u0014\xEFG \u0000\u0002+\u0000\u0000\u0002;\xFD\xFF\u0002[\u0000\u0000\u0002_\u0000\u0000\u0002\xFD\u0017\u0004\u0000"
18    A3                                   # map(3)
19       00                                # unsigned(0)
20       61                                # text(1)
21          49                             # "I"
22       08                                # unsigned(8)
23       45                                # bytes(5)
24          02FD180400                     # "\u0002\xFD\u0018\u0004\u0000"
25       06                                # unsigned(6)
26       00                                # unsigned(0)

[{0: "V", 2: 0}, {-2: "66692637", -3: 1(1763460000), 8: h'040637570A000414EF472000022B0000023BFDFF025B0000025F000002FD170400'}, {0: "I", 8: h'02FD180400', 6: 0}]

1  86                                      # array(6)
2     A3                                   # map(3)
3        21                                # negative(1)
4        68                                # text(8)
5           3731393531333138               # "71951318"
6        22                                # negative(2)
7        C1                                # tag(1)    
8           1A 66D07454                    # unsigned(1724937300)  # "2024-08-29T13:15:00Z"
9        08                                # unsigned(8)
10       58 21                             # bytes(33)
11          040600770300041461D80A00022D1300023B5401025A2002025EF00102FD170000
12    A2                                   # map(2)
13       06                                # unsigned(6)
14       39 0383                           # negative(899) # "2024-08-29T13:00:00Z"
15       08                                # unsigned(8)
16       58 21                             # bytes(33)
17          040600770300041458D80A00022D1300023B5401025A1F02025EF00102FD170000
18    A2                                   # map(2)
19       06                                # unsigned(6)
20       39 0707                           # negative(1799) # "2024-08-29T12:45:00Z"
21       08                                # unsigned(8)
22       58 21                             # bytes(33)
23          0406FF760300041450D80A00022D1800023B5E01025A1F02025EE30102FD170000
24    A2                                   # map(2)
25       06                                # unsigned(6)
26       39 0A8B                           # negative(2699) # "2024-08-29T12:30:00Z"
27       08                                # unsigned(8)
28       58 21                             # bytes(33)
29          0406FF760300041447D80A00022D1300023B5401025A1E02025EEF0102FD170000
30    A2                                   # map(2)
31       06                                # unsigned(6)
32       39 0E0F                           # negative(3599) # "2024-08-29T12:15:00Z"
33       08                                # unsigned(8)
34       58 21                             # bytes(33)
35          0406FE76030004143FD80A00022D1400023B4A01025A2002025EEC0102FD170000
36    A2                                   # map(2)
37       00                                # unsigned(0)
38       61                                # text(1)
39          56                             # "V"
40       02                                # unsigned(2)
41       00                                # unsigned(0)