Erarbeitung eines kanonischen Datenschemas für imkerliche Meßdaten

Andreas · April 18, 2019, 9:11pm

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
}

clemens · April 18, 2019, 10:51pm

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

Andreas · April 19, 2019, 12:25am

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?

Andreas · April 19, 2019, 1:03am

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.

clemens · April 20, 2019, 10:04am

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

Andreas · June 23, 2019, 7:33pm

Zwischensammlung

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

IngoP · July 12, 2019, 6:37am

{
  "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
}

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, …)

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

Andreas · July 12, 2019, 9:59am

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.

IngoP · July 12, 2019, 12:23pm

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?

Andreas · July 12, 2019, 12:51pm

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.

https://jupyter.org/

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…

GitHub - yomguy/TimeSide: scalable audio processing framework and server written in Python

Moar interactive DataViz

Schaumamal.

Apache Superset

IngoP · July 13, 2019, 9:08am

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

Andreas · July 13, 2019, 9:58pm

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:

Das Feld TMSTP.measured heißt einfach time.
Der HIVE.ID-Identifier ist in der Adresse kodiert statt im Payload, siehe auch
- Meßdaten an die Hiveeyes Plattform übermitteln und
- Gestaltung der anonymen Identifizierer (IDs) für die Adressierung von Imkern, Meßknoten und anderen Entitäten. Dadurch wird der Faktsatz agnostisch zur Anwendungsdomäne, woran der verwendete Kotori Data-Historian und die Gesamtarchitektur großes Interesse hat.

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 https://docs.influxdata.com/influxdb/v1/guides/downsample_and_retain/ 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.

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.

– 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. ↩︎
Wir könnten uns vorstellen, dass wir Dich als datenaffinen Menschen ebenfalls für die angesprochenen Technologien begeistern könnten. ↩︎

IngoP · July 14, 2019, 8:53am

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…

clemens · July 14, 2019, 9:38am

@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.

IngoP · July 14, 2019, 11:35am

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.

Andreas · July 14, 2019, 2:47pm

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…

Disclaimer: Auch wenn ich der Hauptautor von Kotori bin, stecken dort viele Einflüsse und Beiträge aus verschiedenen Richtungen drin, https://getkotori.org/docs/CONTRIBUTORS.html vermittelt einen kleinen Einblick. Vielen Dank auch an dieser Stelle an die exzellente Hilfe aller Mitwirkenden! ↩︎

Andreas · September 6, 2019, 12:07am

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

poesel · January 13, 2020, 6:41pm

Ich würde gerne diese Diskussion hier weiterführen. Das was @Andreas vorgeschlagen hat klingt doch schon ganz gut.
Mein Vorschlag ist leicht modifiziert. Zuerst gefällt mir diese ‘:’ Notation nicht, aber das ist ja Geschmackssache Weiterhin habe ich den Einwand von @clemens berücksichtigt und die Möglichkeit für mehrere Brut- und Honigräume berücksichtigt.
Die Reihenfolge, zuerst den Brut/Honigraum zu nennen und dann die Nummer des Sensor erscheint mir logischer. Zumindest lese ich im Geiste aus ‘temperature.body.1.2’ -> ‘Temperatursensor im Brutraum 1 Nummer 2’. Kann man natürlich auch genau andersrum lesen, aber dann ist die Formatierung der Zahlen nicht mehr so hübsch.

Die folgende Tabelle beschreibt dann also eine 4-zargige Beute mit 3 Temperatursensoren im untersten Brutraum und jeweils einen in den übrigen 3 Zargen.

Sensor/Telemetry	Database	Grafana
temperature.0x77.i2c.0	temperature.inside	Temperatur Innen
temperature.28ff641d8fc3944f.onewire.0	temperature.body.1.1	Brutraum 1 Temperatur 1
temperature.28ff641d8fc39441.onewire.0	temperature.body.1.2	Brutraum 1 Temperatur 2
temperature.28ff641d8fc39442.onewire.0	temperature.body.1.3	Brutraum 1 Temperatur 3
temperature.28ff641d8fc39443.onewire.0	temperature.body.2.1	Brutraum 2 Temperatur 1
temperature.28ff641d8fa1b2c1.onewire.0	temperature.super.1.1	Honigraum 1 Temperatur 1
temperature.28ff641d8fa1b2c3.onewire.0	temperature.super.2.1	Honigraum 2 Temperatur 1

clemens · January 13, 2020, 7:18pm

Mit @Andreas habe ich vor drei, vier Wochen das Ganze recht ausführlich am Telefon durchgesprochen, vielleicht hast du dir Andreas da Notizen gemacht (mir war so) und könntest das dort kondensierte hier nochmal reinschreiben.

Wir haben die nicht einfach durchnummeriert, sondern statt “Temperatur” die Wagebengasse verwendet, d.h. es kann dann so was abgebildet werden

Brutraum 1, Wabengasse 3
Brutraum 1, Wabengasse 4
Brutraum 1, Wabengasse 5
Brutraum 1, Wabengasse 6

und man braucht sich nicht nochmal einen Zettel hinlegen / in Grafana nochmal mappen, dass Temperatur 1 Wabengasse 3 ist usw.

Wir haben auch überlegt, ob temperature.body möglich sein soll, wen es nur einen Sensor pro Magazin gibt.

poesel · January 13, 2020, 8:35pm

Ok, macht Sinn. Jetzt brauchen wir nur noch eine Definition, wie Wabengassen gezählt werden - für Kalt- und Warmbau.

Spaß beiseite: für den ‘body’, also wenn man nur einen Sensor für den Stock hat, würde ich die Nummer ‘0’ reservieren.

Wie sieht das eigentlich mit anderen Sensoren aus? Müssten wir das nicht auch definieren?