Home
Langzeitarchiv für die Zentrale (CCU) des Hausautomations-Systems HomeMatic
In diesem Handbuch können bereits Funktionalitäten beschrieben sein, die noch nicht in der stabilen Version des CCU-Historians enthalten sind.
Autor dieses Handbuchs ist Mathias Dzionsko. Dieses Handbuch steht unter folgender Lizenz:
- Einleitung
- Zusätzliche Funktionalität
- Installation
- Konfiguration
- Start
- Datenbank
- Web-Schnittstelle
- Unterstützung
- Tipps & Tricks
Der CCU-Historian stellt ein Langzeitarchiv für die HomeMatic-Zentrale (CCU) zur Verfügung. In dem Langzeitarchiv werden Kommunikationsvorgänge der CCU-Schnittstellen (BidCos-RF, BidCos-Wired und System) aufgezeichnet. Darunter befinden sich z.B. die Messwerte aller Sensoren und alle ausgeführten Schaltvorgänge. Aus der Logikschicht der CCU werden zusätzlich die Systemvariablen archiviert. Die gesammelten Daten werden in einer Datenbank abgelegt und stehen daraufhin für Visualisierungen oder Analysen zur Verfügung. Für einen ersten Überblick werden Web-Seiten mit Trend-Diagrammen durch einen eingebetteten Web-Server generiert.
Folgende Zielsetzungen waren und sind bei der Entwicklung maßgebend:
- Keine Software-Installation oder Konfiguration auf der CCU.
- Verwendung von offiziellen bzw. gut dokumentierten Schnittstellen.
- Möglichst geringe Belastung der CCU.
- Selbstkonfiguration des Langzeitarchivs.
- Verwendung einer Datenbank mit offenen Schnittstellen.
- Einfacher Export der Daten über eine Web-Schnittstelle.
Im Folgenden wird die Umsetzung der einzelnen Ziele näher erläutert:
-
Auf der CCU sind für den CCU-Historian keine zusätzlichen Software-Pakete nötig. Der CCU-Historian kann direkt mit einer neu ausgelieferten CCU verwendet werden. Des Weiteren müssen auch keine gesonderten Programme oder Systemvariablen auf der CCU angelegt werden.
-
Der CCU-Historian verwendet die HomeMatic XML-RPC bzw. BIN-RPC API und die Remote HomeMatic-Script API. Bei der Script API wird auf die Verwendung des nicht dokumentierten Befehls system.Exec verzichtet.
-
Die Kommunikationsvorgänge des CCU-Historians mit der CCU werden auf das Notwendige beschränkt. Datenbankabfragen sind völlig von der CCU entkoppelt, und belasten nur den Rechner auf dem der CCU-Historian läuft.
-
Nach der ersten Konfiguration des CCU-Historians für die Inbetriebnahme, ist keine weitere Konfigurationspflege mehr nötig. Insbesondere wenn Geräte an der CCU angelernt oder entfernt werden, aktualisiert der CCU-Historian selbstständig die Verwaltungsstrukturen in der Datenbank. Von neu angelernten Geräten werden automatisch alle Kanäle und die zugehörigen Parameter erkundet.
-
Auf Grund der zu erwartenden Datenmengen und den vielfältigen Abfragemöglichkeiten wird eine Datenbank mit SQL-Unterstützung und den Schnittstellen JDBC und ODBC verwendet. Dadurch können auch mächtige Report-Werkzeuge wie z.B. BIRT (http://www.eclipse.org/birt/phoenix) auf die Daten zugreifen.
-
In dem CCU-Historian ist ein Web-Server eingebettet, der für das einfache Exportieren von Zeitreihen und die Generierung von Trend-Diagrammen zuständig ist. Über eine URL mit zusätzlichen Parametern, die im einfachsten Fall über einen Web-Browser eingegeben wird, wird die Abfrage angestoßen.
Der CCU-Historian ist in der Programmiersprache Groovy (http://www.groovy-lang.org/) implementiert und benötigt für die Ausführung Java mindestens in der Version 11. Er ist damit plattformunabhängig und kann somit auch z.B. unter Linux eingesetzt werden.
Um die zusätzliche Installation einer Datenbank zu vermeiden, wurde die H2 Database Engine (http://www.h2database.com) in den CCU-Historian eingebettet. Diese stellt zusätzlich eine Web-Bedienschnittstelle zur Verfügung. Dadurch kann die Datenbank leicht über einen Web-Browser verwaltet werden.
Über eine Web-Schnittstelle kann der CCU-Historian Daten exportieren oder darstellen. Dazu ist der Web-Server Jetty (http://www.eclipse.org/jetty/) ebenfalls im CCU-Historian eingebettet. Zusätzlich zu den HTML-Seiten des CCU-Historians kann der Anwender eigene HTML-Seiten über den Web-Server anbieten. Dadurch kann der Anwender beliebige Übersichtsseiten mit aktuellen Messwerten und/oder Trend-Diagrammen erstellen.
Für die Generierung von Trend-Diagrammen wurde die Bibliothek JFreeChart (http://www.jfree.org/jfreechart/) verwendet.
Eine Übersicht des CCU-Historians ist in der folgenden Abbildung zu finden:
Neben der Grundfunktionalität eines Langzeitarchivs, wie sie bereits in der Einleitung beschrieben worden ist, bietet der CCU-Historian zusätzliche Möglichkeiten, die im Folgenden beschrieben werden.
Die aufgezeichneten Zeitreihen der Datenpunkte können als Trend-Grafik visualisiert werden. Nach Auswahl der anzuzeigenden Datenpunkte und des Zeitbereichs in der Web-UI des CCU-Historians wird eine PNG-Grafik berechnet und an den Web-Browser des Anwenders zur Anzeige geschickt.
Durch das zusätzliche Plug-In H2-HighChart, welches immer mit ausgeliefert wird, und im Menü unter Extras → H2-HighChart zu finden ist, können auch interaktiv Trend-Kurven analysiert werden.
Die Wertaktualisierungen aller Datenpunkte durchlaufen eine Vorverarbeitung bevor sie in der Datenbank abgelegt werden. Die Vorverarbeitung dient dazu, die anfallende Datenmenge zu reduzieren indem unnötige Wertaktualisierungen verworfen werden und/oder bestimmte Bereinigungsfunktionen auf den Werteverlauf eines Datenpunktes anzuwenden.
Eine aktivierte Vorverarbeitung für einen Datenpunkt wirkt sich in mehrerlei Hinsicht positiv aus:
- Geringerer Speicherbedarf auf dem Datenträger
- Höhere Geschwindigkeit bei der Trend-Darstellung
- Geringere Netzwerkbelastung
Die Konfiguration erfolgt über die Web-Bedienschnittstelle des CCU-Historians. Je Datenpunkt kann eine individuelle Vorverarbeitung aktiviert und konfiguriert werden (s.a. Datenpunktkonfiguration).
Zurzeit unterstützte Algorithmen zur Vorverarbeitung:
| Name | Parameter | Beschreibung |
|---|---|---|
| Delta Kompression | Maximale Wertedifferenz (Standardwert: 0,0) | Bei der Delta Kompression wird die Wertedifferenz von zwei aufeinanderfolgenden Wertaktualisierungen betrachtet. Nur wenn diese größer oder gleich dem angegebenen Parameter ist, wird die Wertaktualisierung in der Datenbank abgelegt. |
| Zeitliche Kompression | Zeitlicher Mindestabstand in Sekunden | Nur Wertaktualisierungen, die einen zeitlichen Mindestabstand zur vorhergehenden Aktualisierung besitzen, werden in der Datenbank gespeichert. |
| Mittelwert | Intervalllänge in Sekunden | Die Messwerte in einem zeitlichen Intervall werden gesammelt. Wenn ein Intervall abgelaufen ist, so wird der Mittelwert berechnet und gespeichert. Die Mindestintervalllänge ist 60 Sekunden. |
| Minimum | Intervalllänge in Sekunden | Die Messwerte in einem zeitlichen Intervall werden gesammelt. Wenn ein Intervall abgelaufen ist, so wird das Minimum berechnet und gespeichert. Die Mindestintervalllänge ist 60 Sekunden. |
| Maximum | Intervalllänge in Sekunden | Die Messwerte in einem zeitlichen Intervall werden gesammelt. Wenn ein Intervall abgelaufen ist, so wird das Maximum berechnet und gespeichert. Die Mindestintervalllänge ist 60 Sekunden. |
| Swinging-Door | Maximale Wertedifferenz (Standardwert: 0,0) | Der Messwert wird mit der angegebenen maximalen Wertedifferenz stückweise linear interpoliert. Nur die Anfangs- und Endwerte der linearen Verläufe werden gespeichert. |
Mit der Delta Kompression ist es möglich, ohne oder mit nur einem geringen Qualitätsverlust, die aufgezeichnete Datenmenge zum Teil erheblich zu reduzieren. Der Parameterwert gibt dabei die maximale Abweichung der aufgezeichneten Werte zu den tatsächlichen Werten vor.
Die Delta Kompression bietet sich für digitale Datenpunkte (z.B. STATE,
MOTION) oder Aufzählungen an. Als Kompressionsparameter kann für diese 0,5
verwendet werden. Diese Kompression ist bei Datenpunkte vom Typ ACTION (z.B.
PRESS_SHORT, PRESS_LONG) nicht sinnvoll, da diese Datenpunkte immer den
gleichen Wert besitzen.
In der Trend-Darstellung werden delta-komprimierte Datenpunkte immer treppenförmig dargestellt.
Beispiel:
Ein Temperaturaußensensor liefert etwa 567 Wertaktualisierungen pro Tag. Bei aktivierter Delta Kompression mit einem Parameterwert von 0,01, der unterhalb der Messgenauigkeit von 0,1 °C liegt, reduziert sich die Menge auf beispielsweise 191 Wertaktualisierungen pro Tag. Das heißt, die Datenmenge wird fast um Faktor 3 ohne einen Verlust an Qualität des Temperaturverlaufs reduziert.
Bei der Mittelwert-, Minimum- und Maximumberechnung werden die zeitlichen Positionen der Messwerte berücksichtigt, um eine größtmögliche Genauigkeit zu erreichen. Der letzte Messwert in einem Vorgängerintervall kann auch das nachfolgende Intervall beeinflussen.
In der Trend-Darstellung werden diese Datenpunkte immer treppenförmig dargestellt.
Insbesondere für analoge Messgrößen (z.B. BRIGHTNESS, POWER, TEMPERATURE)
sollte die Swinging-Door Kompression aktiviert werden. Der Parameterwert gibt
dabei die maximale Abweichung der aufgezeichneten Werte zu den tatsächlichen
Werten vor. Lineare Verläufe eines Messwertes werden nur mit dem Anfangs- und
Endwert archiviert. Die dazwischenliegenden Punkte werden verworfen, sofern sie
innerhalb der zulässigen Abweichung liegen.
Beispielhaft ist dies aus der folgenden Abbildung ersichtlich. Die rote Kurve zeigt den tatsächlichen Messwertverlauf, die blaue Kurve die gespeicherte Trend-Kurve mit einer zulässigen Abweichung von 0,1.
Analoge Messgrößen mit Swinging-Door Kompression werden in der Trend-Ansicht linear interpoliert dargestellt.
Zwischen der Delta Kompression und der Swinging-Door Kompression sollte nachträglich nicht gewechselt werden. Der bereits gespeicherte Teil der Zeitreihe wird u.U. falsch dargestellt.
Wertänderungen können im Arbeitsspeicher zwischengespeichert werden. Die
ankommenden Wertänderungen werden dann nicht mehr sofort in die
Datenbank geschrieben, was einen häufigen Zugriff auf das Speichermedium
(Festplatte, Speicherkarte, USB-Stick) der Datenbank vermeidet. Wenn
zusätzlich das Datei-Log durch Setzen der Option
logSystem.fileLevel=Level.OFF (Standardeinstellung) abgeschaltet wird,
und der Erkundungszyklus durch Setzen der Option historian.metaCycle
verlängert wird, so erfolgt für einen bestimmten Zeitraum keinerlei
Zugriff auf das Speichermedium. Bei einem Systemabsturz gehen aber alle
Wertänderungen, die noch im Arbeitsspeicher liegen, verloren.
Die Zwischenspeicherung wird durch das Setzen der Option
historian.bufferTime aktiviert. Zusätzlich kann die maximale Anzahl
der zwischengespeicherten Werte durch die Option historian.bufferCount
gesetzt werden.
Folgende Konfigurationsoptionen müssen zum Beispiel für eine Zwischenspeicherung von einem Tag gesetzt werden:
logSystem.fileLevel=Level.OFF
historian.metaCycle=24*60*60*1000
historian.bufferTime=24*60*60*1000
Falls mit dem CCU-Historian auch die Datenpunkte für Wartungsmeldungen der CCU aufgezeichnet werden, was die Standardeinstellung ist, können alle aufgetretenen Wartungsmeldungen nachträglich analysiert werden. Der CCU-Historian kann die Wartungsmeldungen chronologisch auflisten, und erstellt auch eine Liste der häufigsten Meldungen im analysierten Zeitbereich.
Der CCU-Historian besitzt einen eingebetteten Web-Server. Über diesen
wird die Web-Oberfläche des CCU-Historians angeboten. Die dazugehörigen
Dateien liegen im Unterverzeichnis webapp des Installationsordners.
Dort können auch beliebige benutzerdefinierte Dateien im Verzeichnis
webapp/custom abgelegt werden. Diese können dann unter der Adresse
http://localhost/custom abgerufen werden.
Weitere Informationen sind in unter Eigene Verweise auf Web-Seiten und Eigene Web-Seiten zu finden.
Der CCU-Historian kann bei Bedarf von der CCU überwacht werden. Dazu kann er so konfiguriert werden, dass er zyklisch (z.B. alle 5 Minuten) ein Zentralenprogramm aufruft. Die nötige Logik in der CCU ist im Folgenden aufgeführt. Diese sorgt dafür, dass die Alarmvariable Alarm Historian nach 6 Minuten Inaktivität des CCU-Historians gesetzt wird.
Systemvariable:
Programm:
Hinweis: Falls der Alarm immer manuell quittiert werden soll, so ist die Zeile Systemzustand Alarm Historian sofort nicht ausgelöst zu entfernen.
CCU-Historian-Konfiguration:
Hinweis: Die Konfigurationsdatei muss mit der Zeichenkodierung UTF-8 gespeichert werden, insbesondere wenn Umlaute oder ß verwendet werden.
In der Konfigurationsdatei muss für jede Zentrale, die den CCU-Historian
überwachen sollen, folgende Option hinzugefügt werden (device1 für jede Zentrale entsprechend abändern):
devices.device1.watchdogProgram='Überwachung Historian'
Die vorgegebene Zykluszeit von 5 Minuten kann bei Bedarf abgeändert werden. Die Zykluszeit wird in Millisekunden angegeben (s.a. Optionen für eine CCU1/2/3 und RaspberryMatic mit Funkmodul). Beispiel für 10 Minuten:
devices.device1.watchdogCycle=600000
Zu jeder Wertänderung eines Datenpunktes werden der Zeitstempel, der Wert an sich und zusätzlich der Zustand des Wertes aufgezeichnet. Der Zustand des Wertes setzt sich wie folgt zusammen:
- Den Zustand PREPROCESSED erhält ein Messwert, wenn er vorverarbeitet worden ist (z.B. mit Delta Kompression, o.ä.).
- Den Zustand FIRST_ARCHIVED erhält der erste aufgezeichnete Messwert nach dem Start des CCU-Historians.
- Die Messwertqualität (BAD, UNCERTAIN, UNKNOWN, GOOD) gibt Auskunft
darüber, inwieweit dem Wert vertraut werden kann.
- Messwerte von der CCU werden grundsätzlich mit GOOD gekennzeichnet, da die CCU keine Messwertqualität kennt.
Wenn Messwerte aggregiert werden (MIN, MAX, AVG), so wird auch der Zustand aggregiert:
- Die schlechteste Qualität eines Intervalls ist maßgebend für das Gesamtintervall.
- Wenn nicht über die gesamte Intervalllänge Messwerte vorhanden sind, so ist die Qualität des Gesamtintervalls höchstens UNCERTAIN.
Der Zustand wird in einer 32 Bit-Ganzzahl abgespeichert. Die Bits haben folgende Bedeutung:
| Bit(s) | Beschreibung |
|---|---|
| 1 und 0 |
Die Qualität des Wertes: 00: Qualität BAD 01: Qualität UNCERTAIN 10: Qualität UNKNOWN 11: Qualität GOOD (Standardwert bei Werten aus der CCU.) |
| 2 | PREPROCESSED Der Wert wurde vorverarbeitet. Es handelt sich also nicht mehr um einen Rohwert vom Sensor. |
| 3 | FIRST_ARCHIVED Zusätzliche Kennzeichnung des ersten archivierten Wertes nachdem der CCU-Historian gestartet worden ist. |
| 4 bis 23 | Reserviert |
| 24 bis 31 | Frei verwendbar durch andere Applikationen |
Für den CCU-Historian existieren verschiedene Installationspakete: Es wird ein allgemeines Paket angeboten, das auf jeder Plattform, das die Systemvoraussetzungen erfüllt, lauffähig ist. Und für bestimmte Geräte (z.B. Synology NAS, RaspberryMatic) werden Pakete angeboten, die den dort bereit gestellten Installationsmechanismus verwenden, und daher einfacher zu installieren sind.
Alle Installationspakete können bei den Veröffentlichungen herunter geladen werden.
Der CCU-Historian wird in einer ZIP-Datei
(ccu-historian-X.Y.Z-bin.zip) angeboten. Für die Installation reicht
es, die ZIP-Datei in ein leeres Verzeichnis zu entpacken. Das gesamte
Verzeichnis kann später an einen beliebigen anderen Ort verschoben
werden, und der CCU-Historian ohne Konfigurationsänderung wieder
gestartet werden.
Das Paket besitzt einen Dateinamen in der Form ccu-historian-X.Y.Z.spk für die DSM Version 6 und einen Dateinamen in der Form ccu-historian-dsm7-x.y.z-noarch.spk für die DSM Version 7. Es wird über die Synology DSM Oberfläche installiert. Zusätzlich muss ein Java-Paket (min. Version 11) installiert sein.
Falls die Trend-Grafiken auf DSM Version 6 nicht angezeigt werden, so muss das Java-Paket manuell auf der Synology aktualisiert werden.
Für die DSM Version 7 kann das Java-Paket Unofficial Java Installer verwendet werden. Allerdings fehlen in diesem Paket noch Dateien für Schriftarten. Nachträglich können sie mit dieser Anleitung installiert werden. Als Quellpaket für die Schriftarten sollte auf der Seite Java-Downloads für alle Betriebssysteme im Abschnitt "Linux" das Paket "Linux" ausgewählt werden.
Das Paket besitzt einen Dateinamen in der Form ccu-historian-addon-X.Y.Z.tar.gz. Es wird über die CCU Web-UI installiert.
Hinweis: Bei großen Datenbanken (z.B. 500 MB) dauert das Herunterfahren des CCU-Historians einige Zeit (z.B. 1-2 Minuten) auf langsamen USB-Sticks. Dadurch dauert ein Neustart der Zentrale ebenfalls länger.
Weitere Informationen zur Installation als Add-On sind bei den Tipps & Tricks zu finden.
Für den Betrieb muss ein USB-Stick an der Zentrale angeschlossen sein.
Falls der USB-Stick mit dem Dateisystem FAT32 formatiert ist, ist die Datenbankgröße auf 4 GB beschränkt. Gerade die CCU-Software RaspberryMatic unterstützt noch weitere Dateisysteme, die besser verwendet werden sollten:
- F2FS (speziell für USB-Sticks und SD-Karten)
- EXT4 oder EXT3
- NTFS
Da preiswerte USB-Sticks unter der hohen Last, wenn alle Datenpunkte aufgezeichnet werden, nach einigen Monaten ausfallen, sollten explizit nur gewünschte Datenpunkte aufgezeichnet werden. Eine hilfreiche Konfigurationoption ist dabei historian.defaultDisabled=true, die alle neuen Datenpunkte erst einmal auf inakiv setzt. Gewünschte Datenpunkte müssen dann manuell in der Datenpunktkonfiguration aktiv gesetzt werden.
Der Rechner auf dem der CCU-Historian installiert werden soll, muss folgende Systemvoraussetzungen erfüllen:
| Mindestanforderung | Empfohlen | |
|---|---|---|
| CPU | 1 GHz, 2 Kerne | 2 GHz, 2 Kerne |
| RAM | 1 GByte | 2 GByte |
| Festplatte / SD-Karte | 1 GByte/Jahr/Zentrale | |
| Java | Version 11 |
Die ZIP-Datei kann direkt in eine vorhandene Installation entpackt werden. Die Konfigurationsdatei ccu-historian.config und die vorhandene Datenbank werden nicht überschrieben. Normalerweise können die Konfigurationsdatei und die Datenbank ohne manuelle Anpassungen mit neueren Versionen des CCU-Historians verwendet werden.
Hinweis: Vor dem Einspielen eines Updates sollte immer eine Sicherungskopie der Datenbank und der bisherigen Installation erstellt werden (s.a. Sicherungskopie der Datenbank erstellen).
Das komplette Archiv, also alle Zeitreihen und die nötigen
Verwaltungsinformationen, werden in einer Datei abgelegt. Der Dateiname
wird durch die Konfigurationsoptionen database.dir
(Standardeinstellung ./data) und database.name
(Standardeinstellung history) vorgegeben. Die Dateiendung ist immer
.mv.db. Daraus resultiert dann der vollständige Dateipfad
<Installationsverzeichnis vom CCU-Historian>/data/history.mv.db.
Mit einer einfachen Dateikopie kann das komplette Archiv an anderer Stelle gesichert werden. Der CCU-Historian darf während des Kopierens nicht gestartet sein.
Die Konfiguration erfolgt über die Datei ccu-historian.config. Diese
Datei ist nicht im Installationspaket vorhanden. Sie muss durch Kopieren
oder Umbenennen der Datei ccu-historian-sample.config erst erstellt
werden.
Die Konfigurationsdatei kann mit einem beliebigen Text-Editor bearbeitet werden. Die Datei muss mit der Zeichenkodierung UTF-8 gespeichert werden, insbesondere wenn Umlaute oder ß in der Datei verwendet werden. In der Datei befindet sich eine Liste an Konfigurationsoptionen in der Form:
Konfigurationsoption=Wert
Alle Konfigurationsoptionen besitzen einen Standardwert. Nur vom Standard abweichende Konfigurationsoptionen müssen deshalb gesetzt werden.
Kommentarzeilen werden mit zwei Schrägstrichen // eingeleitet. Ein
ganzer Block kann durch die Verwendung von \* am Anfang und */ am Ende
auskommentiert werden. Zeichenkettenwerte (z.B. die Adresse der CCU)
müssen in einfachen Hochkommata ' eingeschlossen werden. Eine Liste
wird mit einer eckigen Klammer [ eingeleitet und mit einer eckigen
Klammer ] abgeschlossen. Die einzelnen Elemente werden durch Kommata
, getrennt.
Bei Konfigurationsoptionen, mit denen ein Datei- oder Verzeichnispfad
gesetzt wird, muss unter Linux als Pfadtrennzeichen ein Schrägstrich
/ verwendet.
Unter Windows muss der rückwärtige Schrägstrich \ in Pfaden
verdoppelt werden, da er eine Sonderfunktion besitzt.
Beispiel: Der Pfad C:\CCU-Historian\Backup\%Y-w%W.zip für die
Option database.backup muss wie folgt gesetzt werden:
database.backup='C:\\CCU-Historian\\Backup\\%Y-w%W.zip'
Relative Pfade beginnen mit Punkt und Schrägstrich ./ und werden vom
Verzeichnis der Datei ccu-Historian.jar aus ausgewertet.
Im einfachsten Fall reicht das Setzen der Konfigurationsoptionen
devices.device1.type und devices.device1.address für den Betrieb des
CCU-Historians aus. Falls z.B. eine CCU1 mit der IP-Adresse 192.168.0.2
verbunden werden soll, müssen die beiden Konfigurationsoptionen wie
folgt gesetzt werden:
devices.device1.type=CCU1
devices.device1.address='192.168.0.2'
Bei einigen Java VMs funktioniert die automatische Erkennung der eigenen IP-Adresse des CCU-Historian-Rechners nicht. Dann müssen folgende zwei Optionen manuell auf die IP-Adresse des CCU-Historian-Rechners gesetzt werden, z.B. für die IP-Adresse 192.168.0.5:
devices.historianAddress='192.168.0.5'
webServer.historianAddress='192.168.0.5'
Wenn ein anderes Passwort für die Datenbank verwendet werden soll, so sollte dies vor dem ersten Start gesetzt werden:
database.password='NeuesPasswort'
Für die Fehlersuche ist das Erstellen von Log-Dateien mit weiteren Informationen hilfreich:
logSystem.fileLevel=Level.FINER
Die Konfigurationsdatei kann im laufenden Betrieb des CCU-Historians angepasst werden. Zum Zeitpunkt des Speicherns sollte sie natürlich in einem gültigen Zustand vorliegen. Die geänderte Konfiguration wird spätestens nach 15 Sekunden neu geladen. Etwaige Fehler werden im Konsolenfenster angezeigt.
| Optionsname | Standardwert | Beschreibung |
|---|---|---|
| base.scriptDir | '.' | Suchverzeichnis für Skripte Bei einigen Ereignissen im CCU-Historian können benutzerdefinierte Skripte ausgeführt werden (z.B. `trenddesigns.groovy`). |
| logSystem.consoleLevel | Level.INFO | Meldungsfilter für die Konsole Mögliche Werte: Level.OFF, Level.SEVERE, Level.WARNING, Level.INFO, Level.CONFIG, Level.FINE, Level.FINER, Level.FINEST, Level.ALL |
| logSystem.fileLevel | Level.OFF | Meldungsfilter für die Log-Datei Mögliche Werte: Level.OFF, Level.SEVERE, Level.WARNING, Level.INFO, Level.CONFIG, Level.FINE, Level.FINER, Level.FINEST, Level.ALL |
| logSystem.fileName | './ccu-historian-%g.log' | Dateiname für die Log-Datei(en) %g wird durch eine aufsteigende Nummer ersetzt. |
| logSystem.fileLimit | 1000000 | Dateigrößenbegrenzung für Log-Dateien in Bytes |
| logSystem.fileCount | 5 | Max. Anzahl an Log-Dateien |
| logSystem.binRpcLevel | Level.WARNING | Zusätzlicher Filter für Log-Meldungen der BINRPC-Schnittstelle |
| database.dir | './data' | Verzeichnis für die Ablage der Datenbank |
| database.name | 'history' | Datenbankname |
| database.user | 'sa' | Datenbankbenutzer |
| database.password | 'ccu-historian' | Datenbankpasswort |
| database.webEnable | true | Aktivierung der Web-Bedienschnittstelle: false=aus; true=ein |
| database.webPort | 8082 | Netzwerk-Port für die Web-Bedienschnittstelle |
| database.webAllowOthers | false | Zugriff über das Netzwerk auf die Web-Bedienschnittstelle erlauben: false=aus; true=ein |
| database.tcpEnable | false | Aktivierung der TCP-Schnittstelle: false=aus; true=ein |
| database.tcpPort | 9092 | Netzwerk-Port für die TCP-Schnittstelle |
| database.tcpAllowOthers | false | Zugriff über das Netzwerk auf die TCP -Schnittstelle erlauben: false=aus; true=ein |
| database.pgEnable | false | Aktivierung der PostgreSQL-Schnittstelle: false=aus; true=ein |
| database.pgPort | 5435 | Netzwerk-Port für die PostgreSQL-Schnittstelle |
| database.pgAllowOthers | false | Zugriff über das Netzwerk auf die PostgreSQL -Schnittstelle erlauben: false=aus; true=ein |
| database.backup | '' |
Dateipfad mit Platzhaltern zur Ablage von Backups der Datenbank. Mit dem Standardwert ist diese Funktionalität abgeschaltet. Für eine genaue Beschreibung siehe Automatisierte Erstellung von Backups der Datenbank. |
| database.tasks | [:] |
Mit dieser Option können zyklisch auszuführende Aufgaben definiert werden. |
| historian.metaCycle | 3600000 | Zykluszeit für die Abfrage von Meta-Informationen [Millisekunden]; 0=Abfrage deaktiviert |
| historian.bufferCount | 5000 | Max. Anzahl an Wertänderungen, die im Arbeitsspeicher gepuffert werden sollen. Diese Option ist nur wirksam, wenn historian.bufferTime größer als 0 gesetzt wurde. |
| historian.bufferTime | 0 | Max. Zeitspanne, in der Wertänderungen im Arbeitsspeicher gepuffert werden sollen. [Millisekunden]; 0=Pufferung ist deaktiviert |
| historian.defaultDisabled | false | true: Neu gefundene Datenpunkte werden nicht aufgezeichnet; false: Sie werden aufgezeichnet. |
| historian.defaultHidden | false | true: Neu gefundene Datenpunkte werden versteckt; false: Sie sind sichtbar in der Datenpunktliste. |
| webServer.port | 80 | Port für den eingebetteten Web-Server |
| webServer.dir | './webapp' | Wurzelverzeichnis für die Dateien und Skripte, die über den Web-Server abrufbar sein sollen. |
| webServer.logLevel | Level.WARNING | Zusätzlicher Meldungsfilter für Log-Meldungen des eingebetteten Web-Servers. Jede Meldung wird wie immer auch durch logSystem.consoleLevel und logSystem.fileLevel gefiltert. |
| webServer.historianAddress | '' | Unter der angegebenen Adresse ist der Web-Server von außerhalb erreichbar. Das Setzen dieser Option ist nur sinnvoll, wenn der CCU-Historian-Rechner über mehrere Netzwerkschnittstellen (z.B. auch VPN-Verbindungen) verfügt oder die automatische Erkennung nicht funktioniert. Diese Option sollte immer zusammen mit devices.historianAddress gesetzt werden. Leer: Die Adresse wird automatisch ermittelt. |
| webserver.trendDesigns | [:] |
Definition verschiedener Trend-Darstellungsformen. Ein Satz an Einstellungen (Farben, Strichstärken, usw.) wird unter einem frei gewählten Bezeichner abgespeichert. Die Einstellungen können nachher bei der Trend-Generierung abgerufen werden. Eine detaillierte Beschreibung ist im Abschnitt Anpassung der Trend-Darstellung zu finden. Zusätzlich können die Trend-Darstellungsformen in der separaten Datei |
| webServer.apiKeys | [] |
Der Export von Zeitreihen (s.a. Export von Zeitreihen), die Generierung von Trend-Diagrammen (s.a. Generierung von Trend-Diagrammen) und die JSON-RPC Schnittstelle (s.a. JSON-RPC Schnittstelle) können durch Schlüsselwörter geschützt werden. Der Anfragende muss bei Benutzung einer der Schnittstellen eines der Schlüsselwörter mit übertragen. Beispiel mit einem Schlüsselwort abc: ['abc'] Beispiel mit zwei Schlüsselwörtern: ['abc', 'def'] |
| webServer.menuLinks | [:] |
Einbindung von eigenen Web-Verweisen in das Menü der Web-Applikation des CCU-Historians (s.a. Abschnitte Web-Server, Eigene Verweise auf Web-Seiten und Eigene Web-Seiten). |
| webServer.showLastValue | false |
Bei |
| webServer.trendSvg | false |
Bei |
Im folgenden einleitenden Beispiel wird eine CCU3 mit einem zusätzlich installierten CUxD konfiguriert:
devices.device1.type=CCU3
devices.device1.address='192.168.0.5'
devices.device1.plugin1.type=CUXD
Die Optionen für die Konfiguration der angeschlossenen Geräte haben als
ersten Namensbestandteil (bis zum ersten Punkt) das Schlüsselwort
devices.
Folgende Konfigurationsoptionen gelten für alle angeschlossenen Geräte:
| Optionsname | Standardwert | Beschreibung |
|---|---|---|
| devices.historianAddress | '' | Die angegebene Adresse wird bei der CCU als Zieladresse für die Benachrichtigungen registriert. Das Setzen dieser Option ist nur sinnvoll, wenn der CCU-Historian-Rechner über mehrere Netzwerkschnittstellen (z.B. auch VPN-Verbindungen) verfügt oder die automatische Erkennung nicht funktioniert. Diese Option sollte immer zusammen mit webServer.historianAddress gesetzt werden. Leer: Die Adresse wird automatisch ermittelt. |
| devices.historianBinRpcPort | 2099 | Netzwerk-Port für den BINRPC-Server des CCU-Historians |
| devices.historianXmlRpcPort | 2098 | Netzwerk-Port für den XMLRPC-Server des CCU-Historians |
Der zweite Namensbestandteil (zwischen dem ersten und dem zweiten Punkt)
fasst die Optionen für ein Gerät zusammen. Für diesen Namensbestandteil
sind die Schlüsselwörter device1 bis device10 erlaubt. Der
CCU-Historian kann sich also mit bis zu zehn Geräten verbinden. Die Gerätenummern können in beliebiger Reihenfolge sein und
müssen nicht fortlaufend vergeben werden. Im
Folgenden wird die Gerätenummer 1 verwendet.
Für alle Geräte sind folgende Optionen zu setzen:
| Optionsname | Standardwert | Beschreibung |
|---|---|---|
| devices.device1.address | Option muss gesetzt werden | Die Adresse des Gerätes. Meistens handelt es sich um die IP-Adresse der CCU. |
| devices.device1.type | Option muss gesetzt werden | Zulässige Gerätetypen sind z.B.: CCU1, CCU2, CCU3, CUSTOM_CCU, BINRPC Die verschiedenen Gerätetypen sind weiter unten näher beschrieben. |
Hinweis: Für RaspberryMatic mit Funkmodul (RPI-RF-MOD oder HM-MOD-RPI-PCB) ist der Gerätetyp CCU3 zu setzen. Wird RaspberryMatic ohne eines dieser Funkmodule betrieben, muss der Typ CUSTOM_CCU verwendet werden (siehe auch Optionen für OCCU-basierte Zentralen).
Ein Gerät kann eventuell durch zusätzliche Hardware und/oder Software
erweitert werden. Zum Beispiel kann eine CCU1 mit der Software CUxD
und der zugehörigen Hardware FS20-Komponenten unterstützen, oder eine
CCU2 wird mit dem HomeMatic Wired RS485 LAN Gateway betrieben. Die
Konfiguration dieser Plug-Ins erfolgt über einen dritten
Namensbestandteil. Bis zu zehn Plug-Ins können über die Schlüsselwörter
plugin1 bis plugin10 konfiguriert werden. Die
Plug-In-Nummern können in beliebiger Reihenfolge sein und müssen nicht
fortlaufend vergeben werden. Im Folgenden wird für die
Plug-In-Nummer 1 verwendet.
Für alle Plug-Ins sind folgende Optionen zu setzen:
| Optionsname | Standardwert | Beschreibung |
|---|---|---|
| devices.device1.plugin1.type | Option muss gesetzt werden | Zulässige Plug-In-Typen sind z.B.: CUXD, HMWLGW |
Hinweis für die Anbindung des CUxD: Falls der CCU-Historian nicht zusammen mit dem CUxD auf der CCU betrieben wird, muss in der CCU-Firewall zusätzlich der Port 8701 freigeschaltet werden. Zudem ist der Netzwerkzugriff auf die BINRPC-Schnittstelle des CUxD durch die Konfigurationsoption ACCESS-RPC (s.a. Handbuch des CUxD) zu ermöglichen.
In diesem Abschnitt sind die zusätzlichen Konfigurationsoptionen für ein Gerät vom Typ CCU1/2/3 und RaspberryMatic mit Funkmodul (RPI-RF-MOD oder HM-MOD-RPI-PCB) beschrieben.
| Optionsname | Standardwert | Beschreibung |
|---|---|---|
| devices.device1.timeout | 10000 | Auf BIN-RPC-Anfragen muss die CCU innerhalb der angegeben Zeitspanne antworten, ansonsten wird ein Fehler ausgelöst. [Millisekunden] |
| devices.device1.reinitTimeout | 300000 | Falls längere Zeit keine Nachrichten von der CCU empfangen worden sind, wird die BIN-RPC API neu initialisiert. Die Zeit wird in Millisekunden angegeben. |
| devices.device1.writeAccess | false | Schreibzugriff auf der CCU erlauben. Dadurch kann z.B. der aktuelle Zustand eines Datenpunktes geändert werden. |
| devices.device1.sysVarDataCycle | 30000 | Zykluszeit für das Lesen von Systemvariablen [Millisekunden] |
| devices.device1.prefix | '' | Falls mehrere Geräte vom gleichen Typ verwendet werden (auch CCU1 mit CCU2), müssen die Geräte durch ein Präfix unterschieden werden. Dieses Präfix wird z.B. in den Tabellennamen eingefügt. Es sind keine Sonderzeichen erlaubt. Bei Verwendung des CUxD mit einer Version kleiner als 2.6.0 muss das Präfix leer sein. |
| devices.device1.watchdogProgram | '' | Name eines vorhandenen Programms in der CCU-Zentrale, das zyklisch vom CCU-Historian ausgeführt werden soll. Dadurch kann die CCU-Zentrale beispielsweise feststellen, ob der CCU-Historian aktiv ist. |
| devices.device1.watchdogCycle | 300000 | Zykluszeit für den Watchdog-Prozess [Millisekunden] |
| devices.device1.username | '' | Benutzername für den authentifizierten Zugriff auf die XML-RPC API und die Homematic-Script API |
| devices.device1.password | '' | Passwort für den obigen Benutzer |
Für eine CCU2/3 sind die Plug-Ins CUXD und HMWLGW zulässig, für eine CCU1
nur das Plug-In CUXD. Falls die virtuellen Geräte des Add-Ons
CCU-Jack aufgezeichnet werden sollen, kann
das Plug-In JACK konfiguriert werden.
Der authentifizierte Zugriff auf die CCU-Schnittstellen kann in der Systemsteuerung der CCU → Sicherheit aktiviert werden:
OCCU-basierte Zentralen, die nicht exakt in ihren Schnittstellen einer
CCU1, CCU2 oder CCU3 entsprechen, müssen als CUSTOM_CCU konfiguriert werden.
Dazu zählt beispielweise RaspberryMatic, wenn es ohne eines dieser
Funkmodule RPI-RF-MOD oder HM-MOD-RPI-PCB betrieben wird. Dann ist der Schnittstellenprozess für
HM-IP nicht verfügbar.
Bei Verwendung des Gerätetyps CUSTOM_CCU müssen alle CCU-Schnittstellen
als Plug-In konfiguriert werden. Folgende Plug-Ins stehen zur Verfügung:
BIDCOS_WIRED (i.d.R. nur CCU1), BIDCOS_RF, SYSTEM (i.d.R. nur CCU1),
HMIP_RF, JACK (für den CCU-Jack).
Beispiel:
RaspberryMatic ohne Funkmodul-Aufsatz aber mit Funk-LAN Gateway
(HM-LGW-O-TW-W-EU)
devices.device1.type=CUSTOM_CCU
devices.device1.address='192.168.0.5'
devices.device1.plugin1.type=BIDCOS_RF
Beispiel:
RaspberryMatic ohne Funkmodul-Aufsatz aber mit Funk-LAN Gateway
(HM-LGW-O-TW-W-EU), Wired-LAN Gateway (HMW-LGW-O-DR-GS-EU) und CUxD
devices.device1.type=CUSTOM_CCU
devices.device1.address='192.168.0.5'
devices.device1.plugin1.type=BIDCOS_RF
devices.device1.plugin2.type=HMWLGW
devices.device1.plugin3.type=CUXD
Der CCU-Historian kann so konfiguriert werden, dass er ein beliebiges Gerät, das eine HomeMatic XMLRPC- bzw. BINRPC-Schnittstelle besitzt, abfragt und archiviert.
Im Dokument HomeMatic XML-RPC-Schnittstelle v1.502 (zu finden auf http://www.eq-3.de/software.html) ist die XMLRPC-Schnittstelle beschrieben.
| Optionsname | Standardwert | Beschreibung |
|---|---|---|
| devices.device1.name | Option muss gesetzt werden | Name der Schnittstelle; Er darf keine Leerzeichen oder Sonderzeichen enthalten. |
| devices.device1.port | Option muss gesetzt werden | Portnummer der Schnittstelle |
| devices.device1.prefix | '' | Falls mehrere Geräte vom gleichen Typ verwendet werden (auch CCU1 mit CCU2), müssen die Geräte durch ein Präfix unterschieden werden. Dieses Präfix wird z.B. in den Tabellennamen eingefügt. Es sind keine Sonderzeichen erlaubt. |
| devices.device1.timeout | 10000 | Auf BIN-RPC-Anfragen muss das Gerät innerhalb der angegeben Zeitspanne antworten, ansonsten wird ein Fehler ausgelöst. [Millisekunden] |
| devices.device1.reinitTimeout | 300000 | Falls längere Zeit keine Nachrichten von dem Gerät empfangen worden sind, wird die BIN-RPC API neu initialisiert. Die Zeit wird in Millisekunden angegeben. |
| devices.device1.writeAccess | false | Schreibzugriff auf das Gerät erlauben. Dadurch kann z.B. der aktuelle Zustand eines Datenpunktes geändert werden. |
| device.device1.username | '' | Benutzername für den authentifizierten Zugriff auf die XML-RPC API und die Homematic-Script API (nur XML-RPC) |
| device.device1.password | '' | Passwort für den obigen Benutzer (nur XML-RPC) |
Ein XMLRPC- bzw. BINRPC-Gerät besitzt niemals Plug-Ins.
Eine CCU1
devices.device1.type=CCU1
devices.device1.address='192.168.0.5'
CCU2 mit HMWLGW und CUxD
devices.device1.type=CCU2
devices.device1.address='192.168.0.5'
devices.device1.plugin1.type=HMWLGW
devices.device1.plugin2.type=CUXD
Eine CCU1 mit CUxD und eine CCU2 mit HMWLGW
Für CUxD-Versionen kleiner als 2.6.0 gilt Folgendes: Bei Verwendung des CUxD-Plugins darf nur ein leeres Präfix gesetzt werden. Dadurch ist es nicht möglich zwei CUxD-Plugins auf verschiedenen CCUs anzubinden.
devices.device1.type=CCU1
devices.device1.address='192.168.0.5'
devices.device1.prefix=''
devices.device1.plugin1.type=CUXD
devices.device2.type=CCU2
devices.device2.address='192.168.1.5'
devices.device2.prefix='WORK_'
devices.device2.plugin1.type=HMWLGW
Bei einer fehlerhaften Konfigurationsdatei erscheint normalerweise nur folgende Meldung:
Exception: Configuration file ccu-historian.config is invalid
Weitere Informationen zu Fehlern können auch über die Kommandozeile aktiviert werden. (Normalerweise geschieht dies in der Konfigurationsdatei, diese ist aber defekt.)
java -jar ccu-historian.jar -loglevel finest
Detaillierte Fehlerinformationen (insbesondere für die Entwickler) sind wie folgt zu finden:
Es können automatisiert Backups der Datenbank erstellt werden. Diese
Funktionalität wird mit der Option database.backup konfiguriert. Durch
diese Option wird ein Dateipfad mit bestimmten Platzhaltern zur Ablage
der erstellten Backup-Dateien angegeben. Relative Dateipfade beziehen
sich auf das Arbeitsverzeichnis vom CCU-Historian. Dies ist
normalerweise das Installationsverzeichnis.
Hinweis: Bei Dateipfaden auf einem Windows-Betriebssystem sind die
rückwärtiges Schrägstriche \ zu verdoppeln \\, da sie eine Sonderrolle einnehmen.
Die verwendbaren Platzhalter haben folgende Bedeutungen:
| Platzhalter | Bedeutung |
|---|---|
| %Y | Jahr (4-stellig) |
| %M | Monat (2-stellig) |
| %D | Tag im Monat (2-stellig) |
| %W | Woche im Jahr (2-stellig) |
| %h | Stunde (2-stellig) |
| %V | Versionsnummer des CCU-Historians (ab V3.4.0) |
| %% | Prozentzeichen |
Die Zykluszeit für die Backup-Erstellung ergibt sich aus dem verwendeten Platzhalter, der die kleinste Intervalllänge besitzt. Falls eine Zykluszeit abgelaufen ist, und der CCU-Historian zu diesem Zeitpunkt nicht gestartet war, so wird nachträglich kein Backup erstellt.
Falls der angegebene Dateiname die Dateiendung .zip besitzt, so wird
die Backup-Datei ZIP-komprimiert. Bei der Dateiendung .gz wird die
Backup-Datei GZIP-komprimiert.
Die erstellte Backup-Datei ist textuell und beinhaltet alle SQL-Kommandos, um die komplette Datenbank wieder herzustellen. Die Wiederherstellung erfolgt über die Web-Bedienschnittstelle der Datenbank (s.a. Web-Bedienschnittstelle) durch Ausführen des folgenden SQL-Kommandos:
RUNSCRIPT FROM '*Dateiname der Backup-Datei*'
Falls die Backup-Datei ZIP- oder GZIP-komprimiert ist, so ist an das
SQL-Kommando noch COMPRESSION ZIP bzw. COMPRESSION GZIP anzuhängen.
Beispiele
database.backup='db_%Y-%M-%D.zip'
Es wird jeden Tag um Mitternacht eine ZIP-komprimierte Backup-Datei
erstellt. Die erstellten Dateien sind z.B.: db_2014-04-30.zip,
db_2014-05-01.zip, db_2014-05-02.zip, usw.
database.backup='L:\\Backups\\%Y-w%W.gz'
Das ist ein Beispiel mit Windows-Pfadangaben. Es wird am Beginn jeder Woche (jeden Montag um 00:00 Uhr) eine
GZIP-komprimierte Backup-Datei erstellt. Die erstellten Dateien sind
z.B.: L:/Backups/2013-w52.gz, L:/Backups/2014-w01.gz,
L:/Backups/2014-w02.gz, usw.
Skripte können auch zyklisch automatisch ausgeführt werden (ab V3.2.0). Die zyklischen Skripte werden in der Konfigurationsdatei ccu-historian.config definiert:
database.tasks.<Aufgabenname>.enable=<true (Ein) oder false (Aus)>
database.tasks.<Aufgabenname>.cron="<Cron-Ausdruck oder @start>"
database.tasks.<Aufgabenname>.script={
// Skripttext
}
Es können beliebig viele Skripte zu beliebigen Zeitpunkten konfiguriert werden. Der Aufgabenname muss eindeutig sein, mit einem Buchstaben beginnen und nur aus Buchstaben, Zahlen und _ bestehen. Der Cron-Ausdurck orientiert sich am Quartz-Standard. Eine Aufgabe kann auch einmalig beim Start den CCU-Historians ausgeführt werden, wenn der Cron-Ausdruck @start ist.
Beispiele für Cron-Ausdrücke:
| Ausdruck | Bedeutung |
|---|---|
| 0 0 2 * * ? | Jeden Tag um 2:00 Uhr |
| 0 0 1/3 * * ? | Alle 3 Stunden ab 01:00 Uhr |
| 0 10 13 15 * ? | Am 15. jeden Monats um 13:10 Uhr |
| 0 0 0 ? * SUN | Jeden Sontag um 00:00 Uhr |
| 0 0 12 1/5 * ? | An jedem 5. Tag um 12:00 Uhr ab dem 1. Tag jeden Monats |
| 0 11 11 11 11 ? | Jeden 11.11. um 11:11 Ur |
Skriptausgaben mit dem Kommandos println, log.severe, log.warning, log.info und log.fine landen in der Log-Datei des CCU-Historians.
Skriptbeispiele sind bei den Tipps & Tricks zu finden.
Mit der Konfigurationsoption webServer.menuLinks können im Kopf-Menü benutzerdefinierte Einträge hinzugefügt werden. Jeder Verweis auf eine Web-Seite des CCU-Historians oder auf eine beliebige Internet-Seite wird mit einer Unteroption link1, link2, usw. beschrieben. Folgende Optionen müssen je Verweis gesetzt werden:
| Optionsname | Standardwert | Beschreibung |
|---|---|---|
| webServer.menuLinks.link1.text | Option muss gesetzt werden | Anzeigetext des Verweises |
| webServer.menuLinks.link1.address | Option muss gesetzt werden | Adresse des Verweises (Es können relative oder absolute Adressen, vom eigenen Web-Server oder von fremden Web-Servern angegeben werden.) |
Die Option dient primär dazu auf eigene Web-Seiten im Verzeichnis webapp/custom zu verweisen (s.a. Eigene Web-Seiten), oder CCU-Historian-Web-Seiten mit vorgegeben Parametern (z.B. Datenpunktauswahl, Zeitbereichsauswahl) aufzurufen.
Beispiel
webServer.menuLinks.link1.text='Beispiel 1 - Vorjahresvergleich'
webServer.menuLinks.link1.address='/custom/example1.html'
Ergebnis
Für eine vollständige Funktion des CCU-Historians müssen einige Netzwerkverbindungen zwischen dem CCU-Historian-Rechner und der CCU freigeschaltet werden.
Auf dem CCU-Historian-Rechner müssen folgende Netzwerk-Ports erreichbar sein:
| Port-Nr. | Funktion | Zugehörige Konfigurationsoption |
|---|---|---|
| 80 / 8082* | Port für den eingebetteten Web-Server | webServer.port |
| 2098 | Netzwerk-Port für den XMLRPC-Server des CCU-Historians | devices.historianXmlRpcPort |
| 2099 | Netzwerk-Port für den BINRPC-Server des CCU-Historians | devices.historianBinRpcPort |
| 8082 | Netzwerk-Port für die Web-Bedienschnittstelle der Datenbank | database.webPort |
| 9092 | (Optional) Netzwerk-Port für die TCP-Schnittstelle der Datenbank | database.tcpPort |
| 5435 | (Optional) Netzwerk-Port für die PostgreSQL-Schnittstelle der Datenbank | database.pgPort |
(* Bei Verwendung als Add-On auf einer CCU3 oder RM.)
Auf der CCU müssen folgende Netzwerk-Ports erreichbar sein:
| Port-Nr. | Funktion |
|---|---|
| 2000 | Schnittstellenprozess BidCos-Wired (CCU1 oder CCU2 mit HMWLGW) |
| 2001 | Schnittstellenprozess BidCos-RF |
| 2002 | Schnittstellenprozess System (nur CCU1) |
| 2010 | Schnittstellenprozess HM-IP (nur CCU2) |
| 8181 | HM Skript Schnittstelle |
| 8701 | CUxD (wenn angeschlossen) |
Die Firewall der CCU muss entsprechend konfiguriert sein, dass der CCU-Historian auch die CCU erreichen kann. In der folgenden Beispielkonfiguration besitzt der CCU-Historian-Rechner die IP-Adresse 192.168.0.10:
Hinweise:
- Eine geänderte Firewall-Einstellung wird unter Umständen erst nach einem Neustart der CCU aktiv!
- Zur Fehlersuche sollte die CCU-Firewall auf Vollzugriff eingestellt werden!
- Ab der CCU3 Firmware Version 3.41.7 und RaspberryMatic Verion 3.41.11.20181124 muss ein CCU-Benutzer inkl. Passwort in der Konfigurationsdatei des CCU-Historians angegeben werden (s.a. Optionen für eine CCU1/2/3). Alternativ kann die Authentifizierung in der CCU abgeschaltet werden: Das Häkchen bei Einstellungen → Systemsteuerung → Sicherheit → Authentifizierung aktiv ist zu entfernen.
Falls der CCU-Historian auf einer CCU3 oder RaspberryMatic als AddOn installiert wurde, muss die Firewall wie folgt eingestellt werden:
Insbesondere muss der Port 8082 für die Web-Oberfläche des CCU-Historians freigegeben werden.
Nach der Installation und Konfiguration kann der CCU-Historian gestartet werden. Als erstes wird die Konfigurationsdatei eingelesen. Danach werden der eingebettete Web-Server und die Datenbank gestartet.
Wenn keine Datebank vorgefunden wird, wird automatisch eine neue Datenbank angelegt. Der Name der Datenbank wird durch die Konfigurationsoption database.name gesetzt,
das Verzeichnis für die Datenbankdateien durch database.dir angegeben.
Das beim Erstellen verwendete Passwort (Konfigurationsoption
database.password) darf für den späteren Zugriff nicht verändert
werden.
Je nach Konfiguration werden auch Log-Dateien erstellt, die bei
Verwendung der Standardwerte für die Optionen logSystem.fileName,
logSystem.fileLimit und logSystem.fileCount im Verzeichnis der Datei
ccu-historian.jar liegen und folgende Namen erhalten:
ccu-historian-0.log, ccu-historian-1.log, usw.
Bei einem Fehler wird der Start abgebrochen. Weitere Informationen sind dann auf der Konsole oder in der Log-Datei zu finden.
Als nächstes werden die Verbindungen zu den CCU-Schnittstellen aufgebaut. Systemvariablen werden sofort erkundet und in der Datenbank historisiert. Gerätedatenpunkte werden erst nach einer ersten Wertänderung oder Aktualisierung in der Datenbank angelegt und historisiert. Dies kann bis zu einem Tag dauern, je nachdem wie oft sich ein Gerät bei der CCU meldet.
Bei einer Installation als AddOn auf der CCU wird der CCU-Historian zusammen mit der CCU gestartet. Unter Einstellungen → Systemsteuerung → Zusatzsoftware kann die Web-UI (Schaltfläche Einstellen) des CCU-Historians aufgerufen werden, oder dieser auch neu gestartet werden.
Der Start des CCU-Historians erfolgt unter MS Windows durch Ausführen
der Datei ccu-historian.jar (z.B. mit einem Doppelklick). Unter
anderen Betriebssystemen muss folgender Befehl auf der Konsole
eingegeben werden:
java -jar ccu-historian.jar
Es öffnet sich dann ein Konsolenfenster, das bei einer Standardkonfiguration folgenden Inhalt zeigt:
Für den Betrieb des CCU-Historians muss das Konsolenfenster geöffnet bleiben. Um den CCU-Historian zu beenden, das Konsolenfenster aktivieren, und dann die Tastenkombination Strg-C betätigen. Nur mit dieser Vorgehensweise meldet sich der CCU-Historian auch ordnungsgemäß bei der CCU ab und schließt ordentlich die Datenbank.
Unter Linux sollte der CCU-Historian mit einem TERM-Signal beendet werden.
Beispiel für die Prozess-ID 1234: kill -15 1234 Erst wenn der CCU-Historian
nach mehreren Minuten immer noch läuft, sollte der Prozess mit kill -9 1234
beendet werden.
Für den automatischen Start des CCU-Historians beim Rechnerstart kann unter MS Windows die Aufgabenplanung vom Betriebssystem verwendet werden.
Der CCU-Historian unterstützt verschiedene Kommandozeilenparameter um bereits Einstellungen vor dem Lesen der Konfigurationsdatei zu setzen (z.B. der Pfad zur Konfigurationsdatei) und verschiedene Wartungsarbeiten durchzuführen (z.B. Sicherung/Wiederherstellung der Datenbank).
Die Liste der unterstützen Kommandozeilenparameter inklusive
Beschreibung wird durch Aufruf des CCU-Historians in der
Eingabeaufforderung mit dem Parameter –help ausgegeben.
Unter MS Windows ist die Eingabeaufforderung im Startmenü an folgender Stelle zu finden:
Mit dem Kommando cd Installationsverzeichnis muss als erstes in das Installationsverzeichnis des CCU-Historians gewechselt werden.
Danach ist unter MS Windows Folgendes einzugeben:
ccu-historian -help
Auf anderen Betriebssystemen muss der CCU-Historian mit java gestartet werden:
java -jar ccu-historian.jar -help
Die Ausgabe sieht wie folgt aus:
usage: ccu-historian [options]
options:
-clean <date> deletes all time series entries before the
specified date (format is DD.MM.YYYY or
YYYY-MM-DD) and then shuts down
-compact compacts the database and then shuts down
-config <file> changes the path to the configuration file
-createscript <file> dumps the database to a file as SQL scipt and then
shuts down
-help prints this help message
-loglevel <level> sets the console log level (off, severe, warning,
info, fine, finer, finest) before the
configuration file is read
-recalc recalculates compressed data points and then shuts
down
-runscript <file> runs an SQL script from file and then shuts down
Liste aller Startparameter:
| Startparameter | Argument | Standardwert | Beschreibung |
|---|---|---|---|
| clean | Datum | - |
Löscht alle Zeitreiheneinträge vor dem angegebenen Datum (Datumsformat Tag.Monat.Jahr oder Jahr-Monat-Tag) und beendet sich dann. |
| compact | - | - |
Kompaktiert die Datenbank. Dadurch wird ungenutzter Speicher in der Datenbank freigegeben. Dies sollte immer nach Benutzung der Startparameter |
| config | Konfigurationsdatei | ccu-historian.config |
Setzt den Pfad zur Konfigurationsdatei. |
| createscript | Skriptdatei | - |
Der Datenbankinhalt wird als SQL-Skript in der angegebenen Datei gespeichert. Danach beendet sich der CCU-Historian. |
| help | - | - |
Gibt eine Hilfe zu den Kommandozeilenoptionen aus. |
| loglevel | Log-Level | info |
Setzt den Meldungsfilter für Log-Meldungen auf der Konsole. Dieser Meldungsfilter ist bereits vor dem Lesen der Konfigurationsdatei aktiv. Dadurch können Fehler in der Konfigurationsdatei besser analysiert werden. |
| recalc | - | - |
Komprimiert die Zeitreihen erneut (s.a. Vorverarbeitung aller Wertaktualisierungen) und beendet sich dann. |
| runscript | Skriptdatei | - | Führt die angegebenen SQL-Kommandos in der Skript-Datei aus und beendet sich dann. |
Das interne Datenmodell der HomeMatic CCU sieht in groben Zügen wie folgt aus: Jedes an der CCU angeschlossene Gerät besitzt eine eindeutige Seriennummer. Jedes Gerät stellt eine Anzahl an Kanälen zur Verfügung, die über eine Kanalnummer identifiziert werden. Jeder Kanal besitzt eine Anzahl an Datenpunkten, die über ihren Namen identifiziert werden. Um einen Datenpunkt eindeutig zu identifizieren wird also die Seriennummer des Geräts, die Kanalnummer und der Name des Datenpunktes benötigt.
Mit diesen Informationen legt der CCU-Historian eine Tabelle für jeden Datenpunkt an. In dieser wird dann die gesamte Historie des Datenpunktes gespeichert. Der Tabellenname wird nach folgender Regel für numerische (Logikwert, Werteliste, Zahl, Alarm) Datenpunkte generiert: D_Schnittstellenname_Seriennummer_Kanalnummer_Datenpunkt
Für Datenpunkte vom Typ Zeichenkette gilt folgende Regel: C_Schnittstellenname_Seriennummer_Kanalnummer_Datenpunkt
Der Schnittstellenname ist z.B. BidCos_RF, BidCos_Wired oder
System. Alle nicht alphanumerischen Zeichen werden durch einen
Unterstrich (_) ersetzt.
Eine Historientabelle besitzt folgenden Aufbau:
| Spalte | Name | Datentyp | Beschreibung |
|---|---|---|---|
| 1 | TS | TIMESTAMP | Zeitstempel |
| 2 | VALUE | DOUBLE (numerischer Datenpunkte) VARCHAR (Zeichenkettendatenpunkte) |
Wert |
| 3 | STATE | INTEGER |
Status: 3 |
Die Tabelle zu einem Datenpunkt wird erst dann angelegt, wenn die erste Aktualisierung des Wertes, beim CCU-Historian eintrifft.
Alle Datenpunkte mit den Namen RAIN_COUNTER oder SUNSHINEDURATION
werden als Zähler behandelt, die nur bis zu einem Maximalwert zählen und
dann überlaufen. Der CCU-Historian bemerkt diese Überläufe und
korrigiert automatisch alle nachfolgenden Werte.
Jede Systemvariable wird von der Logikschicht der CCU über eine eindeutige Objekt-Identifikation (eine Zahl) referenziert. Diese ID ändert sich auch bei Umbenennung der Variable nicht. Der CCU-Historian nutzt diesen Umstand, um einen eindeutigen Tabellennamen im folgenden Format zu generieren: D_Schnittstellenname_SystemvariablenID_VALUE
Für Systemvariablen vom Datentyp Zeichenkette gilt folgende Regel: C_Schnittstellenname_SystemvariablenID_VALUE
Der Schnittstellenname ist i.d.R. SysVar.
Die angelegten Tabellen haben denselben Aufbau wie die Historientabellen
der Gerätedatenpunkte (s.a. Historientabellen für Gerätedatenpunkte). Falls der Datentyp einer
bestehenden Systemvariable zwischen numerisch (Logikwert, Werteliste,
Zahl, Alarm) und Zeichenkette wechselt, so wird für diese Systemvariable
eine zweite Tabelle angelegt, um den geänderten Datentyp speichern zu
können. Das Feld TABLE_NAME in der Tabelle DATA_POINTS gibt immer
den jeweils gültigen Tabellennamen an.
Die Werte der Systemvariablen werden zyklisch vom CCU-Historian
abgefragt. Die Zykluszeit wird mit der Konfigurationsoption
historian.sysVarDataCycle gesetzt. Wenn sich der Wert einer
Systemvariablen zwischen zwei Abfragen ändert, so wird der tatsächliche
Zeitpunkt der Änderung abgespeichert. Wenn sich der Wert mehrmals
zwischen zwei Abfragen ändert, so kann nur die letzte Änderung ermittelt
und abgespeichert werden. Eine Zykluszeit kleiner als 5000 Millisekunden
sollte nicht eingestellt werden.
Für jeden Datenpunkt pflegt der CCU-Historian einen Eintrag in der
Tabelle DATA_POINTS. Die Tabelle hat folgenden Aufbau:
| Spalte | Name | Datentyp | Beschreibung |
|---|---|---|---|
| 1 | DP_ID | INT | Eindeutige ID des Datenpunktes im CCU-Historian |
| 2 | TABLE_NAME | VARCHAR | Name der Historientabelle |
| 3 | STATE | INT | Reserviert |
| 4 | INTERFACE | VARCHAR | CCU-Schnittstelle des Gerätes (BidCos-RF, BidCos-Wired, System oder SysVar) |
| 5 | ADDRESS | VARCHAR | Seriennummer:Kanalnummer oder Systemvariablen-ID |
| 6 | IDENTIFIER | VARCHAR | Datenpunktbezeichner |
| 7 | DISPLAY_NAME | VARCHAR | Anzeigename des Kanals/der Systemvariable in der Logikschicht der CCU |
| 8 | COMMENT | VARCHAR | Kommentar (wird noch nicht gesetzt) |
| 9 | PARAM_SET | VARCHAR | Parameter-Satz des Datenpunktes (z.B. VALUES für dynamische Werte) |
| 10 | TAB_ORDER | INT |
Für die Beschreibung der Spalten 10 bis 18 wird auf die Dokumentation der XML-RPC-Schnittstelle verwiesen (Abschnitt 3.2). Bei Systemvariablen werden die Felder 12, 13, 14, 16, 18 mit Informationen aus der Logikschicht der CCU gefüllt. |
| 11 | MAXIMUM | DOUBLE | s.o. |
| 12 | UNIT | VARCHAR | s.o. |
| 13 | MINIMUM | DOUBLE | s.o. |
| 14 | CONTROL | VARCHAR | s.o. |
| 15 | OPERATIONS | INT | s.o. |
| 16 | FLAGS | INT | s.o. |
| 17 | TYPE | VARCHAR | s.o. |
| 18 | DEFAULT_VALUE | DOUBLE | s.o. |
Wenn vom CCU-Historian Werte von einem unbekannten Gerätedatenpunkt
empfangen werden, werden als erstes die Spalten 1 bis 6 und 9 in der
Tabelle DATA_POINTS gefüllt und eine neue Historientabelle angelegt.
Dadurch können die empfangenen Werte sofort in die Datenbank
weggeschrieben werden. In einem separaten Arbeitszyklus (s.a.
Konfigurationsoption historian.metaCycle) werden die
Meta-Informationen in den restlichen Spalten nachgepflegt.
Die Meta-Informationen von Systemvariablen werden kontinuierlich
abgeglichen. Wenn z.B. der Name einer Systemvariablen geändert wird,
wird der neue Name beim nächsten Zyklus automatisch nachgepflegt. Bei
Systemvariablen wird in der Spalte INTERFACE der Wert SysVar
eingetragen.
Eventuelle weitere, hier nicht dokumentierte Tabellen werden vom CCU-Historian nur intern verwendet und können sich in neueren Versionen des CCU-Historians ändern oder nicht mehr vorhanden sein.
Hinweis: Der Spaltenname VALUE ist seit einer Umstellung der internen Datenbank ein reserviertes Schlüsselwort. Damit der Spaltenname in SQL-Ausdrücken verwendet werden kann, muss er nun in doppelte Hochkommas gesetzt werden: "VALUE"
Alle am 22.1.2011 gesendeten Helligkeitswerte des Bewegungsmelders mit der Seriennummer GEQ0126000 sortiert nach dem Zeitstempel abfragen:
SELECT * FROM V_GEQ0126000_1_BRIGHTNESS WHERE TS>='2011-01-22' AND TS<'2011-01-23' ORDER BY TS
Die minimale und maximale Helligkeit an diesem Tag abfragen:
SELECT MIN("VALUE"), MAX("VALUE") FROM V_GEQ0126000_1_BRIGHTNESS WHERE TS>='2011-01-22' AND TS<'2011-01-23'
Anzahl der Kommunikationsstörungen an diesem Tag mit diesem Gerät:
SELECT COUNT(*) FROM V_GEQ0126000_0_UNREACH WHERE "VALUE"<>0.0 AND TS>='2011-01-22' AND TS<'2011-01-23'
Die zuletzt vom Gerät übermittelte (also aktuelle) Helligkeit:
SELECT * FROM V_GEQ0126000_1_BRIGHTNESS WHERE TS=(SELECT MAX(TS) FROM V_GEQ0126000_1_BRIGHTNESS)
Nur alle Werte größer als 60 für einen Zeitbereich zurückgeben:
SELECT * FROM D_SYSVAR_19147_VALUE WHERE "VALUE" > 60.0 AND TS >= '2022-02-08 00:00:00' AND TS <= '2022-05-06 00:00:00'
Den Durschnittswert, die minimale und die maximale Temperatur für einen Zeitbereich berechnen:
SELECT AVG("VALUE") AS TEMPERATUR_AVG, MIN("VALUE") AS TEMPERATUR_MIN, MAX("VALUE") AS TEMPERATUR_MAX FROM D_HMIP_RF_XXXXXXXXXXXX_1_ACTUAL_TEMPERATURE WHERE TS >= '2022-04-01 00:00:00' AND TS <= '2022-04-30 23:59:59'
Einen Eintrag mit dem Wert 3,0 und dem Zeitstempel 2022-03-01 00:00:00 in eine Zeitreihe einfügen:
INSERT INTO D_SYSVAR_41178_VALUE (TS, "VALUE", STATE) VALUES ('2022-03-01 00:00:00', 3.0, 2);
Bestimmte Einträge einer Zeitreihe auf einen bestimmten Wert setzen:
UPDATE D_SYSVAR_63193_VALUE SET "VALUE"=-24354 WHERE TS >= '2021-01-01 00:00:00' AND TS <= '2021-01-01 01:00:00'
Den Helligkeitsverlauf vom 22.1.2011 als CSV-Datei exportieren. Die
Datei wird im Verzeichnis von der Datei ccu-historian.jar erstellt.
Verwendete Hochkommas im SQL-Ausdruck müssen verdoppelt werden:
CALL CSVWRITE ('Helligkeitsverlauf.csv', 'SELECT * FROM V_GEQ0126000_1_BRIGHTNESS WHERE TS>=''2011-01-22'' AND TS<''2011-01-23'' ORDER BY TS')
Anmerkung: Über die Web-Schnittstelle des CCU-Historians (s.a. Web-Schnittstelle) können auch CSV-Daten exportiert werden.
Eine Auflistung aller vorhandenen Historien-Tabellen liefert folgender SQL-Ausdruck:
SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE 'V\\_%'
Die Existenz einer Tabelle kann mit folgender Abfrage festgestellt
werden. Sie liefert einen Wert ungleich 0, falls die angegebene Tabelle
V_GEQ0126000_1_BRIGHTNESS existiert:
SELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME='V_GEQ0126000_1_BRIGHTNESS'
Auf die Web-Bedienschnittstelle der Datenbank kann lokal mit der
Web-Adresse http://localhost:8082 zugegriffen werden. Dazu muss die
Konfigurationsoption database.webEnable=true gesetzt sein. Falls der
Zugriff auch von anderen Rechnern aus erlaubt sein soll, so muss die
Option database.webAllowOthers=true zusätzlich gesetzt werden.
Für den Zugriff auf die Datenbank muss als erstes eine Anmeldung
erfolgen. Die Angaben für JDBC URL, Benutzername und Passwort
hängen von den Konfigurationsoptionen database.dir, database.name,
database.user und database.password ab. Wenn die Standardwerte für
diese Optionen verwendet werden, ist der Anmelde-Dialog wie folgt
auszufüllen:
Die Web-Oberfläche der Datenbank sieht wie folgt aus: Links wird eine Liste der vorhandenen Tabellen angezeigt, oben rechts werden SQL-Ausdrücke eingegeben und unten rechts werden die Ergebnisse von ausgeführten SQL-Ausdrücken angezeigt.
Die eingebettete Datenbank unterstützt das PostgreSQL-Netzwerkprotokoll.
Dadurch kann der PostgreSQL-ODBC-Treiber auch für den Zugriff auf die
CCU-Historian-Datenbank verwendet werden. In der Konfiguration muss die
Option database.pgEnable=true gesetzt sein. Falls der Zugriff auch von
anderen Rechnern aus erlaubt sein soll, so muss die Option
database.pgAllowOthers=true zusätzlich gesetzt werden.
Der PostgreSQL-ODBC-Treiber ist unter folgender URL zu finden: http://www.postgresql.org/ftp/odbc/versions
Fertige Installationspakete sind im Ordner MSI zu finden.
Hinweise:
-
Die Version 9.3.200 des Treibers ist kompatibel mit dem CCU-Historian. Bei neueren Versionen (z.B. 9.6.500, 10.1.0) schlägt der Verbindungstest fehl.
-
Unter einem 64-Bit Windows gibt es sowohl 64-Bit als auch 32-Bit-Treiber. Deswegen gibt es auch einen 64-Bit ODBC-Datenquellen-Administrator, der über das normale Startmenü erreichbar ist, und zusätzlich eine 32-Bit-Version, die unter c:\Windows\SysWOW64\odbcad32.exe zu finden ist. Die benötigte Version von Treiber und Administrator hängt von der Applikation ab, die den Treiber verwenden will.
Nach Installation des Treibers muss im ODBC-Datenquellen-Administrator eine neue Datenquelle unter Verwendung des PostgreSQL-Treibers angelegt werden. Die Einstellungen sind wie folgt zu setzen:
Das Feld Database setzt den Dateinamen (ohne Endung) der Datenbank. Dieser muss eventuell als absoluter Pfad angegeben werden. Zum Beispiel muss er für eine CCU-Historian-Installation unter Linux im Verzeichnis /opt/ccuhistorian wie folgt lauten: /opt/ccu-historian/data/history
Die Bedienung des CCU-Historians erfolgt hauptsächlich über einen Web-Browser. Dazu ist ein Web-Server im CCU-Historian eingebettet.
Neben den Standard Web-Seiten werden folgende Funktionen über den Web-Server angeboten:
Der CCU-Historian bietet einen Standardsatz an Web-Seiten. Zum Anzeigen der Web-Seiten muss im Web-Browser der Name oder die IP-Adresse des Rechners, auf dem der CCU-Historian läuft, in die Adresszeile eingegeben werden. Falls der CCU-Historian-Rechner beispielsweise die IP-Adresse 192.168.0.10 besitzt, so muss Folgendes in die Adresszeile eingegeben werden:
http://192.168.0.10
Falls der CCU-Historian auf dem selben Rechner läuft, auf dem auch der Web-Browser gestartet wird, dann kann immer auch localhost als Rechnername verwendet werden. Wenn die Konfigurationsoption webServer.port nicht den Standardwert 80 besitzt, muss an die Adresse noch die konfigurierte Portnummer angehängt werden (z.B. http://192.168.0.10:81).
Falls für die Web-Seiten ein Passwort gesetzt worden ist, muss beim ersten Zugriff das Passwort eingegeben werden:
Das Passwort wird auf der Web-Seite Konfiguration gesetzt oder gelöscht.
Auf der Hauptseite des CCU-Historians werden eine Liste weiterer Web-Seiten und Anwendungen (z.B. Werkzeuge, Zentralen) und eine Liste aller Datenpunkte angezeigt:
Alle sichtbar geschalteten Datenpunkte (s.a. Datenpunktkonfiguration) werden mindestens mit Kanal und Parameter aufgelistet. Je nach verfügbarer Bildschirmbreite werden automatisch zusätzliche Spalten eingeblendet: Raum, Gewerk, Schnittstelle und Adresse. Durch Klicken auf eine Zeile wird der zugehörige Datenpunkt aus- bzw. abgewählt. Es können mehrere Datenpunkte ausgewählt werden.
Die Datenpunktliste kann gefiltert werden. Mit dem Textfilter 
können beliebige Datenpunkteigenschaften durchsucht werden. Es wird nach
allen Teilen des Filterausdrucks in allen Eigenschaften des Datenpunktes
gesucht. Die Groß- und Kleinschreibung wird ignoriert.
Wird ein Suchbegriff in | (Verkettungszeichen) eingeschlossen, so wird nach exakt übereinstimmenden Eigenschaften gesucht. Die gesuchte Eigenschaft darf dann keine Leerzeichen enthalten. Wird nur ein | voran gestellt, so wird nach dem Wortbeginn gesucht. Wird hinter dem Suchbegriff ein | angefügt, so wird nach dem Wortende gesucht. Beispiel: state findet STATE und ARMSTATE. |state| findet aber nur STATE. 10 findet z.B. 10, 100, 101, 210. Allerdings findet |10| nur 10.
Über die
Schaltfläche 
werden nur die bereits
selektierten Datenpunkte sichtbar geschaltet. Hilfstexte zu den weiteren
Filtermöglichkeiten werden automatisch eingeblendet, sobald sich der
Mauszeiger über diesen befindet.
Beispiele:
-
Der Filterausdruck "motion garage" zeigt nur die Bewegungskanäle im Raum "Garage" an.
-
"abc0123456789" zeigt nur die Datenpunkte des Gerätes mit der angegeben Seriennummer, auch wenn die Spalte mit den Seriennummern gerade nicht sichtbar ist.
Mit den selektierten Datenpunkten können verschiedene Aktionen über die
Schaltflächen 
durchgeführt werden. Diese werden
im Folgenden beschrieben.
Über die Schaltfläche 
werden die Datenpunkte in
einem gemeinsamen Trend-Diagramm dargestellt.
Auf der Web-Seite zur Trend-Darstellung kann im oberen Bereich der Zeitbereich für das Trend-Diagramm verändert werden. Im unteren Bereich erfolgt die Trend-Darstellung der Datenpunkte:
Verschiedene vorgegebene Zeitbereiche können über ein Menü ausgewählt werden, oder es kann ein Zeitbereich textlich angegeben werden. Das Format für diesen Fall ist im Abschnitt Export von Zeitreihen dokumentiert. Für die einfache Navigation existieren weitere Schaltflächen.
Mit der Schaltfläche 
werden die Trends getrennt übereinander angeordnet:
Mit der Schaltfläche 
werden zusätzliche Optionen unterhalb eingeblendet. Dort können die
Trends auf Gruppen aufgeteilt werden. Alle Trends einer Gruppe werden im
selben Diagrammbereich gezeichnet. Des Weiteren kann auch die Größe der
generierten Grafik angepasst werden.
Alle vorgenommenen Einstellungen werden automatisch mit in die Adresszeile des Web-Browsers aufgenommen. So kann die aktuelle Ansicht inkl. der ausgewählten Datenpunkte einfach als Lesezeichen abgespeichert werden. Die Adresse kann auch mit anderen Geräten geteilt werden.
Die Schaltfläche 
führt zurück zur Datenpunktauswahl. Alle bisher ausgewählten Datenpunkte werden automatisch vorselektiert.
Zu jeden Datenpunkt können weitere Details angezeigt werden. Auf der Detail-Seite zu einem Datenpunkt werden weitere Meta-Informationen (wie Seriennummer, Kanalnummer, Minimum, Maximum, usw.) und zwei Trends für numerische Datenpunkte oder eine Werteliste für Zeichenkettendatenpunkte angezeigt. Ein Trend zeigt die Entwicklung des Wertes innerhalb der letzten 24 Stunden an, ein zweiter Trend innerhalb der letzten Woche. Die Werteliste für Zeichenkettendatenpunkte enthält die gespeicherten Werte der letzten Woche (max. 50 Einträge).
Unterhalb jeder Trend-Darstellung und der Werteliste wird eine
Schaltfläche 
angezeigt. Mit dieser Schaltfläche kann die im Trend oder in der Werteliste dargestellte Zeitreihe im CSV-Format auf dem lokalen Rechner abgespeichert werden.
Die Detail-Seite zu einem numerischen Datenpunkt sieht zum Beispiel wie folgt aus:
Für Datenpunkte vom Typ Zeichenkette wird eine tabellarische Darstellung der Zeitreihe verwendet. Es werden die Einträge der letzten 7 Tage angezeigt (max. 50 Einträge).
Falls ebenfalls die Datenpunkte für Wartungsmeldungen der CCU (z.B. UNREACH, LOW_BAT) aufgezeichnet werden, kann eine mit dem CCU-Historian Meldungsanalyse durchgeführt werden. Alle Wartungsmeldungen eines Zeitbereichs werden chronologisch aufgelistet:
Zudem wird eine Liste der häufigsten Meldungen in diesem Zeitbereich generiert:
Auf der Werkzeugseite werden verschiedene Funktionen bereitgestellt, um zum Beispiel die Historien von Datenpunkten zu leeren oder bei einem Gerätewechsel zu kopieren:
Hinweis: Mit diesen Funktionen können Daten unwiderruflich gelöscht werden! Es sollte immer vorab eine Sicherungskopie der Datenbank erstellt werden.
Datenpunktspezifische Einstellungen können auf der Seite Datenpunktkonfiguration vorgenommen werden:
Zu jedem Datenpunkt können die Eigenschaften Inaktiv und Versteckt angepasst werden. Versteckte Datenpunkte werden in der Datenpunktübersicht nicht angezeigt. Inaktive Datenpunkte werden nicht archiviert.
Eine Datenvorverarbeitung kann in den Spalten Vorverarb. und Parameter konfiguriert werden. Die Einstellmöglichkeiten und Funktionalitäten sind im Abschnitt Vorverarbeitung aller Wertaktualisierungen beschrieben.
Auf der dieser Konfigurationsseite können verschiedene Einstellungen bezüglich der Web-Applikation vorgenommen werden. Momentan sind nur Optionen zum Passwortschutz vorhanden:
Die Beschreibung der Skriptumgebung ist nun auf einer eigenen Seite zu finden.
Für die bessere Anbindung von AJAX-Anwendungen besitzt der CCU-Historian eine JSON-RPC-Schnittstelle.
Es gibt mehrere Möglichkeiten die Parameter für einen JSON-RPC-Aufruf zu übertragen. Sie sind weiter unten beschrieben. Die Antwort ist aber immer ein JSON-konformes Textdokument, das leicht mit JavaScript weiter verarbeitet werden kann.
Über die JSON-RPC Schnittstelle können die Eigenschaften, die
archivierten und die aktuellen Werte aller Datenpunkte abgefragt werden.
Falls die Konfigurationsoption devices.device1.writeAccess=true gesetzt ist, können auch die aktuellen Werte der Datenpunkte in
den Geräten bzw. der CCU verändert werden.
Eine JSON-RPC Anfrage besteht aus den drei Komponenten Methodenname, Parameterliste und der Identifikation der Anfrage. Der Methodenname bestimmt die aufzurufende Methode. Diese wird dann mit den Parametern aus der Parameterliste aufgerufen. Das Ergebnis des Funktionsaufrufes oder ein eventueller Fehler werden dann zusammen mit der Identifikation zum Aufrufer zurück geschickt.
Als Identifikation kann ein beliebiger JSON-Datentyp übergeben werden. Sie ist optional und kann daher auch komplett entfallen.
Alle Zeitstempel werden generell als Zahl, die die Millisekunden seit dem 1.1.1970 00:00:00 in der Zeitzone UTC repräsentiert, übertragen. In JavaScript kann mit new Date(Millisekunden) ein zugehöriges Date-Objekt einfach erzeugt werden. Von einem vorhandenen Date-Objekt kann der Wert durch Aufrufen von date.getTime() ermittelt werden.
Ein Aufruf sieht z.B. wie folgt aus. Es werden die Eigenschaften des Datenpunktes mit der Historian-ID 39 über ein HTTP GET angefragt:
http://localhost/query/jsonrpc.gy?m=getDataPoint&p1=39&i=123
Die vom CCU-Historian generierte Antwort ist dann z.B.:
{
"id":"123",
"result":{
"interfaceHmSysVar":false,
"managementFlags":0,
"id":{
"interfaceId":"BidCos-RF",
"address":"HEQXXXXXX:1",
"identifier":"LEVEL"
},
"interfaceHmDevice":true,
"historyHidden":false,
"attributes":{
"displayName":"Rollladen Terrasse",
"comment":null,
"paramSet":"VALUES",
"tabOrder":0,
"maximum":1.0,
"unit":"100%",
"minimum":0.0,
"control":"BLIND.LEVEL",
"operations":7,
"flags":1,
"type":"FLOAT",
"defaultValue":0.0
},
"historyTableName":"V_HEQXXXXXX_1_LEVEL",
"idx":39,
"historyDisabled":false,
"interfaceType":0
}
}Insgesamt werden drei Anfragearten unterstützt. Die Beispiele zu den
Anfragearten rufen immer dieselbe Methode echo mit dem Parametern
"Hallo Welt!" und 0.5 und der Identifikation 123 auf. Falls
die Konfigurationsoption webServer.apiKeys gesetzt ist, muss eins von
den dort angegebenen Schlüsselwörtern mit dem Parameter k in der
aufzurufenden Adresse übergeben werden.
Aufzurufende Adresse, hier mit dem Schlüssel abc:
http://localhost/query/jsonrpc.gy?k=abc
Es wird ein JSON-Dokument mit einem JSON-Objekt übertragen. Das
JSON-Objekt besitzt die drei Komponenten method für den
Methodenname, params ein JSON-Array für die Parameterliste und
id für die Identifikation.
Beispiel:
{
"id": 123,
"method": "echo",
"params": ["Hallo Welt!", 0.5]
}Nach der JSON-RPC-Spezifikation ist dies die einzig zulässige Aufrufart. Einige Methodenaufrufe mit komplexen Parametern können nur oder am besten in dieser Aufrufform realisiert werden.
Die Aufrufparameter können gänzlich ohne JSON-Darstellung in der URL
einer HTTP GET-Anfrage kodiert werden. Es muss der Parameter m für
den Methodenname, die Parameter p1, p2, usw. für die
Parameterliste, und optional i für die Identifikation gesetzt
werden. Ob und wie viele Parameter p1, p2, usw. angegeben werden
müssen, hängt von der aufzurufenden Methode
ab.
Beispiel:
http://localhost/query/jsonrpc.gy?m=echo&p1=Hallo+Welt!&p2=0.5&i=123
Analog können die Parameter auch über ein HTTP POST als Formular-Parameter kodiert (Content-Type: application/x-www-form-urlencoded) übermittelt werden.
Ein JSON-Dokument mit einer Anfrage kann auch direkt in der URL einer
HTTP GET-Anfrage kodiert werden. Der Parameter j muss dann mit dem
Inhalt versehen werden.
Beispiel:
http://localhost/query/jsonrpc.gy?j={"id":123,"method":"echo","params":["Hallo+Welt!",0.5]}
Analog kann der Parameter auch über ein HTTP POST als Formular-Parameter kodiert (Content-Type: application/x-www-form-urlencoded) übermittelt werden.
Die Rückgabe ist immer ein JSON-Dokument (Content-Type:
application/json). Das zurückgegebene JSON-Objekt enthält entweder die
Komponenten id und result, oder im Fehlerfall die Komponenten
id und error. result enthält das Ergebnis des
Methodenaufrufs, error besteht aus den Komponenten code
(numerische Fehlerkennung) und message (Klartextfehlermeldung).
Falls keine Identifikation im Aufruf angegeben wurde, hat die Komponente
id den Wert null.
Beispiel für eine erfolgreiche Ausführung einer Methode (siehe Aufrufbeispiele oben):
{
"id":123,
"result":["Hallo Welt!",0.5]
}Beispiel für eine fehlgeschlagene Ausführung einer Methode:
{
"id":123,
"error":{
"code":-32601,
"message":"Method not found"
}
}Diese Methode dient zum Testen von JSON-RPC-Clients. Die Parameterliste wird unverändert zurückgegeben.
Beispielanfrage:
{
"id": 456,
"method": "echo",
"params": [
"String",
123
]
}Beispielantwort:
{
"id": 456,
"result": [
"String",
123
]
}Diese Methode gibt die Eigenschaften eines Datenpunktes zurück, wenn ihr die Historian-ID eines Datenpunktes als Parameter übergeben wird. Alternativ kann auch der ISE-Name (z.B. "BidCos-RF.ABC0123456:2.STATE") eines Datenpunktes angegeben werden. Es können die Eigenschaften mehrerer Datenpunkte angefragt werden, wenn ein JSON-Array an Historian-IDs übergeben wird. Es werden die Eigenschaften aller Datenpunkte zurückgegeben, wenn die Methode ohne Parameter aufgerufen wird.
Beispielanfrage:
{
"method": "getDataPoint",
"params": [
"1"
],
"id": "123"
}Beispielantwort:
{
"id":"123",
"result":{
"interfaceHmSysVar":false,
"managementFlags":0,
"id":{
"interfaceId":"BidCos-RF",
"address":"HEQXXXXXX:1",
"identifier":"LEVEL"
},
"interfaceHmDevice":true,
"historyHidden":false,
"attributes":{
"displayName":"Rollladen Terrasse",
"comment":null,
"paramSet":"VALUES",
"tabOrder":0,
"maximum":1.0,
"unit":"100%",
"minimum":0.0,
"control":"BLIND.LEVEL",
"operations":7,
"flags":1,
"type":"FLOAT",
"defaultValue":0.0
},
"historyTableName":"V_HEQXXXXXX_1_LEVEL",
"idx":39,
"historyDisabled":false,
"interfaceType":0
}
}Als Parameter werden die Historian-ID, die Anfangszeit und die Endzeit des abzufragenden Zeitbereichs übergeben. Alternativ kann auch der ISE-Name (z.B. "BidCos-RF.ABC0123456:2.STATE") eines Datenpunktes anstatt der Historian-ID angegeben werden. Falls keine Einträge zur Anfangszeit oder Endzeit existieren, so werden sie zusätzlich generiert.
Beispielanfrage:
{
"id": 123,
"method": "getTimeSeries",
"params": [
14,
1311414600000,
1311414900000
]
}Beispielantwort:
{
"id": 123,
"result": {
"states": [
1,
1,
1
],
"values": [
100.0,
92.0,
92.0
],
"dataPoint": {
"interfaceHmSysVar":false,
"managementFlags":0,
"id":{
"interfaceId":"BidCos-RF",
"address":"HEQXXXXXX:1",
"identifier":"LEVEL"
},
"interfaceHmDevice":true,
"historyHidden":false,
"attributes":{
"displayName":"Rollladen Terrasse",
"comment":null,
"paramSet":"VALUES",
"tabOrder":0,
"maximum":1.0,
"unit":"100%",
"minimum":0.0,
"control":"BLIND.LEVEL",
"operations":7,
"flags":1,
"type":"FLOAT",
"defaultValue":0.0
},
"historyTableName":"V_HEQXXXXXX_1_LEVEL",
"idx":39,
"historyDisabled":false,
"interfaceType":0
},
"timestamps": [
1311414600000,
1311414744343,
1311414900000
]
}
}Als Parameter werden die Historian-ID, die Anfangszeit und die Endzeit des abzufragenden Zeitbereichs übergeben. Alternativ kann auch der ISE-Name (z.B. "BidCos-RF.ABC0123456:2.STATE") eines Datenpunktes anstatt der Historian-ID angegeben werden. Es werden nur Einträge zurückgegeben, die der Bedingung Anfangszeit<=Zeitstempel des Eintrags<Endzeit entsprechen.
Beispielanfrage:
{
"id": 123,
"method": "getTimeSeriesRaw",
"params": [
14,
1311414600000,
1311415500000
]
}Beispielantwort:
{
"id": 123,
"result": {
"states": [
1,
1,
1
],
"values": [
92.0,
92.0,
92.0
],
"dataPoint": {
"interfaceHmSysVar":false,
"managementFlags":0,
"id":{
"interfaceId":"BidCos-RF",
"address":"HEQXXXXXX:1",
"identifier":"LEVEL"
},
"interfaceHmDevice":true,
"historyHidden":false,
"attributes":{
"displayName":"Rollladen Terrasse",
"comment":null,
"paramSet":"VALUES",
"tabOrder":0,
"maximum":1.0,
"unit":"100%",
"minimum":0.0,
"control":"BLIND.LEVEL",
"operations":7,
"flags":1,
"type":"FLOAT",
"defaultValue":0.0
},
"historyTableName":"V_HEQXXXXX\_1_LEVEL",
"idx":39,
"historyDisabled":false,
"interfaceType":0
},
"timestamps": [
1311414744343,
1311415037609,
1311415302140
]
}
}Als Parameter wird entweder nur die Historian-ID eines Datenpunktes übergeben oder ein JSON-Array mit den Historian-IDs mehrerer Datenpunkte. Alternativ können anstatt der Historian-IDs auch die ISE-Name (z.B. "BidCos-RF.ABC0123456:2.STATE") angegeben werden.
Beispielanfrage 1 (ein Datenpunkt):
{
"id": 123,
"method": "getValue",
"params": [14]
}Beispielantwort 1 (ein Datenpunkt):
{
"id": 123,
"result": {
"timestamp": 1331491325804,
"value": 32.0,
"state": 1
}
}Beispielanfrage 2 (mehrere Datenpunkte):
{
"id": 123,
"method": "getValue",
"params": [
[12, 14, 16]
]
}Beispielantwort 2 (mehrere Datenpunkte):
{
"id": 123,
"result": [
{
"timestamp": 1331491329494,
"value": 33.0,
"state": 1
},
{
"timestamp": 1331491325804,
"value": 32.0,
"state": 1
},
{
"timestamp": 1331488593167,
"value": 0.0,
"state": 1
}
]
}Als Parameter werden die Historian-ID des Datenpunktes und der zu
setzende Wert übergeben. Alternativ kann auch der ISE-Name (z.B.
"BidCos-RF.ABC0123456:2.STATE") eines Datenpunktes anstatt der
Historian-ID angegeben werden. Das Ergebnis des Methodenaufrufes bei
fehlerfreier Ausführung ist immer null. Der zu setzende Wert sollte
dem Datentyp des Datenpunktes entsprechen, ansonsten wird eine
Konvertierung versucht. Für das erfolgreiche Setzen muss die
Konfigurationsoption devices.device1.writeAccess=true
gesetzt sein und der Datenpunkt muss beschreibbar sein. Dies kann auf
der Detail-Seite zu einem Datenpunkt eingesehen werden (s.a. Detail-Seite zu Datenpunkten).
Beispielanfrage:
{
"id": 456,
"method": "setValue",
"params": [
122,
1
]
}Beispielantwort:
{
"id": 456,
"result": null
}Mit executeScript können Skripte, welche im Abschnitt Skriptumgebung beschrieben sind, über die JSON-RPC-API ausgeführt weren.
Beispielanfrage:
{
"id": 123,
"method": "executeScript",
"params": [
"println 'Hello'"
]
}Beispielantwort:
{
"id": 123,
"result": "Hello\r\n"
}Mit calculateTimeSeries können Berechnungsausdrücke, wie sie im Abschnitt Skriptumgebung beschrieben sind, ausgeführt werden.
Der erste Parameter muss den Berechnungsausdruck enthalten, der zweite Parameter den Beginnzeitstempel und der dritte Parameter den Endezeitstempel des Berechnungszeitraums.
Zeitstempel müssen als Anzahl verstrichener Millisekunden seit dem 1.1.1970 00:00:00 UTC angegeben werden.
Beispielanfrage:
{
"id": 123,
"method": "calculateTimeSeries",
"params": [
"1+dataPoint(21)",
1533852000000,
1534284000000
]
}Beispielantwort:
{
"id": 123,
"result": {
"timestamps": [
1533852000000,
1533878448230,
1533883350839,
...
],
"values": [
33.24238223798249,
34.0,
95.0,
...
],
"states": [
2,
2,
2,
...
],
"characteristics": 2
}
}Über eine speziell formatierte Web-Adresse können Zeitreihen aus der Datenbank im CSV-Format auf dem lokalen Rechner abgespeichert werden. Das Format ist so gewählt, dass die Datei ohne Anpassungen in einem MS Excel mit der Ländereinstellung Deutsch geöffnet werden kann:
| Funktion | Zeichen |
|---|---|
| Feldtrenner | ; (Semikolon) |
| Dezimaltrenner | , (Komma) |
| Tausendertrenner | . (Punkt) |
| Textbegrenzer | " (doppelte Anführungszeichen) |
Die Web-Adresse für den Abruf muss dazu folgenden Aufbau haben. Optionale Komponenten sind in eckigen Klammern [ ] dargestellt:
http://Rechnername[:Portnummer]/query/csv.gy?dp1=Historian-ID1[&dp2=Historian-ID2]...[&b=Beginn][&e=Ende][&k=Schlüsselwort]
Die einzelnen Komponenten haben folgende Bedeutung:
| Parameter | Bezeichnung | Beschreibung |
|---|---|---|
| Portnummer |
Die Portnummer muss angegeben werden, wenn die Konfigurationsoption |
|
| dp1, dp2, … | Historian-ID oder ISE-Name |
Die Historian-ID des Datenpunktes (s.a. Detail-Seite zu Datenpunkten). Dieser Parameter kann mehrfach angegeben werden, um mehrere Datenpunkte in einer CSV-Datei zu exportieren (z.B. Alternativ kann auch der ISE-Name (z.B. |
| b | Zeitbereichsanfang | Anfang des zu exportierenden Zeitbereichs (optional) |
| e | Zeitbereichsende | Ende des zu exportierenden Zeitbereichs (optional) |
| k | Schlüsselwort |
Falls die Konfigurationsoption |
Die Parameter b und e sind optional. Folgende Kombinationen
können angegeben werden:
| Parameter | Zeitbereich |
|---|---|
| b, e | vom angegeben Beginn bis zum angegebenen Ende |
| keine | die letzten 24 Stunden. |
| b | vom angegebenen Beginn bis jetzt |
Ein Zeitpunkt kann entweder absolut oder relativ angegeben werden. Bei
einer absoluten Angabe ist das Format YYYYMMDDhhmmss zu verwenden.
YYYY ist der Platzhalter für das Jahr, MM für den Monat, DD
für den Tag, hh für die Stunde, mm für die Minute und ss für
die Sekunde. Platzhalter am Ende können weggelassen werden, z.B. reicht
auch die Angabe YYYYMMDD. Dann wird die Uhrzeit mit 00:00:00 angenommen. Es folgen ein paar Beispiele:
| Zeitpunkt | Kodierung |
|---|---|
| 01.02.2011 12:13:14 | 20110201121314 |
| 03.02.2011 12:00:00 | 2011020312 |
| 01.02.2011 00:00:00 | 201102 |
| 01.01.2011 00:00:00 | 2011 |
Zeitpunkte können auch relativ angegeben werden. Eine relative Angabe
des Parameters b (Zeitbereichsanfang) bezieht sich auf die aktuelle
Zeit, eine relative Angabe des Parameters e (Zeitbereichsende)
bezieht sich auf den Zeitbereichsanfang.
Eine relative Angabe besteht aus mindestens einer Komponente in der Form ZahlManipulator. Es können mehrere Manipulatoren direkt hintereinander angegeben werden, der Zeitpunkt wird dann nach und nach entsprechend des aktuellen Manipulators verschoben.
Bedeutung der Manipulatoren:
| Feldname | Bedeutung |
|---|---|
| Y | Anzahl Jahre vor oder zurück (negative Anzahl) |
| M | Anzahl Monate vor oder zurück (negative Anzahl) |
| D | Anzahl Tage vor oder zurück (negative Anzahl) |
| h | Anzahl Stunden vor oder zurück (negative Anzahl) |
| m | Anzahl Minuten vor oder zurück (negative Anzahl) |
| s | Anzahl Sekunden vor oder zurück (negative Anzahl) |
| =Y | Jahr setzen |
| =M | Monat setzen |
| =D | Tag vom Monat setzen |
| =w | Wochentag setzen |
| =W | Woche im Jahr setzen |
| =h | Stunde setzen |
| =m | Minute setzen |
| =s | Sekunde setzen |
| z | Uhrzeitkomponenten auf 0 setzen (keine Anzahl angeben) |
Es folgen ein paar Beispiele:
| Parameter b | Parameter e | Bedeutung |
|---|---|---|
| -1h | (nicht angegeben) | Letzte Stunde |
| -1D | (nicht angegeben) | Letzten 24 Stunden |
| z | 1D | Aktueller Tag (ab 00:00 Uhr 24 Stunden) |
| -1D z | 1D | Vortag |
| -7D | (nicht angegeben) | Letzten 7 Tage |
| 1=w z | 1W | Aktuelle Woche (ab Montag 00:00 Uhr) |
| -1W 1=w z | 1W | Vorwoche |
| -1M | (nicht angegeben) | Letzter Monat |
| 1=D z | 1M | Aktueller Monat (ab 1. Tag 00:00 Uhr) |
| -1M 1=D z | 1M | Vormonat |
| -6M | (nicht angegeben) | Letzten 6 Monate |
Hier sind noch einige komplette
Beispiele (mit lokalem Zugriff über localhost und ohne Schlüssel):
| Web-Adresse | Bedeutung |
|---|---|
http://localhost/query/csv.gy?dp1=1 |
Die letzten 24 Stunden vom Datenpunkt mit der Historian-ID 1 exportieren. |
http://localhost/query/csv.gy?dp1=3&b=-1W |
Die letzte Woche vom Datenpunkt mit der Historian-ID 3 exportieren. |
http://localhost/query/csv.gy?dp1=64&b=20110227 |
Alle Daten vom 27.2.2011 bis jetzt vom Datenpunkt mit der Historian-ID 64 exportieren. |
http://localhost/query/csv.gy?dp1=16&b=2011&e=1W |
Die erste Woche vom Jahr 2011 vom Datenpunkt mit der Historian-ID 16 exportieren. |
Bei Eingabe der so gebildeten Web-Adresse in einen Web-Browser, wird die CSV-Datei mit den gewünschten Daten generiert und an den Web-Browser geschickt. Dieser kann sie dann speichern oder direkt von MS Excel öffnen lassen.
Eine exportierte Zeitreihe sieht in MS Excel zum Beispiel wie folgt aus:
Damit die Zeitstempel in der vollen Auflösung angezeigt werden, sind die Zellen mit den Zeitstempeln wie folgt zu formatieren:
Über eine speziell formatierte Web-Adresse kann der Web-Server des CCU-Historians auch direkt Aggregate zu einer Zeitreihe berechnen und als Text zurück liefern. Die Web-Adresse muss dazu folgenden Aufbau haben. Optionale Komponenten sind in eckigen Klammern [ ] dargestellt:
http://Rechnername[:Portnummer]/query/text.gy?dp=Historian-ID[&b=Beginn][&e=Ende][&ag=Aggregat 1][&ag=Aggregat 2]...[&k=Schlüsselwort]
Der Parameter dp bestimmt den Datenpunkt, b und e geben den Auswertezeitraum an und k ist der API-Schlüssel. Diese Parameter sind bereits im Abschnitt Export von Zeitreihen beschrieben.
Der Parameter ag kann einfach oder mehrfach angegeben werden und bestimmt die zu berechnenden Aggregate. Falls er nicht angegeben wird, wird der Mittelwert berechnet. Wenn mehrere Aggregate angegeben werden, sind die einzelnen Ergebnisse durch Tabulatoren ("\t") im Antworttext getrennt.
Zurzeit unterstützte Aggregate:
| Kürzel | Bedeutung |
|---|---|
| min | Minimum |
| mints | Zeitstempel des Minimums (Format: JJJJ-MM-TT HH:MM:SS) |
| max | Maximum |
| maxts | Zeitstempel des Maximums (Format: JJJJ-MM-TT HH:MM:SS) |
| avg | Durchschnittswert |
| diff | Differenz zwischen letzten und ersten Wert |
| counter | Summe der positiven Differenzen (ignoriert also Zählwerksrücksetzungen) |
| first | Erster Wert |
| last | Letzter Wert |
Im Folgenden sind Beispiele in HM-Skript für eine CCU3 (bzw. RaspberryMatic) aufgelistet. 192.168.0.4:8080 ist IP-Adresse und Portnummer des CCU-Historians.
Durchschnittswert der letzten 24 Stunden des Datenpunkts mit der ID 736:
string out;
system.Exec("curl 'http://192.168.0.4:8080/query/text.gy?dp=736'", &out);
WriteLine(out.ToFloat());
Minimum der letzten 7 Tage des Datenpunkts HmIP-RF.00181709ADB1AD:1.ACTUAL_TEMPERATURE:
string out;
system.Exec("curl 'http://192.168.0.4:8080/query/text.gy?dp=HmIP-RF.00181709AD0000:1.ACTUAL_TEMPERATURE&b=-7D&ag=min'", &out);
WriteLine(out.ToFloat());
Minimum, Maximum und Durchschnittswert des Vormonats:
string out;
system.Exec("curl 'http://192.168.0.4:8080/query/text.gy?dp=736&b=-1M1=Dz&e=1M&ag=min&ag=max&ag=avg'", &out);
WriteLine("Min: " + out.StrValueByIndex("\t", 0));
WriteLine("Max: " + out.StrValueByIndex("\t", 1));
WriteLine("Avg: " + out.StrValueByIndex("\t", 2));
Tipp: In der Trend-Ansicht des CCU-Historians sind etliche Zeitbereiche vordefiniert. Die Werte der Parameter b und e können von dort (ohne Leerzeichen) übernommen werden.
Über eine speziell formatierte Web-Adresse kann der Web-Server des CCU-Historians auch direkt eine Grafik zu einer Zeitreihe generieren. Die Grafik wird im PNG-Format an den Web-Browser geschickt. Sie kann damit einfach in eigene Web-Seiten eingebunden werden. Mit Werkzeugen zum Herunterladen von Dateien (z.B. cURL oder wget) können die Trend-Grafiken auch als Dateien abgespeichert werden.
Die Web-Adresse muss dazu folgenden Aufbau haben. Optionale Komponenten sind in eckigen Klammern [ ] dargestellt. Die Zeilenumbrüche wurden nur der Übersichtlichkeit halber hinzugefügt:
http://Rechnername[:Portnummer]/query/trend.gy?dp1=Historian-ID1[&dp2=Historian-ID2]...[&g1=Gruppe1][&g2=Gruppe2]...[&gh1=Gruppenhöhe1][&gh2=Gruppenhöhe2]...[&b=Beginn][&e=Ende][&w=Breite][&h=Höhe][&t=Aussehen][&k=Schlüsselwort]
Die einzelnen Komponenten haben folgende Bedeutung:
| Parameter | Bezeichnung | Beschreibung |
|---|---|---|
| Portnummer |
Die Portnummer muss angegeben werden, wenn die Konfigurationsoption |
|
| dp1, dp2, … | Historian-ID oder ISE-Name |
Die Historian-ID des Datenpunktes (s.a. Detail-Seite zu Datenpunkten). Dieser Parameter kann mehrfach angegeben werden, um mehrere Datenpunkte in einer CSV-Datei zu exportieren (z.B. Alternativ kann auch der ISE-Name (z.B. |
| g1, g2, … | Gruppe |
Zu jedem Parameter (optional) |
| gh1, gh2, … | Gruppenhöhe |
Zu jeder Gruppe kann eine Höhe angegeben werden. Die Gruppenhöhe bestimmt wieviel Zeichenfläche einer Gruppe zugewiesen wird. Beispiel: Wenn die Gruppenhöhen auf 1, 2 und 4 gesetzt werden, dann betragen die relativen Anteile an der Zeichenfläche 1/7, 2/7 und 4/7 (7 ist die Summe der individuellen Höhen). Die Anzahl der (optional) |
| b | Zeitbereichsanfang | Anfang des Zeitbereichs (optional) |
| e | Zeitbereichsende | Ende des Zeitbereichs (optional) |
| w | Breite |
Breite der generierten Grafik in Pixeln (optional, Standardwert: 1000) |
| h | Höhe |
Höhe der generierten Grafik in Pixeln (optional, Standardwert: 600) |
| t | Aussehen |
Bezeichner zur Auswahl des Satzes an Einstellungen für das Aussehen der generierten Grafik (optional, Standardwert: default). Der angegebene Bezeichner muss vorher in der Konfigurationsdatei definiert worden sein (s.a. Liste aller Optionen und Anpassung der Trend-Darstellung). |
| k | Schlüsselwort |
Falls die Konfigurationsoption |
Durch Mehrfachangabe des Parameters dp können mehrere Datenpunkte in
einem Trend-Diagramm dargestellt werden. Wenn sich die Wertebereiche
oder die Einheiten der Datenpunkte unterscheiden, werden automatisch
zusätzliche Y-Skalen angelegt.
Mit dem Parameter g können Kurvengruppen gebildet werden. Jede
Kurvengruppe wird in einem eigenen Zeichenbereich dargestellt. Die
einzelnen Kurvengruppen werden dann übereinander mit einer gemeinsamen
Zeitachse dargestellt. Wenn der Parameter g nicht verwendet wird,
werden alle angegebenen Datenpunkte in einer Gruppe - also in einem
Zeichenbereich – dargestellt.
Für das Format der Parameter b und e wird auf den Abschnitt Export von Zeitreihen verwiesen.
Hier sind noch einige Beispiele (mit lokalem Zugriff über localhost und ohne Schlüssel):
| Web-Adresse | Bedeutung |
|---|---|
http://localhost/query/trend.gy?dp1=1 |
Die letzten 24 Stunden vom Datenpunkt mit der Historian-ID 1 als Grafik darstellen. |
http://localhost/query/trend.gy?dp1=3&b=-1W |
Die letzte Woche vom Datenpunkt mit der Historian-ID 3 als Grafik darstellen. |
http://localhost/query/trend.gy?dp1=64&b=20110227 |
Alle Daten vom 27.2.2011 bis jetzt vom Datenpunkt mit der Historian-ID 64 als Grafik darstellen. |
http://localhost/query/trend.gy?dp1=16&b=2011&e=1W |
Die erste Woche vom Jahr 2011 vom Datenpunkt mit der Historian-ID 16 als Grafik darstellen. |
http://localhost/query/trend.gy?dp1=10&dp2=12&dp3=14&dp4=33 |
Die letzten 24 Stunden der Datenpunkte mit den Historian-IDs 10, 12, 14 und 33 werden in einem Diagramm dargestellt. |
http://localhost/query/trend.gy?dp1=10&dp2=20&g1=1&g2=2 |
Die Datenpunkte mit den IDs 10 und 20 werden übereinander in zwei getrennten Zeichenbereichen dargestellt. |
http://localhost/query/trend.gy?dp1=10&dp2=20&dp3=30&g1=1&g2=1&g3=2&gh1=2&gh2=1 |
Die Datenpunkte mit den IDs 10 und 20 werden in einer Gruppe der Höhe 2/3 und der Datenpunkt mit der ID 30 mit der Höhe 1/3 gezeichnet. |
Ein generiertes Trend-Diagramm für fünf Datenpunkte sieht zum Beispiel wie folgt aus:
Im Diagramm werden die Trends der fünf Datenpunkte mit unterschiedlichen Farben, die aus der Legende ersichtlich sind, dargestellt. Hinter dem Datenpunktnamen wird jeweils in Klammern die zugehörige Y-Skala angegeben. Die Nummerierung der Skalen erfolgt von links nach rechts. In diesem Diagramm verwenden die ersten drei Datenpunkte die Skala links, weil sowohl die Wertebereiche als auch die Einheiten (in diesem Fall sind die Datenpunkte ohne Einheit) identisch sind. Falls ein Datenpunkt eine Einheit besitzt, wird diese an der Y-Skala mit angegeben (siehe auch Skala 3).
Aktionen (z.B. Tastendrücke) von Datenpunkten vom Typ ACTION werden
als Symbole dargestellt. Zum Zeitpunkt jeder Aktion wird ein Symbol
gezeichnet:
Durch Verwendung der URL-Parameter g und gh sind z.B. folgende
Trend-Darstellungen möglich:
Die Trend-Darstellung kann vielfältig angepasst werden. Es können alle Farben, die Strichstärken, die Texte für die Beschriftungen und vieles mehr geändert werden. Ein Satz an Einstellungen wird unter einem frei gewählten Bezeichner in der Konfigurationsdatei definiert (s.a.Konfiguration).
Zusätzlich können die Trend-Darstellungsformen in der separaten Datei
trenddesigns.groovy abgelegt werden. Dies hat den Vorteil, dass nicht die
gesamte Konfigurationsdatei des CCU-Historians neu geladen werden muss. Das
Verzeichnis für Skripte kann mit der Konfigurationsoption base.scriptDir
geändert werden. Mit der Standardeinstellung ('.') werden die Skripte im
Arbeits-/Startverzeichnis des CCU-Historians gesucht. Wenn
Trend-Darstellungsformen in dieser Datei konfiguriert werden, muss das Präfix
webServer. bei den Optionen entfernt werden.
Bei der Trend-Generierung kann dann in der Web-Adresse mit dem Parameter
t (Aussehen) der vorher definierte Satz an Einstellungen aktiviert
werden.
Es können mehrere Einstellungssätze definiert werden, und bei jeder
Trend-Generierung ein anderer Satz ausgewählt werden. Die
Standarddarstellung (z.B. auf den CCU-Historian Web-Seiten) kann durch
Definition eines Einstellungssatzes mit dem Bezeichner default
geändert werden.
Die Grundstruktur von einem Satz an Einstellungen sieht in der Konfigurationsdatei wie folgt aus. Die Platzhalter BEZEICHNER, EINSTELLUNGEN ZUR DIAGRAMMFLÄCHE, usw. werden dann je nach Anforderung gefüllt:
webServer.trendDesigns.BEZEICHNER.displayName='ANZEIGENAME DES DESIGNS'
webServer.trendDesigns.BEZEICHNER.chart={
EINSTELLUNGEN ZUR DIAGRAMMFLÄCHE
}
webServer.trendDesigns.BEZEICHNER.plot={
EINSTELLUNGEN ZUR KURVENFLÄCHE
}
webServer.trendDesigns.BEZEICHNER.timeAxis={
EINSTELLUNGEN ZUR ZEITACHSE
}
webServer.trendDesigns.BEZEICHNER.rangeAxes=[
{
EINSTELLUNGEN ZUR ERSTEN Y-SKALA
},
{
EINSTELLUNGEN ZUR ZWEITEN Y-SKALA
},
{
USW.
}
]
webServer.trendDesigns.BEZEICHNER.series=[
{
EINSTELLUNGEN ZUR ERSTEN DATENSERIE
},
{
EINSTELLUNGEN ZUR ZWEITEN DATENSERIE
},
{
USW.
}
]
webServer.trendDesigns.BEZEICHNER.renderers=[
{
EINSTELLUNGEN ZUR ERSTEN KURVE
},
{
EINSTELLUNGEN ZUR ZWEITEN KURVE
},
{
USW.
}
]
Der Bezeichner eines Einstellungssatzes kann aus Buchstaben und Ziffern
bestehen, er muss aber mit einem Buchstaben beginnen (z.B. default,
design3).
Es können beliebig viele Einstellungssätze definiert werden. Der Bezeichner muss allerdings eindeutig sein.
Alle Bereiche sind optional. Es kann auch nur ein Bereich (chart,
plot, timeAxis, rangeAxes, series oder renderers)
angegeben werden. Für die nicht angegeben Bereiche werden die
Standardeinstellungen verwendet.
Wenn im generierten Trend-Diagramm mehr Y-Skalen/Kurven vorkommen, als
im Bereich rangeAxes/series/renderers angegeben worden sind, so
werden die Einstellungen zyklisch durchlaufen. Wenn z.B. drei Y-Skalen
konfiguriert worden sind, so bekommt eine eventuelle vierte Y-Skala die
Einstellungen von der ersten Y-Skala. Oder wenn z.B. nur die
Einstellungen für eine Kurve konfiguriert worden ist, werden die
Einstellungen für alle Kurven verwendet.
Beliebige Farben werden wie folgt angegeben:
new ChartColor(ROTANTEIL, GRÜNANTEIL, BLAUANTEIL)
Die Farbanteile werden im Bereich von 0 bis 255 angegeben. Es kann auch eine Farbkonstante der folgenden Liste verwendet werden:
| ChartColor.BLACK | ChartColor.BLUE |
| ChartColor.CYAN | ChartColor.DARK_BLUE |
| ChartColor.DARK_CYAN | ChartColor.DARK_GRAY |
| ChartColor.DARK_GREEN | ChartColor.DARK_MAGENTA |
| ChartColor.DARK_RED | ChartColor.DARK_YELLOW |
| ChartColor.GRAY | ChartColor.GREEN |
| ChartColor.LIGHT_BLUE | ChartColor.LIGHT_CYAN |
| ChartColor.LIGHT_GRAY | ChartColor.LIGHT_GREEN |
| ChartColor.LIGHT_MAGENTA | ChartColor.LIGHT_RED |
| ChartColor.LIGHT_YELLOW | ChartColor.MAGENTA |
| ChartColor.ORANGE | ChartColor.PINK |
| ChartColor.RED | ChartColor.VERY_DARK_BLUE |
| ChartColor.VERY_DARK_CYAN | ChartColor.VERY_DARK_GREEN |
| ChartColor.VERY_DARK_MAGENTA | ChartColor.VERY_DARK_RED |
| ChartColor.VERY_DARK_YELLOW | ChartColor.VERY_LIGHT_BLUE |
| ChartColor.VERY_LIGHT_CYAN | ChartColor.VERY_LIGHT_GREEN |
| ChartColor.VERY_LIGHT_MAGENTA | ChartColor.VERY_LIGHT_RED |
| ChartColor.VERY_LIGHT_YELLOW | ChartColor.WHITE |
| ChartColor.YELLOW |
Die Möglichkeiten sollen nun anhand von Beispielen aufgezeigt werden. Die jeweiligen Ausschnitte können zum Test in die Konfigurationsdatei vom CCU-Historian kopiert werden. Der CCU-Historian übernimmt eine geänderte Konfiguration nach spätestens 15 Sekunden. Die Beispiele enthalten Kommentare, um die jeweiligen Einstellungen zu beschreiben. Nach jedem Beispiel ist eine mit diesen Einstellungen generierte Grafik abgebildet.
// Mit dem Bezeichner default werden die Standardeinstellungen für
// die Darstellung geändert.
webServer.trendDesigns.default.renderers=[
// Es wird nur eine Kurve definiert. Die Einstellungen werden
// also für alle Kurven übernommen.
{
// Die Strichstärke wird auf 5 Pixel gesetzt.
stroke=new BasicStroke(5)
}
]
webServer.trendDesigns.default.renderers=[
// Die Kurvenfarben von vier Kurven werden gesetzt.
{
// dunkles Rot
paint=new ChartColor(190, 0, 0)
},
{
// dunkles Blau
paint=new ChartColor(0, 190, 0)
},
{
// dunkles Grün
paint=new ChartColor(0, 0, 190)
},
{
// Schwarz
paint=ChartColor.BLACK
}
]
webServer.trendDesigns.default.chart={
// Farbe der Diagrammfläche
backgroundPaint=ChartColor.GRAY
// Diagramm ohne Legende
removeLegend()
}
webServer.trendDesigns.default.plot={
// Farbe der Kurvenfläche
backgroundPaint=ChartColor.BLACK
}
webServer.trendDesigns.default.timeAxis={
// Zeitachse mit Beschriftung
label='Zeitachse'
// Farbe der Beschriftung
labelPaint=ChartColor.RED
// Farbe der Skalen-Werte
tickLabelPaint=ChartColor.GREEN
// Farbe der Markierungen
tickMarkPaint=ChartColor.BLUE
}
webServer.trendDesigns.default.rangeAxes=[
{
label='Helligkeit (0 - 255)'
labelPaint=ChartColor.GREEN
tickLabelPaint=ChartColor.RED
tickMarkPaint=ChartColor.BLUE
},
{
label='Rollladenbehanghöhe (0 - 1)'
labelPaint=ChartColor.BLUE
tickLabelPaint=ChartColor.RED
tickMarkPaint=ChartColor.GREEN
}
]
webServer.trendDesigns.default.chart={
removeLegend()
}
webServer.trendDesigns.default.renderers=[
{
// 3 Pixel Strichstärke
stroke=new BasicStroke(3)
// Farbe Rot
paint=ChartColor.RED
},
{
stroke=new BasicStroke(3)
// Farbe Grün
paint=ChartColor.GREEN
},
{
// 3 Pixel Strichstärke
// gestrichelt (15 Pixel gezeichnet, 10 Pixel Leerraum,
// 3 Pixel gezeichnet, 10 Pixel Leerraum)
stroke=new BasicStroke(
3, BasicStroke.CAP_ROUND, BasicStroke.JOIN_ROUND, 0, [15, 10, 3, 10] as float[], 0
)
// Farbe Rot
paint=ChartColor.RED
},
{
stroke=new BasicStroke(
3, BasicStroke.CAP_ROUND, BasicStroke.JOIN_ROUND, 0, [15, 10, 3, 10\ as float[], 0
)
paint=ChartColor.GREEN
}
]
webServer.trendDesigns.default.chart={
// Titel des Diagramms
title=new TextTitle('Titel des Diagramms')
// Legende entfernen
removeLegend()
// Diagonaler Farbverlauf in der Diagrammfläche
// 0, 0: Startpunkt
// ChartColor.LIGHT_GRAY: Startfarbe
// 100, 100: Endpunkt
// ChartColor.WHITE: Endfarbe
// true: Farbverlauf wiederholen
backgroundPaint=new GradientPaint(
0, 0, ChartColor.LIGHT_GRAY,
100, 100, ChartColor.WHITE, true
)
// Rand um das Diagramm zeichnen
borderVisible=true
// in Schwarz
borderPaint=ChartColor.BLACK
// 3 Pixel breit
borderStroke=new BasicStroke(5)
}
webServer.trendDesigns.default.plot={
// Farbverlauf in der Diagrammfläche
// new ChartColor(128, 128, 255): Farbe unten
// new ChartColor(255, 128, 128): Farbe oben
// (Diagonale Verläufe sind nicht möglich.)
backgroundPaint=new GradientPaint(
0, 0, new ChartColor(128, 128, 255),
0, 0, new ChartColor(255, 128, 128)
)
}
webServer.trendDesigns.default.chart={
// Hintergrundfarbe der Legende
legend.backgroundPaint=ChartColor.LIGHT_GRAY
// Textfarbe der Legende
legend.itemPaint=ChartColor.DARK_RED
// Rahmen der Legende
legend.frame.paint=ChartColor.DARK_GREEN
}
webServer.trendDesigns.default.series=[
{
// Name der Datenserie (auch in der Legende)
key='A'
}, {
key='B'
}, {
key='C'
}, {
key='D'
}
]
webServer.trendDesigns.default.plot={
// Linien für die Zeitachse
domainGridlinePaint=ChartColor.PINK
domainGridlineStroke=new BasicStroke(5)
// Linien für die Messwertachse
// (Das Raster orientiert sich immer an der ersten Y-Skala.)
rangeGridlinePaint=ChartColor.CYAN
rangeGridlineStroke=new BasicStroke(5)
}
webServer.trendDesigns.default.rangeAxes=[
{
// 1. Y-Skala (links) von -250 bis 260
setRange(-250, 260)
},
{
// 2. Y-Skala (rechts) von -0,1 bis 3
setRange(-0.1, 3)
}
]
import java.awt.geom.Ellipse2D
import java.awt.geom.Rectangle2D
import java.awt.geom.GeneralPath
webServer.trendDesigns.default.renderers=[
{
// X, Y, Breite, Höhe
shape=new Ellipse2D.Double(-6.0, -3.0, 12.0, 6.0)
},
{
// X, Y, Breite, Höhe
shape=new Rectangle2D.Double(-6.0, -3.0, 12.0, 6.0)
},
{
// frei definierte Symbol
def p = new GeneralPath()
// nach X, Y ohne Linie
p.moveTo(-1.0, -3.0)
// nach X, Y mit Linie
p.lineTo(1.0, -3.0)
p.lineTo(1.0, -1.0)
p.lineTo(3.0, -1.0)
p.lineTo(3.0, 1.0)
p.lineTo(1.0, 1.0)
p.lineTo(1.0, 3.0)
p.lineTo(-1.0, 3.0)
p.lineTo(-1.0, 1.0)
p.lineTo(-3.0, 1.0)
p.lineTo(-3.0, -1.0)
p.lineTo(-1.0, -1.0)
p.closePath()
shape=p
}
]
Das generierte PNG-Bild ist transparent, wodurch ein eventueller Hintergrund durchscheint.
webServer.trendDesigns.default.chart={
// Transparente Diagrammfläche
backgroundPaint=new Color(255,255,255,0)
// Transparente Legende
legend.backgroundPaint=new Color(255,255,255,0)
}
webServer.trendDesigns.default.plot={
// Transparente Kurvenfläche
backgroundPaint=new Color(255,255,255,0)
}
webServer.trendDesigns.default.chart={
// Diagramm ohne Legende
removeLegend()
}
webServer.trendDesigns.test.rangeAxes=[
{
// alle Werteachsen unsichtbar
visible=false
},
]
webServer.trendDesigns.test.timeAxis={
// Zeitachse unsichtbar
visible=false
}
Eigene Web-Seiten können im Verzeichnis webapp/custom abgelegt werden.
Dort liegende Dateien werden über den eingebauten Web-Server des
CCU-Historians zum Herunterladen in einem Web-Browser angeboten.
Dateien mit folgenden Endungen werden vom CCU-Historian vorverarbeitet, um dynamische Web-Seiten erzeugen zu können:
| Dateiendungen | Beschreibung |
|---|---|
| .html, .htm, .gsp | Template-Dateien (HTML-Dateien mit eingebetteten Groovy-Skripten) |
| .gy, .groovy | Groovy-Dateien (Groovy-Skripte, die beliebigen Inhalt generieren können) |
Unzählige Beispiele für diese Dateien sind im CCU-Historian selbst zu
finden. Diese befinden sich alle im webapp-Unterverzeichnis.
| Thema | Adressen |
|---|---|
| Skriptsprache Groovy | http://groovy-lang.org/ |
| Groovy-Dateien | http://docs.groovy-lang.org/latest/html/documentation/servlet-userguide.html |
Der CCU-Historian fügt zu den bereits vorhandenen globalen Variablen folgende hinzu:
| Name | Bedeutung |
|---|---|
| database | Datenbank |
| utils | Hilfsfunktionen |
| interfaceManager | Schnittstellenverwaltung |
| webServer | Web-Server |
Bei Fragen oder Problemen gibt es vielfältige Möglichkeiten der Unterstützung. Als erste Informationsquelle ist dieses Handbuch zu nennen. Hier ist insbesondere ein genaues Studium des Abschnitts Konfiguration zu empfehlen.
Des Weiteren wird ein Besuch der Internet-Seiten zum CCU-Historian empfohlen (http://www.ccu-historian.de/). Auf diesen Seiten sind auch aktuellere Informationen zu finden, die noch nicht in dieses Handbuch eingepflegt worden sind. Speziell für die Unterstützung wurde die Seite Tipps & Tricks angelegt (http://www.ccu-historian.de/index.php?n=CCU-Historian.TippsAmpTricks).
Die größte Benutzergemeinde und auch der Entwickler des CCU-Historians ist im HomeMatic-Forum zu finden (http://homematic-forum.de/). Dort existiert ein eigenes Forum für den CCU-Historian (HomeMatic Addons CCU-Historian). Viele Fragen und Probleme wurden in diversen Themen bereits behandelt. Bevor eine neue Frage gestellt wird, sollte kurz mit Hilfe der Foren-Suche festgestellt werden, ob bereits ein entsprechendes Thema mit einer Antwort existiert. Bei vielen Problemen ist die Veröffentlichung des Fehlerprotokolls hilfreich (s.a. Erstellung eines Fehlerprotokolls).
Zu guter Letzt kann der Entwickler unter der E-Mail-Adresse info@ccu-historian.de auch direkt erreicht werden. Allerdings ist dort unter Umständen mit längeren Antwortzeiten zu rechnen, da der CCU-Historian ein reines Freizeitprojekt ist.
Je nach Problem ist ein Fehlerprotokoll zur Analyse sehr hilfreich. Damit kann in den meisten Fällen die Fehlerursache schnell eingegrenzt werden. Um ein Fehlerprotokoll zu erstellen ist folgende Einstellungen in der Konfigurationsdatei vorzunehmen (s.a. Liste aller Optionen):
logSystem.fileLevel=Level.FINEST
logSystem.binRpcLevel=Level.FINER
logSystem.fileLimit=10000000
Dadurch werden Log-Dateien (z.B. ccu-historian-0.log) im
Installationsverzeichnis des CCU-Historians erstellt. Die Log-Dateien
können mit diesen Einstellungen bis zu 50 MByte an Festplattenplatz
verbrauchen. Für die Fehlersuche sind auch die Log-Meldungen vor
Auftreten des Fehlers notwendig.