TTN-Daten an Kotori weiterleiten

Feldnamenkonvergenz bei Übertragung via TTN

Einleitung

Auch im Zuge der Arbeiten am GitHub - hiveeyes/hiveeyes-micropython-firmware: Hiveeyes MicroPython Datalogger -- Data logging for humans streben @einsiedlerkrebs, @tonke und ich Konvergenz zwischen klassischer MQTT/HTTP Datenübermittlung und dem Transport von Meßdaten über TTN an und haben nun für die erste Iteration ebenfalls CayenneLPP als Serialisierungsformat anvisiert. Im Zuge dessen wollen wir Kotori nun endlich die angepeilte TTN-Schnittstelle verpassen - auf Basis einer TTN-Application mit Standard CayenneLPP Decoder, genau wie von @Thias gewünscht.

Recap Kanaladressierung

Recap Serialisierungsformat und Feldnamenmapping

CayenneLPP sieht bereits bestimmte Sensor-/Meßwertfamilien vor, alle übrigen müssen wir über analog_X tunneln. Ein ingress-payload sieht also beispielsweise folgendermaßen aus:

{
  "payload_fields": {
    "temperature_2": -3.2,
    "temperature_1": -2.9,
    "analog_in_1": 35.99,
    "analog_in_3": 3.53,
    "relative_humidity_2": 57.5,
    "relative_humidity_1": 55.5
  }
}

Problemstellung

Wir wollen sprechende Feldnamen (vgl. “Feuchte außen”) im Grafana gewinnen, über den schmalen TTN Kanal mit CayenneLPP Serialisierung ist das jedoch nur begrenzt möglich.

Lösungsvorschlag

Wir wollen ein Feldnamenmapping einführen, mit dem man Feldnamen der Telemetriestrecke sprechenden Meßwertfeldnamen zuordnen kann. Dieses Mapping kann einmalig gesetzt werden und bedient sich intern dem bereits für die CSV Datenerfassung [1,2] etablierten Subsystem, ähnlich wie unter CSV data acquisition beschrieben.

# HTTP
cat mapping.json | http POST $HTTPURI/$CHANNEL/mapping.json

# MQTT
cat mapping.json | mosquitto_pub -h $BROKER -t $CHANNEL/mapping.json -l

[1] Daten per HTTP und PHP ans Backend auf swarm.hiveeyes.org übertragen
[2] Open Hive GSM and WiFi Firmware: Telemetrie an Hiveeyes Backend anpassen

Per-channel metadata store

Ähnliches hatten wir bereits unter Imkerliche Metadaten angerissen.

Automatic fieldname announcement

In der Luxusvariante teilt der Meßknoten sein konfiguriertes Mapping einmalig beim Startvorgang mit - sofern er über WiFi verbunden ist und damit über HTTP oder MQTT kommunizieren kann.

Ausblick

Wir erschließen damit nun den langersehnten Komfortmapper auf Infrastrukturseite, der in Folge alle möglichen schmalen Radiotransporte unterstützen kann - sowohl seitens des PHY (RFM69, RFM95… (LoRa), LoRaWAN, etc.), als auch seitens des jeweils verwendeten Serialisierungsformats (BERadio, CayenneLPP, custom-bytepacked, etc.). Natürlich kann er aber auch darüber hinaus ein Remapping der Feldnamen leisten.

Requests for comments

Falls Ihr einen besseren Vorschlag fürs “Naming Things” anstelle des Suffixes mapping.json habt: Her damit! (vielleicht einfach meta.json?) Weitere Vorschläge und Ideen zu diesem Thema sind natürlich ebenfalls immer willkommen.

1 Like

Von @clemens grade bei Beelogger geteilt, finde ich die Integration mit TTN bei beelogger - LORA - Arduino Datenlogger mit Stockwaage für Imker auch hier erwähnenswert. Im Gegensatz zum plattformartigen Betrieb mehrerer Teilnehmer über die gleiche TTN-Application ist dies ist das Szenario, wenn jeder Teilnehmer einen eigenen TTN-Account hat. Das sollten wir bei der Ausreifung unserer entsprechenden Dekoder ebenfalls berücksichtigen.

1 Like