Lichtsteuerung Teil 2: Software

Nachdem der letzte Eintrag nur ein paar Hardwaredinge beleuchtet hat, geht es jetzt um die Software, genaugenommen das Webinterface und ein paar Zusatzskripte.
Die Dateien liegen wie alles andere im dorfmap repository und einige Helfer in dorfmap-deb.

Weboberfläche

dorfmap ist Perlcode mit Mojolicious. Zeigt im Browser einen Grundriss des Chaosdorf an und verteilt darauf Symbole für Lampen, Drucker, Türstatus und weitere potentiell interessante Dinge. Die Koordinaten der Geräte sind als Pixel-Offsets (ja, eigentlich möchte man relative Angaben benutzen ;-) ) zusammen mit Steuerungsfoo in einer coordinates-Datei angegeben.

Status anzeigen

Ausgelesen wird entweder direkt aus dem GPIO-Pin (per /sys/class/gpio) oder Caches für die Schieberegister in /tmp. Einige Sonderfälle (z.B. Hosts, die nicht steuerbar sind) werden von einem separaten Skript alle zwei Minuten überprüft und zwischengespeichert.

Status ändern

Per Default wird getoggelt, d.h. ein Klick auf eine eingeschaltete Lampe schaltet sie aus und ein Klick auf eine ausgeschaltete Lampe schaltet sie ein. Einzige Ausnahme ist bei uns die Außenbeleuchtung, die anhand der Tageszeit automatisch gesteuert wird, so dass die dorfmap nur die Automatik ein- bzw. ausschaltet.

API

Ist auch vorhanden, in JSON und plaintext. Dazu bietet sich die
Dokumentation im Wiki an.

Das Webinterface ist inzwischen recht umfangreich, aber einigermaßen portabel. Angepasst werden müssen in erster Linie der Grundriss und die coordinates-Datei, und im Falle von Schieberegistern / anderen Konstruktionen, die nicht direkt auf GPIO-Pins zugreifen, noch die system-Aufrufe in index.pl (avrshift-donationprint etc.)

Lichtsteuerung

Im Chaosdorf ist seit zwei Wochen eine Lichtsteuerung fest installiert. Dieser Artikel soll zeigen, dass so etwas selbst zu bauen deutlich einfacher ist, als man sich anfangs vorstellt, und noch nichtmal nennenswerte Geldmengen benötigt.

Grundsätzlich gibt es nur drei Voraussetzungen:

  • Eine Möglichkeit, Ausgänge digital zu schalten
  • 230V-Relais vor den zu schaltenden Verbrauchern
  • Keine Angst vor Netzspannung

In unserem Fall sind diverse Raspberry Pies schon für andere Zwecke im Raum vorhanden, so dass wir einfach ein paar GPIO-Pins für Lichtsteuerungszwecke benutzen können. Wer keinen Raspberry Pi zur Hand hat, kann genau so gut eine r0ket, einen Arduino oder beliebiges anderes AVR- / ARM-Gefrickel benutzen. Solange man irgendwie Daten reinkippen und digitale Ausgänge rauskriegen kann, ist alles möglich.

Da ein Raspberry Pi nur 3.3V und sehr geringe Ströme schalten kann und keinen Schutz gegen Kurzschluss oder Überspannung besitzt, sind die GPIO-Pins nur mit Optokopplern verbunden. Diese sorgen für eine galvanische Trennung von der 12V-Schaltspannung, so dass Verdrahtungsfehler schlimmstenfalls ein paar Transistoren oder AVRs töten, und nicht die deutlich teureren Raspberry Pies.

In der ersten Version hat jeder GPIO-Pin genau einen Verbraucher gesteuert, d.h. jeder Pin führt zu einem Optokoppler, der seinerseits 12V und einen Transistor (bis 700mA Schaltstrom) kontrolliert. An diese 12V kann man dann entweder ein Relais oder direkt einen Kleinverbraucher (LEDs etc.) hängen. Die Schaltung ist extrem simpel und funktioniert entsprechend gut, hat aber den Nachteil, dass man die verfügbaren GPIO-Pins (Pro Gerät 12 Stück ohne Sonderfunktionen und 9 mit) irgendwann alle belegt hat, und nicht 30€ für einen weiteren Raspberry Pi ausgeben möchte, nur um 12 weitere Verbraucher zu schalten.

Der einfachste Ansatz, um mehr Verbraucher steuern zu können, ist ein Schieberegister — Es braucht 4 Dateneingänge und kann damit (da Schieberegister auch einen seriellen Ausgang haben und dadurch verkettbar sind) beliebig viele Ausgänge schalten. Alternativ nimmt man sich einen kleinen AVR (z.B. ATTiny2313) zur Hand und implementiert ein Schieberegister in Software, das nur noch zwei Eingänge (einmal Daten, einmal Takt, und eine spezielle Daten+Takt-Kombination um die eingegebenen Daten auf die Ausgänge zu übernehmen) braucht. Das Protokoll ist sehr an I2C angelehnt und sowohl im AVR als auch auf dem Raspberry Pi sehr leicht zu implementieren. Vorteil beider Varianten ist, dass man die Optokoppler schon vor dem Schieberegister anbringen kann, so dass man nur noch zwei bzw. vier Stück braucht. AVRs und Schieberegister sind dank DIP-Sockeln schnell austauschbar, falls mal etwas schiefgeht.

Mit einem dieser Ansätze hat man nun 12V, die meisten Lampen, Drucker und sonstige Geräte bevorzugen aber 230V. Was noch fehlt, ist also ein Kabel von der Schalthardware zum Verbraucher, und dort ein 230V-Relais mit ausreichender Schaltleistung. Falls das Relais auf eine geätzte Platine gelötet ist, ist dabei der Sicherheitsabstand zwischen einzelnen 230V-Leiterbahnen und v.a. auch zwischen 230V- und 12V-Bahnen zu beachten (5mm sind empfehlenswert), im Falle einer Loch- oder Streifenrasterplatine sollten unbedingt die Kupferflächen zwischen Leiterbahnen mit einem Messer abgeschabt werden. An die 12V-Seite kommt ein langes Kabel und parallel dazu eine Diode in Sperr-Richtung (um die Spannungsstöße, die die Relaisspule beim ausschalten produzieren kann, abzufangen), auf die 230V-Seite eine einfache Schraubklemme. Bei fest installierten Verbrauchern reicht es, die Phase zu schalten, Erde und Nullleiter können permanent verbunden sein. Die ganze Konstruktion kommt dann in eine Aufputz-Verteilerdose, wird irgendwo festgeschraubt und fertig.

Die Materialkosten halten sich erstaunlich gering:

  • 30€ für einen Raspberry Pi
  • Erste Version: <1€ pro Verbraucher für die Steuerschaltung (Platine, Optokoppler, Transistor, Anschlussklemme)
  • Mit Schieberegister: <6€ pro 12 Verbraucher (Platine, 2 Optokoppler, ATTiny2313, Transistoren, Widerstände, Anschlussklemmen)
  • Ca. 5€ pro Verbraucher für Kabel, Relais und Verteilerdose

Ein paar Fotos und Schaltpläne finden sich in der Gallerie, die Steuersoftware bekommt später einen eigenen Blogpost.

Dashboard, Dashboard an der Wand

Ein datenreiches Monitoringsystem auf Basis von Pixelbildschirmen: Eine der schönen, greifbaren Ideen die uns seit Star Trek durch den Kopf geht. Mit einem Blick auf die Wand bekommt der Betrachter Auskunft über die aktuelle Situation. Also die Datenleitungen, Ressourcenverbrauch und alles, was wir zu Betreiben eines Hackspaces wissen wollen.

Dort sollten Informationen in Zahlenwerten und im zeitlichen Verlauf als Graphen angezeigt werden. Üblichwerweise handelt es sich hier um Informationen wie Auslastung der Rechner und Zugriffsstatistiken für Dienste. So lassen sich hiermit alle möglichen Informationen speichern; eben alles, was sich messen lässt. Wir schlagen hiermit die Brücke zwischen den beiden Trends “Big Data” und Automation.

Dashboard

Das können wir auch im Kleinen probieren. So haben wir erst einmal einen Dienst zum Sammeln der Daten aufgesetzt. Das Projekt Graphite ist eine Freie Software, die auf einem virtuellen Server im Chaosdorf läuft. Über ein simples Protokoll nimmt der – in Python realisierte – Dienst Messwerte an und speichert sie in einer speziellen Datenbank.

Dort werden die Messwerte chronologisch gespeichert und langfristig in immer gröberen Zeitschritten archiviert. Damit ist es möglich, sekundengenaue Auskunft über die vergangenen Tage zu erhalten und länger zurückliegende Daten in Minuten zusammenzufassen, um die Größe der Datenmenge zu begrenzen.

Graphite gibt die Daten in frei konfigurierbaren Graphen als Pixelgrafik (PNG) gerendert oder in maschinenlesbarer Form als JSON-Datei aus. Letzteres verwendet unsere Rauminstallation, die mittels der freien Web-Anwendung Team Dashboard realisiert wurde. Auch diese haben wir nicht selbst entwickelt, da wir uns gerade erst mit deren hochaktueller Technologie auseinandersetzen.

Team Dashboard bezieht die Daten und zeichnet Graphen direkt im Browser als Vektorgrafik (SVG). Dazu nutzt es einen HTML5-Canvas und die Bibliothek D3. Somit erscheinen die Graphen hochauflösend und sind auf dem Endgerät skalierbar. Da das Dashboard auf jedem Rechner im Chaosdorf angezeigt werden kann, sicherlich von Vorteil.

Zudem können ohne weitere Konfiguration am Server beliebig viele verschiedene Messreihen gespeichert werden. Von überall im lokalen Netzwerk werden Daten angenommen und gespeichert. Auf dem Dashboard können sie dann aufgearbeitet angezeigt werden. So entsteht kollaborativ eine Übersicht über die in den verschiedenen Projekten angefallenen Daten.

Derzeit werden folgende Informationen dargestellt – weitere Anzeigen sind geplant.

  • Internet-Traffic stromauf- und abwärts (Graph)
  • Anzahl der Endgeräte im Netzwerk (Zahl)
  • Uplink-Traffic unserer Freifunk-Node stromauf- und abwärts (Graph)
  • Anzahl der Freifunk-Nodes in der Düsseldorfer Community (Zahl)
  • Temperatur der Luft im Hackcenter (Graph/Zahl)
  • Öffnungs-Status der Chaosdoor, unserer Eingangstür (Graph/Zahl)
  • Verbleibende Überbrückungszeit der unterbrechungsfreien Stromversorgung (Graph)
  • Systemauslastung unseres Servers Hyperion (Graph)

DashPi

Die Rauminstallation besteht aus einem kleinen Rechner (Raspberry Pi), an den ein Bildschirm angeschlossen ist und der die Web-Anwendung darstellt. Dazu bootet er ein minimales Betriebssystem (Arch Linux) und startet ein Fenstersystem (awesome), auf dem im Vollbild der Web-Browser (luakit) angezeigt wird.

Der Rechner verfügt über eine GPIO-Stiftleiste, die programmierbar ist. An diese haben wir einen Temperatursensor per I2C-Protokoll angeschlossen. Dieser misst die Raumtemperatur mit einer Auflösung von 0,06 °C.

Die Daten werden sekündlich mit einem eigens entwickelten Werkzeug ausgelesen und übers Netzwerk übertragen. Auf dem Server empfängt StatsD die Daten per UDP und versieht sie mit einem Zeitstempel, bevor er sie alle zehn Sekunden gesammelt an Graphite weitergibt.

Daten per UDP ohne Zeitstempel übermitteln zu können, bedeutet für uns eine weitere Möglichkeit. Mikrokontroller mit minimaler Ausstattung können so Daten sammeln und verfügbar machen. Wir planen derzeit, den Temperatursensor neben anderen Sensoren auf einem eigenen Endgerät unterzubringen, das auf einer 8-Bit-Mikroarchitektur basiert.

Bis dahin sind wir noch damit beschäftigt, weitere sinnreiche Graphen zu spezifizieren. Dazu stellt Graphite Funktionen bereit, mit denen zeitliche Ableitungen, Skalierungen und andere Manipulationen möglich werden. Am Ende trauen wir eben keiner Satistik, die wir nicht selber gefälscht haben.