Sensative Strips Payload-Konfiguration Teil 2: Manuelle Anpassung

Letzte Änderung am 11.04.2024

Vor Kurzem habe ich Euch gezeigt, wie Ihr Eure Strips (LoRaWAN-)Sensoren mithilfe der „Strips Configuration Application“ ganz einfach selbst konfigurieren könnt. Doch leider gibt es dort, wie in meinem Fall, nicht für alle Anwendungsfälle 100 % passende vordefinierte Profile. Dann hilft nur eine manuelle Anpassung der Payload. Wie das geht und wie eine Payload überhaupt aufgebaut ist, zeige Ich Euch heute am Beispiel meines Strips Multi-Sensors +Drip.

Mein Anwendungsfall:
Spülenschrank in der Küche überwachen mit Alarmierung bei Leckage und/oder zu lange geöffneter Türe. Warum? Zum einen hatte ich in meiner neuen Küche bereits mehrmals ein Leck in der Spüle, weshalb sich der Spülenschrank drohte aufzuweichen und zum anderen klettert meine Katze dort gerne hinein, wenn die Schranktüre zu lange offensteht. Da sich dies dank integriertem Kapazitätssensor (zur Leckage-Erkennung) und Magnetsensor (zur Öffnungszustands-Erkennung) mit nur einem einzigen +Drip umsetzen lässt, wollte ich diesen entsprechend konfigurieren. Weitere Beispiel-Use-Cases sowohl im privaten als auch geschäftlichen Bereich, für die eine solche Sensorik-Kombination relevant wäre, sind die Überwachung von Wohnräumen, Kellerräumen, Sanitärbereichen oder Büroräumen. 

Schritt 1: Erstellen einer „Basis“-Payload mithilfe der Strips Configuration App

Um Euch das Leben zu vereinfachen, könnt Ihr im ersten Schritt einfach mit der Strips Configuration Application eine „Basis“-Payload erstellen, wie ich bereits in Teil 1 dieser Beitragsserie beschrieben habe. Danach erst geht es dann an die manuelle Anpassung.

Schritt 2: Manuelle Anpassung der „Basis“-Payload mithilfe von Excel-Tabelle

Zur manuellen Anpassung Eurer „Basis“-Payload benötigt Ihr eine von Sensative zur Verfügung gestellte Excel-Tabelle namens „LoRa-Strips-Payload-formats-1.xlsx“, die Ihr Euch direkt hier herunterladen könnt. Dort sind die verschiedenen möglichen in der Payload enthaltenen Bit-Werte (BitValues) und deren Bedeutung aufgelistet. Bevor es an die eigentliche Anpassung geht, möchte Ich zunächst noch anhand meiner eigenen „Basis“-Payload erläutern, wie sich diese überhaupt zusammensetzt. Anhand dieses Beispiels seht Ihr dann auch, wie genau Ihr die Excel-Tabelle lesen müsst. Grundsätzlich besteht eine Payload i.d.R. immer aus einer hexadezimalen Zeichenfolge. Die Verwendung des Hexadezimalsystems ist in der Datenverarbeitung typisch, da es sich hierbei um eine komfortable Verwaltung des Binärsystems handelt. Dieses System eignet sich sehr gut zur Darstellung von Bitfolgen. Vier Stellen einer Bitfolge entsprechen dabei immer einer Ziffer im Hexadezimalsystem.

Zur Entschlüsselung der Payload benötigt Ihr nun die oben genannte Excel-Tabelle. Eine zentrale Information steht hier in Zeile 239 unter Punkt 1.3.1, und zwar dass der sog. „Configuration Value Report“ zum Setzen/Einspielen einer Konfiguration immer über Port 11 an den Sensor gesendet wird (analog zum Hinweis in der Configuration App) und dass der Inhalt eines Commands = Befehls immer aus 8 Bits besteht, was wiederum 2 Ziffern bzw. Zeichen im Dezimalsystem entspricht. Jede Payload beginnt, wie im Folgenden zu sehen ist, mit einem solchen Command.

Meine „Basis“-Payload: 01 0300006000 2200006002 1B00000E10
(Bitte beachtet: Die hier enthaltenen Leerzeichen wurden lediglich zur besseren Lesbarkeit der jeweils zusammengehörigen Zeichenblöcken ergänzt)

01 => Bei den ersten beiden Zeichen meiner Payload handelt es sich um den eben angesprochenen Command, der dem Sensor sagt, um was für eine Art von Payload es sich handelt. Die 1 steht wie der Tabelle zu entnehmen ist hier für „Set configuration values“ (s. Zeile 304 Punkt 2.3.1). Damit weiß der Sensor, dass eine Konfiguration vorgenommen werden soll. Es folgen die Zeichenblöcke mit den für die eigentliche Konfiguration benötigten Informationen. Diese wiederum bestehen immer aus „ValueID“ und „BitValue“. Die 2-stellige ValueID (entspricht 8 Bits) gibt dabei immer an, welcher Wert bzw. welcher Parameter konfiguriert werden soll und der darauffolgende 8-stellige BitValue (entspricht 32 Bits) enthält dann den jeweils eigentlichen Wert.

0300006000 => Der zweite Zeichenblock  der Payload beginnt mit der ValueID 03, die laut Tabelle für „Enabled sensors bitfield“ steht (s. Zeile 319/320 Punkt 2.3.2.1). Der Sensor weiß damit, dass die darauffolgenden 8 Zeichen (also 32 Bits) angeben, welche Reports aktiviert werden sollen. In diesem Fall folgt der BitValue 00006000, der sich wiederum nur durch eine Addition aus den BitValues des „FloodReport“ und des „FloodAlarm“ bilden lässt, also 00002000 + 00004000 = 00006000 (s. Zeile 433/434 Punkt 2.3.2.2). Somit weiß der Sensor, dass diese beiden Reports aktiviert werden sollen. Der FloodAlarm sorgt dafür, dass der Sensor ein Telegramm sendet, sobald er eine Leckage erkennt. Der FloodReport sorgt dafür, dass der Sensor in regelmäßigen Abständen (abhängig vom hinterlegten Wert) den aktuellen Status übermittelt (Leckage vs. Keine Leckage).

Kleiner Exkurs an dieser Stelle: Ihr fragt Euch vielleicht, warum hier nicht wie in der Tabelle eine 0x03 in der Payload steht? Ganz einfach, weil die 0x lediglich signalisiert, dass es sich hier um eine hexadezimale Zahl handelt. Der eigentliche Wert zur Umrechnung steht immer hinter dem 0x und besteht immer aus mindestens 2 Zeichen.

2200006002 => Der dritte Zeichenblock beginnt mit der ValueID 22, die laut Tabelle für „Combined sensors 1“ steht (s. Zeile 318/382 Punkt 2.3.2.1), also die von mir zuvor via Configuration App erstellte Report-Gruppe 1 (RG1) (siehe Teil 1 dieser Beitragsserie). Danach folgt über die nächsten 8 Ziffern 00006002 die Information, welche Reports in dieser Gruppe zusammengefasst werden sollen. Da die letzte dieser 8 Ziffern eine 2 ist, wisst Ihr anhand der Tabelle, dass es sich hier einmal um den „BatteryReport“ handelt (s. Zeile 421 Punkt 2.3.2.2). Der zweite Wert 6 lässt sich dann wieder aus der Addition von „FloodReport“ und „FloodAlarm“ bilden (s.o.).

1B00000E10 => Der letzte Zeichenblock beginnt mit der ValueID 1B, die laut Tabelle für „Flood report interval“ steht (s. Zeile 367/368 Punkt 2.3.2.1), also das Intervall, in dem der Sensor den jeweils aktuellen Status übermittelt (Leckage vs. Keine Leckage). Die nachfolgenden 8 Zeichen sagen dem Sensor dann, auf welchen Wert das Intervall gesetzt werden soll. In diesem Fall auf 0x0E10, was im Dezimalsystem 3.600 Sekunden entspricht.

Die „Basis“-Payload ist damit entschlüsselt. Aber wie lässt sich nun der noch immer inaktive Magnetsensor aktivieren? Dazu müsst Ihr wieder einen Blick in die Tabelle werfen. Dieser ist zu entnehmen, welche Werte den für den Magnetsensor verfügbaren Reports entsprechen. Ihr habt hier grundsätzlich die Möglichkeit, bspw. nur den „DoorAlarm“, nur den „DoorReport“ oder beides zu setzen. Ihr fragt Euch, was denn der Unterschied ist? Der DoorAlarm sorgt dafür, dass der Sensor lediglich dann sendet, wenn eine Türe, ein Fenster oder ein Tor geöffnet wird/wurde. Der DoorReport sorgt dafür hingegen, dass in einem definierten Intervall regelmäßig der aktuelle Status übermittelt wird, unabhängig davon, ob geöffnet oder geschlossen. In meinem Fall habe ich mich für beides entschieden, weshalb ich analog zu oben die Werte der beiden einmal addieren musste und damit auf einen Bit-Wert von 00000600 komme. Diesen Wert gilt es nun in der Payload von oben einzufügen. Um hierbei jedoch die anderen Reports nicht wieder zu deaktivieren, darf nicht einfach der Wert 00000600 in die Payload eingefügt werden, sondern zum aktuellen Wert wieder addiert werden. In diesem Fall wird damit aus dem Zeichenblock 2200006002 der Block 2200006602.

Die finale Payload, die nun zur Änderung der Konfiguration als Downlink an den Sensor geschickt werden muss, lautet in meinem Fall also: 01030000600022000066021B00000E10.

Wie genau Ihr einen solchen Downlink an Euren Sensor schicken könnt, wird Euch im Blog-Beitrag “ZENNER Datahub Howto: Downlinks versenden“ gezeigt.

Ihr habt Fragen oder Anregungen zu diesem Thema? Dann hinterlasst gerne einen Kommentar!