Betrieb

Zählerdaten können entweder mit MQTT-SN oder LwM2M Send übertragen werden. Die Protokolle können nicht gleichzeitig verwendet, das Gerät kann jedoch ü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 (älteste zuerst (FIFO) oder neueste zuerst (LIFO)).

Das Modul verwendet die Uhr des Zählers zur Zeiterfassung. Die Zählerzeit wird als lokale Standardzeit (ohne Sommerzeit) vorausgesetzt. Bei der Zeitsynchronisation des Zählers mit der Elvaco OTC App wird stets die lokale Standardzeit verwendet, auch wenn die Sommerzeit gilt. Die vom Modul gesendeten Zählerdaten mit Zeitstempel können durch Angabe des Konfigurationsparameters „UTC-Offset“ auf UTC angepasst werden. Der UTC-Offset wird vor der Übertragung vom Zeitstempel abgezogen. Befindet sich der Zähler in Schweden, wo MEZ (Mitteleuropäische Zeit) gilt, muss der UTC-Offset auf +60 (+1 h) gesetzt sein. In diesem Fall wird um 12:00 Uhr ein Telegramm mit dem Zeitstempel 11:00 gesendet, da dies der entsprechenden UTC-Zeit entspricht. Für einen Zähler in New York (USA) muss der UTC-Offset beispielsweise auf „-300“ (-5 h) gesetzt sein. 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, weisen die Geräte vor der Datenübertragung eine zufällige Verzögerung auf. Die Verzögerung kann entweder über die Elvaco OTC App und die NFC-Schnittstelle oder aus der Ferne über ein Geräteverwaltungssystem konfiguriert werden.

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_transmit, T_offset und T_delay sind Parameter des Produkts.

Bedingungen

• T_offset + T_delay <= T_transmit

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 Modus Benutzerdefiniert wählt der Benutzer aus, welche unterstützten Zählerregister das Modul in die übertragenen Nutzdaten aufnimmt. Jedes auswählbare Register ist einem Bit in der Bitmaske der benutzerdefinierten Übertragungsfelder zugeordnet (siehe Benutzerdefiniertes Nachrichtenformat für verfügbare Register).

Bei Verwendung des Modus Voreingestellt hängen die gesendeten Daten vom ausgewählten Nachrichtenformat ab. CMi6110 bietet zwei Nachrichtenformate zur Auswahl: Standard und Erweitert. Eine vollständige Liste der in den Formaten enthaltenen Datensätze finden Sie in Abschnitt Voreingestellte 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.

Die folgende Tabelle zeigt die verfügbaren Zählerfehler und ihre Zuordnung zur Bitmaske.

Bei Verwendung des Nachrichtenformats Standard können typische Nutzdaten wie folgt aussehen:

046D002A323B0C7837266966040637570A000414EF472000022B0000023BFCFF025B0000025F000002FD170400

0x02FD17 ist der M-Bus-DIF/VIF-Indikator für Fehlerflags, und die folgenden beiden Bytes 0x0400 zeigen einen Fehler an. Da die M-Bus-Codierung das LSB verwendet, wird die entsprechende Bitmaske als 0x00 04 gelesen. Daraus ergeben sich die Bits 0b0000 0000 0000 0100. Dies bedeutet, dass Bit 2 gesetzt ist und ein Problem mit dem Rücklauftemperatursensor vorliegt (siehe Tabelle Interpretation der Zählerfehler oben).

Werden die Nutzdaten stattdessen als Alarmmeldung gesendet, sehen sie ähnlich aus; zusätzlich werden jedoch die erweiterten Fehlercodes an die Nachricht angehängt:

046D0F2A323B0C7837266966040637570A000414EF472000022B0000023BFCFF025B0000025F000002FD17040002FD180400

0x02FD17 kennzeichnet erneut die Fehlerflags, und die folgenden beiden Bytes 0x04 00 sind mit dem obigen Beispiel identisch. Da diese Nachricht als Alarm ausgelöst wurde, werden die erweiterten Fehlercodes an die Nutzdaten angehängt, siehe 02FD180400. FD18 kennzeichnet eine M-Bus-Fehlermaske. Die Bytes der Fehlermaske werden wie die Fehlerflags anhand der Informationen in der obigen Tabelle Interpretation der Zählerfehler decodiert.

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.

Beispielnutzdaten, 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"
}

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.

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)