Erarbeitung eines kanonischen Datenschemas für imkerliche Meßdaten

Einleitung

Um das Benutzerhandbuch Meßdaten an die Hiveeyes Plattform übermitteln runder zu kriegen, arbeiten wir endlich an einer Empfehlung, wie die kanonischen Feldnamen in die InfluxDB Datenbank übermittelt werden sollten.

Metadaten

Komplementär zu den Meßdaten haben wir bereits ein wenig zu den zu erhebenden Metadaten gesammelt.

Vorbild Beep

@marten.schoonman und @iconize vom Beep Projekt haben viel Aufwand betrieben, ein Datenschema für die imkerlichen Stockkarteneinträge zu erarbeiten. Die Meßdaten sind zwar deutlich weniger komplex und vielfältig, trotzdem wollen wir diesem Thema endlich höhere Aufmerksamkeit widmen.

Todo: Referenz/Link.

Ziel

Wenn man die Daten an die Plattform in diesem Format übermittelt oder einen entsprechenden Umsetzer benutzt, kommt man out-of-the-box in den Genuß der meisten Features, wie z.B. fertige Dashboards wie Standard Dashboard für imkerliche Daten / Default dashboard for beekeepers oder Designstudie: Stockübersicht & Bienenwetter (BeeKloppte). Bei Erarbeitung eines kanonischen Dashboards für imkerliche Daten kümmern wir uns darum, wie das zusammengeht.

Bestandsaufnahme

Wir greifen exemplarisch ein paar Teilnehmer heraus.

Open Hive

Die Fraktion rund um die BeeKloppten, die @clemens’ Open Hive Systeme verwendet, übermittelt folgende Feldnamen.

Open Hive field names
> show field keys from default_1_sensors
name: default_1_sensors
fieldKey      fieldType
--------      ---------
H1 Temp       float
H2 Temp       float
H3 Temp       float
H4 Temp       float
H5 Temp       float
Inside Humid  float
Inside Temp   float
Outside Humid float
Outside Temp  float
Voltage       float
Weight        float
> show field keys from default_2_sensors
name: default_2_sensors
fieldKey            fieldType
--------            ---------
Aussen-Feuchtigkeit float
Aussen-Temperatur   float
Gewicht             float
Spannung            float
> show field keys from default_5_sensors
name: default_5_sensors
fieldKey      fieldType
--------      ---------
Inside Temp   float
Outside Humid float
Outside Temp  float
Voltage       float
Weight        float

Misc

Feldnamen verschiedener Teilnehmer.

Miscellaneous field names

@einsiedlerkrebs übermittelt

> show field keys from vay55_42_sensors
name: vay55_42_sensors
fieldKey    fieldType
--------    ---------
humidity    float
node        float
temperature float
> show field keys from vay55_999_sensors
name: vay55_999_sensors
fieldKey fieldType
-------- ---------
hum1     float
hum2     float
temp1    float
temp2    float
temp3    float
temp4    float
wght1    float
> show field keys from vay55_2_sensors
name: vay55_2_sensors
fieldKey fieldType
-------- ---------
hum1     float
loops1   float
rssi1    float
temp1    float
temp2    float
temp3    float
temp4    float
temp5    float
temp6    float
temp7    float
temp8    float
wght1    float
wght2    float

@karsten übermittelt

> show field keys from cfb_hive1_sensors
name: cfb_hive1_sensors
fieldKey               fieldType
--------               ---------
airhumidity            float
airhumidity_outside    float
airtemperature         float
airtemperature_outside float
broodtemperature       float
entrytemperature       float
weight                 float

@Thias übermittelt

> show field keys from pdm_node_1_sensors
name: pdm_node_1_sensors
fieldKey      fieldType
--------      ---------
battery_level float
hum_in        float
temp_in       float
temp_out      float
weight        float
1 Like

Vorschlag

Blaupause

So wie sich bei Develop BOB on FiPy mittlerweile ein lowlevel Schema herausgebildet hat, welches die Hardwaretopologie reflektiert à la

{
  "humidity.0x77.i2c:0": 73.46,
  "pressure.0x77.i2c:0": 1021.17,
  "temperature.0x77.i2c:0": 22.67,
  "temperature.28ff641d8fc3944f.onewire:0": 23.5,
  "temperature.28ff641d8fdf18c1.onewire:0": 23.75,
  "weight": 42.42,
  "memfree": 2291968
}

könnte man das Ganze auch hier aufziehen, mit einer ähnlichen Konvention à la "{was}.{wo}".

Allgemeine Specs

Ich denke mal wir setzen (vorerst) einfach mal ein paar Dinge voraus. z.B. die Einheiten in Grad Celsius und Kilogramm, Bytes, usw.; Englischsprachige Labels; Nicht zu lang, aber auch nicht zu knapp.

Gerne hier noch mehr dazu sammeln.

Beispiele

Einfaches Beispiel I

{
  "humidity.outside": 33.46,
  "temperature.outside": 22.67,
  "temperature.inside": 23.5,
  "weight": 42.42,
  "memory.free": 2291968
}

Einfaches Beispiel II

{
  "humidity.outside": 33.46,
  "temperature.outside": 22.67,
  "temperature.inside:entry": 21.5,
  "temperature.inside:brood": 23.5,
  "weight": 42.42,
  "memory.used": 2950912
}

Beispiel mit Temperature Array

Klar, dass Open Hive Temperature Array hier mehr Daten rauswirft, die wir sinnvoll benennen sollten. Die Positionen/Orte der Sensoren sind ja sowas wie “Wabengasse 1”, “Wabengasse 2”, nicht? Auf Englisch hieße das wohl “honeycomb alley” oder auch “honeycomb lane”. “lane” wiederum fände ich ein schönes kompaktes Label für diesen Zweck.

{
  "humidity.outside": 33.46,
  "temperature.outside": 22.67,
  "temperature.inside": 23.5,
  "temperature.lane:1": 22.67,
  "temperature.lane:2": 22.67,
  "temperature.lane:3": 22.67,
  "temperature.lane:4": 22.67,
  "weight": 42.42
}

Beispiel mit vier Wägezellen

Manche haben ein Setup mit vier Wägezellen. Die Daten könnte man folgendermaßen übermitteln.

{
  "weight.corner:1": 10.605,
  "weight.corner:2": 10.605,
  "weight.corner:3": 10.605,
  "weight.corner:4": 10.605,
  "weight": 42.42
}

Neben der Wabengasse könnten die aber auch mehrfach pro Magazin / horizontale Schicht sein, d.h. Wabengasse 1, Brutraum 1 und Wabengasse 1, Brutraum 2 oder Wabengasse 1, Honigraum 1 …

So weit ich weiß
hive body = Brutraum, BR
hive super = super = Honigraum, HR

1 Like

D.h. wir wollen dort für die Variante “Wintertraubenverfolgung” an dieser Stelle zwei Dimensionen adressieren können?

Danke! Also vielleicht so?

"temperature.body:1": 22.67,
"temperature.body:2": 22.67,
"temperature.super:1": 22.67,
"temperature.super:2": 22.67,

Ist die “lane” Nomenklatur in Ordnung oder gibt es da was besseres aus dem Fachjargon?

Vorschlag

Ausgehend von der per Terkin for MicroPython implementierten Telemetrienamenkonvention für Develop BOB on FiPy wäre ein vollständiges Mapping in folgender Form denkbar.

Sensor/Telemetry Database Grafana
temperature.0x77.i2c:0 temperature.inside Temperatur Innen
temperature.28ff641d8fc3944f.onewire:0 temperature.body:1 Temperatur Brutraum 1
temperature.28ff641d8fdf18c1.onewire:0 temperature.body:2 Temperatur Brutraum 2
temperature.28ff641d8fa1b2c3.onewire:0 temperature.super:1 Temperatur Honigraum 1
temperature.28ff641d8fd4e5f6.onewire:0 temperature.super:2 Temperatur Honigraum 2

Handhabung

Die einzelnen DS18X20 Sensoren wären entsprechend mit HR1, HR2, BR1, usw. beschriftet, damit man sie nach einer Entnahme wieder ordentlich reinhängen kann.

Ausblick

Dank den Arbeiten von @wtf an Implementing i18n support for Grafana dashboards kommt vielleicht auch hier schon bald die Unterstützung für Mehrsprachigkeit in der dritten Spalte.

Da fehlt noch eine Ebene, wird nicht häufig vorkommen aber wir könnten pro Ebene mehrere Temperatursensoren haben.

Brutraum 1, Sensor in Wabengasse 1
Brutraum 1, Sensor in Wabengasse 1

Brutraum 2, Sensor in Wabengasse 1
Brutraum 2, Sensor in Wabengasse 2

1 Like

Zwischensammlung

  • Zwei oder mehr Waagen pro Meßknoten im Telemetriedatenformat vorsehen, per ESP32 mit Arduino.

Im Datenmodell sehe ich jetzt die JSON Datenfelder temp inside und temp lane:#

Wird auf Seite der Datenbank eine Aggregation vorgenommen? Es müßte das Attribut Temp inside ja ein MUSS Feld sein, dass sich aus dem Mittelwert aller LANES bildet. (Kompatibilität zu denen die keine einzelnen Lanenmessungen machen)

gibt es eine komplette Datenstrukturbeschreibung, wie die Gesamtdatenpakete ankommen müssen?

Metadaten (wer wo was)
Nutzdaten (temp, hum, …)
:penguin:

Und wie ist die Vorgabe bezüglich der Auflösung der Messwerte? (DS18B20 > 10bit oder 9bit)

Hi Ingo,

wir haben derzeit kein verpflichtendes Datenschema. Dieses wird in diesem Beitrag erst erarbeitet. Momentan kannst Du beliebige Felder in einem flachen JSON-Container übermitteln.

Viele Grüße,
Andreas.

Ok, das heißt ich könnte dann einen Vorschlag machen?

Vor diesem Hintergrund ist spätereDatenhaltung und ggf ETL Schichten interessant.

Ich weiß, dass ihr grafana einsetzen wollt, aber ist es angedacht DataMarts zu bauen und dann Dimensionen anzuflanschen?

Merci

Gern. Wenn es Dir um einen Vorschlag zur kanonischen Benennung der imkerlichen Meßdaten geht, ist hier der richtige Platz, daneben gibt es noch das Schwesterthema Imkerliche Metadaten.

Damit die Diskussion auch in Richtung “allgemeines Schema für Telemetriedatenformat” gehen kann, haben wir drüben bei Telemetriedatenformat v2 entsprechenden Platz geschaffen. Dort kann ein etwaiges neues Nachrichtenformat diskutiert werden.

Ja, unbedingt. Die kollaborativen Interaktionsmöglichkeiten rund um die erfassten Daten sind grandios.

Gedanken

Solche Dinge haben wir nicht als primäres Ziel ins Auge gefasst, vielleicht kennen wir uns aber auch im entsprechenden Jargon noch nicht gut genug aus, um das richtig einschätzen zu können. Auf der Ebene der Datenhaltung stellt InfluxDB in Form von Tags eine Möglichkeit zur Verfügung, den Daten Dimensionen zu verleihen. Das wollen wir auf jeden Fall erreichen und stärker erschließen, daher brauchen wir u.a. auch ein möglichst kanonisches Datenschema.

Wenn es um die Datenverarbeitung geht, wollen wir strategisch eher in Richtungen gehen, bestehende innovative Open Source Projekte zu integrieren bzw. die Daten mit ihnen interoperabel zu machen, damit wir sie kollaborativ und interaktiv noch besser analysieren können. Wir schielen hier auf… / go figure…

JupyterLab

Klare Angelegenheit.

iSCAPE Sensor Analysis Framework

Tolles Gerät (jedoch noch nicht ausprobiert, schaumamal), das wir vor kurzem entdeckt haben und Horizon2020-gefördert beim FabLabBCN ensteht. Ping @Ron.

Audio processing and analysis

Sobald wir gerne bald Audiodaten anliegen haben…

Moar interactive DataViz

Schaumamal.

So hier mal mein Vorschlag für einen Faktsatz.

{
  "TMSTP.measured": YYYYMMDD-HHMMSS,
  "HIVE.ID":nnnnnnnn,
  "humidity.outside": nn.nn,
  "pressure.outside":nnnn.nn,
  "temperature.outside": nn.nn,
  "temperature.inside.cumulated": nn.nn,
  "temperature.lane:1": nn.nn,
  "temperature.lane:2": nn.nn,
  "temperature.lane:3": nn.nn,
  "temperature.lane:4": nn.nn,
  "weight.cumulated": nn.n,
  "weight.mount1": nn.n,
  "weight.mount2": nn.n
}

Mit Dimensionsbildung meine ich, dass wir ausgehen von diesem Faktensatz (DataMart) über Attribute Dimensionen veknüpfen können.

BSP:

  • TMSTP > in Dimension Zeit > externe Dimnesionen Wetterdaten etc.
  • HIVE ID > Dimension Hives “unsichtbar” (inklusiver der Geodaten;) wird einmalig beim generieren / Anmelden des Stockes generiert und nicht jedes mal mit übertragen.
in HIVE.ID > 
ID
ID.long
ID.alt
ID.NN

Ich meine es geht jetzt nicht um das primär oder sekundär Ziel, sondern eher darum, dass man die Datenbasis bei der Generierung so anlegt, dass sie möglichst flexibel am Ende erweitert werden kann und vor Allem dann größtmögliche Flexibilität bietet.

Platt die ganzen Sätze zu persistieren ist über kurz oder lang der Overkill jedweder Datenbank.

welche Frequenz soll die Datenübermittlung haben (Frage der Infrastruktur und Bandbreite am Knotenpunkt; Wiwviele Threads kann der Appserver der den Service hosted parallel verkraften bis er die Grätsche macht
wie sollen die Daten aggregiert werden? Auf Stundenbasis ? Auf Tagesscheibenbasis?

Es gibt da gerade bei der Konzipierung der Gesamtlösung noch viele offene Flanken.

Wie wäre es mal eine SKY Session mit ein paar Entwicklern / Architekten hier aus dem Team zu machen?

So, jetzt erst einmal schönes Wochenende :smiley:

Hi Ingo,

vielen Dank für Deinen Vorschlag. Während wir einerseits dringend in Richtung Telemetriedatenformat v2 gehen wollen, wollen wir das Format v1 natürlich gerne behalten. Das entspricht strukturell der von Dir vorgeschlagenen Variante mit zwei Unterschieden:

Kann man sich das in etwa vorstellen, wie man in einer relationalen Datenbank Relationen miteinander verknüpft?

Freilich, wir geben uns Mühe.

Das Thema Data Retention haben wir schon öfters diskutiert. Vor kurzem hatten wir uns auch einmal konkreter mit Downsampling and data retention | InfluxData Documentation beschäftigt (siehe zur Einführung z.B. auch https://towardsdatascience.com/influxdb-data-retention-f026496d708f), momentan ist es aber noch nicht akut und wir sind froh, dass InfluxDB bereits solche Dinge wie kontinuierlich-selektives Downsampling vorsieht [1] [2].

Das sind exzellente Fragen, danke. Eine umfassende Beantwortung oder eine etwaige Diskussion um alle möglichen Details innerhalb dieser Themen kann locker Bände füllen. Generell wollen wir auch hier in allen Aspekten flexibel bleiben und entsprechend auf die wachsenden Anforderungen reagieren.

Wir können gerne telefonieren und senden Dir über PM unsere Telefonnummer. Einstweilen vielen Dank für Deine Impulse.

Viele Grüße,
Andreas.


  1. Du siehst, wir sind hier grundsätzlich sehr technologiegetrieben unterwegs, nichtsdestrotrotz wollen wir uns zukünftig weitere Gedanken über die Datenstrukturen machen, gerade bzgl. jeglicher Metadaten.

    Aktuell ist fix, dass die Daten in einer InfluxDB-Datenbank gespeichert und in Grafana dargestellt werden. InfluxDB und Grafana sind für uns und andere derzeit das absolut dynamischste Duo vergleichbar mit der guten alten Parabel auf GNU/Linux.

    image

    The Dynamic Duo: The Gnu and the Penguin in flight - GNU Project - Free Software Foundation

    Wir schielen jedoch bereits stark rüber zu PostgreSQL mit TimescaleDB, siehe auch Looking at TimescaleDB und 4 Best Time Series Databases To Watch in 2019. Im Besonderen, weil wir vor kurzem durch die Erneuerung der Luftdatenpumpe bereits mit PostGIS in diese Richtung gegangen sind.

    Während wir also Dimensionsdaten gerne bereits jetzt in einer PostgreSQL-Datenbank unterbringen können, werden die Zeitseriendaten wohl bis auf weiteres in der InfluxDB bleiben, gerade weil auch dort weiterhin ordentliche Innovationen rauspurzeln, mit denen unsereiner bisher noch von keinem anderen Datenbanksystem in dieser Art und Weise genußvoll in Berührung kommen durfte. Allen voran ist hier die neue Anfragesprache Flux zu nennen.

    Die damit interaktiv gestaltbaren aggregierenden Abfragen übersteigen die Möglichkeiten von SQL bei weitem und haben uns bereits wertvolle Dienste beim gemeinsamen Erschließen der Daten geleistet. Hier wächst also in vorsichtiger Art und Weise ein wenig OLTP und OLAP zusammen, wie man es auch von Bemühungen anderer moderner Datenbanken ablesen kann. Diesen Weg, neue Technologien für uns zu erschließen, halten wir für sinnvoll – einiges das wir dadurch bisher erreichen konnten wäre ohne viele dieser wichtigen Implementierungsdetails nicht möglich. ↩︎

  2. Wir könnten uns vorstellen, dass wir Dich als datenaffinen Menschen ebenfalls für die angesprochenen Technologien begeistern könnten. ↩︎

Hallo,
ja, die dim tables sind relational angebunden.

Mein Ansatz ist es erst einmal die Anforderung / Datenmodell klar zu strukturieren und DANN in die Technologiefrage zu gehen (ist halt täglich Brot in meinem Job)

Was mir aktuell fehlt ist neben den bereits geschilderten Punkten:

  • eine Prozessbeschreibung aller Prozesse in Neudeutsch Userstories
  • das visuelle Datenmodell inklusive Relationen (normalisiert)
  • Nicht Funktionale Anforderungen wie z.B. Datenmengengerüst (in Ableitung das Aktualisierungsintervall); Zugriffsgeschwindigkeiten/Antwortzeitverhalten, Datenschutz iSv. Hosting der Daten in der Cloud / on premise vor dem Hintergrund der EUDSGVO

… ich melde mich bei Dir, und wie gesagt vielleicht könnten wir ja mal mit mehreren eine SKYPE Session machen, damit wir eine Art Workshop abhalten, wo wir dann eben nicht alle zusammenkommen, aber unsere Gedanken relativ schnell zusammenführen und abgleichen können…

@IngoP, sorry, dass ich hier jetzt reingrätsche, aber wir machen das auch schon ein paar Jährchen, in professionellen, teilweise internationalen Teams, großen und keinen Firmen und dev-teams mit großen tech-Unis wie ETH oder UCB, eher agil als im Wasserfallmodell.

Wir sind dankbar für jede Hilfe, dann sollten wir aber auch eine rudimentär gemeinsame Basis finden und nicht “wir machen das, wie ich es immer mache.”

Just my 2ct.

Nun, wenn ich Dir zu Nahe getreten bin tut es mir Leid.
Bezüglich Deiner angesprochenen rudimentären Basis, ja klingt gut, aber kannst Du diese benennen, da ich nirgends gesagt habe “wir machen das, wie ich es immer mache.” sondern dass das mein Ansatz ist.

Und agil bedeutet nicht gleich Konzeptlos und Alle rennen in unterschiedliche Richtungen. Gibt es hier den Scrum Master? wie sieht der MVP aus? Was ist als nächster Sprint geplant Warum frage ich nach SKYPE Sessions als Ersatz für Dailies? …

Vielleicht hast Du ja an dieser Stelle sachliche Informationen bzw. Antworten zu meinen Fragen.

Ihr Guten,

vielen Dank für Eure Beiträge.

Es sieht so aus, als ob sich hier Profis begegnen. Vielen Dank, dass Ihr dabei seid.

Wir versuchen hier an der Schnittstelle zwischen Mensch und Maschine einen gewagten Spagat im Bereich von Open Data/Open Hardware/Citizen Science/Academia Support/DIY/Call me names. Extrem viel passiert bei Hiveeyes seit Beginn an in hybriden Modi und das macht einen Großteil der kollaborativ-kollektiven Realität aus, deren Geist hier durch die Räume weht.

Wir schätzen diese Vorgehensweise sehr und bitten um Verständnis, wenn es dadurch in der Dokumentation an eindeutigen Papers mangelt, die grundlegende Designentscheidungen des Gesamtsystems klarer beleuchten. Wir arbeiten daran.

Viele Aspekte und Implementierungsdetails im Bereich der Datenhaltung finden sich konkret ein wenig abseits von Hiveeyes, sondern beim verwendeten Kotori Data-Historian [1]. Dessen technische Konzepte und Paradigmen stellen bewusst einige Dinge komplett auf den Kopf, die wir aus klassischen Vorgehensweisen heraus kennen. Die Entscheidung dazu trafen wir auf Basis von Forschungsarbeiten im Bereich ähnlicher Softwarekomponenten aus dem proprietären und open source Bereich.

Viele Meta-Vorgehensweisen spielen sich ebenso geplant jenseits von Wasserfall bzw. -kopf und in Form von durch Scrum++ bekannten agilen Methoden ab. Auch wenn solche Dinge an einigen Stellen im Forum bereits sichtbar und konkret benannt werden, fehlen auch hier bisher vermutlich noch klare Einstiegspunkte. Wir arbeiten daran.

Wir sollten aufpassen, dass die Diskussion rund um das System sich nicht hoffnungslos in Argumente verheddert, die grundsätzliche Vorgehensweisen in der Systementwicklung mit technischen Implementierungsdetails ungünstig vermischen.

Have fun!

Herzliche Grüße,
Andreas.

Always look…


  1. Disclaimer: Auch wenn ich der Hauptautor von Kotori bin, stecken dort viele Einflüsse und Beiträge aus verschiedenen Richtungen drin, Contributors — Kotori 0.22.7 documentation vermittelt einen kleinen Einblick. Vielen Dank auch an dieser Stelle an die exzellente Hilfe aller Mitwirkenden! ↩︎

1 Like

A post was split to a new topic: Diskussion über Meßintervall