Erarbeitung eines kanonischen Datenschemas für imkerliche Meßdaten

Entwicklung / Development Daten / Data
14

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:

16

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

  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. ↩︎

19

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…

20

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

23

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.

26

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, https://getkotori.org/docs/CONTRIBUTORS.html vermittelt einen kleinen Einblick. Vielen Dank auch an dieser Stelle an die exzellente Hilfe aller Mitwirkenden! ↩︎

1 Like
30

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

31

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 :slight_smile: 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. :smiley:

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
32

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.

33

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

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?

1 Like
34

Vorschlag fürs Gewicht:

“weight.1” für die erste und “weight.2” für die 2te Beute usw…Für die Leute mit 2+ Waagen pro MCU.

“weight.1.0” ist das Gesamtgewicht der Beute. Entweder von einer Zelle oder errechnet aus mehreren.
“weight.1.1”, “weight.1.2”… für die Einzelzellen (falls vorhanden).

35

Hi Markus,
ich finde, das geht scho in die richtige Richtung. Danke für deine Überlegungen!

Da ich jedoch die Implementierung des Schema in die LoRa-Telemetrie übernehme, habe ich noch einen weiteren Vorschlag, den ich auch so schon mit Andreas am Telefon vereinbart habe. Dabei geht es um die generelle Struktur des Namensraums. Unsere Idee war immer mit einen Realm zu starten. Das wäre dann system, inside und outside. Auch wenn klar ist, dass zB. die Waage außerhalb der Beute platziert ist, würde es trotzdem outside zugewiesen bekommen, weil generell alle Variablen einem Realm zugeordnet werden. Ich brauche diese feste Struktur, um die Sensoren einigermaßen elegant und ohne 1000 Workarounds auf die CayenneLPP Channels zu mappen.

Beispiele:

  • Waage mit einer Zelle:
    outside.weight.1.0
  • Temperaturarray im ersten Brutraum:
    inside.temperature.1.[3-8]
  • Ein Temperatursensor im zweiten Brutraum:
    inside.temperature.2.0
  • Außenfeuchte:
    outside.humidity.0
  • Batteriespannung:
    system.voltage.1 oder system.voltage-battery

@Andreas stimmt du noch zu? :slight_smile: Was sagen deine Notizen von unserem Gespräch?

36

Hmm, kannst Du mal erklären, worin der Nutzen der zusätzlichen Ebene liegt?
Im Gegensatz zu: ‘alle Variablen liegen in einem Realm’.

37

Es geht darum Abstraktionsebenen zu haben, die sich immer mehr dem eigentlichen Sensor annähern. Von grob zu fein quasi. Dabei muss jede Position des Namensraum genutzt werden. Das erleichtert nicht nur mir das Mapping der Sensoren auf die CayenneLPP Channels, es wird auch dabei helfen generische Dashboards robuster erzeugen zu können. Wichtig ist dabei, die verschiedenen individuellen Konfigurationen von verbauten und intrinsischen Sensoren eindeutig auf die Telemetrienamen zu übersetzen um ein allgemeines Schema zu haben, in das sich jeder mit seinem Aufbau einpassen kann.

Warum ich immer auf CayenneLPP herumreite fragst du dich vielleicht? Ich würde mich freuen, wenn der Datenlogger so überzeugend funktioniert, dass er auch in eine breitere Nutzerbasis findet, als nur für uns Bienenbastlern. Die WiFi Option halte ich für wenig praxistauglich. Bienenstöcke stehen meistens fernab einer Steckdose, welche die Telemetrieeinheit mit Dauerstrom versorgen und dann Sendeintervalle und Payloadgröße keine Rolle spielen. Ein WiFi AP ist ebenfalls die Ausnahme im Gelände. LoRaWAN bietet eine energiesparende Alternative mit viel größeren Reichweiten, die aber andererseits mit einem sehr kompakten Payload arbeiten muss. Hier brauchen wir ein intelligentes Mapping.

Zurück zu deiner Frage. Ich stelle mir schon länger vor die verfügbaren CayenneLPP Channels in Blöcke zu zerlegen die jeweils einem “Realm” zuordnet sind. Diese Blöcke werden dann mit Sensordaten gefüttert, je nach dem, was an der Beute verbaut wurde. Zu bedenken ist ebenso, dass dieses Mapping später in Kotori rückwärts betrieben wird. Dass also die Telemetrienamen auf dem Node am Ende genauso in die Datenbank geschrieben werden, wie bei der vollen Übertragung über MQTT oder HTTP.

38

Ok, habe ich jetzt nicht alles verstanden, muss ich aber auch nicht. :slight_smile:
Da ich einen ähnlichen Anwendungsfall wie Du habe, vertraue ich darauf, das Du weisst, was Du da machst. Wenn ich es recht verstanden habe, werden die Daten im Cayenne binär codiert und verpackt, d.h. die Länge des Mappings spielt für die resultierende Datenmenge keine Rolle.

Dann könnten wir doch jetzt eine (fast vollständige) Liste der Messwerte erstellen oder nicht?

39

Anknüpfend an My DIY "Hive Minder" monitoring setup (LoRa sensors w/ Grafana) - #2 by wtf – danke @wtf! – würde ich zur Vervollständigung in diesem Kontext gerne den gerade von @hannes_oberreiter bei Development Updates info.btree.at vorgestellten b.tree server erwähnen, dabei aber auch die BEEP platform bzw. BEEP Anwendung nicht vergessen [1].

Hier sind die direkten Referenzen auf diejenigen Stellen in den entsprechenden Repositories, an denen die Datenmodelle der jeweiligen Anwendungen untergebracht sind. Dort lässt sich schön nach möglichen und wichtigen Entitäten und Attributen stöbern. Persönlich finde ich die Implementierung des Datenmodells der b.tree Anwendung sehr übersichtlich und gelungen [2]. Danke Hannes!

BEEP

b.tree server

BeeXML

Hier könnten wir auch mal wieder nach Updates sehen.

  1. Ich glaube die Datenbankperspektive kennt @wtf hier schon ein wenig aus der Praxis? ↩︎

  2. Besonders möchte ich hier auch noch auf die detaillierte Ausarbeitung der Rearing* Entitäten bei models/rearing hinweisen, was einen kleinen Teil der Frage von @clemens bei Development Updates info.btree.at - #5 by clemens beantworten könnte. ↩︎

1 Like
41

Ohja. Die ist sehr hart. Also: Mir scheint, dass BEEP ja nen gut sortiertes Abbild geschaffen hat. Allerdings ist das Datenbankschema dahinter AFAIR alles andere als ontologisch offensichtlich bzw so gestaltet, dass mensch es nicht ohne automatisierte Queries erschließen kann: Was ein Wert beschreibt ist in einer Relations-Tabelle abgelegt, die auch als parent wieder auf sich selbst zeigen kann und so die Verschachtelung [des Metadatums] aufbaut → das wär erstmal IT-mäßig krude zu parsen, beschreibt am Ende aber ne Ontologie, die ja imkerlich “gut abhangen” erscheint und sicher ne gute Grundlage darstellen würde bzw mitlerweile sicher einige Aspekte mitabdeckt, an die mensch zunächst erstmal nicht denkt.

Diesen Ontologie-Baum seht “Ihr Imker” aber im BEEP-Backend sicher eh schneller und übersichtlicher als ich Datenbank-Miner.

1 Like
42

Ich habe es mir ehrlich gesagt noch nie konkret angesehen, aber vielleicht eine grobe Vorstellung im Kopf. Ist es in etwa wie ein EAV Modell [1][2], also nicht besonders klassisch-relational auf die Datenbank abgebildet?

  1. Entity–attribute–value model - Wikipedia ↩︎

  2. Was ist eigentlich EAV? | PPT. Siehe Vorteile vs. Nachteile auf den Seiten 18 bis 21.

    Komplexe Programmierung von SQL Queries [sic].

    ↩︎
43

Ja, das roch genau so.

1 Like
44

Ja, das ist schick, weil das Schema Laufzeit-erweiterbar ist, ohne dass man Änderungen an Datenbank Schemata pflegen muss – siehe o.g. Präsi auf Slide 19. Aber für analytische Zwecke ist es halt eine Ente, da würde man dann batch-mäßig besser normalisierend nach OLAP exportieren, um dann dort zu analysieren.

Aber selbst jedes OLTP-orientierte, klassische SQL Schema wäre besser abzufragen als EAV – now I feel your pain. EAV kann man eigentlich praktikabel nur durch ne Anwendungsschicht hindurch abfragen, die von der jeweiligen Schemaimplementierung abstrahiert.