Inhaltsverzeichnis

 

1. Vorwort Inhalt

In diesem Artikel möchten wir der CCU1 des Systems „HomeMatic“ einmal auf den Zahn fühlen. Und nachdem das der erste Artikel seiner Bauart werden wird, eine Anmerkung zum Aufbau der HomeMatic-Testberichte: Nach der Einleitung wird stets eine kleine allgemeine Beschreibung des Bauteils erfolgen, dann die Installation beschrieben, persönliche Erfahrungen hinzugefügt und zuletzt -sofern vorhanden- mir aufgefallene Bugs angegeben.

2. Beschreibung Inhalt

Die CCU1 ist ein ARM7-Mehrplatinen-Embedded-System (Fotos) und dient als zentraler Baustein des HomeMatic-Systems. Sie besteht aus drei Platinen (Power, embedded-Teil und Funkadapter) und läuft unter einem abgespeckten Linux-Betriebssystem. GPL-Konform sind Betriebssystem und Tool-Chain auf der Webseite des Herstellers frei zum Download verfügbar, außer die Quelltexte der entsprechenden Daemons für Funk, RS485 und zentrale Schnittstelle („virtuelle Kanäle“).

Die CCU erfüllt im Wesentlichen drei Aufgaben:

• Anlernen der Funk- und bedrahteten Komponenten (z.B. zum Verteilen der System-Keys)
• Konfigurieren ihrer unterschiedlichsten Parameter
• Bereitstellen einer http-Schnittstelle zum Bedienen des Gesamtsystems, sowohl für Maschinen (XMLRPC) wie auch für Menschen (Web-Interface)

Eine gut strukturierte Seite mit manchen Zusatzinformationen findet man hier.

3. Struktur der Software Inhalt

Wie links abgebildet laufen von Haus aus auf der CCU unterschiedliche Softwarekomponenten parallel und können über TCP/IP miteinander und mit externen Teilnehmern kommunizieren.

Die Dokumentation des HomeMatic-Systems trennt besagte Komponenten in Kommunikations- und Logikschicht, so einfach ist das aber nicht. Im Prinzip ist das Ziel ja, mit unterschiedlichen Sensoren und Aktoren (Funk- und drahtgebunden) zu kommunizieren, und die CCU bringt dafür zwei Interfaces mit; zum einen eine CC1100-Funkplatine, zum anderen die RS485-Schnittstelle.

Leider gibt es keine so komplett vollständige Beschreibung des Zusammenspiels zwischen der Hardware und den links abgebildeten Softwareteilen, deswegen soll das an dieser Stelle nachgeholt werden.

3.1 Betriebssystem Inhalt

Wie erwähnt sitzt als Grundlage ein embedded-Linux auf der Plattform, kleiner 2.6er Kernel, vermutlich nur das nötigste drin, und minimaler Footprint (~8MB für alles).  Das System ist komplett offen, kein root-Kennwort vergeben und kann von jedem nach Gusto verändert oder erweitert werden; nötig sollte es nicht sein. Ansonsten beschreiben einige Artikel, die später genannt werden, wie man das System um Standardfunktionen (ssh, telnet, ftp, …) ergänzt, die von Seiten des Herstellers nicht installiert oder aktiviert sind.

Wer sich unter Linux auskennt, kann sich z.B. eigene Shellscripte oder startup-Scripte erstellen und einrichten. Vielleicht sollte etwa bei jedem Start ein bestimmtes Script gestartet werden, oder man möchte seine syslog-Meldungen per netcat weitergeben, oder hätte gerne ein NAGIOS Monitoring aktiviert, oder, oder, oder….

3.2 Hardwarekommunikation Inhalt

Um mit den Aktoren zu kommunizieren existieren drei binäre Programme (daemons), die auf unterschiedlichen TCP-Ports auf Nachrichten warten. Es findet keine Berechtigungsprüfung mittels Credentials statt, lediglich eine IP-Adress-basierte Firewall läßt sich aktivieren und würde Pakete schon vor dem Eintreffen im System ausfiltern. Wie performant sie ist, oder welche Softwarelösung eingesetzt wird (eventuell in jedem daemon selbst implementiert anstatt im Betriebssystem), weiß ich nicht.

Jeder der drei daemons unterstützt zwei Protokolle. Zum einen das bekannte textbasierte XML-RPC, die hiermit von einem daemon unterstützten Methoden sind gut dokumentiert. Zum anderen ein binäres Protokoll, das nicht dokumentiert ist, wohl aber ähnliche Funktionen bietet wie sein XML-RPC-Pendant.

3.2.1 Ziele Inhalt

Aufgabe der drei Programme ist es, die physischen Gegebenheiten durch Entgegennehmen und Anbieten von Daten möglichst genau abzubilden, und zwar nicht nur Kanalwerte. Es lassen sich eine ganze Reihe mehr Daten verarbeiten:

• Kanalwerte (lesen/schreiben)
• Verknüpfungen zwischen Aktoren und Sensoren („Direktverknüpfung“, „Link“)
• Fehlerzustände
• Logische Zusammenhänge zwischen Gerät, Kanal und Datenpunkt
• etc.

3.2.2 Einschränkungen Inhalt

Wie bereits im Bild zu erkennen ist, besitzen die daemons keine Information über Daten der Web-UI, wie etwa:

• Räume
• Gewerke
• Namen von Geräten und Datenpunkten
• Systemvariablen
• Zeitprogramme (sind nicht cron-basiert)

Es ist deswegen nicht möglich, per (mitgeliefertem) XML-RPC Programme zu starten oder Systemvariablen zu ändern. Dafür muß man sich selbst ein TCL-Script schreiben und dieses in das WWW-Verzeichnis des Webservers kopieren. Ein weiterer Artikel wird sich damit beschäftigen.

3.2.3 Weitere Features Inhalt

Auf der anderen Seite ist die Software recht gut programmiert. Ein wesentliches Feature ist das Event-System der daemons. Damit kann sich ein beliebiger Client von den  Diensten benachrichtigen lassen, sobald an einem der dort registrierten Aktoren eine Änderung eines Datenpunktes auftritt. Nachdem die CCU selbst nur geringfügige Logging-Möglichkeiten bietet (und vor allem die geloggten Daten nicht weiterverarbeitet), lassen sich so ideale Datensenken programmieren. Es muss die Senke einfach selbst einen XMLRPC-Dienst anbieten und sich einmalig (bei jedem Neustart der CCU) bei allen drei Diensten registrieren. Damit wird sie dann stets bei Änderung eines Datenpunktes von einem der drei daemons benachrichtigt. Es stört die CCU auch nicht, wenn besagte Senke einmal offline ist; die Daten werden einfach weiter geschickt.

3.3 Web-UI Inhalt

Die mitgelieferte Weboberfläche der CCU ist das zentrale Bedien- und Anzeigeelement des Gerätes. Nach dem Aufruf wird zunächst ein großes JavaScript von der CCU geladen, dass danach on-the-fly die Oberfläche im Browser zusammenbaut. Ein großer Teil Zeit geht dabei drauf, die einzelnen Aktoren initial von den drei daemons zu ziehen und diese dann mit der eigenen (Web-UI internen) Datenbank abzugleichen.

Im Prinzip also speichern daemon und Web-UI die gleichen Informationen, im Web-UI gibt’s allerdings Zusätze (Räume, Gewerke, Systemvariablen, …), die nur für die Darstellung dort interessant sind.

Leider beinhaltet das Webinterface selbst noch ein bißchen mehr Logik, auch auf binärer Linux-Ebene, an die man eben über die regulären XML-RPC-Mechanismen nicht herankommt. Ein Artikel wird sich eben damit beschäftigen, wie XML-RPC- und Web-UI-Inhalte unter einen Hut gebracht werden können.

3.4 TCL-Interpreter Inhalt

Die vorrangige Scriptsprache auf der CCU ist TCL. Schon etwas betagter bietet die Sprache eine weitere Möglichkeit, auf die Zustände und Variablen des Web-UI zuzugreifen, indem am Anfang eines Scripts die Erweiterung „rega.so“ geladen wird. Damit ist es möglich, HomeMatic-Script -Befehle direkt in TCL auszuführen und ohne Web-UI Programme, Zustände und Funktionen zu ändern.

TCL ruft dabei über das „rega.so“-Modul Methoden aus der Logik des Web-UI auf und kann so z.B. Kanäle setzen oder Systemvariablen auslesen. Nachdem der Kommunikationsweg aber immer über TCL geht, das dann XMLRPC generieren muss und dann erst einen der drei daemons benachrichtigt, und dieser danach den Aktor steuert, ist der Weg meßbar langsamer (im Sekundenbereich auf meiner Instanz) als die direkte XML-RPC-Kommunikation mit den drei daemons. Alleine das Laden des „rega.so“-Moduls dauert bei mir 0,9 Sekunden, und da ist noch kein Code interpretiert.

Wozu ist der dann gut? Nun, zum einen muss ich Scripte nicht auf der CCU ablegen. Ich kann sie per http/POST an den Interpreter auf Port 8181 schicken und erhalte eventuelle Ausgaben als Text zurück. Der CCU-Historian etwa benutzt ein kleines Script, das er zur Laufzeit immer an die CCU schickt, um von dort die im Web-UI vergebenen Namen für Kanäle auszulesen. Er kommuniziert zum Auslesen der Werte der Kanäle ansonsten nur mit den XML-RPC-Schnittstellen (Event-Mechanismus).

Zum anderen scheint der TCL Interpreter einen ziemlich geringen Foot-Print zu besitzen und damit optimal für die geringe Image-Größe der CCU geeignet zu sein.

Daß TCL nun nicht mehr so ganz die Scriptsprache der Wahl ist, Python, Ruby oder Perl können ja auch einiges, halte ich nicht für tragisch; die Lernkurve ist recht steil dabei.

4. Installation Inhalt

Kurz sei noch auf die Installation der Hardware eingegangen, bei der zwei Möglichkeiten bestehen. Ohne eigenes Kabelnetzwerk zuhause würde man per USB-Kabel installieren, nennt man schon ein Kabelnetz sein Eigen, so genügt ein Anschluß an selbiges, die CCU ist dann direkt ansprechbar. Dazu kann mittels Tasten und Display eine IP-Adresse vergeben oder DHCP ausgewählt werden; nach einem Neustart genügt ein Aufruf der IP-Adresse und man gelangt zur Weboberfläche der CCU.

4.1 Webinterface (Web-UI) Inhalt

Das gesamte System läßt sich plattform- und betriebssystemunabhängig über eine Weboberfläche einrichten und fernbedienen. Zwar habe ich keinen Assistenten oder „Wizard“ gefunden, der die wichtigsten Daten abfragen würde, allerdings läßt sich alles über einen zentralen Punkt einstellen. Das ganze Einrichten scheint erfreulich gut zu funktionieren.

4.2 USB-Kabel Inhalt

Für den Anschluß über USB ist leider wie bei USB gängig eine eigene Software auf dem entsprechenden Rechner nötig. Mitgeliefert wird lediglich die Windows-Variante, ob MAC OS und Linux unterstützt werden werden, weiß ich nicht. Die Software besteht einfach aus einem Windows-Dienst, der die USB-Schnittstelle auf der einen Seite bedient und zum Endanwender hin ein eigenes Netzwerkinterface mit eigener IP-Adresse bereitstellt.

Die eigentliche Installation geschieht dann genau wie im vorigen Absatz über den Webbrowser und das CCU-interne Webinterface, mit dem Unterschied, dass die Daten nicht über Ethernet übertragen werden.

5. Persönliche Erfahrung Inhalt

In jedem guten Testbericht darf auch die persönliche (selbstverständlich subjektive) Meinung des Testers nicht fehlen.

5.1 Installation Inhalt

Nun, den designierten Heimanwender mit ein bisserl Netzwerkkenntnissen sollte die Installation nicht vor große Hürden stellen. Es gibt nur wenige Teile, die Schnellstartanleitung ist leicht verständlich und drei Löcher in die Wand zu bohren dürfte auch ohne Hilti-Hammer machbar sein.

So in der Theorie. Bei meiner ersten CCU schien allerdings ein Defekt vorzuliegen; nach dem ersten Booten weigerte sich das Display standhaft zu leuchten und zeigte auch keinen Text an. Ein Update der Zentrale schlug gefühlte zwanzig mal fehl. Das Problem scheint bekannt und kein Einzelfall zu sein, in diesem Beitrag versuchte man sich durch Löten selbst zu behelfen.

Kurz und gut, der Laden bei dem ich bestellte, erklärte sich „kulanterweise“ bereit, meine augenscheinlich defekte Kiste vorab zu tauschen; kurz vor Einsendung hab ich sie dann doch aufgeschraubt, um zumindest diesen Fehler ausschließen zu können. Und richtig, die Leiterbahn sah etwas angekratzt aus, wie auch die meisten manuell montierten Bestandteile dadrin (mal ordentliche Portionen Heißkleber verteilt, eine Schraube einfach vergessen, also Made-in-Germany sähe anders aus); aber sie hatte Kontakt. Daran lag’s also nicht.

Was letztlich den Ausschlag gab, weiß ich nicht, ich hab den FTP-Daemon, Telnet und SSH-Client installiert, neu gebootet, und auf einmal ging’s Display wieder. Auch ein Update von der ausgelieferten Firmware-Version 1.404 auf 1.504beta5 lief jetzt durch und die vorab zugesandte Ersatz-CCU konnte unbehelligt wieder retourniert werden.

Daß das ein sporadischer und Software-Fehler zu sein scheint, gibt mir immer noch ein bißchen zu denken.

5.2 Performanz Inhalt

Das ist ein heikles Thema, umfasst es doch mehrere Bereiche an einem Rechensystem. Zwar stand ich stets mit der Stoppuhr bereit, möchte aber auch aufgrund von Zuschriften anmerken, dass die gemessenen Zeiten wohl von Gerät zu Gerät und von Konfiguration zu Konfiguration unterschiedlich sind.

5.2.1 Startvorgang Inhalt

Zunächst können wir uns mit der Bootzeit beschäftigen; in der jetzigen Konfiguration fährt das Maschinchen in knapp einer Minute so hoch, dass ich sie anpingen kann. Nach zwei Minuten mehr stehen auch die XML-Dienste auf Port 2000 bis 2002 zur Verfügung; bis allerdings das Webinterface bereitsteht, vergehen insgesamt mehr als 5 Minuten mit meinen 50 Aktoren.

Fazit: Nun so oft bootet man nicht, man kann’s also lassen.

5.2.2 Webinterface Inhalt

Sofern die CCU bereit ist, wird das gesamte Webinterface inkl. Oberfläche und Logik teilweise mittels AJAX vollständig in den Browser geladen. Es existieren nur wenige statische Inhalte (z.B. Bilder), im Prinzip rendert ein JavaScript die gesamte Oberfläche zur Laufzeit. Das erforder einen etwas längeren Start des Webinterface (etwa 1:30), sorgt aber dann für eine flüssige Bedienung.

Ungefähr 2:30 werden noch einmal fällig, wenn man Konfigurationen vornehmen möchte. Sodann müssen die vollständigen Gerätebeschreibungen nachgeladen werden, stehen dann aber für die Browsersitzung zur Verfügung.

Die Bedienung der einzelnen Geräte geschieht über selbst erzeugte HTML-Komponenten (Slider, Buttons, etc.) und leider muß sich feststellen, dass sporadisch über das Webinterface eine gewisse Verzögerung zwischen Tastendruck dort und Aktor-Reaktion besteht. Ich kreide es dem WebUI an, denn rufe ich einen Webservice direkt auf, so ist die Reaktionszeit gefühlt „0“.

Dass das Webinterface vom Umfang her nicht für Mobilbildschirme geeignet ist, ist leider auch nicht schön; versteht mich richtig, es läuft. Aber nicht wirklich bedienbar.

Fazit: Laden=Lahm, Bedienung von der Performanz her knapp noch ok.

5.2.3 Webservices Inhalt

Auch sollten wir angeben, wie schnell die XML-RPC-Webservices auf Kommandos reagieren. WGET-Tests bestätigten eine Reaktionszeit von 50-100ms, je nachdem, welcher Aktor gesteuert wurde. Das heißt nicht, dass der Aktor dann diesen Wert unverzüglich bekommen hat (Thermostate brauchen unter Umständen zwei Minuten und länger), sondern nur, dass der Daemon den Befehl bestätigt hat.

Fazit: Im Allgemeinen liegt allerdings die Schaltzeit von Jalousie-, Schalt- und Dimm-Aktoren nicht wesentlich über den 100ms des Dienstes, es geht also schnell.

6. IT-Sicherheit Inhalt

Wie ist’s nun um die IT-Sicherheit bestellt. Zum einen ist da einmal sehr positiv hervorzuheben, dass das System nicht irgendwie abgesichert ist. Ist noch nicht mal ein root-Paßwort gesetzt. Warum positiv? Damit können sich die fähigen Menschen unter uns selbst um die Sicherheit kümmern, eben je nach Bedarf, und müssen sich nicht darauf verlassen, daß der Hersteller keinen Mist gebaut hat bei der Absicherung.

Weiters ist dort ein 2.6er Kernel drauf auf dem System, allerdings auch schon etwas älter, neue Sicherheits-Patches sind wahrscheinlich nicht integriert. Ob das überhaupt sinnvoll wäre, wage ich einmal dahinzustellen. Die Rechenleistung des Kastens reicht so gerade aus, um das System flüssig und reaktiv zu halten, da noch iptables oder gar stateful inspection zu aktivieren, halte ich für utopisch.

Das Teil ist eben hauptsächlich ein LAN-Gateway mit programmierbarem Scheduler drauf.

Empfehlungen:

• Unter gar keinen Umständen darf die CCU, etwa per PAT, ins Internet exponiert werden. Jedes Script-Kiddie schießt die in vernachlässigbar geringer Zeit über eine Standard-DSL-Leitung dreimal um den Mond.
• Zur Fernbedienung von unterwegs aus benutze man einen eigenen Rechner mit Webinterface, das nur die XML-RPC-Schnittstellen der CCU bedient, gerne auch über DynDNS. Eine leistungsfähige AVM-Fritzbox mit PHP drauf leistet hier hervorragende Dienste, oder man hat gleich seinen eigenen 24/7 Rechner am Laufen.
• Wenn machbar, und der Switch das hergibt, baue man sie abgeschottet in ein eigenes VLAN ein zum Schutz im LAN.
• Wenn ein Exponieren unbedingt erforderlich ist, ausschließlich mit Application-Level-Gateway! Die Verbindung muß getrennt sein, oder zumindest durch eine SPI-Firewall laufen.

7. Bugs Inhalt

7.1 Software Inhalt

Es läuft die Firmware-Version 1.504beta5. Wochenlang schon läuft die Maschine zuverlässig; bis auf einen Absturz des BidCos-Daemons habe ich in der Software bislang keine Fehler gefunden. Angelernt sind etwa 30 Sensoren (Taster, Fenster, etc.) und 20 Aktoren (Schalter, Dimmer).

7.2 Hardware Inhalt

• LCD: Hintergrundbeleuchtung flackert reproduzierbar. Schaut ziemlich unschön aus; und damit eignet sich die  CCU nicht mehr als Anzeigeelement.
• LCD: Einzelne Pixel unterschiedlich schwarz