3.7 Speicherbedarf von KNX-Log und Zeitreihen

Beschreibung: Abschätzung wieviel Speicher von Zeitreihen benötigt werden

Kategorie: Grundwissen, Grafana

Link zu diesem Beitrag: Alles auswählen

[url=https://forum.timberwolf.io/app.php/kb/viewarticle?a=32&sid=da2449dffa1c92b037e445aa0c13fe9c]Knowledge Base - 3.7 Speicherbedarf von KNX-Log und Zeitreihen[/url]

Allgemeines zur Datenspeicherung:
Die Aufzeichnungen der Logs (z.B. KNX Log) sowie aller angelegten Zeitreihen erfolgt beim Timberwolf Server in die Datenbank ‚InfluxDB‘.
Zeitreihen („Timeseries“) sind Logs (Auflistung aufgetretener Events) und Messwerte mit zeitlichen Bezug. Es wird also immer die genaue Uhrzeit mitgespeichert.
InfluxDB ist eine Datenbank die speziell für die Aufzeichnung von Events und Zeitreihen entwickelt wurde.
Besonderheit von InfluxDB ist die Fähigkeit eine extreme Anzahl von Werten gleichzeitig aufzuzeichnen, bei hoher und dennoch verlustloser Datenkompression.

Abschätzung des Speicherbedarfes:
Es wird immer Messwert+Zeitstempel gespeichert, dies sind ca. 14byte je Messwert (ob 10 oder 12bit oder ein KNX Telegramm) ist wegen der Kompression vernachlässigbar. Schwieriger ist die Frage zu beantworten, wie oft ein Wert geschrieben wird.

Der Speicherbedarf hängt von den Einstellungen ab!
  • Grundsätzlich läßt sich bei KNX-Devices (fast aller Hersteller) in der ETS einstellen, wann ein Wert eines Objektes auf den Bus geschrieben wird. Die Auswahl ist zumeist "nur bei Wertänderung um X" oder "in Intervallen von x Sekunden" oder auch eine Kombination aus beidem.
  • Wenn man die Dichte der Telegramme - insbesondere wenn diese auch aufgezeichnet werden sollen, geringer halten möchte, dann empfiehlt es sich einzustellen, dass ein Wert nur "bei Änderung von einigen Prozent" gesendet werden soll und ansonsten alle viertel Stunde. Das ist meistens völlig ausreichend. Bei kritischen Steuerungen / Regelungen (z.B. Windalarm für Raffstore / Markisen) mag eine häufigere Wiederholung des Alarms sinnvoll sein (für den Fall dass ein Telegramm nicht jeden Jalousieaktor erreicht hat).
  • Bei dem Anlegen von 1-Wire Regeln gilt das gleichermaßen, auch hier sollte die Dichte der Meldungen auf ein vernünftiges Maß begrenzt werden. Es stehen die gleichen Möglichkeiten für das Senden zur Verfügung, also "bei Weertänderung um X Prozent" oder "X absolut" sowie im Interval und auch die Kombination aus beiden. Empfehlung von ElabNET: "Senden bei Wertänderung um 5% bzw. alle 15 Minuten" aus dem "Mittelwert aus drei Messintervallen" um die Genauigkeit der Messung zu erhöhen.
  • Bei Fensterkontakt gibt es nur Auf / Zu, also einen binären Wert. Hier wählt man "Senden bei Wertänderung" sowie "Intervall alle 30 Minuten" (bei Wichtigkeit auch öfters).
  • Wer hinsichtlich der Zeitreihen sparen will, legt bei 1-Wire zwei Regeln an. Die eine Regel die auf den Bus sendet (mit den obigen Einstellungen) und eine fast identiche Regel (hier auf den Kopier-Button drücken) die "nur bei Wertänderung um x" in eine Zeitreihe schreibt plus einem Intervall von mehreren Stunden (damit es auch bei einem das ganze Jahr über geschlossenem Fenster wengistens ein paar mal am Tag einen Datenpunkt gibt, sonst tut sich Grafana mit der Anzeige schwer).
Insgesamt kann man mit diesen optimierten Einstellungen folgenden Datenverbrauch erwarten:
  • Temperaturen ändern sich zumeist langsam. Schreibt man nur bei einer Änderung ab ein paar Prozent und auch nur den Mittelwert aus mehreren Messungen und anstonsten einmal pro Stunde, dann dürfte das in zwei bis drei Dutzend aufgezeichneten Datenpunkten resultieren. Damit ergäben sich ca. 36 x 14 Byte = 504 Bytes pro Tag. In zehn Jahren macht dies dann 1,75 MByte. Eintausend solcher Datenreihen belegen dann 1,75 GB.
  • Ähnliches gilt für Feuchte, VOC etc.
  • bei der Aufzeichnung des KNX Log werden auch etwa 14 Byte pro Datenpunkt geschrieben. Hier ist die Datenbank so eingestellt, dass mit der Zeit ältere Einträge gelöscht werden. Beim TWS 950 ist das Log auf 100 Millionen Einträge = 1,3 GB begrenzt. Bei TWS 2600 ist es eine Milliarde Einträge, das sind dann 13 GB, allerdings ist der Server auch mit 256 GB minimal ausgestattet.
Negativbeispiel (schlechteste Einstellung):
  • Anwender legt eine Überwachungsregel im 1-Wire Geräteeditor an und prüft einen Fensterkontakt nicht nur sekündlich, sondern schreibt das auch in die Datenbank
  • Das führt zu 86400 Einträgen pro Tag und Fensterkontakt, mithin 1,153 MByte / Tag, ergibt 4,11 GByte in zehn Jahren. Das mal 30 Fenster wären 123 GByte. Kann man machen, aber empfehlen wir nicht
Bearbeitet von SW am 2018-10-13