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.

Beschreibung

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.

Struktur der Software

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.

Betriebssystem

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….

Hardwarekommunikation

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.

Ziele

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.

Einschränkungen

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.

Weitere Features

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.

Web-UI

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.

TCL-Interpreter

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.

Installation

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.

Webinterface (Web-UI)

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.

USB-Kabel

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.

Persönliche Erfahrung

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

Installation

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.

Performanz

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.

Startvorgang

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.

Webinterface

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.

Webservices

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.

IT-Sicherheit

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.

Bugs

Software

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).

Hardware

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

Nach einem kurzen generellen Überblick zum Thema möchte ich Ihnen in diesem Artikel nun ein paar der verfügbaren Systeme vorstellen, und sofern möglich ein bißchen auf Vorzüge und Nachteile eingehen.

Im Prinzip gibt es Lösungen in jedem Preisbereich; angefangen von den billigen Baumarkt-Funksteckdosen bis hin zu den mehrere zehntausend Teuro teuren speicherprogrammierbaren Steuerungen (SPS) namhafter Hersteller wie Siemens oder Wago.

Konzentrieren möchte ich mich hier allerdings auf Systeme, die bis zur Größe eines Einfamilienhauses ausgelegt sind, und so um die 100 bis 150 Komponenten unterstützen. Professionelle Systeme, die als Steuerung eine SPS mit einer Vielzahl an Kanälen sowie eine Sternverkabelung aller Verbraucher zu einem zentralen Punkt im Gebäude voraussetzen und dort in einem großen Schaltschrank enden, scheiden somit aus.

Allerdings bieten nahezu alle Hersteller von Schalterprogrammen (Berker, Merten, Gira, Busch-Jäger, etc.) eigene Lösungen –teils auf Basis des KNX/EIB Standard- an für ihre Produkte. Der Vorteil liegt klar im angepaßten Design: ein Berker Funkschalter fügt sich natürlich zum einen nahtlos in die Optik des Systems (Schalter, Steckdosen, etc.) ein und lässt sich zum anderen über die Hersteller-eigenen Konfigurationswerkzeuge oder auch Standardwerkzeuge (für KNX) einrichten.

Aber auch Hersteller wie Siemens oder Eltako bieten inzwischen Lösungen im Bereich Heimautomatisierung an, wobei eine Integration in das Schalterprogramm durch Einbindung lediglich der Aktoren im Unterputz oder versteckt z.B. in Zwischendecken stattfindet.

Die Hersteller verfolgen insgesamt sehr modulare Konzepte, im Wesentlichen decken sie alle die im vorigen Artikel genannten Bereiche an Sensorik und Aktorik ab, zu vergleichbaren Preisen.

Kurzes Preis-Beispiel

Schauen wir uns ein Beispiel der Firma ELTAKO an, bei dem wir ein Zimmer mit einem Heizkörper mit Automatisierung ausstatten möchten, so müssen wir für den Ventilantrieb „FKS“ 145 EUR, und für den Raumregler „FTR55D“ knapp 145 EUR berappen; netto natürlich. Weiters wird eine Funk-AccessPoint „BSC-BAP“ erforderlich, der die Steuerung der Wohnung übernimmt, ohne Software versteht sich. Da sind wir mit 298 EUR dabei. Möchten wir eine Software („FVS-Professional-Lizenz“) bekommen, dann kostet das weitere 540 EUR. Zwingend benötigen wir einen PC für diese Variante, oder wir kaufen uns einen kleinen Rechner der Firma Eltako für schlappe 888 EUR.

Ohne weiter ins Detail gehen zu wollen, ist glaube ich klar ersichtlich, dass diese Preispolitik nicht für den Massenmarkt gedacht ist. Kein Objektbesitzer möchte fünf- bis sechstausend EUR ausgeben, nur um seine Lichtlein ein- und auszuschalten.

Vielleicht geht es im Niedrig-Preis-Segment ja auch anders; ich lege den Fokus also eher auf den ambitionierten Heimanwender, der ein kleines Spielzeug sucht, denn mal ganz ehrlich: brauchen tut das Zeugs kein Mensch, wir haben auch vor 100 Jahren schon unsere Buden warmbekommen, ohne daß die Fenster elektrisch überwacht wurden. Und daß wir mal zwei Meter zum Lichtschalter laufen müssen, fördert eher die Durchblutung; ich möchte mich deswegen nur mit zwei Systemen beschäftigen, die eher im unteren Preissegment angesiedelt sind.

Ansprüche

Die folgenden Ansprüche möchte ich an das System stellen:

• Preiswert: Irgendwo muß ja mal Schluß sein mit dem Ausnehmen.
• Integrierbar in vorhandene Schalterprogramme, möglichst ohne Neukauf von Teilen
• Zuverlässigkeit: Entweder über FEC oder bidirektionale Kommunikation mit Bestätigung der Befehle
• Sicherheit: Während es mir noch wurscht ist, ob jemand meine Schalterbetätigungen mitbekommt, möchte ich auf keinen Fall, dass besagter Jemand auf einmal auch mein Licht schalten kann.
• Funkbasiert: Kein Bock, überall Kabel durch die Wand zu ziehen.

Also, Deutschland ist eh zu fett, deswegen here goes…

System „FS 20“

Beim FS20 handelt es sich um ein von [[eQ3]] entwickeltes Steuerungs- und Regelungssystem, das hauptsächlich funkbasiert arbeitet und es dank langjähriger Marktpräsenz mittlerweile zu einer stattlichen Anzahl an Sensoren und Aktoren gebracht hat.

Das System unterstützt die Kommunikation der Komponenten untereinander oder direkt über ein PC-Interface. Der hybride Modus ist ab Werk nicht verfügbar, mit genug Aufwand lässt er sich mit entsprechender –teilweise kostenfreier- PC-Software und einer Funkschnittstelle (USB, WLAN, z.B. busware’s CUL) nachrüsten.

Technik

Hier einmal die Eckdaten der Funkschnittstelle:

• Frequenz: ~868 MHz
• Impulsformung: Keine Ahnung
• Modulation: Amplitudenmodulation (AM)
• Codierung: On-Off-Keying (OOK), erweitert (ähnlich DCF77), feste Bit-Länge, Codierung von 0 und 1 durch unterschiedlich lange Sendeimpulse pro Bit
• Fehlerkorrektur: Keine
• Fehlererkennung: Einfache Parität
• Bidirektional: Nein
• Sicherheit: Keine
• Zuverlässigkeit: Mehrfache Übertragung des Telegramms ohne Rücksicht auf Verluste

Das geübte Ingenieursauge erkennt recht schnell, dass diese Spezifikation vor allem eines ist: ziemlich preiswert. Und so kann man es dann auch im Laden oder Onlinehandel bestätigt finden, ein Wandtaster etwa kostet den Endkunden knapp 20 €, damit ist’s in Fernost für möglicherweise nicht mehr als 5 EUR im Tausenderpacken eingekauft worden und besitzt eine entsprechende Qualität.

Der Fairness halber muß ich allerdings gestehen, dass die nicht so schlecht ist, zumindest von der Verarbeitung her; funktechnisch gesehen ist es eine andere Geschichte.

Test, Fazit

Ich habe mir das System mit einem Dimmer und einem kleinen Taster selbst einmal kurz angeschaut (siehe entsprechender Artikel: [[HomeMatic heiratet FS20]]), bin aber schnell zu dem Schluß gekommen, dass das wirklich keinen gehobenen Ansprüchen genügen kann.

In Kürze: Von 10 gesendeten Tastendrücken kommen 7 an. Das nervt einfach. Vielleicht geht’s ja besser auch…

System HomeMatic

Ohne schon zu viel vorwegnehmen zu wollen, eine kurze Einschätzung: ja, es geht. Hat ja auch lange genug gedauert. In diesem Teil des Artikels beschäftigen wir uns deswegen mit dem System „HomeMatic“, zumindest in Deutschland auch aus dem Hause eQ3.

Uns soll an dieser Stelle weniger die Entwicklungs- und Preishistorie des Systems interessieren, wir wollen uns eher mit den technischen Details beschäftigen und einmal genauer hinter die Kulissen blicken. Auch sei gleich eine weitere Sache vorweggenommen. Das Konzept ist gut, aber alles andere als vollständig. Wie traumhaft, dass es findige und motivierte Programmierer gibt, die hier Abhilfe schaffen.

Überblick

Ohne ein allzu großes Loblied anstimmen zu wollen, muß ich doch sagen, dass das HomeMatic-System nicht schlecht durchdacht ist. Da sei zunächst der Aspekt der Zentrale genannt: Im Prinzip braucht man erst einmal keine. Die Fernbedienungen für’s Licht oder die Jalousien können direkt an den jeweiligen Stellgliedern angelernt werden und bei den Heizungen erlauben die Raumregler eine direkte Bedienung mittels Stellrädchen.

Der ganze Anlernvorgang geschieht ähnlich einfach wie bei FS20: Bei beiden Geräten drücke man einen Knopf ziemlich lange, warte ein bißchen und gut ist. Auch kann eine Fernbedienung an mehrere Lampen angelernt werden (oder andersrum) und damit mehrere Birnchen steuern. Funktionierte in der Praxis einigermaßen zuverlässig, ich werde in separaten Artikeln aber noch auf jeden Aktor einzeln eingehen; Pro & Contra gehen so übersichtlich Hand in Hand.

Steigen irgendwann die Ansprüche in Richtung „Fernbedienung aus dem Internet“, damit man etwa beim Schlußapplaus im Theater bereits die Heizung daheim einschalten kann, oder vor dem Verlassen der Bude mal kurz gucken kann, ob auch alle Fenster zu sind, wird ein bißchen mehr Hardware fällig, nämlich eine der drei zentralen Steuerungsmöglichkeiten.

Technik

Hier einmal die Eckdaten der Funkschnittstelle, basierend auf diesem Artikel:

• Frequenz: ~868 MHz
• Impulsformung: Der Texas-Instruments CC1100 [PDF] kann optional einen Gaußfilter aktivieren zur Impulsformung, ob aktiviert, weiß ich nicht.
• Modulation/Codierung: 2-Frequenzmodulation (2-FSK)
• Fehlerkorrektur: Der CC1100 kann FEC aktivieren, ob sie aktiv ist, weiß ich nicht.
• Fehlererkennung: unbekannt
• Bidirektional: Ja
• Sicherheit: AES (128) Challenge-Response zuschaltbar bei Funk-Komponenten
• Zuverlässigkeit: Einstellbare Wiederholung, wenn keine Bestätigung seitens des Empfängers erfolgt.

Alles in allem macht diese Spezifikation einen wesentlich besseren Eindruck. Ob es mit der Sicherheit wirklich so weit her ist, kann ich nicht einschätzen. Mal ehrlich: Wenn einer in Eure Bude will, hat er ein Brecheisen mit. Dagegen hilft euch das beste AES-CR-Verfahren nichts. Trotzdem würde ich mir gut überlegen, den Fenstermotor oder das elektrische Haustürschloß, so denn bereits vorhanden, gegen die HomeMatic-Produkte auszutauschen. Der Komfortgewinn erscheint mir ziemlich gering in Anbetracht des Risikos; und Brecheisen machen Krach. Elektronische Einbrüche im Allgemeinen nicht.

Zentrale Steuerungsmöglichkeiten

Auch wenn kein Muß, bieten die folgenden drei Geräte ein kleines Plus an Komfort.

USB-Konfigurationsadapter

Zunächst kann man sich in der Lowest-Cost-Variante für den USB-Konfigurations-Adapter entscheiden. Mit einem Windowstreiber ausgeliefert bietet er die Möglichkeit, in den HomeMatic-Geräten Parameter zu ändern oder schon angesprochene direkte Verknüpfungen zwischen zwei Geräten herzustellen. Weitergehende Funktionen, insbesondere das Erstellen von Zeitprogrammen, gibt es nicht. Wenn ihr allerdings eure eigene Software einsetzen wollt und sowieso ein Rechner schon 24/7 läuft, so ist der Adapter Erste Sahne.

LAN-Konfigurationsadapter

Das Ganze gibt es auch in etwas schicker, nämlich als LAN-Version. Der LAN-Adapter hat schon ein kleines Webinterface eingebaut, mit dem man HomeMatic-Geräte einstellen kann. Möchte man XML-RPC benutzen, wird allerdings wieder ein Dauerläufer-PC fällig: Und richtig, mit Windows-Betriebssystem. Dort wird ein Windows-Service installiert, der übersetzt das binäre Protokoll des LAN-Adapters in Text-XML-RPC. Der Vorteil dieses Apparates liegt wohl im Webinterface: Wer kein XML-RPC braucht, und kein Windows hat, ist hiermit sicher besser bedient als mit dem USB-Dingen.

Zentrale Steuerung (CCU)

Nun, und dann gibt’s da noch die Luxus-Variante, die Zentrale CCU1. Neben einem kleinen vollwertigen Linux-Embedded-System, das schickerweise auch komplett offen ist, bietet sie im Wesentlichen den Vorteil der Hardware-RS485-Feldbus-Schnittstelle gegenüber dem LAN-Adapter sowie der Erstellung von Programmen zur Steuerung von Komponenten (“Wenn Knopf1 gedrückt, schalte Licht im Badezimmer an und stelle Radiokanal Bayern 3 ein.”).

Auch bringt sie ein umfangreicheres Webinterface als das des LAN-Adapters mit; es ist vollständig HTML/AJAX-basiert und läuft in den meisten modernen Browsern. Opera 10 hatte nicht funktioniert, aber wer hat den schon.

Fazit

Kurzer Rede langer Sinn: Es ist dann dieses System geworden. Nach und nach werde ich in dieser Kategorie jede einzelne Komponente beschreiben und auch die Selbstbaulösungen nicht vorenthalten. Denn auch, wenn es von Haus aus schon ziemlich viel kann, gibt es leider keine schicke Oberfläche. Auch auf die IT-Sicherheit müssen wir etwas genauer schauen; es kann keine Lösung sein, eine kleine ARM7-Kiste mit lighttpd über DSL direkt ins Internet zu exponieren. Jedes Skriptkiddie schießt die in Sekunden dreimal in den Orkus und retour.

Ein Traum, was dieser Planet alles für Spielzeug anzubieten hat. Sogar so traumhaft, dass damit gleich eine ganze neue Kategorie geboren wird, die der „Heim-Automatisierung“. Doch halt, worum geht es?

Unter der Home-Automation (neudeutsch) oder auch Gebäudeautomatisierung (für die konventionell  orientierten LeserInnen) verstehe ich zunächst einmal alle technischen Hilfsmittel zur Steuerung elektrischer Geräte in einem Gebäude. Plakativ gesprochen ist das nichts anderes als ein Lichtschalter mit Fernbedienung.

Wurden bislang die Bedienelemente (Schalter, Dimmer, etc.) direkt per Leitung mit den Verbrauchern (Lampen, Jalousien, etc.) verbunden und existierte dadurch eine strenge Zuordnung von Schalter zu Verbraucher, so geht man in der Gebäude-Automatisierung dazu über, diese starre Verbindung zu lösen.

Ein Schalter, nennen wir solche Bedienelemente allgemein einmal „Sensoren“, aktiviert nun nicht mehr direkt einen Verbraucher, sondern zeigt seine Bedienung („Umschalten“, „Tastendruck“, „Langer Tastendruck“) zunächst einmal unverbindlich als Nachricht („Telegramm“) an. Die Übertragung Letzterer kann dabei drahtgebunden oder auch auf dem Funkweg erfolgen; verschiedene Systeme und Protokolle existieren, allen voran der selbsternannte Industriestandard KNX/EIB.

Um nun einen Knopfdruck auch verarbeiten zu können, benötigt es mindestens einen Empfänger, in der Regel wird ein solcher dann die Steuerung des Verbrauchers übernehmen. Man nennt diese Komponente „Aktor“. Auch sie gibt es in den unterschiedlichsten Ausführungen an den jeweiligen Einsatzzweck angepasst (Schalter, Dimmer, Heizungsventilantriebe, etc.).

Verknüpfungen zwischen Sensor und Aktor

Eingangs erwähnt habe ich bereits, dass die starre Verknüpfung zwischen Bedienelement (Sensor) und Aktor nun gelöst werden soll, und wir können das auf drei Arten durchführen.

Direktverknüpfung

Zum einen könnte ein Sensor seinen Bedienzustand direkt an einen oder mehrere Aktoren senden. Dieses Prinzip kennen wir von preiswerteren Baumarkt-Funksteckdosen; die Fernbedienung sendet einen Knopfdruck nur an die mitgelieferten und „angelernten“ Steckdosen. Aber auch professionelle Systeme unterstützen diese Art des Betriebes, wenn etwa nur wenige Komponenten innerhalb eines Bereiches zu verschalten und komplexe programmgesteuerte Abläufe nicht vorgesehen sind.

Nachdem nun kein zentraler Anlaufpunkt existiert, ist diese Art der Steuerung für den Funkkanal prädestiniert. Ein Sensor „bläst“ seinen Wert einfach auf den Funkkanal in den Äther und programmierte Aktoren, natürlich nicht notwendigerweise alle, reagieren entsprechend, z.B. mit Einschalten einer Lampe.

Auf einfache Art und Weise lassen sich so schon eine Reihe Funktionalitäten realisieren, der Eye-Catcher ist in diesem Falle das Herabregeln der Heizung, wenn ein Fenster geöffnet ist. Das Heizungsventil besitzt einen kleinen Motor als Aktor und am Fenster befindet sich ein Kontakt, der das Öffnen meldet.

Nachteilig ist hierbei natürlich, dass das System keine komplexeren Aufgaben zuläßt. Um ein an den Haaren herbeigezogenes Beispiel zu geben, könnte man sich so überlegen, die Heizung nur herabzuregeln, wenn das Fenster offen ist und die Außentemperatur unter 10°C liegt. Das wäre nicht mehr so einfach möglich, nun müßte der Motor schon zwei Signale verarbeiten können, einmal den Fenstersensor und einmal einen Temperaturfühler.

Zentrale Steuerung

Abhilfe lässt sich schaffen, wenn man eine zentrale Steuerung (nennen wir sie „Zentrale“) hinzunimmt. Nun werden sowohl Sensoren wie auch Aktoren direkt an die Zentrale verbunden und interagieren nur mit ihr.

Der Taster in der Wand meldet seine Bedienung somit als Nachricht an die Zentrale; dieser wurde programmiert, welche Aktoren anzusteuern sind, und sie sendet entsprechende Steuerbefehle aus.

Klar erkennen können wir den Vorteil der schier unbegrenzten Möglichkeiten. Beliebige Eingangskanäle lassen sich sogar zeitgesteuert auf beliebige Ausgangskanäle umsetzen, der Kreativität sind die Grenzen nur durch die Rechen- und Speicherkapazität der Steuerung und der Kanalkapazität des Übertragungskanals gesetzt.

Wer einmal einen Windowsrechner sein Eigen nannte, wird auch schnell den wesentlichen Nachteil dieser Lösung erkennen. Fällt die Zentrale einmal aus, verbleibt das schöne gute Haus im Status Quo.

Ingenieure sind doch nicht doof™ – Hybride Lösung

Um dem Dilemma zu entkommen, haben sich die Entwickler nun in einem schieren Kraftakt eine Vereinigung der Vorteile aus beiden Konzepten erdacht. In manchen Systemen ist es möglich, einen Sensor sowohl mit einer Zentrale wie auch direkt mit einem Aktor zu verknüpfen.

Damit kann bei Ausfall der Zentrale der Betrieb zumindest rudimentär aufrechterhalten werden. Zwar sind Programmabläufe nicht mehr verfügbar, aber autark laufende Verknüpfungen funktionieren weiterhin. Wir müssen also beim Absturz von Linux nicht mehr im Dunkeln sitzen bleiben.

Sensoren

Weiters soll nun kurz beschrieben werden, welche Sensor-Komponenten überhaupt denk- und kaufbar sind im Bereich der Home-Automation; die folgende Liste erhebt natürlich keinen Anspruch auf Vollständigkeit. Auch muß nicht in jedem System jeder der unten genannten Sensoren vorhanden sein; darauf sollte man vor dem Kauf achten, die Systeme sind in der Regel nicht kompatibel.

• Schalter: Melden Ein/Aus
• Taster: Melden Ein, solange sie gedrückt werden
• Türkontakt: Melden Unterbrechung, solange der Magnetkontakt nicht geschlossen ist
• Fensterkontakt: Bessere Sensoren können offen, gekippt und geschlossen melden, z.B. anhand der Stellung des Fensterdrehgriffes
• Klima: Melden Temperatur und Luftfeuchte
• Wetterstation: Vollständige Wetterdaten, wie Licht, Regenmenge, Windrichtung, etc.
• Sicherheit: Alle erdenklichen Meßgrößen, wie Erschütterung, Wasserkontakt, Rauch, etc.
• Handfernbedienung: Genau wie Taster

Um möglichst flexibel in der Anbringung zu bleiben, sind die meisten der Sensoren batteriebetrieben, was insbesondere mit einer Funkschnittstelle eine große Herausforderung darstellt. Zum einen müssen Meßwerte möglichst aktuell und zeitnah übertragen werden, zum anderen soll die Batterie möglichst lange halten.

Wir lösen das, indem wir die Steuerung des Sensors komplett abschalten, wenn nichts zu tun ist. Im Prinzip läuft nur noch ein Zeitmodul, das den Sensor nach einer bestimmten Zeitspanne (z.B. zehn Minuten) aufweckt, dieser dann sein Soll erfüllt und absendet und sich danach wieder vollständig schlafen legt. Das Zeitmodul an sich verbraucht nur einen Bruchteil dessen, was der Sensor im Betrieb verbraucht; die Batterielebensdauer kann so erheblich verlängert werden.

Bei Tastsensoren ist es sogar noch einfacher: diese verbrauchen nichts, wenn keine Taste gedrückt ist.

Aktoren

Auch auf der Aktorseite erleben wir keine großen Überraschungen. Für die vielen Anwendungsfälle gibt es in gängigen Systemen entsprechende Schalt- und Stellglieder:

• Schalter: Schalten Verbraucher Ein / Aus
• Dimmer: Können Lampen in der Helligkeit steuern
• Jalousie: Fahren Lamellenstellung und Abschattung
• Rolladen: Abschattung
• Ventilantriebe: Stellen Heizungsventile auf eine Prozentsatz
• Fenstermotoren: Öffnen und Schließen von Fenstern
• Fußbodenheizung: Steuern Wärmeabgabe

Bei Aktoren gestaltet sich der Stromsparbedarf nicht ganz so kritisch. Die meisten Aktoren sollen große Lasten bedienen und besitzen deswegen einen Anschluß an das 230V Stromnetz. Daraus kann z.B. mit einem kapazitiven Netzteil der geringe Strombedarf für die Elektronik des Aktors bezogen werden.

Eine Ausnahme ist mir allerdings bekannt: Die Ventilantriebe bei Heizungen. Niemand möchte quer durch den Raum Kabel zu seinen Heizkörpern legen; die einzige Lösung ist hier der Batteriebetrieb. Nun verbraucht erstaunlicherweise der Motor an sich mit seinem stark untersetzenden Getriebe nur wenig Strom. Der größte Bedarf entsteht beim Empfangen von Nachrichten für die Stellung des Ventilantriebes.

Deswegen wird in der Regel der Empfänger in den Stellgliedern nur für eine ganz kurze Zeitspanne aktiviert, innerhalb welcher die Steuerung dem Antrieb einen Stellbefehl übermitteln kann. Außerhalb der Zeitspanne liegt der Aktor im Schlafmodus und kann keine Befehle empfangen. Typischerweise liegen die Intervalle bei wenigen Millisekunden Empfangszeit zu mehreren Minuten vollständigem Schlafmodus.

Natürlich erfordert das Vorgehen eine genaue Synchronisation der Zeitintervalle zwischen Sender und Empfänger. Der interessierte Leser kann sich unter dem Stichwort Slotted Mode (beacon-enabled) über die Mechanismen genauer informieren; damit ist eine Synchronisation nach längerer (~Wochen) Inaktivität wieder möglich.

Anwendungen

Nun, vielleicht macht es ja doch etwas Sinn, wenn man seine Gedanken in Richtung “Anwesenheit” schweifen läßt. Gesetzt den Fall, es gäbe einen Zustand “Anwesenheit”, der entweder per Knopfdruck beim Verlassen des Hauses oder auch beim Abschließen des Haustürschloßes geändert wird auf meinetwegen “nicht anwesend”, so könnte man nun automatisieren:

• Alle Lichter oder anderweitigen Verbraucher abschalten
• Die Heizungen herunterregeln
• Mittels elektrischen Fenstermotoren diese schließen, aber nur, wenn die Luftfeuchte paßt

Ein weiterer lustiger Fall wäre eine Art “Coming-Home” Funktion: Ist z.B. das Handy, das seine Position über GSM ermittelt hat, in der Nähe des Anwesens und die Helligkeit geringer als Wert X, so könnte man schon einmal Flur- und Garagenlicht einschalten.

Und mein persönlicher Favourit: Beim Stellen des Weckers am Handy wird ein Programm auf der Steuerung angelegt, das zur Weckzeit + 5 Minuten im Schlafzimmer alle Lampen voll andreht und alle Schalter für 10 Minuten sperrt. Die bleiben also an. Wirkt besser als zwei Eimer kaltes Wasser.

Fazit

Wir haben gesehen, es lässt sich einiges an “Nice-To-Have” erdenken, wie das technisch ausschaut, und was wir für Mittel und Wege zum Ziel einschlagen, werden die Artikel in dieser Rubrik so nach und nach preisgeben.

Manchmal wundert man sich. Da gibt’s so einfache und nützliche Webseiten im Internet, die uns das tägliche Leben erleichtern. Viele kleine Helferlein, die uns in der digitalen und auch realen Welt den Weg weisen.

In der heutigen Ausgabe spreche ich von Preisvergleichsseiten im Internet. Eingetippt wird ein Produktname und nach kurzer Zeit erscheint eine Liste aller anbietenden Händler, mit Versandkosten und Gebühren und allem drum und dran gleich mit dabei. Die Liste läßt sich nach Preisen aufsteigend sortieren und fertig ist im Prinzip meine Bestellung; ich nehme natürlich den obersten.

A small bump in the road…

Winziges Manko: Was denn, wenn ich aus einer Sparte mehrere verschiedene Produkte bestellen möchte? Vielleicht, um einen ganzen PC selbst zusammenzustellen oder mein nächstes Bike für den Sommer? Fazit heute, das schon Stefan Raab  mit seinen Tele-Tubbie-Figuren herausfand: ooooch, göht nicht.

Welch geniale Funktion wäre denn diese: Ich rüste in den Preisvergleich einen Warenkorb nach. Die Artikel, die ich bestellen möchte, kommen dort hinein, und das System ermittelt mir den aktuellen Gesamtpreis aller Anbieter, die die Artikel liefern oder zumindest im Angebot haben. Idealerweise werden die Versandkosten auch gleich verglichen.

Das wäre mal’n Dingen: eine nützliche Seite, die noch nützlicher wird.

Nun gut, Geizhals kann das nicht, wir legen wie gewöhnlich selbst Hand an.

…well, let’s get to work!

Besagte Schwierigkeit läßt sich einfach mit etwas programmatischem Geschick lösen. Wir konzentrieren uns auf die Plattform Geizhals.at, die mit zu den am einfasten zu bedienenden gehört. Es ist zwar kein Eye-Candy, aber hey, unserem Programm wird das wurscht sein. Außerdem läßt sich der HTML-Code so besser parsen.

Aufgabenstellung

Womit wir beim nächsten Punkt, nämlich dem Konzeptionellen, angelangt sind. Unser Programm muß folgende Aufgaben erfüllen:

1. Entgegennehmen der fraglichen Produkte von Geizhals
2. Abfragen der Händler und Preise für die Produkte
3. Herausfiltern der Händler, die alle Produkte liefern
4. Addieren zu Gesamtpreis pro Händler
5. Ausgeben der sortierten Händlerliste, der billigste zuerst.

Technisch gesehen

Lösen werden wir das Ganze mit einem kleinen Script in der Programmiersprache Python (Version 2.7.1, nicht mehr die aktuelle), da diese einen extrem guten SGML-Parser besitzt, der mit der Erweiterung BeautifulSoup wunderbar einfach angesprochen werden kann und auch dreckigen HTML-Code noch relativ robust verarbeitet. Wir parsen also die Webseite von Geizhals und fischen und die gewünschten Info’s, indem wir einen Webseitenbesuch simulieren.

And done.

Das folgende Listing zeigt das fertige Python-Script. Zur Ausführung sind ein paar Schritte erforderlich:

1. Man lade sich Python 2.7.1 herunter und installiere es in ein beliebiges Verzeichnis auf dem Computer.
2. Man erstelle auf seinem Desktop oder /home ein Unterverzeichnis.
3. Dort hinein kopiere man das Script von unten in eine neue Date, z.B. “gh.py”.
4. Man lade sich BeautifulSoup, neueste Version, herunter und kopiere es ebenfalls dorthinein.
5. Dann bearbeite man die Textdatei und trage die URLs der Artikel auf Geizhals oben in das Listing ein. Möchte man nur Händler, die den Artikel auch vorrätig (“grünes Versandkostenfeld”) haben, kann man das mit dem Zusatz “?v=l” bewerkstelligen, die komplette URL lautet dann etwa “http://geizhals.at/deutschland/a591090.html?v=l”.
6. Abschließend rufe man das bearbeitete Script mit Python auf, z.B. durch Eingeben “C:\Program Files\Python\python.exe gh.py” auf der Kommandozeile.

Der Winter naht, und des Bikers liebstes Wetter (Sonne und traumhafte leichte Brise) neigt sich eher dem Ende zu. Auch Tage werden kürzer, die Nächte brechen früher herein. Über kurz oder lang wird man deswegen um eine vernünftige Beleuchtung nicht herumkommen.

Für wahre Puristen sind Gymmicks wie der Nabendynamo oder die Handkurbel tabu. Auch bleut einem der Gewichtsparzwang ein, nur ja nur das absolut nötigste in Gramm ausgedrückt mitzuschleppen. Die Beleuchtung muß deswegen abnehmbar sein.

Der Artikel beschreibt kurz einen Self-Made-Akkupack für die Ixon-IQ-Speed Vorderlampe, der Preis von derzeit ~64 EUR für den Scheinwerfer und knapp 120 EUR für Akku und Ladegerät noch mit bei ist einfach nicht gerechtfertigt.

Zutaten

Werfen wir einen Blick auf die zu beschaffenden Teile. Bitte beachtet, dass ein bißchen bastlerisches Geschick notwendig ist; Montagezeit beträgt etwa 20-30 Minuten.

Werkzeug und Kabel

• Lötkolben
• Lötzinn (bleifrei bevorzugt)
• Multimeter (Durchgangsprüfer) zum Feststellen der Polarität des Kabels
• Seitenschneider
• Etwas Litze (0,75mm² oder stärker)
• Draht 0,75mm²

Teile für den Scheinwerfer

Für den Scheinwerfer benötigen wir neben der LED-Lampe an sich etwas Gemüse.

• Kleine Neopren-Tasche (z.B. suche man in der Bucht nach “author fahrradtasche”), ca. 3,50 EUR
• Halterung für 6 Mignon-Akkus und 9V Clip-Anschluß, z.B. vom großen C, 0,50 EUR
• 5 Mignon-Akkus NiMH, 2800 mAh, 1.2V, ca. 25 EUR
• Passendes Ladegerät, z.B. 4 Zellen, ca. 7 EUR
• Ixon IQ Speed Zusatzscheinwerfer, bei Geizhals den günstigsten herausfinden, ca. 64 EUR

Macht summa summarum knapp 90 EUR, wenn man alles neu kaufen muss. Hat man noch Akkus und ein passendes Ladegerät, verringert sich der auszugebende Betrag beträchtlich, mich hat es knapp 70 EUR gekostet, da ich nur Tasche und Batteriehalter selbst beschaffen mußte.

Montage

Die einzige Schwierigkeit besteht in der belastbaren Verbindung zwischen Kabel und Batteriehalter. Folgt einfach der Anleitung.

1. Zunächst knipst man den Stecker am geraden Ende, nicht am gewinkelten (!), ab und isoliert die Enden mit einem scharfen Messer auf 0,5cm ab. Vorsicht, nicht schneiden.
2. Die Enden werden nun verzinnt.
3. Die Halterung wird ebenfalls am Clip-Anschluß verzinnt.
4. Überbrückt nun mit der Litze eine Batterieposition, z.B. die direkt am Anschluß, sodaß insgesamt nur 5 Zellen eingesetzt werden müssen. Auch der Originalakku hat nur 5 Zellen. Beide Seiten gut verlöten.
5. Lötet nun das abisolierte und verzinnte Kabel an den Batteriehalter an. Achtet unbedingt auf die Polung, leider wurden offenbar keine einheitlichen Kabel verbaut, ich kann deswegen nichts zu Kabelfarben aussagen.
6. Das Lampenkabel muss gut am Batteriehalter gegen Zugbelastung gesichert befestigt werden. Ich habe dafür ein kleines Loch in den Halter geschmolzen, es mit dem Draht (siehe Zutaten) mehrfach am Halter befestigt und diesen dann mit der Hand verdreht.
7. Bestückt den Halter mit den 5 geladenen Batterien und steckt den gewinkelten Stecker in die Lampe.
8. Testet die Lampe: Langer Druck muss sie einschalten, es sollte die LED oben abwechselnd rot und grün blinken. Kurzer Druck auf den Knopf sollte zwischen Heller und Dunkler umschalten.

Voila, das war’s schon.

Pro und Contra

Sehr für die IQ Speed spricht natürlich die helle Lichtausbeute und der extrem gut gefertigte Reflektor. Sie macht ein schönes helles Viereck auf die Straße und sorgt in der Dämmerung für eine brilliante Sichtbarkeit. Auch die Akkulaufzeit ist mit 10 Stunden (getestet mit 2800 mAh Akkus) durchaus brauchbar.

Getestet habe ich sie auch bei Neumond im stockfinsteren Wald auf Teerstraße, ist einwandfrei machbar, Sichtweite etwa 30m. Über Wurzelwege würde ich sie dagegen nicht emfehlen. Zumindest nicht alleine.

Außerdem kann man sich in den Mignon-Batteriehalter zur Not auch ganz normale Batterien von der Tankstelle einbauen, sofern den Akkus unterwegs die Puste ausgeht.

Allerdings hat die Lampe zwei große Mankos. Zum einen ist sie laut der StVZO nicht im Bereich des Straßenverkehrs zugelassen. Schlecht gelaunte Beamte und es genaunehmende Versicherungen können euch im Prinzip etwas anhängen. Ist kein Witz, wenn es in der Dunkelheit kracht, bekommt ihr zumindest Teilschuld, weil der Unfallgegner sich immer auf unzureichende Beleuchtung, so schizophren das auch sein mag, berufen kann.

Zum anderen stört sie Funktachometer gewaltig. Egal ob hell oder dunkel eingestellt, ich habe noch keinen Funktacho gefunden (analog oder digital), der bei gleichzeitigem Betrieb mit der Lampe (oder einer anderen Ixon IQ) noch funktioniert hätte. Kabelgebundene dagegen haben kein Problem. Das muß man einfach wissen.

Aller Anfang ist schwer, vor allem, wenn es darum geht, eine im wesentlichen einfache Sache zu beschreiben. Kurz: Zur sportlichen und geistigen Betätigung und Erfrischung haben wir am Lehrstuhl dank tatkräftiger Mithilfe und Überzeugzeugskraft aller einen schönen made-in-china Tischkicker bekommen.

War doch anfangs die Freude über die neue Erheiterung recht groß, so stellte sich bald eine gewisse Ernüchterung ein, war doch das ganze Äußere nicht allzu ansprechend gestaltet. Klar, grüner Tisch, Torzähler und die Männeken, aber eben nur “ok”, nicht “very ok”.

Ein Mißstand, dem abgeholfen werden muss; auch mit Ideen der anderen Kollegen war schnell das Projekt “Pimp My Kicker” geboren, und welches Gebiet würde sich besser dafür eignen als das Tor an sich. Selbstspielende Kickerautomaten gibt’s schon, elektrische Torzähler sind seltener.

Und nachdem der verkappte E-Techniker noch abgehalten wurde, “es knacken zu lassen”, war aus “Pimp My Kicker” schnell das Projekt “Wham-O-Meter” mutiert, wie der Name schon sagt, sollte es eine Messung des “Whams”, sprich der Eintrittsgeschwindigkeit des Kickerballs, durchführen.

Weitergesponnen ergab sich dann die folgende Liste der Ideen-Sammlung wünschenswerter Features:

• Ballgeschwindigkeit, und zwar unabhängig vom Einfallwinkel
• Spielstandsanzeige
• Highscore-Liste (“TOP10″) der jeweils schnellsten Schüsse in einem Tor
• Handicap: Ballgeschwindigkeit minimal und maximal pro Seite
• Handicap: Siegbedingungen (Toranzahl) pro Seite einstellbar
• Handicap: Führende Tore eines Teams pro Seite einstellbar
• 2 synchrone LCDs
• Einfacher Tor-Storno
• Einfacher Spiel-Reset

Der vorliegende Artikel wird die gesamte Meßanlage ausführlich in Theorie und Praxis beschreiben.

Wir werden uns zunächst der Geschwindigkeitsmessung in der Theorie mit ein wenig Physik widmen, danach eine passende Hardware entwerfen und die Software und ihre Ansteuer-Routinen für ein Grafik-LCD beschreiben. Es folgt die Beschreibung der Montage und der Inbetriebnahme, danach eine Art Handbuch der Software in der MCU. Abschließen werde ich mit einigen Demonstrationsvideos.

Alle in diesem Artikel veröffentlichten Inhalte (Platinen, PCB-Designs, Fotos, Texte, Software, etc.) sind unter der deutschen Creative-Commons-Lizenz 3.0 by-nc-sa (kurz: Namensnennung, Nicht-Kommerziell, Weitergabe zu gleichen Bedingungen gestattet) verfügbar.

Danksagung

Zunächst aber möchte ich mich an dieser Stelle bei zwei Personen besonders bedanken, die durch ihre Tatkraft und Mithilfe dieses Projekt erst ermöglicht haben.

• Christian Schneider: Unermüdliches Schaffen bei der Montage, obwohl er auch anderes zu tun gehabt hat…
• Thomas Stibor: Hat den genialen Einfall mit der Verbesserung der Hardware gehabt und besonders intensives Beta-Testing betrieben…

Eigentlich ist es ja trivial – an unserem Lehrstuhl gibt’s einen Kühlschrank, der dankenswerterweise von der Sekretärin mit Leben (Waren) befüllt wird. Insbesondere im Sommer weiß der durstige Assistent die kühlen Cola’s zum Fast-EK gegenüber der überteuerten Cafeteria sehr zu schätzen. Wäre da nicht…… ja, wäre da nicht das lästige Zahlen.

Das bisherige System ist denkbar einfach: Für jeden Artikel hängt eine Strichliste mit Namen aus, man kreuzt an, wieviel man wovon konsumiert hat. Einmal in zwei Monaten wird zusammengerechnet und beglichen; dann gibt’s auch neue Lieferungen.

Leider ergeben sich, trotz des Vorteils der einfachen “Bedienung”, ein paar Nachteile:

• Kein Kontostand: Selbst wenn ich eingezahlt habe, kenne ich mein Guthaben nicht.
• Abrechnung nur alle paar Wochen: ich falle regelmäßig aus allen Wolken, ein bißchen Kontrolle und Übersicht wären chic.
• Zusammenzählen per Hand: Bei 20 Assistenten ist die Sekretärin mal ordentlich beschäftigt.
• Sicherheit: Theoretisch könnte mir jemand ein Kreuzchen machen, und ich würde das wohl nicht bemerken.

Irgendwann war ich das Gehampel satt, Zeit würde es für eine vollelektronische Variante, die all die obigen Schwächen beseitigt. Auch eine schöne Weboberfläche sollte nicht fehlen.

Wie bereits am Ende der Beschreibung zum ersten Controller angekündigt, ist das System nicht optimal. Gelegentliche Farbblitzer und zu geringe Auflösung in dunklen Bereichen bei 10 Bit hinterlassen einen nicht ganz so positiven Eindruck. Zwar könnte man mit Diffusionsfolie noch ein Stück weit kommen, eines Ingenieurs ist das aber nicht würdig

Es gilt daher, die vorhandenen Schwächen mittels neuer Hardware zu beseitigen. Im Wesentlichen sind das:

• Software-PWM
• Nur 10 bit Auflösung bei 75 Hertz PWM-Grundfrequenz
• Insgesamt drei RGB-Kanäle, sprich 9 PWM-Kanäle

Die theoretischen Kapitel über Ambilight, Biologie (Gammakorrektur) und PWM aus dem Artikel Ambient Light im Eigenbau gelten auch für diesen Controller, es macht daher Sinn, den Artikel zuerst zu lesen, so noch nicht geschehen.

Atmels XMega-AVR Baureihe

Wie schon in Ambient Light im Eigenbau (Seite 5) im Unterkapitel “MCU al­lei­ne oder mit de­di­zier­tem LED-?Trei­ber?” beschrieben existierte bis dato keine vernüftige Hardware-Lösung, wenn mann einmal von FPGA-Programmierung absieht. Mittlerweile aber sind von Atmel Chips der Baureihe ATxMega lieferbar (waren seit Mitte 2008 angekündigt!). Sie zeichnen sich durch geringeren Stromverbrauch, einheitlicheres Hardware-Design und höhere Taktfrequenz aus.

Ich habe mich für einen ATxMega16A4 entschieden, da das TQFP44-Gehäuse noch einigermaßen im Eigenbau behandelbar ist, sowohl mit Ätzen wieauch zum Löten an sich. Außerdem bietet der Chip bereits alle Voraussetzungen, die wir für die neue Hardware brauchen:

• 16 PWM-Kanäle mit je 16 Bit Auflösung
• 5 USARTS (wir benötigen nur einen)
• Taktfrequenz bis 32 Mhz
• AES/DES-Crypto-Engine (die wir aber nicht brauchen)
• 3,3V Betriebsspannung
• 16 KByte Flash-ROM, optionaler Bootloader

Mit Mustern schauts relativ mau aus, ich hatte aber das Glück, bei Farnell welche zu bekommen. Leider gibt’s Stand heute (12/2009) bei Digikey nur die großen TQFP100 oder BGA-Gehäuse, offenbar dürfen sie wegen der AES-Crypto-Engine nicht exportiert werden, in den USA wären sie nämlich lieferbar. Das soll einer verstehen, vor allem, weil die großen die Crypto-Funktionen ebenfalls besitzen.

Schnittstelle am PC

Etwas länger habe ich überlegt, ob Version 2 für die Datenübertragung wieder eine USB-Schnittstelle bekommen soll. Der FTDI-Chip hätte nämlich einige Vorteile. Nicht nur, dass er fast ohne externe Bauteile auskommt und sich vollständig um die Kommunikation mit dem PC kümmert, er hätte auch einen 3,3V Ausgang, um den Atmel mit Strom zu versorgen.

Ich habe mich dann aber dagegen entschieden, im Wesentlichen aus zwei Gründen:

1. Das Teil ist schweineteuer. Fünf EUR beim Reichelt sind mir einfach zu viel, v.a. wenn es ein ganzes Kabel bei eBay für knapp 4 € gibt.
2. Aus Erfahrung mit dem ersten Controller weiß ich, dass das System einen Standby mit geöffnetem COM-Port nicht überlebt, sprich man mußte den Controller nach jedem Aufwachen des Rechners erst einmal wieder abstecken und wieder hinstecken, damit der COM-Port wieder existierte. Die Software Boblight erkennt einen Standby aber nicht und läßt den COM-Port ständig offen. Das funktioniert unter Windows XP aber nur mit einer Hardware-Schnittstelle zuverlässig.

Der neue Controller wird deswegen keinen USB-Anschluss bieten. Wer möchte, kann sich einen mittels USB2Serial-Kabel selbst konstruieren, sei aber darauf hingewiesen, dass das bei mir nicht richtig funktionierte.

Hinweis: Auf der Platine sind die RX-/TX-Leitungen der seriellen Buchse vertauscht. Man kann den Controller daher nur mit einem Nullmodem-Kabel betreiben. Wenn ihr einen USB2Serial-Adapter benutzt, wird der nicht direkt an der Buchse funktionieren. Entweder ihr zieht die Leiterbahnen neu, oder schaltet noch ein Nullmodem-Kabel zwischen Controller und Adapter.

Wikipdia listet als ersten Absatz im Artikel “Ticketsystem“:

Ein Issue-Tracking-System (TTS; Synonyme: Help-Desk-System, Serviceticket-System, Ticketing-System, Task-Tracking-System, Support-Ticketing-System, Trouble-Ticket-System, teilweise auch Fallbearbeitungssystem) ist eine Art von Software, um Empfang, Bestätigung, Klassifizierung und Bearbeitung von Kundenanfragen (Tickets bzw. Fälle) zu handhaben. Als Anfragen werden eingehende Kundenanrufe, E-Mails, Faxe und ähnliches betrachtet.

Wichtigstes Feature hierbei ist der zentrale Anlaufpunkt für eingehende Anfragen; ein Kunde oder ein firmeninterner Mitarbeiter bei größeren Firmen weiß im Allgemeinen nicht, welche Einzelperson sein Anliegen am ehesten bearbeiten kann. Mit Hilfe eines Ticketsystems können die Anfragen kanalisiert den richtigen Personen im Unternehmen zugeleitet werden; außerdem speichert das System im Allgemeinen zu jeder Anfrage Historie und Eingaben aller Beteiligten. Es ist so wegen der durchgeführten “Visualisierung” von Arbeitsabläufen sehr einfach möglich, bestehende Strukturen zu prüfen und zu überarbeiten.

Wünschenswerte Features

In diesem Kapitel möchte ich Ihnen Features vorstellen, die ein einfacher gestricktes Ticketsystem mindestens besitzen sollte. Es muss sowohl für den Helpdesk-Mitarbeiter (“Agenten”) wie auch für den Anfragenden (“Kunden”) sehr einfach und übersichtlich zu bedienen sein.

Plattform

An den Rechner von Kunde und Agent dürfen keine großen Erwartungen gestellt werden, Betriebssystem und Benutzerrechte können beliebig breit gestreut sein. Es ist daher sicherzustellen, dass das System ohne Installation auskommt und auf möglichst vielen Plattformen läuft. Eine webbrowserbasierte Oberfläche für den Benutzer / Administrator erscheint zweckmäßig, auf der Serverseite sollte eine SQL-Datenbank die Speicherung der Inhalte übernehmen.

Die größte Entwicklergemeinde hat derzeit wahrscheinlich PHP, an Open-Source-Datenbanken erscheint MySQL mit seiner InnoDB-Storage-Engine sehr ausgereift und für die Zwecke optimal geeignet.

Benutzer-Schnittstelle

Wie eingangs bereits erwähnt, sollte die GUI für Agenten webbasiert sein und auf allen modernen Browsern ungefähr gleich aussehen, zumindest aber die gleichen Funktionalitäten anbieten. Kunden oder reguläre Mitarbeiter der Firma sollten sich per Mail an eine zentrale eMail-Adresse an den Helpdesk wenden können, es bietet für den Kunden drei Vorteile:

• Dokumentation: Im eMail-Ausgang des eMail-Programms des Kunden liegt die gesendete Mail zur Dokumentation und Nachvollziehbarkeit bereit.
• Spam-Bekämpfung: Mail-Filter zum Blockieren von unerwünschten Nachrichten sind relativ ausgereift; andere Schnittstellen wären gegen unerwünschte Kontaktaufnahme möglicherweise nicht so robust.
• Einfachheit: Der Kunde muss nicht die Bedienung einer neuen grafischen Oberfläche erlernen, sondern kann sein gewohntes eMail-Programm benutzen.

Das System wird deswegen ein oder mehrere eMail-Postfächer benötigen. Optimal wäre es, wenn einzelne Abteilungen jeweils auch eigene Adressen bzw. Postfächer eingerichtet bekommen könnten, sodass z.B. Mails an die Systemadministratoren an “sysadmin@domain.tld” und Fragen an Redakteure an “redaktion@domain.tld” geschickt werden können; trotzdem sollten beide Postfächer in einem System zusammen laufen, damit gegebenenfalls Anfragen aus anderen Bereichen bzw. Abteilungen innerhalb des selben Tickets beantwortet werden können, ohne dass erneut eMails versendet werden müssen.

Antworten an den Kunden sollten dann von der gewohnten Adresse (“sysadmin@” und “redaktion@”) abgeschickt werden können, wobei im Namensfeld (RFC2822) der Sachbearbeiter genannt werden kann, oder -sofern gewünscht- die Mail im Auftrag geschickt werden kann.

Automatische Antworten.

Für Kunden wäre es unter Umständen wünschenswert, über die Bearbeitungsschritte seines Tickets informiert zu werden. Zumindest aber der Erhalt der Anfrage sollte dem Kunden bestätigt werden; einen Statusübergang bei Rückfragen in andere Abteilungen oder 2nd-Level-Support kann für den Kunden Klarheit schaffen und Last vom 1st-Level-Support nehmen (“Was ist mit meiner Anfrage XYZ geschehen?”).

Standardantworten für Agenten

Für häufig wiederkehrende Anfragen sollten Agenten in der Lage sein, vordefinierte Texte möglicherweise mit Datei-Anhängen (z.b. Bedienungsanleitungen) auszuwählen und dem Kunden als Antwort zu schicken. Es läßt sich so Arbeitszeit einsparen. Die Standardantworten sollten selbstverständlich vor dem Absenden noch bearbeitet werden können.

Auch wäre es gut, für verschiedene Support-Levels jeweils gleiche Standardantworten definieren zu können bzw. Letztere in mehreren Queues anbieten zu können.

Status und Prioritäten

Selbstverständlich muss ein Ticket verschiedene Status (u-Deklination, deswegen lautet der Plural “Status” mit langem “u”) zulassen, die unterschiedlich zu visualisieren sind:

• Der erste Status eines Tickets wird wohl “offen” oder ähnlich sein, eben genau dann, wenn die Anfrage neu erstellt wurde. Zusätzlich kann, wie bei Mails üblich, noch ein Zusatzflag definiert werden, das das Vorhandensein neuer (=ungelesener) Texte innerhalb des Tickets anzeigt.
• Sofern nach Beantwortung eines Tickets die Schwierigkeit aus Sicht des Agenten gelöst ist, sollte das Ticket geschlossen werden. Es ist somit ein Status “geschlossen” zu definieren.
• Sollte der Kunde noch eine Antwort nachliefern müssen, könnte man, anstatt das Ticket zu schließen, einen Zwischenstatus (“warten”) definieren, welcher anders gekennzeichnet wird, damit der Agent weiß, dass hier auf eine Antwort vom Kunden gewartet wird.
• Zu guter Letzt muss ein Ticket auch gesperrt werden können, damit Agenten besonders bei mehreren Agenten pro Queue nicht zwei das gleiche Ticket bearbeiten. Gesperrte Tickets können außer vom “Sperrer” nur gelesen werden.

Jeder Agent sollte selbst aussuchen können, welche Status er bei Tickets sehen möchte. Der 1st-Level-Support etwa würde wohl nur die “offenen” Tickets sehen wollen; Mitarbeiter einer Fachabteilung aber haben möglicherweise so wenig Tickets, dass sie auch die geschlossenen aufgelistet bekommen möchten.

Eine wichtige Frage ist die der Prioritäten. Das vorliegende Ticketsystem verzichtet bewußt auf Prioritäten für Tickets, da:

• zu klären wäre, wer die Prioritäten setzen darf.
• sich das System von einem Bugtracker unterscheiden soll.
• es im Gegensatz zum Status keine handfesten Kriterien für die Einordnung in eine bestimmte Prioritätsstufe gibt.
• Möglicherweise vom Datum her “hinten liegende” oder neuere Tickets mit ähnlichem Inhalt eine höhere Priorität bekommen müßten. Mit anderen Worten: Um die Priorität richtig zuweisen zu können, müßten immer alle neuen offenen Tickets inhaltlich durchsucht werden.
• Die Anzahl von Stufen wohl nicht ganz klar sein würde. Sind es 3 (eMail) oder 5 (OTRS Standard)?

Es erscheint mir daher zweckmäßig, von Anfang an auf Prioritäten zu verzichten.

Persönliche Queues

Im Konkurrenzprodukt OTRS kann jedem Agenten ein Ticket zugewiesen werden; die Bearbeitung ist dann nur noch durch diesen Mitarbeiter möglich. Die Tickets bleiben aber in der entsprechenden Queue liegen. Ich finde das unübersichtlich und verfolge den Ansatz, dass auch Agenten eine eigene persönliche Queue haben können; prinzipiell unterscheidet sich diese nicht von anderen Queues, kann aber nur von dem einen Agenten bearbeitet werden.

Persönliche Queues sollten per Standard grundsätzlich flach im Queue-Baum liegen; jeder Agent kann aus Gründen der Übersicht aber einzelne persönliche Queues ausblenden. Es werden also nur die persönlichen Queues der engeren “Mit-Agenten” oder bekannter Mitarbeiter aus anderen Abteilungen angezeigt statt alle Mitarbeiter des Systems.

Anbindung für Kundendaten

Eine sehr wichtige Frage ist die der Integration von Kunden der Firma. Es gilt folgende Fragen zu klären:

• Sollten Kunden eine Oberfläche bekommen mit allen ihren bisherigen Anfragen?
• Wie würden sie sich registrieren?
• Können / Sollen / Dürfen wir als Firma Daten aus dem CRM importieren oder Anfragen in dieses überspielen?
• Was geschieht bei unvollständigen Kundendaten oder nicht im CRM vorhandenen Fragestellern?

Nach viel Diskussion in größeren Runden und Gesprächen mit Firmen, die bereits solche Lösungen einsetzen, erscheint es sinnvoll, auf eine Anbindung an einen Firmen-LDAP-Server oder das CRM zu verzichten. Einerseits sind rechtliche Fragen zum Datenschutz nicht einfach zu beantworten, wenn Daten ohne Einwilligung in mehrere Systeme überspielt werden sollen. Andererseits besteht immer die Schwierigkeit der Verfügbarkeit, wenn das angebundene System ausgefallen ist und z.B. Kundendaten nicht gelesen werden können.

Es sollte daher von vorneherein möglichst auf eine saubere Implementierung mit unbekannten Kundendaten (Name, Vorname, usw.) geachtet werden; optional könnte versucht werden, aus dem Mailtext bestimmte Informationen zu extrahieren.

Das System an sich sollte aber Stand-Alone laufen können, da im Zweifelsfalle genau ein angebundenes System das ist, das ausgefallen ist und für das die Support-Anfrage gilt.

Bemerkungen zur Oberfläche

Die Benutzeroberfläche muss sehr einfach und intuitiv bedienbar sein. Insbesondere 2nd- und 3rd-Level Support hat möglicherweise nicht die Erfahrung oder Zeit, Fehler und Imperformanzen des Systems durch manuelle Arbeit auszugleichen.

Es empfiehlt sich daher, sich möglichst an “Industriestandards” zu orientieren. Einen guten Ansatz dafür bietet die Oberfläche von Outlook, sie ist mit der gut verständlichen Anordnung der einzelnen Bereiche (Ordner, Ordnerinhalt, Mailtext) und ihrer Symbolik auch für Laien gut verständlich.

Weiters sollte die Oberfläche ein optisches Feedbeck bieten, sofern der Benutzer eine Aktion auslöst oder mit der Maus über Bedienelemente fährt.

Besonderes Augenmerk ist auf die Mailfunktionen zu legen. Insbesondere müssen:

• Verschiedene Zeichensätze (Unicode, ISO9660, Latin, usw.) einwandfrei erkannt werden.
• HTML-Mails als solche erkennbar, in Nur-Text umgewandelt und mit entsprechenden Anhängen versehen werden.
• Anhänge korrekt dekodiert und mit richtigen Dateinamen versehen werden.
• bei Antworten die Benutzer unbedingt zur Vermeidung von TOFU animiert werden.
• mehrere unterschiedliche Bildschirmauflösungen und Webbrowser unterstützt werden.

Wie erst heute auf Heise Online zu lesen ist, hat der Bundesgrichtshof (BGH) bereits Ende März einen äußerst fragwürdigen Beschluß in Bezug auf die providerseitig gelagerten eMails ausgesprochen (PDF, AZ “1 StR 76/09″).

Zusammengefaßt läßt sich schreiben, der BGH mißt eMails in Providerpostfächern keine relevante Bedeutung bei, der 1. Strafsenat erkennt keinen “Telekommunikationsvorgang” beim Speichern der Mails in DV-Systemen. Das bedeutet, dass Strafverfolgungsbehörden nun relativ einfach an providerseitige eMails gelangen können; zwar ist nach wie vor ein Richtervorbehalt (lach!) gegeben, der Richter hat nun aber die Möglichkeit, nach §99 (Beschlagnahmung von Post-Sendungen) zu begründen und muss nicht mehr §98 (insbesondere Buchstabe b) oder §100 der Strafprozessordnung (StPO) heranziehen, die beide wesentlich strengere Auflagen erfordern.

Ziel dieses Dokuments

Nachdem es mit dem Verschlüsseln von eMails noch immer an allen Ecken und Enden hapert und Letzteres nur innerhalb von Organisationen bei entsprechend guten Administratoren und Prozessen (PKI, Zertifikatsverwaltung, etc.) einigermaßen akzeptabel funktioniert, möchte ich im Folgenden ein Systemkonzept vorstellen, mit dem auch Privatleute ihre eMails besser vor ungerechtfertigten Zugriffen schützen können.

Das Konzept ist mehrfach im Einsatz und hat sich bereits jahrelang bewährt. Ich möchte Ihnen im Folgenden die einzelnen Bestandteile erklären; detaillierte Erklärungen und Installationsanleitungen folgen, sobald ich Zeit habe. Sie sollten von Internettechniken und Betriebssystemen etwas Ahnung haben.

Gesamtkonzept

Die Lösung basiert auf der simplen Annahme, dass Ihre Mails bei irgendeinem Provider (auch ausländischen!) im Internet nicht mehr sicher sind. Staatliche Stellen bekommen, wie oben aufgezeigt, leicht Zugriff, und gegen Hacker-Angriffe (Phishing, Man-In-The-Middle, usw.) haben Sie noch weniger Chancen; allen Beteuerungen und Produkten (“Sicherheitspakete”) zum Trotz.

Die Lösung ist nun, die Mails bei Ihnen zuhause in Ihrer eigenen Wohnung zu speichern und einen Provider gar nicht mehr in den Genuß Ihrer Mails kommen zu lassen. Was er nicht hat, kann er nicht herausgeben. Und die Mails dann von Ihrem eigenen Rechner abzuziehen, wird einerseits gar nicht so einfach werden und kommt andererseits rechtlich einer Hausdurchsuchung gleich.

Liste der Komponenten

1. DSL mit 24/7 Flatrate bei einem beliebigen Provider
2. Eigene Internetdomain (“www.meinname.de”), am besten bei einem persönlich bekannten Provider
3. Rechner, der 24/7 eingeschaltet ist (kann ein Nettop sein), “Server”
4. Sehr gute Firewall/Router
5. Registrierter Name bei DynDNS oder einem vergleichbaren Provider

Funktionsweise

Mailsystem mit Speicherung beim Provider

Normalerweise würde der Provider Ihrer Domain Ihnen auch einige, z.B. 10, eMail-Postfächer zur Verfügung stellen. Wenn eine Mail für Ihre Domäne ankommt (“ich@ich.de”), so speichert der Provider die Mail zwischen und wartet darauf, dass Sie sie abholen.

Hier setzen wir an: Die Mail wird am Provider vorbeigeleitet, direkt zu Ihnen nach Hause auf Ihren heimischen Rechner. Zwar könnte der Administrator Ihres DSL die Mail unter Umständen mitlesen, aber ein Richter kann nicht mehr, wie oben, nach Postbeschlagnahmung argumentieren. Und das ist ja die Hauptsache.

Der Trick ist ganz einfach. Um die Mail direkt zu Ihnen zu leiten, muss Ihr Domain-Provider den MX-Record (Mail-Exchanger) auf Ihren DynDNS-Hostnamen (eben nicht die IP-Adresse, welche sich im Allgemeinen alle 24h Stunden ändert) setzen.

Mailsystem mit eigener Speicherung

Schreibt Ihnen nun jemand eine Mail, so löst das Mailsystem Ihre Domain auf, findet den MX-Record, der auf “ihrhost.dyndns.org” zeigt, löst die IP-Adresse auf Ihre aktuelle IP-Adresse auf und sendet Ihrem Rechner direkt die Mail. Kein Provider involviert.

Und beim Versenden? Normalerweise bekommen Sie von Ihrem Domain-Provider noch einen sogeannten “smarthost” zur Verfügung gestellt. Das ist einfach ein Mailversandrechner, an dem Sie sich mit Ihren Zugangdaten anmelden und dann beliebig Mails verschicken dürfen. Der smarthost kann im Allgemeinen verschlüsselt erreicht werden (“STARTTLS” Mailkommando) und speichert keine Mails. Der “Versendet” Ordner befindet sich ausschließlich auf Ihrem Server zuhause.