Integration des Cayenne Low Power Payload Protocol

Entwicklung / Development Funkinfrastruktur / Wireless infrastructure
, ,
1

About

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

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

Documentation

Implementations

1 Like
2

Shipping MicroPython support

– Release Shipping MicroPython support · smlng/pycayennelpp · GitHub

3

für Arduino:

1 Like
4

Vielen Dank!

Hier gibt es ganz frisch ein paar interessante Erweiterungen.

5

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
6

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.

7

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

8
9

Generic 4-byte unsigned integer

In der Reihe…

cc @Thias, @tonke, @roh

10

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.

11

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.

12

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. Weitere Details zu diesem Thema finden sich bei TTS-/TTN-Daten an Kotori weiterleiten, hier geht es ja primär um Aspekte rund um CayenneLPP selbst.

1 Like
13

Nur ein Zwischeneinwurf, zur Orientierung…

… besonders dieser Abschnitt fiel mir auf:

1 Like
14

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
15

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.

16

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.

17

5 posts were merged into an existing topic: TTN-Daten an Kotori weiterleiten

23

JFYI. Sebastian Meiling is currently preparing PyCayenneLPP 2.0.0, see Commits · smlng/pycayennelpp · GitHub.

He also shared some thoughts about interoperability testing where we added some of our thoughts, see add inter-op tests · Issue #71 · smlng/pycayennelpp · GitHub.

24

Bei der kanonischen C++-Implementierung GitHub - ElectronicCats/CayenneLPP: Library for Arduino compatible with Cayenne Low Power Payload werden gerade zwei interessante Erweiterungen eingereicht.