Scripte für den Einsatz von Busware.de COC/CUN(O)/CUL in IP-Symcon

Einsatz:

Einbindung der CUN(O) und CUL Module sowie die COC Extension für Raspberry Pi von www.busware.de in IP-Symcon. Diese Geräte sind in der Lage, mit der Firmware culfw mit den gängigen Homeautomatisierungsgeräten wie FS20, HMS, FHT, EM1010 usw., offizielle Liste und alle Funktionen siehe culfw.de, zu komunizieren und geben die empfangenen Daten über einen eigenen Netzwerkport(CUN), den Raspberry Pi bzw. virtuellen Comport über USB(CUL) an den PC weiter und können deren Aktoren ansteuen.
Zur Verarbeitung in IPS ist es notwendig, die empfangenen Datensätze zu dekodieren. Jedes Gerät verfügt über eine individuelle Recordstruktur. Die Scripte bietet z.Z. eine Implementierung für die Datensätze der EM1000, WS300 und HMS-Sensoren, der Telegramme der FS20 und FHT-Sender sowie der FS20 Aktoren. Desweiteren wurde eine dynamische Erstellung und Verwaltung der IPS-Variablen sowie ein Eventhandler zur automatischer Konfiguration des CUN/CUL bei Aktivierung integriert.

Sourcecode:

benötigtes Interface:

Ich empfehle, das dazu passende Gehäuse sowie wenn möglich die HF-Abschirmung mit zu bestellen.

Funktion:

Das Script implementiert z.Z. die Auswertung Daten von ESA1000/2000, EM1000, HMS, WS300, FS20 sowie FHT80B-Raumthermostaten incl. TFK und das Ansteuern von FS20 Funkschaltern und Dimmern. CUNO (das Vorgängermodell CUN ist nicht mehr lieferbar) und COC können haben zusätzlich ein 1Wire Interface und lesen DS18[BS]20-Temperatur Sensoren selbstständig im einstellbaren Intervall aus und stellen sie als HMS-Temperatursensoren da.
Die günstigen FHT-TFK können auch ohne installierte FHT80B Thermostaten genutzt werden.
Für jedes vom CUL/CUN-Parser empfangene Gerät wird eine neue IPS-Kategorie in den IPS-Baum eingefügt und dort für jeden Typ spezifische Variablen selbstständig angelegt, die sich anschliesssend beliebig weiterverarbeiten lassen. Weiterhin können alle Daten in Logfiles geschrieben werden. Außerdem wird die Empfangsstärke jedes Senders am CUNO/CUL/COC (Variable Signal in dB) ausgegeben und kann zur Optimierung des Sender- oder CUN/CUL-Standortes genutzt werden. Ein Eventhandler-Script überwacht den Status der IO-Instance und sendet die benötigten Initialisierungsbefehle bei Aktivierung der Instance zum CUL bzw. CUN.
Das Regvar-Script kann man auch über die Konsole ausführen. Dadurch wird die Instance kurz deaktiv und wieder aktiv geschaltet, wodurch über den Eventhandler die Parameter noch einmal an das CUN/CUL geschickt werden und die Version abgefragt wird. Das FS20Send Script wird als Eventhandler bei Aktualisierung der FS20-Statusvariablen konfiguriert und kann damit die Änderungen an der FS20-Instance über CUN/CUL an den Aktor übertragen.

Dynamisch erzeugte Variablen
Dynamisch erzeugte Variablen

Log Einträge
Log Einträge


Installation

Als erstes muss die Firmware culfw auf das CUN bzw. CUL aufgespielt werden, weil die Geräte ohne Firmware ausgeliefert werden. Die etwas umfangreichere Einrichtung des Raspberry mit der COC-Extension wird hier im Detail beschrieben.

Für die im August 2010 ausgelieferten CUN mit dem Atmel AT90USB646 war dazu die Version 1.39 aus dem CVS-Repository und das Programm FLIP von Atmel notwendig. Dazu sind die Atmel USB-Treiber (Bestandteil des Flip-Dowmloads) für die USB-Schnittstelle zu installieren und die Firmware mittels Flip auf die Geräte zu flashen. Nach dem Neustart meldet sich ein neues Gerät CUN bzw CUL. Diese sollten mittels des MyUSB-Treibers im culfw Packet(docs/MyUSB_USBtoSerial.inf) oder des Treiber-Files von busware.de( CUL.inf ) einen neuen virtuellen ComPort im System generieren. Dazu auch bitte die Anleitungen auf der Herstellerseite und auf http://www.koeniglich.de/culfw/culfw.html beachten.

CUL COM-Port
neuer COM-Port für CUL mit CUL.inf

Das CUNO besorgt sich seine IP-Adresse über DHCP. Da die generierte MAC-Adresse nicht bekannt ist, kann man über den USB-Anschluss mit "c" die aktuelle Einstellung ansehen und auch eine feste IP-und/oder Mac-Adresse (Kommandos "Wia"bzw "Wim")konfigurieren.
Zur Inbetriebnahme muss für das CUL im Gerätemanager ein virtueller COM-Port und für das CUN(O) und COC die IP-Adresse bekannt sein. Bei der Daten-Verbindung mit dem CUN muss der Telnet-Port des Gerätes (Standard:2323) angesprochen werden.
Der Raspberry wird so konfiguriert, das er die von der COC-Extension genutzte serielle Schnittstelle über einen Software-Daemon an den TCP-Port 2323 des Raspberry weitergeleitet wird, so das er wie ein CUNO angesprochen werden kann.

Nun kann man sich mittels Hyperterm/Hterm auf CUN(O) und CUL auf den COM-Port bzw mit Putty auf CUN und den Raspberry verbinden. Mit dem Kommando "V"<Enter> sollte sich die Geräte nun mit der CULFW Version melden. Mit "X21" wird der benötigte Hex-Modus eingestellt.

IPS-Konfiguration:

Für den Einsatz in IPSymcon müssen eine Reihe von Objekten erstellt werden. Das folgende Bild zeigt die Übersicht.
IPS-Instanzen IPS-Instancen

Zunächst ist für den COMPort des CUL eine IO-Instance "Serial Port" bzw für den CUN(O) und COC eine Instance "ClientSocket" anzulegen. Der Comport wird auf den für CUL erstellten virtuellen Comport mit den Parametern 9600,8,N,1 konfiguriert. Die Clientsocket-Instance bekommt jedoch die IP-Adresse des CUN und den Port 2323 zugewiesen.
Client Socket
neuer Client Socket Instance für CUN(O) und Raspbery-COC

Als nächstes ist eine Instanz des Splittermoduls "Cutter" einzurichten. Diese gewährleistet die Übergabe vollständiger Datensätze. Ohne die Splitter-Instance sind die Daten teilweise verstümmelt, so das sie nicht interpretiert werden können. Diese Splitter-Instance erhlt als Parent die Comport- bzw die Clientsocket-Instanz.
Splitter Instance
Splitter Instance

Jetzt muss noch eine Instanz "RegisterVariable" angelegt werden, welche als Parent wiederum das Cutter-Modul hat

Es ist ein neues Script mit dem Inhalt von CUL_RegVar.phps zu erstellen und im Modul "Registervariable" als Ziel zuzuweisen.
Die aufgezeigten StatusVariablen werden automatisch erzeugt.

IPS RegisterVariable
IPS Register Variable

Es ist ein neues Script mit dem Inhalt von CUL_Event.phps zu erstellen und in der Kern Instance "Event Handler" als Status Event und als Startup-Script für die jeweilige IO-Instance zuzuweisen. Dieses Script setzt den Modus "X21" automatisch im CUN/CUL beim IPS-Start sowie wenn sich der Status der Instance auf "aktiv" ändert. Zusätzlich wird die Firmwareversion abgefragt.

IPS EventHandler
IPS Event Handler

FS20-Schalter:
Ein FS20-Schalter wird zunächst wie gewohnt bei der FHZ1x00 als neue "ELV FS20 Gerät"-Instance angelegt und konfiguriert. Die Verbindung mit einem Parent ist eigentlich nicht notwendig, bei der Bedienung mit dem Webfront gibt es jedoch dann Warnhinweise. In diesem Fall kann man sich wie bei den FHT eine FHZDummy-Instanz anlegen. Zum Senden wird diese Instance jedoch nicht verwendet. Das erledigt das "FS20Send" Script direkt, welches als Eventhandler zu den Status/Intensität-Variablen der ""FS20Gerät"-Instance fungiert. Die vom CUL automatisch angelegten FS20 Statusvariablen können nicht zum Schalten verwendet werden.
Das FS20Send-Script wird in der IPS-Konsole ebenfalls als neues Script erstellt. Nach dem Abspeichern wird diesem Script über "Objekt hinzufügen -> Ereignis hinzufügen" ein neuer Auslöser für die FS20-Statusvariable "Intensität" "Bei Variablenänderung" angelegt.
IPS FS20 EventHandler1
IPS FS20 Event

IPS FS20 EventHandler2
IPS FS20 Auslöser

Die Schritte sind für die Statusvariable "Status" zu wiederholen.


optional: FHZDummy
Die IPS-FHZ und FS20 Schalter Devices erfordern als Parent normalerweise eine FHZ1x00PC-Instance und legen diese auch incl. des FTDI-IO-Parents selbständig an. Wenn man keine echte FHZ hat, gibt es Fehler wegen inaktiver Instancen im Log. Wenn man das nicht möchte, kann man eine Instance des FHZDummy SplitterModul als erstes anlegen. Man kann die FHZdummy-Instance aber auch später anlegen. Dann muss man den Parent für das Device von der FHZ1x00-Instance auf die Dummy-Instance ändern und anschliessend die FHZ1x00PC-Instance und die zugehörige FTDI_Instance wieder löschen.

IPS FHZDummy
IPS FHZDummy

Spezielle Konfiguration

Kategorie- und Variablennamen: Die Namen der angelegten Kategorien kann man ändern, nicht aber deren Hierarchie und die Namen der Variablen.

Logging: Das Logverzeichnis für das RegVar-Script kann am Anfang des Scriptes in der Variable "$logdir" gesetzt werden. Will man das Logging abschalten, muss die Variable für den entsprechenden Bereich auf eine leere Zeichkette z.B.
 $cullog="";
gesetzt werden.

Autocreate: Das automatische Erstellen von Instancen kann man in Zeile 17 des CUL_RegVar Scriptes abschalten, indem man die autocreate Variable ändert.
$autocreate=false;
Damit kann man sicherstellen, das man nur Instancen anlegt, wenn man sie erwartet und damit "Zombie-Instancen, welche durch Übertragungsfehler entstehen können, vermeidet.

EM1000: Für die Sensoren 1-4 (EM1000WZ) muss ggfls der Korrekturfaktor in den angelegten Variablen cf_power und cf_energy angepasst werden. Das ist der Wert Umdrehungen pro Kilowattstunde (U/KWh), welcher auf dem Zähler angegeben ist. Default:150

Erweiterung:

Durch einfache Erweiterung lassen sich auch die anderen gesendeten Records auswerten. Dazu muss einfach eine weitere If-Bedingung zum Matchen in die foreach-Schleife mit den Records eingebaut und mit dem entsprechenden Recordtyp ergänzt werden.
<?php
if (preg_match("/^E[0-9A-F]{18,20}\s*\$/",$line)) {
      //  E0101E2997805002F02
            $type=substr($line,2,1);
            $addr=substr($line,3,2);
?>
Eine gute Hilfe ist hier das Mylogger-Modul aus dem Demo-Packet, welches sich selbstständig mit der erste Instance mit SendText-Interface wie ClientSocket verbindet und alle einkommenen Daten mitloggt. Allternativ könnte man nätürlich auch entsprechende Funktionen in das Script einbauen.

IPSymcon Index
Disclaimer

© 2010-2015 Thomas Dreßler
Alle Rechte vorbehalten
letzte Änderung 06.02.2015