Kompression auf Basis von relativer Änderung

[martinrieder]

Die Wahl der Parameter für Delta- und Swinging-Door-Kompression ist u. A. vom Wertebereich abhängig. Es sollte hier eine Möglichkeit geben, auch relative Werte anzugeben, beispielsweise 1% bezogen auf den Momentanwert.

[mdzio]

Das gibt aber bei allen Messwerten, die auf 0 oder unter 0 gehen können, merkwürdige Effekte.

Beispiel für eine Temperaturmessung mit 5% Kompression: Bei 20°C wird alles mit einem Delta von 1°C archiviert. Bei Werten im Bereich +/- 1°C wird aber praktisch jeder Wert archiviert, da eine Änderung der Temperatur mindestens 0,1°C ist.

Mir kommt da kein Anwendungsfall in den Sinn, wo es Vorteile bringen würde.

Hilfreich wären aber z.B. 5% vom Messbereich. Das könnte der CCU-Historian selber in einen Absolutwert umrechnen. Voraussetzung dafür ist, dass die CCU den Messbereich (Minimum und Maximum) korrekt mitteilt.

[martinrieder]

Stimmt. Danke für den Hinweis. Ich habe auch darüber nachgedacht, ob es bezogen auf den Messbereich sinnvoller wäre. Womöglich braucht es eine Kombination aus beidem!?

• Die von mir vorgeschlagene Variante bezogen auf dem Momentanwert würde wohl nur funktionieren, wenn man eine Normierung des Wertebereichs integriert.
• Für die Variante bezogen auf den Messbereich könnte die Berechnung des Absolutwerts sicherlich mit einem Skript gelöst werden.

Die relative Kompression macht überall dort Sinn, wo man auch logarithmische Skalen (siehe #154) verwenden würde. Ich denke da weniger an Temperaturen, als beispielsweise Strombedarf (Leistung).

[martinrieder]

Ich habe mal ein Beispiel rausgesucht, in dem man die hohe Dynamik gut erkennen kann. Dabei fällt mir aber auch auf, dass alleine die Amplitude zu komprimieren eventuell nicht ausreicht. Eventuell braucht es eine Methode, die auch der zeitlichen Dynamik gerecht wird. Womöglich sollte meine ursprüngliche Idee dahingehend ausgeweitet werden, dass die Änderungsrate des Signals als Grundlage der Kompression dient. (Das wird bei Swinging Door z.T. schon berücksichtigt, aber mit absoluten Werten.)

Das Problem resultiert zum Teil auch einfach aus der Tatsache, dass man mit dem CCU-JACK wunderbar auch Geräte per MQTT einbinden kann. Die Frequenz, mit der die Daten sprudeln ist damit meist deutlich höher als "nur" mit HM. Das Signal-zu-Rausch-Verhältnis ist wegen höherer Bandbreite (Abtastrate nach Nyquist) nun etwas anders...

Ich werde mal ein paar Berechnungen mit o.g. Daten anstellen, um zu sehen, wie sich diese besser komprimieren lassen.

[mdzio]

Eine alternative für hohe Datenmengen ist auch ein performanter Rechner/NAS mit einer SSD für den CCU-Historian.

[martinrieder]

Der Raspi mit 8GB RAM liegt schon bereit, allerdings möchte ich trotzdem die Daten komprimieren. Was habe ich schon davon, meinen Stromverbrauch der letzten X Jahre auf die Sekunde und das Milliampere genau auswerten zu können? (rhetorische Frage)

Hier ein Konferenzbeitrag über mögliche Optimierungen des Swinging-Door-Algorithmus: Swinging Door Trending Compression Algorithm for IoT Environments

[mdzio]

Noch eine Idee:

1. Der CCU-Historian zeichnet für Datenpunkte eine gewisse Zeit Rohdaten auf.
2. Ein Skript, das entweder in der Skriptumgebung oder in der Konfigurationsdatei zyklisch ausgeführt wird, analysiert die Rohdaten von allen Datenpunkten ohne Kompression.
3. Das Skript konfiguriert dann selber die Kompressionen und deren Parameter anhand von bestimmten Kennwerten der Rohdaten.

[mdzio]

Um einfach neue Kompressionsalgorithmen zu testen, ohne diese gleich im CCU-Historian zu implementieren, kann auch die zyklische Ausführung von Skripten in der Konfigurationsdatei verwendet werden. Einmal am Tag könnte dann der vorhergehende Tag komprimiert werden. Parameter könnten auch in der custom-Eigenschaft der Datenpunkte abgelegt werden.

[martinrieder]

Noch eine Idee:

1. Der CCU-Historian zeichnet für Datenpunkte eine gewisse Zeit Rohdaten auf.

Meine 2-3 Gedanken dazu:

1. Für sehr volatile Datenpunkte wäre es in dem Fall von Vorteil, wenn man diese über deren Median filtern könnte. Im Vergleich zum Mittelwert würden hiermit schon mal die Spitzenwerte und Ausreißer eliminiert. Im Nachgang würde ich dann nur noch (per Skript?) die Auflösung reduzieren, indem beispielsweise auf 1% Genauigkeit gerundet wird.

2. Theoretisch ließen sich solche Geschichten auch on-the-fly umsetzen, wenn man Min/Max/Median/Mittelwert mit Delta-/Sw.Do.-Kompression koppeln könnte. Dazu müsste also eine Vorverarbeitung in zwei Schritten konfiguriert werden können. Im ersten Teil wird quasi nur die Amplitude gefiltert und danach wird dann die Anzahl der Werte reduziert.

Diese Ideen lösen nicht das ursprüngliche Thema, nämlich die Anpassung der Parameter an den Wertebereich der Datenreihe... ABER:

3. Die Reduzierung der Auflösung wäre für mich auch durch eine Runden-Funktion denkbar, die auf eine bestimmte Anzahl von signifikanten Ziffern rundet. Das ist ähnlich wie bei einem Multimeter, welches die Wertebereiche umschaltet. Effektiv käme das dann meinem ursprünglichen Vorschlag sehr nahe.