CUxD – das Leatherman für die Homematic®-CCU Teil 3

5,00
Aus ELVjournal 02/2015     0 Kommentare
 CUxD – das Leatherman für die Homematic®-CCU Teil 3

Inhalt des Fachbeitrags

PDF- / Onlineversion herunterladen

Im dritten Teil unserer CUxD-Artikel-Reihe zeigen wir, welche hilfreichen Softwarefunktionen auch ohne zusätzliche Empfänger-Hardware durch das CUxD-Add-on zur Verfügung gestellt werden. Da viele dieser Funktionen sehr umfangreich und komplex sind, ist es empfehlenswert, die detaillierte Beschreibung der einzelnen Funktionen nochmals im CUxD-Handbuch [1] nachzulesen.

Die CUxD-Verwaltungsfunktionen

Bild 1: CUxD-Service-Funktionen
Bild 1: CUxD-Service-Funktionen
Die allgemeinen Notfall-Verwaltungsfunktionen sind über die URL „http://CCU-IP-Adresse/addons/cuxd/maintenance.html“ erreichbar (Bild 1). Hier können zum Beispiel alle aktuell auf der CCU gestarteten Prozesse angezeigt werden. Ein großer Vorteil ist, dass ein Abruf dieser Seite wesentlich schneller als ein Aufruf der WebUI erfolgt und auch nach einem Absturz des ReGaHss-Services, der WebUI oder vom CUxD noch auf diese Webseite mit allen angebotenen Funktionen per Webbrowser zugegriffen werden kann. Auch ein CCU-Neustart (Restart) aus der Ferne ist so bei Problemen einfach möglich. Über den letzten Punkt „Shell command“ können beliebige CCU-Shell-Befehle gestartet werden, die Ausgabe erfolgt in einem separaten Browser-Fenster.

Hinweis:

Sofern der Java-HM-Server deaktiviert wird, sind die Gruppen-, Diagramm- und allgemeinen Einstellungs-Funktionen der CCU2 nicht mehr verfügbar!
Bild 2: Der Filebrowser
Bild 2: Der Filebrowser
Weiterhin besteht die Möglichkeit, auf das gesamte Filesystem der CCU per Webbrowser lesend zuzugreifen und einzelne Dateien herunterzuladen (Bild 2). So können z. B. vor einem Neustart noch schnell die entsprechenden Logfiles (z. B. aus den Verzeichnissen /tmp/ oder /var/log/) für eine spätere Analyse gesichert werden. Der Filebrowser bietet weiterhin die Möglichkeit, Bilder als Thumbnails darzustellen und Zeichenkodierungen auf UTF-8 anzupassen. Die Sortierung der Verzeichnisansicht kann über eine Auswahlliste bestimmt werden.

Die CUxD-Statusseite

Ist der CUxD gestartet, dann können auf der CUxD-Statusseite „http://CCU-IP-Adresse/addons/cuxd/“ alle wichtigen Systeminformationen (Bild 3) abgelesen werden.
Bild 3: Die CUxD-Startseite mit allen wichtigen Systeminformationen im Überblick
Bild 3: Die CUxD-Startseite mit allen wichtigen Systeminformationen im Überblick
Dazu gehören die angeschlossenen und verbundenen USB-Interfaces, die CCU-Uptime und aktuelle Prozessorauslastung, die Hauptspeicherauslastung und die Auslastung aller gemounteten Volumes (Bild 3 oben). Auch alle gemounteten Filesysteme sind auf der Statusseite einsehbar, und durch einen Klick auf den Link „Filesystem:“ (Bild 3 Mitte) wird automatisch der integrierte Filebrowser gestartet (siehe Bild 2). In der HM-Config-Zeile (Bild 3 unten) wird hinter dem „homematic.regadom“-File angezeigt, ob diese Systemdatei beim letzten Mal vollständig (OK!) oder unvollständig (ERROR!) gespeichert wurde. Bei unvollständiger Speicherung gibt es beim nächsten CCU-Neustart sehr wahrscheinlich Probleme. Hier sollte die Sicherung vor dem Neustart wiederholt werden. Das kann ganz einfach durch einen Aufruf von „DOM-Save“ auf der CUxD-Notfallseite (siehe Bild 1) erfolgen.

CUxD-System-Geräte

Bild 4: Zeigt die verschiedenen Funktionen des CUxD-Gerätetyp 28 (System-Devices).
Bild 4: Zeigt die verschiedenen Funktionen des CUxD-Gerätetyp 28 (System-Devices).
Die CUxD-System-Geräte „(28)“ stellen eine Reihe von nützlichen Zusatzfunktionen über virtuelle Geräte auf der CCU zur Verfügung (Bild 4). Diese Funktionen werden über Datenpunkte von virtuellen CCU-Geräten aktiviert oder abgefragt. Dabei handelt es sich um einen 16-Kanal-Timer, ein 16-Kanal-System.Exec mit variablen WebUI-Controls, ein speziell für RGB(W)-Dimmer gedachten 16-Kanal Multi-DIM-Exec und ein 16-Kanal-Netzwerk-Ping. In Verbindung mit eigenen bzw. den bereits mit CUxD aus- gelieferten Scripts können so z. B. ganz einfach CCU-Backups automatisiert, eine Anwesenheit simuliert oder die Erreichbarkeit von Netzwerkgeräten überprüft werden. Die CUxD-Scripts sind in der Anleitung [1] unter Kapitel 6 „Zusatzprogramme“ beschrieben. Eine detaillierte Erläuterung der einzelnen Funktionen der System-Devices kann in der CUxD-Anleitung [1] unter Kapitel 5.8 (28 System-Devices) eingesehen werden.

Timer

Dieses Gerät ermöglicht das programmgesteuerte Auslösen von variablen und zufälligen Ereignissen. Es gibt verschiedene Möglichkeiten, den Timer zu setzen. Entweder in Sekunden relativ zur aktuellen Uhrzeit oder absolut zur Stunde bzw. zum Tag. Zusätzlich kann jedem Wert noch eine zufällige Zeit hinzugefügt werden. Auch ein automatischer Timer-Neustart nach Ablauf des Intervalls ist möglich. Neben der Möglichkeit des Abbruchs und des Retriggerns läuft ein einmal gestarteter Timer auch nach einem CCU- bzw. CUxD-Neustart weiter. Mit dieser Funktion lässt sich z. B. eine Anwesenheitssimulation wie unter [2] beschrieben realisieren.

Exec

Das CUxD-Gerät Exec dient als Ersatz der undokumentierten und nicht sehr stabilen „system.exec()“-Funktion der CCU, mit welcher sich beliebige Prozesse auf der Homematic Zentrale starten lassen. Weiterhin können hiermit bis zu 9 Geräteparameter, 5 Kanalparameter und 99 Parameter-Datenpunkte definiert und als Platzhalter in die Befehlszeile eingebaut werden. Für den direkten Aufruf von URLs ist auch ein automatisches URL-Encoding aller Parameter möglich. Auf der CCU kann dieses Gerät als Taster, Schalter, Jalousieaktor oder Dimmer dargestellt werden. Folgend ein Beispiel zum Ersatz des Original-CCU-„system.Exec()“ durch das „CUxD-Exec“ beim Aufruf durch ein Skript.

Vorher:
string stderr;
string stdout;
string url=“‘http://192.168.0.1/web/message?text=Hello_World&type=3&tmout=10‘“;
system.Exec(„wget -q -O - „#url, &stdout, &stderr);

Nachher:
Für dieses Beispiel muss zuvor im CUxD ein „(28) System-Exec“-Gerät mit der Seriennummer 1 angelegt werden.
string url=“‘http://192.168.0.1/web/message?text=Hello_World&type=3&tmout=10‘“;
dom.GetObject(„CUxD.CUX2801001:1.CMD_EXEC“).State(„wget -q -O - „#url);

HM-Skript mit Rückgabe der Standardausgabe:
In diesem Beispiel wird das Programm bei der Abfrage von CMD_RETS ausgeführt und die Standardausgabe danach in die Variable v geschrieben.
dom.GetObject(„CUxD.CUX2801001:1.CMD_SETS“).State(„ping -c 5 192.168.1.1“);
dom.GetObject(„CUxD.CUX2801001:1.CMD_QUERY_RET“).State(1);
var v = dom.GetObject(„CUxD.CUX2801001:1.CMD_RETS“).State();
WriteLine(v);

Hierbei ist zu beachten, dass die Abarbeitung des HM-Skripts erst fortgesetzt wird, nachdem das aufgerufene Programm beendet wurde. Während dieser Zeit werden auch keine anderen HM-Skripte ausgeführt!

HM-Skript ohne Rückgabe der Standardausgabe (Beispiel):
Dieser Aufruf ist der Abfrage von CMD_RETS immer dann vorzuziehen, wenn die Ausgabe des aufgerufenen Programms nicht weiterverarbeitet werden muss.
dom.GetObject(„CUxD.CUX2801001:1.CMD_SETS“).State(„wget -q -O /dev/null ‚http://192.168.0.99:50000/track=neue_email.mp3‘“);
dom.GetObject(„CUxD.CUX2801001:1.CMD_RUNS“).State(1);

Hierbei wird die Abarbeitung des HM-Skripts sofort und unabhängig von der Laufzeit des aufgerufenen Programms fortgesetzt!

Das Beispiel in Bild 5 zeigt den Aufruf eines Systembefehls ohne HM-Skript direkt aus einem Zentralenprogramm über den Datenpunkt CMD_EXEC, hiermit kann z. B. sehr einfach ein wöchentliches CCU-Backup auf eine SD-Karte realisiert werden.

Bild 5: Zentralenprogramm für ein wöchentliches CCU-Backup
Bild 5: Zentralenprogramm für ein wöchentliches CCU-Backup

Es wird vorausgesetzt, dass die SD-Karte unter dem Verzeichnis „/media/sd-mmcblk0“ erreichbar ist und auf der SD-Karte das Verzeichnis „backup“ angelegt wurde. Das Verzeichnis „backup“ kann mit folgendem Befehl über die CUxD-Service-Seite -> Shell Command erstellt werden.
mkdir -p /media/sd-mmcblk0/backup

Soll das Backup in einem anderen Verzeichnis abgelegt werden, dann ist der Parameter entsprechend anzupassen. Der Parameter in unserem Beispiel sieht so aus:
/usr/local/addons/cuxd/extra/ccu_backup.tcl /media/sd-mmcblk0/backup

Meldungen in das System-Logfile schreiben
Über den Datenpunkt SYSLOG kann aus einem HM-Skript oder über eine Programmverknüpfung direkt eine Meldung in das Syslog (z. B. /var/log/messages) der CCU geschrieben werden:
dom.GetObject(„CUxD.CUX2801001:1.SYSLOG“).State(„eine Statusmeldung“);

Ein sinnvoller Anwendungsfall für die Ausgabe von Meldungen im Syslog ist das Debuggen (zur Fehleranalyse) von aufgerufenen Programmverknüpfungen bzw. HM-Skripten im laufenden Betrieb.

Zufallszahl erzeugen:
Da es mittels HM-Skript keine Funktion zur Erzeugung von Zufallszahlen gibt, existieren dafür bereits verschiedene Lösungsvorschläge [5]. Eine noch einfachere Möglichkeit bietet der Datenpunkt RAND. Er dient zum Erzeugen von Integer-Zufallszahlen zwischen 0 und MAX. Der MAX-Wert kann durch einen Schreibzugriff auf diesen Datenpunkt gesetzt und jederzeit geändert werden. Außerdem kann für jeden Kanal des Gerätes ein unterschiedlicher MAX-Wert gesetzt werden. Er wird dauerhaft in der CUxD-Gerätekonfiguration gespeichert.

So setzen wir den MAX-Wert auf 255 …
dom.GetObject(„CUxD.CUX2801001:1.RAND“).State(255);

… und so erzeugen wir eine Integer-Zufallszahl zwischen 0 und MAX:
integer rand = dom.GetObject(„CUxD.CUX2801001:1.RAND“).State().ToInteger();

Ping

Dieses Gerät dient zum Prüfen der Erreichbarkeit von Hosts anhand von ICMP-Paketen (Ping) oder per Verbindungsversuch auf konfigurierte TCP-Ports. Anhand der TCP-Ports können beliebige Server-Dienste überwacht werden. Neben dem aktiven Aussenden von ICMP-Pings werden auch ankommende ICMP-Pings von den konfigurierten Adressen verarbeitet und starten den Timer für das Sende-Intervall neu. Ist z. B. der Intervall auf 90 s gesetzt und wird alle 60 s vom konfigurierten Host ein Ping an die CCU gesendet, dann erkennt die CCU den Host als ALIVE (erreichbar), ohne dass jemals ein Ping von der CCU an diesen Host gesendet wurde. Um beim Anpingen eines Smartphones mit aktiviertem WLAN Energie zu sparen, können die Ping-Sende-Intervalle nach Erreichbarkeit und nach Nichterreichbarkeit getrennt voneinander konfiguriert werden. Mit dieser Funktion lässt sich z. B. eine Anwesenheitserkennung von Smartphones per WLAN realisieren, zwei Beispiele hierzu finden sich unter [3] und [4].

Daten-Logging

Das Logging von beliebigen CCU-Geräten mittels CUxD stellt eine performante und ressourcenschonende Möglichkeit zum Aufzeichnen von Daten zur späteren Weiterverarbeitung dar. Da hier mit der Zeit große Datenmengen entstehen können, empfiehlt es sich, das Logfile täglich auf einen Massenspeicher auszulagern (USB-Stick, SD-Karte, NFS-Volume).

SD-Karte mounten:
Die SD-Karte sollte auf der CCU2 über die WebUI (Einstellungen -> Systemsteuerung -> Allgemeine Einstellungen) initialisiert werden. Danach ist sie nach jedem CCU-Neustart automatisch unter dem Verzeichnis /media/sd-mmcblk0/ gemountet.

USB-Stick mounten:
Ein USB-Stick muss auf einer CCU immer manuell gemountet werden. Diese Aufgabe kann der CUxD beim Starten erledigen. Dazu sind im CUxD-Setup die folgenden Parameter erforderlich:
MOUNTCMD=mount -t vfat /dev/sda1 /mnt
UMOUNTCMD=umount /mnt
Danach ist auf der CUxD-Statusseite die Taste „Mount“ und anschließend die Taste „Geräteeinstellungen speichern“ zu drücken. Die „Mount“-Taste sollte im gedrückten Zustand verbleiben.

Beim Logging werden die Daten vom CUxD in eine Datei geschrieben, diese Datei wird automatisch angelegt und muss vorher nur im CUxD-Setup mittels DEVLOGFILE-Parameter definiert werden. Um die Systemstabilität nicht zu beeinträchtigen, empfiehlt es sich, die aktuelle Logdatei in der RAM-Disk der CCU zu erzeugen (/tmp-Verzeichnis) und dann jeweils 1x täglich mittels DEVLOGMOVE-Parameter auf einen angeschlossenen USB-Stick bzw. die SD-Karte zu verschieben. Das konfigurierte Zielverzeichnis muss existieren.

CUxD-Setup Beispiel-Konfiguration:
DEVLOGFILE=/tmp/devlog.txt
DEVLOGSIZE=
DEVLOGMOVE=/media/sd-mmcblk0/cuxd/devlog

Die Log-Datei kann dann über die CUxD-Adminoberfläche unter „Info -> Device-Log“ ausgelesen oder mit dem CUxD-Highcharts Add-on [6] grafisch (Bild 8) dargestellt werden.
Bild 8: Zusatzsoftware CUxD-HighCharts
Bild 8: Zusatzsoftware CUxD-HighCharts
Bild 6: Beispiel-Konfiguration für das CUxD-Logging
Bild 6: Beispiel-Konfiguration für das CUxD-Logging

Welche Datenpunkte von welchem Gerät geloggt werden, kann im CUxD-Setup mit dem Parameter LOGIT= festgelegt werden, zudem ist sicherzustellen, dass die CUxD-Parameter SUBSCRIBE_WR=1 und SUBSCRIBE_RF=1 im CUxD-Setup gesetzt sind (Bild 6). In der CUxD-Dokumentation sind alle relevanten Parameter für das Logging ausführlich und mit Beispielen beschrieben. Zum Loggen von Datenpunkten, die nur bei Wertänderungen und relativ selten übertragen werden, wie z. B. Thermostat-Soll-Temperaturen (SETPOINT), eignet sich ein periodischer Aufruf (z. B. jede Stunde) der folgenden HM-Befehle:
string s = „HEQxxxxxxx:2.SETPOINT“;
var v = dom.GetObject(„BidCos-RF.“#s).Value();
dom.GetObject(„CUxD.CUX2801001:1.LOGIT“).State(s#“;“#v);


Im Beispiel wird ein CUxD-System.Exec()-Gerät mit der Seriennummer 1 genutzt. Die Seriennummer des zu loggenden Gerätes ist entsprechend anzupassen. Neben dem Logging von Komponenten können über eine Programmverknüpfung mit CUxD auch Systemvariablen geloggt werden (Bild 7).

Bild 7: Zentralenprogramm zum Loggen von Systemvariablen
Bild 7: Zentralenprogramm zum Loggen von Systemvariablen

Hierzu sind je nach Art des Ausführens folgende Skripte zu verwenden:

Skript zum Logging bei Aktualisierung:
object o = dom.GetObject(„$src$“);
if (o) {
dom.GetObject(„CUxD.CUX2801001:1.LOGIT“).State(o.Name()#“;“#o.Value());
}


Skript zum Logging bei Änderung:
object o = dom.GetObject(„$src$“);
if (o) {
if (o.Value() <> o.LastValue()) {
dom.GetObject(„CUxD.CUX2801001:1.LOGIT“).State(o.Name()#“;“#o.Value());
}
}

CUxD-Highcharts

Zur grafischen Darstellung der mittels CUxD geloggten Daten kann die CCU-Zusatzsoftware CUxD-Highcharts [6] genutzt werden (Bild 8).
Bild 8: Zusatzsoftware CUxD-HighCharts
Bild 8: Zusatzsoftware CUxD-HighCharts

Beispiel-Konfiguration mit Ablage der Logfiles auf der CCU2-SD-Karte:
- CUxD- und Highcharts-Add-on installieren
- SD-Karte per WebUI initialisieren
- auf CUxD-Service-Seite
   -> Shell Command: mkdir -p /media/sd-mmcblk0/cuxd/devlog
   -> Ausführen
- im CUxD-Setup die folgenden Parameter setzen (dürfen nur 1x vorhanden sein!):
   DEVLOGFILE=/tmp/devlog.txt
   DEVLOGSIZE=
   DEVLOGMOVE=/media/sd-mmcblk0/cuxd/devlog
- die gesetzten Parameter auf der CUxD-Statusseite überprüfen
- Aufruf der Diagramme über CUxD -> Info -> Device-Log -> Chart bzw. über http://CCU-IP-Adresse/addons/cuxchart/menu.html

Aufgrund des großen Funktionsumfangs und der Komplexität kann ELV zur Zusatzsoftware leider keinerlei Support übernehmen. Bei alle Fragen zu CUxD steht Ihnen allerdings das Homematic Forum [1] zur Verfügung, welches durch viele erfahrene User und auch den Entwickler selbst betreut wird und somit als Support-Plattform dient.

Weitere Infos:

[1] www.cuxd.de
[2] homematic-forum.de/forum/viewtopic.php?f=18&t=14227&p=110910#p111460
[3] homematic-forum.de/forum/viewtopic.php?f=37&t=19891
[4] homematic-forum.de/forum/viewtopic.php?f=31&t=14058
[5] www.homematic-inside.de/tecbase/homematic/scriptlibrary/item/random
[6] www.homematic-inside.de/software/cuxd-highcharts

Fachbeitrag als PDF-Download herunterladen

Inhalt

Sie erhalten den Artikel in 1 Version:

pdf  als PDF (6 Seiten)

Sie erhalten folgende Artikel:
  • CUxD – das Leatherman für die Homematic®-CCU Teil 3
Produkteweitere FachbeiträgeForen
ELV LED-Lupenleuchte, 1,75-fache Vergrößerung, 850 Lumen, dimmbar, wechselbare Linse

ELV LED-Lupenleuchte, 1,75-fache Vergrößerung, 850 Lumen, dimmbar, wechselbare Linse

Energieeffizienzklasse: A-A++ (A++ bis E)


EUR 54,95*
sofort versandfertig Lieferzeit:1-2 Werktage2

Produktdatenblatt
Uni-Trend Digital-Multimeter UT139A

Uni-Trend Digital-Multimeter UT139A


EUR 33,67*
sofort versandfertig Lieferzeit:1-2 Werktage2


Hinterlassen Sie einen Kommentar:
(Anmeldung erforderlich)
  Name
  E-Mail
KATEGORIEN
DAS KÖNNTE SIE AUCH INTERESSIEREN