Drift

Säkerhet och åtkomstkontroll

Produkten har ett konfigurationslås som förhindrar obehörig åtkomst till modulen. När konfigurationslåset har aktiverats måste en användare inneha den enhetsspecifika produktåtkomstnyckeln (PAK) för att få åtkomst till enheten. Nycklar hanteras på ett säkert sätt med hjälp av Elvacos OTC-lösning som inkluderar mobilapplikationen för konfiguration.

Notera

För mer information om säkerhet och åtkomst vad gäller produkten, se One-touch commissioning (OTC)-dokumentationen på Elvacos hemsida.

Mätaravläsning och dataöverföring

Hur ofta och med när data skickas från CMi6160 baseras på två inställningar, Report interval (rapportintervall) och Transmit interval (sändningsintervall). Report interval styr hur ofta modulen läser data från mätaren, medan Transmit interval styr hur ofta modulen skickar data till till ett mottagande system. Dessa inställningar tillsammans styr mängden och hur ofta data kommer att skickas till det mottagande systemet. Detta betyder t.ex. att om Report interval är kortare än valt Transmit interval kommer flera mätaravläsningar skickas i samma sändning. Vilken data som överförs avgörs av det konfigurerade meddelandeformatet, se Meddelandeformat för en fullständig definition av alla tillgängliga meddelandeformat. Sättet meddelandeformatet är kodat på är också konfigurerbart, se Meddelandekodning för detaljer.

Tabellen nedan sammanfattar de väsentliga inställningarna för att styra data som skickas från CMi6160.

Tabell 31. Väsentliga modulinställningar

Inställning	Beskrivning
Report interval (rapportintervall)	Bestämmer hur ofta mätaren läses av modulen. Avlästa värden lagras i modulen tills nästa sändning. Ett kort Report interval innebär att mätaren läses ofta, vilket innebär att en högre upplösning av data kan uppnås.
Transmit interval (sändningsintervall)	Bestämmer hur ofta data skickas från modulen till det mottagande systemet. Ett kort sändningsintervall innebär att modulen kommer att skicka data oftare, vilket gör att systemet kan hämta data från nyare mätaravläsningar.
Message format (meddelandeformat)	Bestämmer vilket innehåll från mätaravläsningen som skickas till det mottagande systemet. Det är möjligt att välja mellan flera meddelandeformat.
Message encoding (meddelandekodning, exempelvis M-Bus eller JSON)	Bestämmer hur data kodas innan den skickas från modulen. Välj det alternativ som passar det system som tar emot meddelandet bäst.

Tips

Att överföra data är en mycket mer energikrävande operation än att läsa av mätaren. För batteridrivna enheter är det därför klokt att ställa in ett längre sändningsintervall än rapportintervall för att uppnå en lämplig dataupplösning.

Hantering av tid

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.

Synkronisering

Alla mätaravläsningar är baserade på synkronisering med mätarens klocka. Detta innebär att med ett Report interval på 60 minuter synkroniseras mätaravläsningen till att göras varje hel timme, exempelvis 11:00, 12:00, 13:00 etc. Ett Report interval på 120 minuter schemalägger mätaravläsningar till 12:00, 14:00, 16: 00 osv.

När tiden i modulen (eller mätaren) är synkroniserad sker en omplanering så att nästa mätaravläsning görs enligt en uppdaterad tid.

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.

Slumpmässiga sändningar

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 heltimme, 11.00, 13.00 etc. Överföringar kan utföras vid andra tillfällen men planeras varje heltimme genom ett inställt överföringsintervall (T _överföring). Bilden nedan illustrerar detta. Överföringarna är planerade vid tidpunkten T ₁. Den faktiska T _överföring är en slumpmässig tid mellan (T ₁ + T _offset) och (T ₁ + T _{offset< /subscript> + T _dröjsmål).}

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.

Mätardataöverföring

Modulen skickar mätardatameddelanden enligt dess inställningar för sändningsintervaller. Mätaravläsning är alltid relaterad till mätarens klocka vid tidpunkten 00:00:00. Sändningstiden är randomiserad mellan avläsningarna.

Att överföra och tolka mätardata från modulen är flexibelt och användaren kan välja mellan olika kodningstekniker och meddelandeformat. Valt meddelandeformat dikterar vilken data som skickas, medan kodningstekniken bestämmer hur denna data ska tolkas. I följande stycken beskrivs de tillgängliga meddelandeformaten och kodningsteknikerna i detalj.

Återsändning av data

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.

Exempel 5. Exempel 1

En enhet är konfigurerad på följande sätt:

Meddelandekodning: M-Bus
Automatisk uppladdningsordning: FIFO
Mätintervall: 60 minuter
Sändningsintervall: 60 minuter
Sändningsförskjutning: 15 minuter
Sändningsfördröjning: 30 minuter
Maximalt antal uppladdningar per överföring: 4
Ladda upp maximal ålder 72h

Ett nätverksproblem gjorde att modulen var offline i 5 dagar medan den fortfarande läste och lagrade mätdata. När enheten lyckas gå online sker följande scenario.

Enheten börjar med att överföra mätdata som är 3 dagar gammal (FIFO-ordning)
Enheten kommer att skicka 4 mättelegram per timme, vid en slumpmässigt vald tidpunkt mellan minut 15 och 45
Varje telegram innehåller en enda avläsning, totalt 4 avläsningar per sändning
Enheten tar ungefär 1 dag att "komma ikapp" och börja skicka en mätning per timme

Exempel 6. Exempel 2

En enhet är konfigurerad på följande sätt:

Meddelandekodning: SenML/CBOR/M-Bus
Automatisk uppladdningsordning: FIFO
Mätintervall: 60 minuter
Sändningsintervall: 60 minuter
Sändningsförskjutning: 15 minuter
Sändningsfördröjning: 30 minuter
Maximalt antal uppladdningar per överföring: 4
Ladda upp maximal ålder 72h
Enhetens maximala payloadstorlek: 12 (avläsningar per telegram)

Ett nätverksproblem gjorde att modulen var offline i 5 dagar medan den fortfarande läste och lagrade mätdata. När enheten lyckas gå online sker följande scenario.

Enheten börjar med att överföra mätdata som är 3 dagar gammal (FIFO-ordning)
Enheten kommer att skicka 4 mättelegram per timme, vid en slumpmässigt vald tidpunkt mellan minut 15 och 45
Varje telegram innehåller 12 meter avläsningar, totalt 4 x 12 = 48 avläsningar per sändning
Enheten tar ungefär 2 timmar att "komma ikapp" och börja skicka en mätning per timme

Meddelandekodning

Produkten har tre alternativ när det kommer till meddelandekodning:

M-Bus
JSON
SenML/CBOR

M-Bus

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.

Tabell 32. Payload, M-Buskodat meddelande

DIB	Fält	Storlek	Datatyp	Beskrivning
1	Datum/tid	6 byte	INT32	Mätarens datum och tid (ÅÅ-MM-DD TT:MM) Mappad till OBIS 9.36 046Dxxxxxxxx Bit 31-28 = år-högt* Bit 27-24 = Månad Bit 23-21 = år-lågt* Bit 20-16 = Dag Bit 15 = Sommartidsflagga Bit 14-13 = Århundrade Bit 12-8 = Timme Bit 7 = Felflagga Bit 6 = Reserverad för framtida användning* Bit 5-0 = Minut Årtalet läses genom att kombinera fältet år-högt och år-lågt. Till exempel, årshögsta = 0010 och årslägsta = 010 =&; år = 0010010 0 = standardtid, 1= sommartid 0 = tidsstämpel är giltig, 1 = tidsstämpel är inte** giltig
2	Mätar-ID	6 byte	Enligt M-Bus EN13757-3 identifieringsfält	Mätar-ID 0C78xxxxxxxx
3	Energi	6-7 byte	INT32	Energiförbrukning (Wh, J) 0406xxxxxxxx = xxxxxxxx * 0,001 MWh (kWh) 0407xxxxxxxx = xxxxxxxx * 0,01 MWh 04FB00xxxxxxxx = xxxxxxxx * 0,1 MWh 04FB01xxxxxxxx = xxxxxxxx MWh 040Exxxxxxxxx = xxxxxxxx * 0,001 GJ (MJ) 040Fxxxxxxxx = xxxxxxxx * 0,01 GJ 04FB08xxxxxxxx = xxxxxxxx * 0,1 GJ 04FB09xxxxxxxx = xxxxxxxx GJ
4	Volym	6 byte	INT32	Volym (m³) 0413xxxxxxxx = xxxxxxxx * 0,001 m³ 0414xxxxxxxx = xxxxxxxx * 0,01 m³ 0415xxxxxxxx = xxxxxxxx * 0,1 m³ 0416xxxxxxxx = xxxxxxxx m³
5	Effekt	4 byte	INT16	Effekt (W) 022Bxxxxxx = xxxxxx * 0,001 kW (W) 022Cxxxxxx = xxxxxx * 0,01 kW 022Dxxxxxx = xxxxxx * 0,1 kW 022Exxxxxx = xxxxxx kW
6	Flöde	4 byte	INT16	Flöde (m³/h) 023Bxxxxxx = xxxxxx * 0,001 m³/h 023Cxxxxxx = xxxxxx * 0,01 m³/h 023Dxxxxxx = xxxxxx * 0,1 m³/h 023Exxxxxxx = xxxxxx m³/h
7	Fw temp	4 byte	INT16	Framledningstemperatur (°C) 025Axxxx = xxxx * 0,1 °C 025Bxxxx = xxxx * °C
8	Rt temp	4 byte	INT16	Returtemperatur (°C) 025Exxxx = xxxx * 0,1 °C 025Fxxxx = xxxx °C
9	Felflaggor	5 byte	INT16	Fel- och varningsflaggor 02FD17xxxx För ytterligare information om felflaggor, se den senaste mätarens manual
10	Tariff 1 Energi	7 byte	INT32	Tariff 1 Energiförbrukning (Wh, J) 841003xxxxxxxx = xxxxxxxx Wh 841003xxxxxxxx = xxxxxxxx * 10 Wh 841003xxxxxxxx = xxxxxxxx * 100 Wh 841003xxxxxxxx = xxxxxxxx kWh 841003xxxxxxxx = xxxxxxxx 10 kWh 841003xxxxxxxx = xxxxxxxx MJ 841003xxxxxxxx = xxxxxxxx 10 MJ
11	Tariff 2 Energi	7 byte	INT32	Tariff 2 Energiförbrukning (Wh, J) 842003xxxxxxxx = xxxxxxxx Wh 842003xxxxxxxx = xxxxxxxx * 10 Wh 842003xxxxxxxx = xxxxxxxx * 100 Wh 842003xxxxxxxx = xxxxxxxx kWh 842003xxxxxxxx = xxxxxxxx 10 kWh 842003xxxxxxxx = xxxxxxxx MJ 842003xxxxxxxx = xxxxxxxx 10 MJ
12	Tariff 3 Energi	7 byte	INT32	Tariff 3 Energiförbrukning (Wh, J) 843003xxxxxxxx = xxxxxxxx Wh 843003xxxxxxxx = xxxxxxxx * 10 Wh 843003xxxxxxxx = xxxxxxxx * 100 Wh 843003xxxxxxxx = xxxxxxxx kWh 843003xxxxxxxx = xxxxxxxx 10 kWh 843003xxxxxxxx = xxxxxxxx MJ 843003xxxxxxxx = xxxxxxxx 10 MJ
13	Saknar tid	6 byte	INT32	3C22xxxxxxxx = xxxxxxxx timmar 3C23xxxxxxxx = xxxxxxxx dagar

JSON

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.

Tabell 33. Payload, JSON-kodat meddelande

Fält	JSON-nyckel
Mätar-ID	ID
Mätarens datum / tid	TS
Energi	E
Energienhet	U
Volym	V
Volymenhet	VU
Effekt	P
Strömenhet	PU
Flöde	F
Flödesenhet	FU
Vidarebefordra temperatur	FT
Vidarebefordra temperaturenhet	TU
Returtemperatur	RT
Returtemperaturenhet	RU
Felflaggor	EF
Tariff 1 Energi	T1
Tariff 1 Energienhet	U1
Tariff 2 Energi	T2
Tariff 2 Energienhet	U2
Tariff 3 Energi	T3
Tariff 3 Energienhet	U3
Saknar tid	MT
Tidsenhet saknas	MU

Exempel på payload, JSON:

{

"TS":"2019-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"

}

SenML/CBOR

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.

Notera

SenML, CBOR och M-Bus är separata standarder, detta avsnitt beskriver hur produkter kan använda dessa tre tillsammans för att representera flera mätvärden i ett kompakt format lämpligt för radiosändning över till exempel NB-IoT.

Struktur för SenML-paketet

Mätaravläsningsdata skickas som SenML, det vill säga en lista (eller array) av avläsningsvärden (poster), kodade med CBOR. Varje post är en karta över nyckel/värdepar med hjälp av SenML.

Notera

Varje produkt som använder SenML/CBOR-formatet måste följa kraven nedan. Dessutom ska det specificera det exakta innehållet i de inkluderade datavärdena, mätar-ID-format etc. Således är denna specifikation ensam inte tillräcklig för att bygga en parser för en specifik produkt.

Bastid

Base time används för att ställa in en referenstid.

Tidsstämplar är alltid kodade enligt SenML (det vill säga UNIX-tid) (SenML-etikett -1 "Bastid", SenML-definition av Tidsfält)
Detta värde måste inkluderas i den första posten i paketet
Alla andra värden har ett tidsvärde som läggs till bastiden för att definiera den exakta tiden för avläsningen

Basnamn

Base name används för att representera MätarID (Mätaridentifikation in M-Bus) för produkter som levererar mätdata för en mätare.

Om basnamn används
- Detta värde MÅSTE finnas med i den första posten i paketet
- Detta representeras som en strängmatris (CBOR Major Type 3 - SenML-etikett -2 "Basnamn")
  - Produkten ska specificera det exakta formatet för detta fält, eftersom det kan variera beroende på vilken typ av "mätare" som används. För ett M-Busformat är det vanligtvis M-Busdata utan DIF/VIF.
- Inget namn har angivits för återstående mätaravläsningsvärden, endast värden som tillhör en enskild mätare kan representeras i ett paket.
Om avläsningar som ska skickas innehåller olika MeterIDs (modul flyttad mellan mätare till exempel) får de INTE skickas i samma SenML-paket
- Alla värden i ett SenML-paket MÅSTE vara för samma MeterID
- Datavärdena FÅR INTE ha ett namnvärde som specificerar namnet för varje värde.
Basnamn FÅR INTE användas för SenML-paket som har data för flera mätare. I sådana fall ska varje post innehålla mätarens MeterID.

Datavärden

De faktiska värdena från mätaren kan kodas med flera metoder, såsom M-Bus.
Den första posten kan också innehålla ett datavärdefält som innehåller mer information än de återstående posterna i paketet. Detta för att inkludera mer information för den första läsningen och sedan endast en delmängd av värden för de återstående posterna för att spara utrymme. (SenML-etikett 8 - "Data value")

Andra värden

(Bas) Enheten används inte, eftersom enheten specificeras av M-Busdata
Ett "Encoder Version-fält" används i en separat post för att definiera typen och versionen av den kodade payloaddatan.

Ytterligare poster

Alla poster i SenML-paketet förväntas innehålla mätvärden. Om det finns ett behov av att överföra ytterligare information i samma paket kan ytterligare poster läggas till. För sådana poster ska namnfältet användas genom att definiera ett namn med minst ett tecken. I SenML läggs basnamnet och namnfälten till för ett slutligt namn på posten.

Namnet måste innehålla minst ett tecken förutom [A-Fa-f0-9] vilket betyder icke-hexadecimal representation, eftersom mätar-id vanligtvis är decimal/hexadecimal, och detta gör det lättare att kontrollera att namnet på posten är giltigt.

Om en parser hittar en post med ett namnfält som den inte känner igen ska den ignorera posten.

Följande ytterligare poster används för närvarande:

Spela in	Namnfält	Kommentar
Kodartyp & Version	"V"	Detta fält gör det möjligt att definiera versioner för innehållet i mätfältet.

Kodartyp & Version

Följande tabell definierar tillåtna kodartyper och versioner. Informationen skickas i en särskild post "Encoder Version field".

Detta fält kapslar in både kodningen av data och versionshantering
Den innehåller ingen tidsstämpel
Den är kodad som ett SenML-värde
Den har ett Namn-fält med den enda bokstaven "V"
Om en ogiltig version påträffas vid tolkning ska tolkningen stoppas med ett felmeddelande
Värdet ska tolkas som ett UINT16
- Den första byten är kodartypen och den andra är kodarversionen, båda tolkade som UINT8.
  
  Exempel: värde 0x0102 betyder kodartyp 0x01 och kodarversion 0x02.
- Definierade giltiga kodartyper och versioner finns i en tabell nedan på denna sida o
- Storleken på hela posten är maximalt 7 byte
Om posten exkluderas är encoder-typen 0 och encoder-versionen är 0

Spela in

Namnfält

Data

Kommentar

0 (M-Bus)

0x0000

M-Buskodning av payloaddata. Varje datapost innehåller alla DIF/VIF/Värden enligt M-Bus.

Notera att M-Bus använder LSB-ordning ("least significant byte" först) för data även här.

Exempel och datastorlek

Nedan är några verkliga exempel på payload. Observera att detta inte är identiskt med den ovan i några avseenden:

BaseTime innehåller en tagg(1) (Epokbaserat datum/tid). Detta krävs inte av SenML/CBOR.
Typ/version av kodare placeras sist i basmatrisen.

Raw (Base64):

hqMhaDcxOTUxMzE4IsEaZtB0VAhYIQQGAHcDAAQUYdgKAAItEwACO1QBAlogAgJe8AEC/RcAAKIGOQODCFghBAYAdwMABBRY2AoAAi0TAAI7VAECWh8CAl7wAQL9FwAAogY5BwcIWCEEBv92AwAEFFDYCgACLRgAAjteAQJaHwICXuMBAv0XAACiBjkKiwhYIQQG/3YDAAQUR9gKAAItEwACO1QBAloeAgJe7wEC/RcAAKIGOQ4PCFghBAb+dgMABBQ/2AoAAi0UAAI7SgECWiACAl7sAQL9FwAAogBhVgIA

Avkodas med hjälp av CBOR-avkodare.:

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)

Validatorer

På https://cbor.me/ finns en validator för CBOR. Observera att den inte förstår SenML eller M-Bus.

Notera

En liten bugg har identifierats i hex-tolkningen av negativa tal i validatorn. Ha detta i åtanke om du använder validatorn.

Konfiguration

SenML/CBOR är att betrakta som en meddelandekodning. Den definierar hur meddelandena kodas, men inte det faktiska innehållet i meddelandena (vilka fält från mätaren som ingår). SenML/CBOR/M-Bus är en sådan kodning, men det kan finnas flera baserat på denna SenML/CBOR-specifikation och kodarversionsfältet ovan definierar exakt vilken typ och version som används.

Innehållet i meddelandet definieras av meddelandeformatet. Meddelandeformatet anger vilka fält som ska inkluderas i både den första och de efterföljande posterna i SenML-paketet.

Antalet poster som ingår i ett paket ställs in av avläsnings- och sändningsintervallen. Se Schemalagda Avläsningar för mer information. Om avläsningsintervallet är 120 minuter och sändningsintervallet är 1440 minuter kommer totalt 12 avläsningar att inkluderas.

Begränsningar av meddelandestorlek

Varje produkt kan ha olika maximala payloadstorlekar i ett enda telegram. Beroende på konfiguration (till exempel DTLS eller inte) kan payloadens nettostorlek variera. Därför ska enheten "fylla" så många telegram som krävs för att skicka data. Användaren måste definiera en konfiguration som ger en rimlig avvägning mellan strömförbrukning (skicka färre telegram) och funktionskrav (mycket data skickas).

Om en enhet är konfigurerad med ett meddelandeformat och många avläsningar kanske data inte får plats i ett enda telegram. I sådana fall ska flera telegram skickas och varje telegram ska vara helt självbeskrivet, det vill säga innehålla mätar-ID, tidsstämplar etc.

Exempel 1

Parameter	Värde
Avläsningsintervall	60
Sändningsintervall	1440 (daglig)
Meddelandekodning	SenML/CBOR/M-Bus version 0
Meddelandeformat	Standard
Max sändningar per dag	3

Detta exempel resulterar i sändning av ett meddelande per dag, innehållande 24 avläsningar, alla med innehållet definierat i meddelandeformatet Standard. Data kodas med SenML/CBOR/M-Bus. Maximalt 3 icke-sända meddelanden skickas varje gång (om meddelandena av någon anledning inte skickades "förra gången"). Så maximalt sända meddelanden per dag är 3 (innehåller 3x24=72 avläsningar, som täcker 3 dagar)

Exempel 2

Parameter	Värde
Avläsningsintervall	120
Sändningsintervall	720
Meddelandekodning	SenML/CBOR/M-Bus version 0
Meddelandeformat	Tariff
Max sändningar per dag	2

Detta exempel resulterar i sändning av ett meddelande var 12:e timme, innehållande 6 avläsningar, alla med innehållet definierat i Tariffmeddelandeformatet. Data kodas med SenML/CBOR/M-Bus. Maximalt 2 osända sådana meddelanden skickas varje gång (om meddelandena av någon anledning inte skickades "förra gången"), så maximalt sända meddelanden per dag är 4 (innehåller 4x6=24 avläsningar, som omfattar 2 dagar).

Återställ procedurer

Startar om modulen

För att starta om modulen, använd Elvaco OTC-appen.

Öppna Elvaco OTC-appen.
Skanna modulen.
Gå till Tillämpa-läge.
Välj omstartsbrytaren och tillämpa ändringarna.

Notera

Denna funktion är begränsad till registrerad ägare av produkten i Elvaco OTC-appen och är inte synlig/tillgänglig för andra användare.

Stänger av modulen

Använd Elvaco OTC-appen för att stänga av modulen.

Öppna Elvaco OTC-appen.
Skanna modulen.
Gå till Tillämpa-läge.
Välj Stäng av och tillämpa ändringar.

Notera

Denna funktion är begränsad till registrerad ägare av produkten i Elvaco OTC-appen och är inte synlig/tillgänglig för andra användare.

Var denna artikel till hjälp?

0 av 0 tyckte detta var till hjälp

Har du fler frågor? Skicka en förfrågan

Artiklar i detta avsnitt

Kommentarer (0 kommentarer)

Artikeln är stängd för kommentarer.