Integration des Cayenne Low Power Payload Protocol

About

Das Protokoll Cayenne Low Power Payload (kurz: CayenneLPP) beschreibt ein binäres Serialisierungsformat für Meßdaten, ist im LoRaWAN-Umfeld populär und daher auch in die TTN-Plattform integriert.

… todo: IPSO Alliance Smart Objects für Sensor-Identifier; Hartes Mapping auf Wertkodierungsbreite; etc. pepe.

Documentation

Implementations

1 Like

Shipping MicroPython support

Release Shipping MicroPython support · smlng/pycayennelpp · GitHub

für Arduino:

1 Like

Vielen Dank!

Hier gibt es ganz frisch ein paar interessante Erweiterungen.


nicht unspannend… ;)
vor allem binary und kompakt… das passt dann (wenn man will) auch in 8byte payload ueber can, nicht nur lora…

nach dem blaettern in Cayenne Docs und pycayennelpp/cayennelpp at master · smlng/pycayennelpp · GitHub wird schnell klar das es viel komplexer klingt als es ist :)

der wichtige part ist folgender:

  • es gibt bis zu 256 ‘channels’ (1byte)
  • es gibt eine tabelle von bis zu 256 ‘datentypen’ (1byte)
  • je nach datentyp folgen N byte (das muss der decoder anhand des type schon wissen)

schade ist das ich keinerlei version bits, crc oder so gesehen hab. das muss man dann wohl selbermachen. (oder einen transport der das kann benutzen… can hat crc…)
schon very basic, aber trafficsparend.

allerdings ist die liste der typen und die jeweils handgemalten en/decoder eben nie ‘vollstaendig’ ;)
wenn man staendig mit neuen sensoren spielen will muss man also abundzu code anfassen.
ein laengenfeld kostet halt immer ein paar bit, dafuer koennte der deframer generischer sein.

2 Likes

Ja. @Thias und @tonke sind auch Fans.

Medium. Aber der Teufel steckt im Detail einer universellen Integration und die Standarddatentypen fühlen sich teilweise nicht ausreichend an – ich denke wir haben da ähnliche Ziele. Zusammen mit @tonke und @einsiedlerkrebs haben wir da schon ein paar Gedanken reingesteckt. Beim nächsten Mal können wir uns gern drüber austauschen – #cccamp oder so.

Die kamen als Vorschläge nun auch hier bei der CPython-Implementierung an, der wir uns schon einmal genähert hatten.


Generic 4-byte unsigned integer

In der Reihe…

cc @Thias, @tonke, @roh

Drüben bei Unlocking LoRaWAN / TTN on the LoPy4 within Terkin machte sich @Thias nach der Erschließung des Transportkanals per MicroPython irgendwann Gedanken über die Integration des CayenneLPP-Protokolls, um die Meßdaten möglichst optimal von A nach B transportieren zu können.

Gerade weil z.B. beim Temperaturrechen mehrere Sensoren gleichen Typs verwendet werden, muss man irgendwie eine Zuordnung der Sensoren zu den Telemtriefeldnamen vornehmen können.

Wie sonst könnte man das gestalten?

Mein Gedanke hierzu ist: Der Sensorknoten schickt einmalig eine Art Announcement-Paket, das dem Backend das Sensor-Mapping reichhaltiger mitteilt. Dann schwummst das auch besser gleich ins Grafana rein. Im Falle von LoRa müsste dann auch die Channel-ID in dieses Announcement-Paket rein, so dass wir vollen Komfort beim Roundtrip bekommen.

Solcherlei Gedanken hegten wir zusammen mit @tonke und @einsiedlerkrebs, als wir vor einiger Zeit an den Grundlagen für den LoRaWAN-Support gearbeitet hatten.

Mein Gedanke auf dem Arbeitsweg eben war:
So ein “Announcement-Paket” ist mit der begrenzten Flexibilität von CayenneLPP wohl schwierig umzusetzen. Mir fällt gerade nicht ein, wie das sinnvoll implementiert werden kann. Aber bestimmt bist du da schon weiter. Bedenke, dass wir bei LoRa die Pakete nicht beliebig aufblasen können.

Stattdessen dachte ich mir Folgendes: Wir reservieren für jeden Sensor einen 10er-Block Channels und fixieren die Blöcke auf Sensortypen, ala:

system.*    01..10
Waage       11..20
Außensensor 21..30
Innensensor 31..40
...

Wenn potentiell mehrere Innen- oder Außensensoren verwendet werden, dann entsprechend erweitern. Randbedingungen wäre, dass die name Tags der Sensoren entsprechend standardisiert sind oder wir ein neues Feld zu diesem Zwecke einführen. 10er Blöcke sind nötig, damit auch die DS18B20 Temperatursensor-Arrays wie sie u.a. von Clemens verwendet werden auch in einen Block passen. Ein Channel-Block startet mit ?1, damit das Mapping auf die Wabengassen im Code und Dashboard intuitiver ist.

Für die system.* Sensoren können wir auch nur den Channel 00 nutzen und dann für die Waage bei 01 starten. Es sei denn, es gibt system.* Variablen vom gleichen Typ zu senden, zB. Spannung von Batterie und Solarzelle. Das müssten wir nur frühzeitig festlegen.

Kotori kann dann anhand des TTN-Endpoints, das Mapping der Blöcke zurück auf Sensortypen und Nummer vollziehen und vielleicht auch von einem speziellen Template ein Dashboard ins Grafana wuppen.

1 Like

Nur ein Zwischeneinwurf, zur Orientierung…

… besonders dieser Abschnitt fiel mir auf:

1 Like

Also wenn ich das recht verstehe, hat man bei Cayenne maximal 64 Sensoren die jeweils unterschiedliche Datentypen haben können - ?

Mit Blöcken hat man immer relativ viel ‘Leerstand’. Auch neigen solche Systeme dazu zu ‘platzen’.
Bei nur 64 Sensoren würde ich eine einfache Zuordnungsliste mit den gängigen Sensoren bevorzugen. Die würde zentral verwaltet (also durch Kotori).
Man kann dann hinten (50-64) einen Bereich für Sondersensoren frei lassen. Dann hat man eine gewisse Flexibilität.

2 Likes

Wir machen so was momentan schon bei der HTTP-Annahme von CSV-Daten bei Kotori, dort wird auch erstmalig ein “header” geschickt, ähnlich wie die erste Zeile in einer Tabellenkalkulation mit Variablennamen, z.B.

Date/Time,Weight,Outside Temp,Outside Humid,Inside Temp,Inside Humid,H1 Temp,H2 Temp,H3 Temp,H4 Temp,H5 Temp,Voltage

Wenn der komplette header zu lange für eine TTN-Payload ist könnte man den auch trennen und jede Variablenbezeichnung mit einer Nummerierung als einzelne payload schicken, z.B.

unixtime.1 Date/Time
generic.1 Weight
temp.1 Outside Temp
temp.2 Inside Temp
temp.3 Broad Temp 1
... 

Wenn das mit Cayenne zu komplex ist, könnte man den header auch über eine andere application und nicht cayenne encodet schicken.

Wenn ich das richtig sehe, brauchen wir das vor allem, wenn wir mehrere Sensoren mit dem gleichen Typ haben, z.B. Innen und Aussen-Temperatur / Feuchtigkeit oder mehrere Brutraumsensoren, alle anderen ergeben sich aus dem Typ, wenn sie als Typ “unique” sind. Schön wäre noch ein Typ “Gewicht” für uns!

Vielleicht ist auch ein “simpler” Weg und eine “advanced” configuration sinnvoll? Bis zu zwei gleiche Sensoren sind als Konvention 1 draussen, 2 drinnen, alles komplexere wird dann über einen zuvor geschickten header gemapped.

Denke ich auch, will mal jemand Brutraumsensoren für 2 Brutmagazine wären wir mit 10 Sensoren schon am Ende und auch die Zuordnung / das “label”, z.B. Sensor in Wabengasse 2,4,6, oder Wabengasse 1,2,3,4,… oder Brutraum oder Honigraum usw. wäre schon super in der Variablenbezeichung untergebracht und nicht nur eine Durchnummerierung und späteres mapping nur in Grafana und nicht in den Daten als Variablenname in der Datenbank.

Wir sollten bei dieser Gelegenheit auch mal darüber nachdenken welche (Sensor-)Daten wir via LoRa wirklich schicken müssen. Mit WLAN schickt der Terkin datalogger ja momentan sehr viel, von memory-Geschichten bis hin zu den Rohdaten der Waage. Da sollten wir auch mal kritisch streichen bzw. eine Möglichkeit schaffen Daten nur optional z.B. zu Gunsten einer höheren Datenerhebungs-Frequenz zu schicken.

Am Beispiel des GitHub - cyberman54/ESP32-Paxcounter: Wifi & BLE driven passenger flow metering with cheap ESP32 boards kann man sich ggf. ebenfalls Inspirationen holen – siehe Paxcounter payload format.

Wie ist denn jetzt der Stand? Ich habe im code einige Funktionen gefunden, aber anscheinend gibt es nur wenig Doku dazu.

Konkrete Frage: kann ich mit Terkin Daten an Kotori per LPP schicken?
Wenn ja, wie? Wenn nein, warum nicht ? :slight_smile:

Hintergrund ist das T-CALL System, das per 2G Daten schicken soll. Da wäre LPP schon ein gutes Mittel.

Ich denke für 2G lohnt LPP nicht, du hast ja noch so viel Kommunikations-Overhead, da ist es dann egal, ob die Daten selbst nochmal geschrumpft sind weil das für die Gesamtmenge vielleicht 100 % vs. 95 % mit geschrupften Daten ausmacht.

LPP funktioniert in Terkin, @Thias und ich senden da schon muter Daten drüber. Das ist aber momentan eng an TTN gekoppelt, s.

Bei TTN encodet dann auch der TTN-Server die payload und schickt sie weiter, Daten in raw LPP encodet kann der Kotori afaik momentan nicht annehmen.

Was man hier also tun müsste

  • LPP vom Senden an TTN entkoppeln
  • bei Kotori eine Möglichkeit schaffen, LPP encodete Daten zu decoden und weiterzuverarbeiten.

Ja, wäre nice to have, für 2G alleine wäre mir das nicht wert. Vielleicht ist aber auch nicht so viel Arbeit wie es sich (für mich) anhört und @Andreas war evtl. auch schon mal am encoder dran. Teile existieren da auch (allerdings in JavaScrip), siehe Datenweiterleitung via TTN / LoRa zu Hiveeyes, BOB und BEEP einrichten

Spannend wird das dann, wenn mehr als ein Datensatz pro connect übertragen wird. Dann wird sich das schnell lohnen. Stände dann ja auch für alle anderen Übertragungswege mit begrenzter Bandbreite zur Verfügung.