Diskussion über designierte Messfrequenz

Guten Morgen,

ich habe gestern Abend an einen weiteren Imker Kollegen ein zweites System weitergegeben.
Sein erstes System hat er seit dem WS in Köln in Betrieb.

Auf der Basis seines Hinweises mache ich mir aktuell Gedanken um die Datenflut. ca. 1GB je Monat je Stock.
Wir sollten an dieser Stelle unbedingt einmal über die Messfrequenz sprechen … in meinen Augen sind 10sec. der Overkill.
Schon mit einer recht guten 60sec Regel würden wir das Datenvolumen auf 1/6 reduzieren …
Und dann in der Nacht vielleicht sogar alle 120 sec. …

1 Like

Hi @IngoP,
wir haben für das Datenvolumen eine ganz andere Abschätzung der Größenordnung. 1GB wäre in der Tat zu viel. Kannst du kurz beschreiben, wie du auf diesen Wert kommst? Wir rechnen im Moment mit ca 25MB pro Monat bei 10Sek.

Die Messfrequenz ist nur in der jetzigen Projektphase, der sogenannten Datenerhebungsphase, so hoch. Wir wollen im nächsten Entwicklungsschritt unbedingt die Messfrequenz und am liebsten auch die Anzahl der Sensoren verringern. Es gibt verschiedene Hypothesen, was hier sinnvoll sein könnte: 5 Minuten lang alle 10Sek messen und dann 25 Minunten komplett schlafen, nachts nur alle halbe Stunde messen, 24/7 alle 120Sek, die alle bis auf 2 Temperatursensoren loswerden…aber weil wir hier mit wissenschaftlichen Methoden rangehen wollen, haben wir uns entschieden, erstmal eine Datenflut zu erzeugen und diese auszuwerten, bevor wir anfangen zu optimieren.

Es könnte zum Beispiel sein, dass der von uns zu entwickelnde Algorithmus die Datenfrequenz in Zukunft dynamisch anpasst. Wenn die Auswertung der Daten mit geringer Frequenz beispielsweise auf eine Anomalie hinweist, es aber nicht eindeutig ist, was da grade los ist. Dann könnte man für ein paar Minuten genauer hinschauen, sozusagen. Diese Strategie lässt sich aber nur dann sinnvoll verfolgen, wenn man zur Entwicklung des Algorithmus entsprechende Daten hat.

Es kommt sehr darauf an, was wir übertragen. Dieser open-hive Datensatz mit nur CSV-Daten

Date/Time,Weight,Outside Temp,Outside Humid,Inside Temp,Inside Humid,H1 Temp,H2 Temp,H3 Temp,H4 Temp,H5 Temp,Voltage
2016/06/01 00:13:08,   1.909, 20.7, 76.7, 20.7, 77.8, 20.6, 20.8, 20.5, 20.6, 20.6, 4.22

hat ohne die Varriablenbezeichnung eine Größe von ca. 0.09 KB, bei 6 Messungen pro Minute haben wir 8640 Messungen pro Tag, reine Daten wären das ca. 23 MB.

Der Datensatz, den die hiveeyes-Software momentan überträgt ist mit 0.9 KB deutlich fetter:

hiveeyes/statista/hds/hive-1/data.json {"system.temperature": 22.17392, "temperature.28030f2509000057.onewire:0": 16.625, "scale.0.kg": 20.907, "system.wifi.rssi": -57, "system.wifi.country": "CN", "temperature.2890912409000025.onewire:0": 24.75, "system.time": 221239, "scale.0.offset": -2588598.0, "pressure.0x76.i2c:0": 1008.944, "temperature.2822f1240900005d.onewire:0": 20.6875, "system.wifi.channel": 11, "temperature.2879502409000075.onewire:0": 16.75, "system.memfree": 2107104, "scale.0.raw": -3126838.0, "system.voltage": 5.13, "temperature.28a1012409000048.onewire:0": 16.875, "temperature.0x76.i2c:0": 16.14393, "weight.0": 20.907, "scale.0.scale": -25745.0, "system.wifi.max_tx_power": 78, "system.wifi.bandwidth": 2, "system.uptime": 221239.3, "system.runtime": 10, "temperature.28eefa24090000cf.onewire:0": 17.4375, "humidity.0x76.i2c:0": 93.39642}

Das ist die 10-fache Menge von oben, hier aber mit den Varriablenbezeichungen und diversen System-Infos, die man ggf. auch weglassen kann. Wären ca. 225 MB im Monat.

Dazu kommt dann noch der Kommunikationsoverhead.

2 Likes

Die Datenmenge hatte ich vom Imkerkollegen genannt bekommen, der die Daten via GigaCube zur BoB App überträgt

Das hohe Datenvolumen am Gigacube kann man sicher auch durch das Abrechnungsintervall des Providers erklären.

Die Frage ist auch ob der Gigacube genauso rechnet wie der Provider.

Aber dort wird es denke ich bald Abhilfe geben (Stichwort Stromsparen).
Wenn mehrere Messungen gebündelt auf einmal übertragen werden wird sich auch das abgerechnete Datenvolumen drastisch verkleinern.

1 Like

Die Geschichte mit der Taktung bei der Abrechnung von Daten im Mobilfunknetz wird hier ganz gut erklärt

Was für einen Datentarif hat denn der Imkerollege bei Vodafone? Wenn wir dazu die vertragliche Taktung herausfinden kommen wir der Differenz vielleicht auf die Spur.

keine Ahnung.
Leider ist er hier nicht selber online. Die Parameter habe ich nicht alle abgefragt.

Ich versuche mal, wenn meine Beuten online sind, das Ganze über meinen CiscoAP messen zu lassen.

1 Like

2 posts were merged into an existing topic: Untersuchung und Verbesserung des Timings bei der Ansteuerung der DS18B20 Sensoren unter MicroPython

Neben der Datenmenge ist bei diesem Thema auch die mögliche minimale (!) Messfrequenz relevant. Bisher ist laut @caro und @tox eine Messfreqzenz von 10 Sekunden im Projekt vorgesehen.

Minimal mögliche Messfrequenz

Das hier sind Beispieldatensätze mit deaktiviertem deep sleep und einer Wartezeit von 10 Sekunden zwischen Ende Messung / Übertragung und erneuter Messung.

Timestamp,                  Gewi.,Spannung
2019-09-17T09:53:14.510316Z,0.011,4.152
2019-09-17T09:53:32.780887Z,0.012,4.152
2019-09-17T09:53:51.104433Z,0.012,4.152
2019-09-17T09:54:09.381210Z,0.013,4.152
2019-09-17T09:54:27.673770Z,0.012,4.152
2019-09-17T09:54:46.048883Z,0.012,4.152

Das ganze dauert ca. 19 Sekunden, d.h. wenn wir kontinuierlich messen wollen und das Warte-delay auf 0 Sekunden setzen könnten wir alle 9 Sekunden messen. Allerdings gibt es in diesem Modus Probleme und bei mir steigt das System nach ca. 4 Stunden aus.

Geringere Frequenz im deep sleep mode

Dagegen läuft das System im deep sleep-Modus stabil. Hier erfolgt systembedingt ein kompletter reboot nach einer deep sleep-Phase, was viel Zeit zum erneuten Hochfahren braucht und wir haben damit andere Intervalle:

2019-09-18T15:12:03.595625Z,0.003,4.074
2019-09-18T15:13:04.631589Z,0.003,4.074
2019-09-18T15:14:05.279757Z,0.002,4.068
2019-09-18T15:15:04.036381Z,0.001,4.068
2019-09-18T15:16:01.365069Z,0.003,4.074
2019-09-18T15:16:58.619722Z,0.002,4.068

Hier braucht das System ca. 60 Sekunden für einen Zyklus. Auch hier war eine Wartezeit von 10 Sekunden eingestellt, d.h. wir könnten hier maximal mit einer Frequenz von 50 Sekunden messen, die gewünschten 10 Sekunden erreichen wir damit nicht.

Bei der hiverize/FiPy-Software dauert das Auslesen der Sensoren gut 5 sec. Dann wartet man, bis Sekunde 10 erreicht ist. In dieser Wartezeit könnte man Stromsparmassnahmen testen.

Vielleicht wollen wir diese Probleme drüben bei Stabilität und längere Testzeiträume des Terkin-Datenloggers angehen?

1 Like