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.)
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.
Da in einem großen Clubraum immer viel Zeug rumliegt, und man nie genau weiß, was wem gehört, wie zu benutzen ist oder auch nur wo es gelagert wird, ist es für einen Hackspace sehr empfehlenswert, möglichst alles zu labeln.
Anfangs benutzten wir dazu kariert.org aus dem Metalab. Alles doppelt einzugeben (einmal ins Wiki und nochmal fürs Label) ist aber doof, und da wir eh schon leicht parsebare Properties und Templates im Wiki haben, bietet es sich an, daraus irgendwie Labels zu generieren.
Benutzt wird dazu Ruby mit den gems media_wiki, prawn (PDF-Generator) und mongrel (CGI-Foo). Das Skript ist als normale Website erreichbar, nimmt als Argument den Namen einer Wikiseite und generiert ein PDF der entsprechenden Propertywerte.
Der theoretische Ablauf ist jetzt:
Buch oder Ressource im Wiki eintragen
Dabei auch die von kariert.org übernommenen Properties (ownership, usage conditions, location) ausfüllen
Auf PDF-Link klicken
ausdrucken und aufkleben
Der PDF-Link wird direkt nach Anlegen einer passenden Seite im Wiki angezeigt. Einziges Problem: Man kann nicht aus Semantic Forms (die Eingabeformulare für z.B. Auswahl von Club-Eigentum vs. Leihgabe vs. Privatfoo) auf die dort eingegebenen Daten zugreifen, d.h. man muss erst eine Seite anlegen, dann das Label ausdrucken und die Seite nochmal editieren, um anzugeben, dass der Gegenstand gelabelt wurde.
An den Texten im Label wird auch noch gearbeitet.
Alternative Lösungen wären eine Spezialseite für Labelfoo (d.h. nach Wikiedit ein Label zu drucken ist etwas aufwändiger), oder automatische Wiki-Edits beim Generieren des Labels (geht schief, falls jemand generiert aber nicht mehr zum drucken kommt). Mal schauen, was sich am Ende durchsetzt.
