Betrieb

Zählerdaten können entweder mit MQTT-SN oder LwM2M Send übertragen werden. Die Protokolle können nicht gleichzeitig verwendet, aber über LwM2M oder die Elvaco OTC App konfiguriert werden. Der Inhalt der übertragenen Daten bleibt unabhängig vom ausgewählten Transportprotokoll gleich. Bei einer geplanten Zählerdatenübertragung werden die gesendeten Daten durch das ausgewählte Nachrichtenformat festgelegt. Noch nicht gesendete Zählerdaten im Modul werden gemäß der ausgewählten Wiederherstellungsstrategie übertragen (First in First out (FiFO) oder Last in First out (LiFo)).

Das Modul ist auf die Uhr des Zählers angewiesen, um die Zeit zu halten. Es wird davon ausgegangen, dass die Zeit im Zähler in der Standard-Ortszeit (keine Sommerzeit) angegeben ist. Bei der Zeitsynchronisation im Zähler-mit der Elvaco OTC-App wird immer die lokale Standardzeit verwendet, auch wenn die Sommerzeit in Kraft ist. Die vom Modul gesendeten zeitgestempelten Zählerdaten können durch Angabe des Konfigurationsparameters "UTC-Offset" so eingestellt werden, dass sie in UTC gesendet werden. Der UTC-Offset wird vor der Übertragung vom Zeitstempel abgezogen. Wenn sich der Zähler in Schweden befindet, wo die MEZ (mitteleuropäische Zeit) gilt, sollte der UTC-Offset auf +60 (+1h) eingestellt sein. In diesem Fall wird um 12.00 Uhr ein Telegramm mit dem Zeitstempel 11.00 gesendet, da dies die entsprechende UTC-Zeit ist. Ein Zähler in New York (USA) sollte einen UTC-Offset von „-300“ (-5h) haben usw. Ein UTC-Offset von „0“ bedeutet, dass die Zählerzeit unverändert verwendet wird.

Wenn der Zähler auf Sommerzeit eingestellt ist, ignoriert das Modul diese Einstellung und verwendet die Standardzeit. Daher kann die Uhrzeit auf dem Zählerdisplay von der Uhrzeit im Telegramm oder in der Elvaco OTC App abweichen.

Alle Zeitpläne werden mit einer Uhr synchronisiert. Ein Auslesezeitplan von 60 Minuten wird auf volle Stunden synchronisiert, beispielsweise 11:00, 12:00 und 13:00. Bei 120 Minuten ergeben sich 12:00, 14:00 und 16:00. Wenn die Zeit im Modul oder Zähler synchronisiert wird, erfolgt eine Neuplanung, sodass die nächste Zählerauslesung gemäß der aktualisierten Zeit durchgeführt wird. Die Zähleruhr kann periodisch (automatisch) oder manuell synchronisiert werden. Eine periodische Synchronisierung wird empfohlen, damit die Uhr nicht zu stark abweicht.

Um den Fall zu behandeln, dass die Zeitsynchronisation die Zeit über eine zuvor geplante Ablesung hinaus "verschiebt" (z.B. 23.58 → 00.02), wird das Modul immer eine Ablesung und Übertragung eines neuen Wertes vornehmen, wenn die Zeit synchronisiert wird. Das Gerät wird daher eine zusätzliche Auslesung senden, die auf der Serverseite ausgeblendet werden kann.

Um zu verhindern, dass eine große Anzahl von Geräten Daten genau zur gleichen Zeit überträgt, sollten die Geräte vor der Datenübertragung eine zufällige Verzögerung aufweisen. Die Verzögerung ist entweder über die Elvaco OTC-App und die NFC-Schnittstelle oder aus der Ferne über ein Geräteverwaltungssystem konfigurierbar.

Zählerauslesungen erfolgen immer zur vollen Stunde, beispielsweise um 11.00 Uhr und 13.00 Uhr. Übertragungen können zu anderen Zeiten stattfinden, werden jedoch anhand eines festgelegten Übertragungsintervalls (T_transmit) für volle Stunden geplant. Die folgende Abbildung veranschaulicht dies. Die Übertragungen werden für den Zeitpunkt T₁ geplant. Das tatsächliche T_transmit ist ein zufälliger Zeitpunkt zwischen (T₁ + T_offset) und (T₁ + T_offset + T_delay).

T_Übertragung, T_Offset and T_Verzögerung sind Parameter im Produkt.

Bedingungen

• T_Offset + T_Verzögerung <= T_Übertragung

Dies sollte vom Gerät und der OTC-App überprüft werden.

• Wenn T_transmit auf einen Wert unter T_offset + T_delay reduziert wird, muss T_offset auf 0 gesetzt werden und T_delay = T_transmit gelten.

Wenn Daten nicht gesendet werden können, z. B. aufgrund von Netzwerkproblemen, gibt es eine Reihe von Wiederholungsversuchen, nach denen das Gerät aufgibt und die Anzeige als "nicht gesendet" in seinem Speicher belässt. Beim nächsten Übertragungsversuch werden nicht gesendete Daten erneut gesendet (wenn möglich). Die erneute Übertragung kann durch FIFO oder LIFO erfolgen.

Regeln für die erneute Übertragung umfassen das maximale Alter der Daten, die Reihenfolge der Daten, die Anzahl der erneut übertragenen Daten/das Übertragungsintervall.

Im zählergesteuerten Modus wird das im Diehl SHARKY- oder SCYLAR-Zähler festgelegte kundenspezifische Telegramm transparent und unverändert gesendet. Dieses Telegramm ist in der Regel bei der Lieferung im Zähler vorkonfiguriert, kann jedoch auch vor Ort angepasst werden. In diesem Modus wird die Nachrichtenkodierung automatisch auf SenML/CBOR eingestellt, um größere kundenspezifische Telegramme zu übertragen. Da Diehl SHARKY und SCYLAR das M-Bus-Protokoll verwenden, liegt auch die in den SenML/CBOR-Paketen übertragene Nutzlast im M-Bus-Format vor.

Im modulgesteuerten Modus hängen die gesendeten Daten vom ausgewählten Nachrichtenformat ab. CMi6160 bietet die beiden Nachrichtenformate Standard und Tariff. Eine vollständige Liste der in den einzelnen Formaten enthaltenen Datensätze finden Sie in Abschnitt Nachrichtenformate.

Zähleralarme werden über das ausgewählte Transportprotokoll MQTT-SN oder LwM2M Send übertragen. Der Inhalt der übertragenen Daten ist unabhängig vom ausgewählten Transportprotokoll identisch. Wenn ein Alarm ausgelöst wird, entspricht die Nachricht dem ausgewählten Format und die erweiterten Fehlercodes werden angehängt. Noch nicht gesendete Zählerdaten im Modul werden gleichzeitig mit dem Alarm übertragen.

Jedes Bit in der Alarmmaske ist direkt einem Zählerfehler zugeordnet. Die verschiedenen Alarmmasken zur Steuerung der Alarmüberwachung verwenden dieselbe Zuordnung. In den folgenden Abschnitten wird beschrieben, wie die einzelnen Bitmasken verwaltet und interpretiert werden.

In der folgenden Tabelle sind die verfügbaren Zählerfehler und ihre Zuordnung zur Bitmaske aufgeführt.

Bei Verwendung des Nachrichtenformats Tariff kann eine typische Nutzlast wie folgt aussehen:

04139C2E0000023B0000325A0000325E0000841006000000008420FD320000000001FD1750

Wenn dieselbe Nutzlast als Alarmmeldung gesendet wird, werden die erweiterten Fehlercodes an die Nutzlast angehängt:

04139C2E0000023B0000325A0000325E0000841006000000008420FD320000000001FD175002FD180800

Die erweiterten Zählercodes werden durch M-Bus-DIF/VIF 2FD18, Error Mask, identifiziert; darauf folgen die beiden Fehlerbytes 0x0800. Da M-Bus Little-Endian-Kodierung verwendet, lautet die vollständige Fehlermaske 0b0000 0000 0000 1000. Dies bedeutet, dass Fehlerbit 3 gesetzt ist und ein Problem mit den Temperaturmessungen vorliegt (siehe Tabelle zur Interpretation von Zählerfehlern).

Das Systemprotokoll des Moduls kann über MQTT-SN oder LwM2M Send übertragen werden. Welches Protokoll verwendet wird, hängt vom ausgewählten Transportprotokoll für die Zählerdaten ab. Der Inhalt der übertragenen Daten bleibt unabhängig davon gleich. Wenn im Modul ein Systemprotokolleintrag gespeichert wird, dessen Systemprotokollebene für das Senden konfiguriert ist, wird er zusammen mit der nächsten Zählerdatenübertragung gesendet. Alle noch nicht gesendeten Protokolleinträge, die gesendet werden sollen, werden einbezogen.

Unabhängig davon, ob das Systemprotokoll über MQTT-SN oder LwM2M Send gesendet wird, ist die Nutzlast gemäß dem SenML-Datenmodell strukturiert und mit CBOR kodiert. Die Systemprotokollmeldung selbst wird als ASCII-Zeichenfolge im SenML-Datensatz gespeichert.

Eine vollständige Beschreibung der Kodierung von SenML/CBOR-Paketen finden Sie in Abschnitt SenML/CBOR. Das folgende Beispiel zeigt vereinfacht, wie eine Systemprotokollmeldung von der Roh-Nutzlast bis zur menschenlesbaren Meldung dekodiert wird.

Bei Verwendung des M-Bus als Nachrichtenkodierungsverfahren werden die Daten in Dateninformationsblöcke (DIB) unterteilt, die ein Dateninformationsfeld (DIF-Code), ein Wertinformationsfeld (VIF-Code) und ein Datenfeld (DATA) umfassen, in dem die eigentliche Nutzlast gespeichert wird (in der folgenden Abbildung veranschaulicht).

DIB-Struktur

Die nachstehende Tabelle enthält ausführliche Beispiele für die Kodierung von Daten bei Verwendung der Nachrichtenkodierung M-Bus.

Bei Verwendung der JSON-Nachrichtenkodierung bestehen die gesendeten Nachrichten aus einem Objekt mit einer Liste von Schlüssel-Wert-Paaren. Beispiele für die Bezeichnungen der einzelnen Werttypen und Einheiten sind in der nachstehenden Tabelle aufgeführt. Die Werte werden als Zahlen oder Zeichenfolgen codiert und die Einheiten werden als Zeichenfolgen codiert. JSON bietet eine für den Menschen lesbare Datenkodierung, die allerdings nicht so kompakt ist wie z. B. SenML/CBOR.

Beispiel Nutzlast, 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"}

Bei batteriebetriebenen Geräten wird empfohlen, mehrere Messungen im selben UDP-Frame zu senden, um Energie zu sparen. Hierzu werden SenML (Sensor Measurement Lists) und CBOR (Concise Binary Object Representation) verwendet, um eine Messliste zu definieren.

Die Idee ist, eine Liste von Messungen zu senden, wobei der erste Eintrag die Basiszeit für alle Auslesungen (die nur einen Offset angeben müssen) und die für alle Auslesungen gemeinsame Zähler-ID enthält. Die anderen Datensätze in der Liste enthalten möglicherweise weniger ausgelesene Felder, um Platz zu sparen. Das Format erlaubt es, alle Daten für jede Auslesung zu senden. In diesem Fall ist die Einsparung (in Form von Bytes) geringer und liegt darin, dass weniger Telegramme gesendet werden, einige Daten nicht für jede Auslesung übertragen werden müssen (wie die Zähler-ID) und Zeitstempel effizienter gehandhabt werden können. SenML/CBOR bietet auch eine Möglichkeit, Listen von Messwerten effizient zu strukturieren.

Elvaco verwendet die SenML/CBOR/M-Bus-Datendarstellung, um Zählerdaten kompakt und selbstbeschreibend zu übertragen. Die übertragenen Daten werden als Paket bezeichnet, das einen Datensatz pro Messung enthält.

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

Beim Zurücksetzen auf die Werkseinstellungen werden die Geräteeinstellungen auf die Werkseinstellungen zurückgesetzt. Außerdem werden alle im Modul gespeicherten Zählerdaten und Systemprotokolleinträge gelöscht. Das Zurücksetzen kann entweder über die Elvaco OTC App oder remote über LwM2M (Ressource 3/./5) erfolgen.