Imkerliche Metadaten

Entwicklung / Development Daten / Data
1

Einleitung

Hier soll es um den Empfang und die Verarbeitung imkerlicher Metadaten gehen, die zusammen mit den Meßdaten empfangen oder aus ihnen abgeleitet werden.

Hintergrund

Zusammen mit @einsiedlerkrebs wurde das Speicherungskonzept von Kotori so ausgelegt, dass die Daten unterschiedlicher Kanäle in separaten Datenbanken gespeichert werden. Das ist auch sinnvoll, weil wir ein mandantenfähiges System implementieren wollten, bei dem die Datenkanäle und deren Speicherorte voneinander isoliert sind. Dies hat einige Vorteile auf der Detailebene (jede Teilnehmerin kann auf ihren Kanälen veranstalten was sie will), aber bzgl. des Vergleichens von Daten hat es die offensichtlichen Nachteile.

Metadaten: InfluxDB Tags und Grafana Templatevariablen

In der Zwischenzeit haben wir natürlich auch die Metadaten Konzepte von InfluxDB kennengelernt, siehe
InfluxDB tags und how to encode metadata in tags. Diese Tag Strings kommen dann im Grafana direkt als Templatevariablen an und man kann sie dort zum Filtern, Gruppieren und Aggregieren der Daten verwenden.

Planung

Wir wollen am aktuellen “freestyle”/full-isolation Speicherungskonzept nichts grundlegendes ändern, planen aber eine Zusatzfunktionalität, die es erlaubt, alle Daten optional in eine gemeinsame Datenbank einzuspeisen. Dabei würden Informationen aus dem Kanalnamen automatisch für die Erzeugung entsprechender Tags herangezogen werden.

Am Beispiel

Wenn das System Informationen auf folgenden Datenkanälen empfängt

hiveeyes/ecf85b9g/einsiedlerkrebs@wedding/labhive-1/data.json

und man dabei das Adressierungsschema

realm / network / gateway / node

berücksichtigt, würden wir daraus folgende “lowlevel” Tags ableiten

realm   = hiveeyes
network = ecf85b9g
gateway = einsiedlerkrebs@wedding
node    = labhive-1

und dem InfluxDB Datensatz als Metadaten hinzufügen.

Diese Metadaten sind zwar nicht sehr gehaltvoll, reichen aber aus, um einzelne Sensorknoten gezielt über Filter im Grafana zu adressieren und deren Daten zu vergleichen.

Ausblick

Wenn wir ermöglichen, dass man zu einem Datenkanal weitere Metadaten hinterlegen kann, wären auch weitere “highlevel” Tags mit strukturellen Informationen denkbar, gerade detaillierte Standortinformationen scheinen sinnvoll. Im besten Fall könnte man mit einer heuristischen Herangehensweise und einem reverse geocoding Dienst wie Nominatim aus den angelieferten Adressinformationen bereits folgende Tags erzeugen:

location = Wedding,Berlin,Germany
country  = de
state    = Berlin
city     = Berlin
district = Wedding
latlng   = 52.5451,13.3853
geohash  = u33dbtdck
owner    = einsiedlerkrebs
name     = labhive-1

Referenzen

Technische Details

Ein kleiner Blick unter die Haube…

Wiederverwendung/Erweiterung eines bestehenden Subsystems

Im Zuge von Open Hive GSM and WiFi Firmware: Telemetrie an Hiveeyes Backend anpassen haben wir bereits die CSV Datenakquise realisiert. Diese benötigt einen kanalbezogenen aber nicht timeseries-basierten Speicherort für die Aufbewahrung der dabei anfallenden Metadaten - die Namen der CSV Felder. Diesen Speicherort werden wir verwenden, um einen Datenerfassungskanal nun auch mit beliebigen Metadatenfeldern versehen zu können.

Sicherheitsfragen

Bzgl.:

latlng   = 42.42,42.42

Zur Erhebung von exakten Positionsdaten bzw. deren Verunschärfung haben wir auch schon was bei Verunschärfung von Geopositionen.

2

Als weiteres Datum im “per-channel metadata store” wäre u.U. die Zeitzone sinnvoll, mit der der Meßknoten unqualifizierte Zeitstempel überträgt, siehe auch Summer time / Zeitzonen mit InfluxDB. Auf diese Weise könnten Zeitstempel pro Meßknoten auch serverseitig qualifiziert werden.

1 Like