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å att använda sommartid ignoreras den inställningen av modulen, som i stället använder standardtid. Tiden på mätarens display kan därför avvika från tiden i telegrammet eller Elvaco OTC-appen.

Alla scheman synkroniseras mot en klocka. Ett avläsningsschema på 60 minuter synkroniseras till hela timmar, till exempel 11:00, 12:00 och 13:00. Ett schema på 120 minuter ger i stället 12:00, 14:00 och 16:00. När tiden i modulen eller mätaren synkroniseras schemaläggs nästa mätaravläsning om enligt den uppdaterade tiden. Mätarens klocka kan synkroniseras periodiskt (automatiskt) eller manuellt. Periodisk synkronisering rekommenderas för att minska risken för att klockan driver för mycket.

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_transmit minskas till ett värde under T_offset + T_delay ska T_offset ställas in på 0 och T_delay = T_transmit.

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 Raw‑läge skickas det kunddefinierade telegrammet vidare oförändrat, enligt den specifikation som är konfigurerad i Diehl SHARKY‑ eller SCYLAR‑mätaren. Vanligtvis är telegrammet förkonfigurerat vid leverans men kan även justeras i fält. Vid användning av Raw‑läge ställs meddelandekodningen automatiskt in på SenML/CBOR för att rymma större kunddefinierade telegram. Eftersom protokollet i Diehl SHARKY och SCYLAR är M‑Bus kommer även nyttolasten som levereras i SenML/CBOR‑paketen att vara i M‑Bus‑format.

I Hanterat läge beror de data som skickas på det valda meddelandeformatet. CMi6160 har två olika meddelandeformat att välja mellan, Standard och Tariff. Se avsnitt Meddelandeformat för en komplett lista över inkluderade poster i respektive format.

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 Tariff kan en typisk nyttolast se ut så här:

04139C2E0000023B0000325A0000325E0000841006000000008420FD320000000001FD1750

Om samma nyttolast skickas som ett larmmeddelande läggs de utökade felkoderna till i slutet av nyttolasten:

04139C2E0000023B0000325A0000325E0000841006000000008420FD320000000001FD175002FD180800

De utökade mätarkoderna identifieras av M-Bus DIF/VIF 2FD18, Error Mask, som här följs av de två felbyten 0x0800. Eftersom M-Bus kodas i little-endian-format blir den fullständiga felmasken 0b0000 0000 0000 1000. Det innebär att felbit 3 är satt, vilket indikerar ett problem med temperaturmätningarna (se tabellen för tolkning av mätarfel).

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-08-27T07:36:01Z "," ID":81493511, "E":0, "U":"kWh", "V":0, "VU":"m3", "P":5012, "PU":"W", "F":212, "FU":"l/h", "FT":30.1, "TU":"C", "RT":22.5, "RU": "C", "I":"0x0010", "EF":"0x70"}

För batteridrivna enheter rekommenderas att flera mätningar skickas i samma UDP-ram för att spara energi. För 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 det 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 samtliga data för varje avläsning. Besparingen i byte blir då mindre och består i att färre telegram skickas, att vissa data, till exempel mätar-ID, inte behöver överföras för varje avläsning och att tidsstämplar kan hanteras effektivare. SenML/CBOR ger också ett effektivt sätt att strukturera listor med avläsningar.

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

1  83                                      # array(3)
2  
3  ** Record for defining encoder and version **
4  
5     A2                      # map(2)
6        00                   # unsigned(0)   ## Key 1: Name
7        61                   # text(1)       ## Value 1:
8           56                # "V"           ## "V" = version
9        02                   # unsigned(2)   ## Key 2: Value
10       19 0300              # unsigned(768) ## Value 2: enc=3, ver=0
11 
12 ** first record of the pack **
13     
14    A2                      # map(2)
15       22                   # negative(2)          ## Key 1: Base Time
16       C1                   # tag(1)               ## Value 1:
17          1A 6835B149       # unsigned(1748349257) ## 2025-05-27T12:28:33+00:00
18       08                   # unsigned(8)          ## Key 2: Data value
19       58 36                # bytes(54)            ## Value 2: M-Bus telegram
20          6830306808007274
21          031961A51140048B
22          0000000C06080000  # Payload data, line breaks added for readbility
23          00046D220C3B350C
24          13377400008C10FD
25          32000000008C2013
26          000000006D16
27 
28 ** second record of the pack, containing extended information **
29 
30    A3                      # map(3)
31       00                   # unsigned(0)          ## Key 1: Name
32       61                   # text(1)              ## Value 1:
33          49                # "I"                  ## "I" = extended information
34       08                   # unsigned(8)          ## Key 2: Data value
35       45                   # bytes(5)             ## Value 2: M-Bus data
36          02FD187000        # "\u0002\xFD\u0018p\u0000"
37       06                   # unsigned(6)          ## Key 3: Timestamp
38       00                   # unsigned(0)          ## Value 3: Relative time 0

Vid en fabriksåterställning återgår enhetens inställningar till fabriksinställningarna. Alla mätardata och systemloggposter som lagras i modulen raderas också. Fabriksåterställning kan göras antingen via Elvaco OTC-appen eller på distans via LwM2M (resurs 3/./5).