RS.Heatmap365 2.0

Changelog V2.0a vom 21.08.16:

 

Wozu?

In manchen Situationen ist es ganz gut, mal nicht die Mikrometerschraube anzusetzen, sondern vielleicht mal 2-3 Schritte zurück zu treten, um das ‚große Ganze‘ besser erfassen zu können.
So ungefähr verhält es sich auch mit der Datenvisualisierung mit Hilfe von Heatmaps: es geht nicht um Einzelwerte, sondern um das Gesamtbild. In meinem speziellen Anwendungsfall geht es mir darum, diverse met. Messdaten, mit denen ich seit Jahren mein IP-Symcon füttere (die IPS Datenbank ist richtig rund und fett geworden, jetzt will ich endlich mal was sehen!), über lange Zeiträume miteinander zu vergleichen. Zum Beispiel den Temperaturverlaugf der verg. Jahre. Während herkömmliche Charts nur einen ganz kleinen Eindruck der Geschehnisse wiedergeben können (z.B. Temperaturkurve über ein Kalenderjahr), kann man mit einer Heatmap wesentlich mehr Informationen auf kleinstem Raum darstellen. Und ganz wichtig: sie sind für den Betrachter viel leichter in vollem Umfang erfassbar. Nämlich über das optische Muster.

Eine solche Heatmap über ein komplettes Kalenderjahr kann schon spannend sein. Noch viel interessanter finde ich den direkten Vergleich von Heatmaps mehrerer Jahre. Zum Beispiel die des Luftdrucks (siehe Bild rechts).

Nachdem ich vor Jahren schon mal via html damit rum experimentiert hatte (das waren eine meiner ersten PHP-Gehversuche) und das Thema bei mir in Vergessenheit geriet, bin ich diese Woche mal voll eingestiegen und hab  ziemlich kurzer zeit ein (zumindest für mich) sehr brauchbares Ergebnis erreicht. Vom Code her wesentlich schlanker als HighCharts – kann aber auch weniger. Reicht aber für mich. Aus der anfänglichen Spielerei ist nun eine (halbwegs) ernsthafte Anwendung geworden. Wobei ich die Heatmaps (mit angepasstem Farbschema) ausschließlich auf meiner Webseite nutze:

RS Heatmaps Luftdruck

RS Heatmaps Temperatur

 

Programmablauf

Ich will nicht großartig in die Programmierung einsteigen, aber dennoch kurz den Programmablauf skizzieren, da das zum besseren Verständnis der erzeugten Heatmaps beiträgt.

Das Script ermittelt zunächst, für welche Kalenderjahre Daten in der IPS DB verfügbar sind. Die Suche beginnt im Jahr 2005. Anschließend wird für jedes Kalenderjahr, für das geloggte Daten zur Verfügung stehen, ein Array mit Stundendurchschnittswerten (Stundensummen bei Zählervariablen) angesaugt. Das wären dann mal um die 8700 Datensätze – pro Kalenderjahr (ziemlich nahe an den System-Limits)! Aus diesen Stundenwerten wird der (für alle Kalenderjahre übergreifend) der maximale und minimale Stundenwert ermittelt. Diese Werte werden dann in die Variablen ‚Min‘ und ‚Max‘ geschrieben. Gleichzeitig gelten diese Min- und Max-Werte als absoluter oberer und unterer Grenzwert für den Wertebereich und damit die Farbskalierung aller Kalenderjahre. Damit wird sicher gestellt, dass alle erzeugten Heatmaps einer Messgröße miteinander direkt vergleichbar sind.

Erst im Anschluss werden die Stundenwerte des aktuellen Kalenderjahres verwendet, um die Heatmap (HTML-Tabelle) zu erzeugen, mit Tooltips zu versehen und auf die Festplatte zu schreiben.

Startet man manuell das Config-Script, so findet vor allen oben beschriebenen Aktivitäten eine Re-Initialisierung des Projekts statt: 

• Der Projektordner-Name wird mit dem Namen der Messgröße versehen
• Die in den Variablen gespeicherten Max- und Min-Werte werden gelöscht
• Der Timer wird auf einen zufälligen Startzeitpunkt zwischen 0:00 Uhr  und 0:15 Uhr gesetzt und aktiviert
• Erst dann wird das Heatmap365 Core Script gestartet und erledigt den oben beschriebenen Job

 

was geht und was nicht geht

Eigentlich geht mit der Version 2.0 alles: egal ob Verbräuche, met. Messdaten, Standard- oder Zähler-Variablen, mit IP-Symcon geloggte Werte – eigentlich ist alles mit RS Heatmap365 2.0 darstellbar. Ob das immer ein aussagefähiges Bild ergibt, muss der User für sich selbst entscheiden. Aber technisch ist es kein Problem.

Ab der Version 2.0 wird übrigens durchgängig und ausschließlich mit Stundendurchschnittswerten (für Standard-Variablen) und Stundensummen (für Zählervariablen) gearbeitet. Dies gilt natürlich ebenso für alle Min- und Max-Werte.

Obere und untere Kappungsgrenze: wer Daten mit sehr großem Wertebereich visualisieren will, kann (muss aber nicht) mit Hilfe der oberen und unteren Kappungsgrenze Messdaten aus der Visualisierung ausgrenzen. Das ist z.B. dann hilfreich, wenn man extreme Werte oder Ausreißer in der Datenreihe hat und dadurch der eigentlich interessante Wertebereich farblich kaum skaliert werden kann.

Ein anderer Anwendungsfall könnte sein: ich habe einen Energieverbrauch, der täglich zwischen 200 Watt und 2000Watt schwankt. Dieser Wertebereicht ist durchaus brauchbar mit Standard-Einstellungen visualisierbar.

Jedoch interessiert mich im speziellen Beispiel nicht der gesamte Wertebereich (also 200-2000W), sondern nur der Wertebereicht von 200-500 Watt, weil ich nämlich den Standby-Verbrauch meines Wohngehäuses übers Jahr analysieren möchte. Dann würde ich eine obere Kappungsgrenze von 500 ins Config-Script eintragen und Feuer!

Im Bild rechts habe ich ein solches Beispiel rausgefischt: in 2015 habe ich meine IT umgebaut, was zur Reduktion der Grundlast um ca. 60Watt führte. Der Umbau erfolgte Ende Juli. Anhand der Farbmuster bis Juli und (verändert) ab August ist das schon recht gut erkennbar. Im Bild darunter das Gegenbeispiel: selber Zeitraum, aber Kappungsgrenze deutlich höher. Wie Sie sehen, sehen Sie nichts! Also zumindest nicht im Bereich der Grundlast. Die Änderung des Grundrauschens von -60Watt ist einfach nicht mehr sichtbar.Wir lernen: die Kappungsgrenzen können u.A. als „Datenlupe“ oder „Zoomfunktion“ benutzt werden, um ganz spezielle Details sichtbar zu machen.

Ist die Anwendung einer Kappungsgrenze nicht gewünscht, legt man den Wert für die obere Kappungsgrenze so hoch, dass der garantiert über dem höchsten Messwert der Datenreihe aller Kalenderjahre liegt. Für die untere Kappungsgrenze gilt dies umgekehrt.

Skalierungs-Faktor: falls Daten in einem ungeeigneten Wertebereich vorliegen (Beispiel: der Verbrauch des Stromzählers in KW), aber eine Visualisierung in Watt gewünscht ist, lässt sich der Messwert mit dem Skalierungsfaktor mit 1000 multiplizieren (Beispiel: $Faktor = 1000;). Umgekehrt geht auch: $Faktor = 1/1000; multipliziert die Messwerte mit 0.001. Z.B. dann hilfreich, wenn die Messwerte in Watt vorliegen, ich aber in KW visualisieren möchte.

 

 

Tipp für die Vergangenheit

In der Version 1.0 war es möglich, nachträglich für jedes vergangene Kalenderjahr eine Heatmap zu erzeugen (sofern denn geloggte Daten vorlagen). Macht man das 1, 2 Mal, ist das kein Beinbruch. Aber auf Dauer (wie ich z.B. bei der Entwicklung und Testen) wird das anstrengend.

Daher hab ich dem Projekt ein kleines Steuer-Script (‚RS Heatmaps 365 2.0 Beispiel externe Steuerung‘) beigelegt, welches man bei Bedarf manuell starten kann. Dieses Script scannt die IP-Symcon Datenbank auf geloggte Daten und erzeugt automatisch für jedes mit Loggingdaten bestückte Kalenderjahr ein dediziertes Heatmap-File und legt dies auf der Festplatte ab. In der HTML-Box wird jedoch weiterhin ’nur‘ die Heatmap des aktuellen Kalenderjahres angezeigt. Will man die Heatmaps der verg. Kalenderjahre im WFE visualisieren, muss man sich diese selbständig ins WFE verlinken.

Die Heatmap-Files finden sich dann im Ordner ‚\webfront\user\ips_media\heatmaps\‚ wieder und sind erkennbar am Dateinamen ( Messgröße + Script-ID + Kalenderjahr). Diese können dann (manuell) via iframe und HTML-Box ins WFE eingebunden werden.

 

Zu groß?

Ich arbeite zur Zeit fast ausschließlich mit 4k-Bildschirmen. Die Heatmap kann daher durchaus auf dem ein oder anderen System zu groß erscheinen – wenn dort mit geringerer Bildschirmauflösung gearbeitet wird. Natürlich kann man das anpassen: in der Config die Parameter für Höhe und Breite ändern ($height und $width). Diese Angaben beziehen sich auf genau einen Stundenwert. Da der Tag aber 24 von diesen Stunden hat und das Kalenderjahr 365 Tage, ergibt sich hieraus eine Größe von 730 x 72 Pixel (+ Tabellenkopf und -Fuß) bei den Default-Werten  height = 3pixel und $width = 2pixel. Man könnte so die Heatmap auf eine Größe von 365 x 24 Pixel schrumpfen (+ Kopf- und Fußzeile). Wer es gern groß mag: geht natürlich auch!

 

Ressourcenbedarf

Durch die konsequente Umstellung auf Stundensummen/Stundendurchschnittswerte ist der Ressourcenbedarf erheblich gestiegen. Das ist auch der Grund, warum ich die RS Heatmap365 V1.0 parallel mit eigener Projektseite und -Download weiterhin online halte. Meiner Meinung nach ist der Ressourcenbedarf nicht kritisch (ein RasPi 3 benötigt nur etwa 5% mehr Zeit zur Erstellung der Heatmaps) – aber man weiß ja nie. Die Script-Durchlaufzeit auf meinem System IPS 3.4, WIN) liegt nun bei ~ 3000ms (vorher: ~1100ms). Auf dem RasPi geringfügig mehr.

Interessanterweise benötigt das Projekt unter IPS 4.0 wesentlich mehr RAM als unter IPS 3.4: während es bei IPS 3.4 deutlich unter 32MB liegt, braucht das Script unter IPS 4.0 mindestens 40MB RAM (ca. 30% mehr RAM). Finde ich ziemlich krass – kann ich aber nicht ändern. Also eine Memory-Limit Prüfung eingebaut, die automatisch das RAM-Limit auf 64MB hoch setzt. Da das nur für den Durchlauf für dieses Script gilt, sollte das unkritisch sein.

Der aufmerksame Leser und HighEnd-Heatmapper wird sich jetzt fragen: Alter, ich hab mehrere hundert Heatmap-Instanzen installiert! Wenn die jetzt bei dem Ressourcenbedarf 1x pro Stunde alle gleichzeitig starten?

Auch kein Problem: zur Vermeidung von Lastspitzen wird der Timer jeder Heatmap365-Installation auf einen zufälligen Startzeitpunkt innerhalb der ersten 15 Minuten einer Stunde gesetzt. Die Aggregatzustands-Änderung der CPU von fest auf gasförmig (nebst Atompilz) dürfte somit nahezu ausgeschlossen sein.

 

Showcase

Wer statt drögem Text lieber was Buntes sehen will: habbich auch! Hier geht’s zu einem ganzen Haufen echter Heatmaps (area51.raketenschnecke.net).

 

Installation

Wie üblich: Datei aus dem Download runterladen, das Installer-Script ins IP-Symcon kopieren und ausführen. Das Projekt ist nun installiert, aber noch nicht initialisiert.

Anschließend das Config-Script mit den gewünschten Parametern versorgen und einmalig manuell ausführen. Das Projekt wird initialisiert und läuft ab diesem Zeitpunkt selbständig. Ich hab diesmal auf Objekte für das Webfront verzichtet: für (zunächst) ein Objekt lohnt sich das nicht. Hier muss der Anwender selbst Hand anlegen: am besten die Variable ‚Heatmap HTML Box‘ an die Stelle ins WFE verlinken, wo man es später auch sehen will. Entweder via Link-Objekt direkt im IPS Objektbaum oder Einbindung über den Webfront-Konfigurator.

Wer will, kann das Farbschema der Heatmap an die eigenen Wünsche anpassen. Darüber hinaus hilft es auch, den grünen Text oben im Config Script zu lesen ;-)

 

Update

Wer bereits die V 1.0 installiert hat: keine Panik, alles kein Problem! Einfach das Installer-Script aus dem Download in das vorhandene Installationsscript kopieren uns einmalig manuell ausführen. Das Projekt hat nun sein Update bekommen. Es ist auch eine neue Config dazu  gekommen – die Alte kann gelöscht werden (nachdem ggf. die Konfig-Parameter aus dem alten Config-Script übernommen wurden). Dann einmalig das Config-Script starten – fertig. Das Projekt führt nun selbständig alle 60 Minuten eine Aktualisierung der Heatmap des aktuellen Kalenderjahres durch.

 

IPS-Versionen

Das Projekt wurde zwar unter IPS 3.4/Windows entwickelt, aber auch auf IPS 4.0 Windows und Linux (RasPi 3) erfolgreich getestet und ist dort uneingeschränkt lauffähig.

 

Versions-Hinweise

RS Heatmaps365 2.0: Version vom 19.08.2016

RS Heatmaps365 1.0: Initial-Version vom 13.08.2016

 

 

Quellen:

• Skalierungsfunktion nach Martin’s Schablone

 

 

Nutzungsrechte

• das Script darf für private, nicht kommerzielle Zwecke frei verwendet werden
• für evtl. entstehende Schäden durch die Verwendung dieses Scripts wird vom Autor keinerlei Haftung übernommen 
• gewerbliche Nutzung nur in vorheriger Abstimmung mit dem Projektautor (MICH)

 

Download

Unterhalb dieses Beitrags:

 

---