RS DB-Analyzer Update V2.5
Zunächst mal als Übersicht der Neuigkeiten ein Auszug aus dem Changelog:
2013-01-07 V2.5
Fixes
- fixed: Fehlermeldung im Logfile-Scanner: „Undefined Index: Performance“
- fixed: fehlerhafte Berechnung einiger Sparklinedaten korrigiert
- fixed: Speicherlogik 40Tage-CSV: speichert jetzt nur noch max. einmal pro Tag
- fixed: Sortierung deutscher Datumsformate
Features
- Planungsforecast für Timeslots: zeigt die Auswirkungen der Timeslot-Planung auf die Abarbeitung der Queue als Forecast-Tabelle im Info-Fentser an (nur bei Aktionen im TS-Manager,die Auswirkungen auf die Planung haben)
- Erweiterung einiger Sparkline-Darstellungen
- Record-Analyzer: Anaylse von systembedingten Datenfehlern in Zählervariablen incl. Lösch-Option
Versions-Details
neben den Bugfixes (die hoffentlich selbsterklärend sind) gibts 2 wesentliche Neuerungen:
Download der Version 2.5 auf der Projekt-Homepage
Planungsforecast
ich habe dem Aggregationsmanager einen Planungsforecast spendiert: sobald man eine Änderung im Timeslot-Manager vornimmt (die sich auf die Dauer des geplanten Aggregations-Jobs auswirkt), erscheint nach 3 Sekunden eine Tabelle mit voraussichtlichen Joblaufzeiten im Info-Fenster. So kann man die Timeslot-Planung sehr einfach optimieren und sieht sofort, welche Auswirkungen diese Änderungen haben. Vorsicht: der Planungsforecast kann (noch) keine unsinnigen Eingaben in den Timeslots kompensieren (z.b. sich überlappende Timeslots)
Modul Record Analyzer
Funktion
Der Record-Analyzer untersucht alle Datensätze von Zähler-Variablen auf Fehlerwerte. Diese Fehlerwerte können via GUI analysiert und bereinigt werden (Cleaning). Anschließend sollten die betroffenen Variablen reaggregiert werden. Dazu erstellt der Record-Analyzer eine Reaggregations-Queue, die vom User via Aggregations-Manager zur Abarbeitung angestoßen werden kann. Sicherheitshalber schreibt der Record-Analyzer ein Log ins Projektverzeichnis („\RSDB_Analyzer\RecordAnalyzer\Log\“), welches alle gelöschten Daten enthält. Achtung: die Fehlerausgabe ist auf max. 500 Fehler begrenzt, da es sonst zu Memory-Problemen in IPS kommt. Hat eine Variable mehr als 500 Datenfehler, muss der Cleaning-Prozess entsprechend oft angestoßen werden
Grundlagen
Zunächst sollte man verstehen, wie diese Fehler zustande kommen:
Die Ursache liegt in einem systemischen Mechanismus von IPS und besteht aus 3 Parts.
- Schreiben und Lesen der Variablenwerte beim IPS-Restart:
Grundsätzlich werden alle aktuellen Variablenwerte auch in der Settings gespeichert. Fährt man IPS runter, werden diese beim Beenden in die Settings geschrieben. Beim IPS Start passiert genau das Gegenteil: IPS liest diese Variablenwerte aus und schreibt sie als erste Aktion nach dem Start in die Datenbank (natürlich nur bei geloggten Variablen). Das führt dazu, dass ein Wert in die DB geschrieben wird, der nicht mehr der Realität entspricht. Stellen wir uns einen Stromzähler vor: der hat zwischenzeitlich fleißig weiter gezählt und inzwischen einen anderen (höheren) Zählerstand.
- Datenbank-Aggregationslogik für Zählervariablen:
Die Aggregationslogik für IPS Zählervariablen kennt nur ansteigende Record-Values. Das bedeutet: es werden immer nur positiv-Deltas zwischen aktuellem und vorhergehendem Messwert berücksichtigt. Negative Deltas werden ignoriert.
- Unabhängig vom Wert, der in die Settings geschrieben wird, werden die aktuellen Daten ja ständig in die Logging-Datenbank geschrieben.
Im Normalfall (IPS innerhalb von 1-2 Minuten neu starten) ist das ein Problem mit eher homöopathischen Auswirkungen und vernachlässigbar. In einigen Sonderfällen kann die Auswirkung aber signifikant werden:
- Bei Wiederherstellung der Settings durch ein älteres Backup
- IPS schreibt im Betrieb die Settings nicht mehr (macht sich z.B. dann bemerkbar, wenn sich beim IPS-Runterfahren der IPS-Task nicht selbständig beendet und via Taskmanager abgeschossen werden muss)
Startet man nun IPS neu, so schreibt IPS erst mal den letzten Variablenwert aus der Settings in die DB. Das führt zwangsläufig dazu, dass der neu geschriebene Wert kleiner ist als der zuletzt in die DB geschriebene Wert. Es entsteht ein Negativ-Delta. Unmittelbar danach werden dann die vom Sensor gelieferten Werte weiter geschrieben. Für den User macht sich das so bemerkbar, dass der Stromverbrauch (um mal beim Beispiel Stromzähler zu bleiben) für den Zeitraum zwischen letztem Settings-Wert und IPS-Neustart doppelt gezählt wird (siehe Beispiel im Bild rechts: die Summe der Datenfehler beträgt 22 kWh). Je größer die Zeitdifferenz zwischen Settings-Datum und DB-Datum, desto größer das Fehlerpotenzial.
Eine anschließende Neu-Aggregation der bereinigten Variablen ist dringend anzuraten: nur so wird Das Cleaning auch für alle Auswertungen (IPS-Charts, HighCharts, DB-Abfragen) wirksam. Auch das ist denkbar einfach: durch die vom Record-Analyzer vorbereitete und an den Aggregationsmanager übergebene Aggregations-Queue muss man eigentlich nur noch den Aggregationsmanager (Automatik-Modus) starten.
