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
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)
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?
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.
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…
Klare Angelegenheit.
Tolles Gerät (jedoch noch nicht ausprobiert, schaumamal), das wir vor kurzem entdeckt haben und Horizon2020-gefördert beim FabLabBCN ensteht. Ping @Ron.
Sobald wir gerne bald Audiodaten anliegen haben…
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:
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 
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:
TMSTP.measured heißt einfach time.HIVE.ID-Identifier ist in der Adresse kodiert statt im Payload, siehe auch
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. ↩︎
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:
… 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.
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! ↩︎
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 |
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
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.
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?
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).
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:
outside.weight.1.0
inside.temperature.1.[3-8]
inside.temperature.2.0
outside.humidity.0
system.voltage.1 oder system.voltage-battery
@Andreas stimmt du noch zu? Was sagen deine Notizen von unserem Gespräch?
Hmm, kannst Du mal erklären, worin der Nutzen der zusätzlichen Ebene liegt?
Im Gegensatz zu: ‘alle Variablen liegen in einem Realm’.
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.