Knöpfchenspiel 1 - Systemübersicht

Heute beschreibe ich das Knöpfchenspiel. Wie bereits im Podcast erzählt, ist das primäre Ziel das Spiel bis April fertig zu bekommen. Daher gibt es bereits einige fertige Komponenten.

Das originale Knöpfchenspiel steht meistens in Spielhallen und kann dort gegen Geldeinwurf gespielt werden. Dazu müssen die leuchtenden Knöpfe gedrückt werden. Jeder Knopfdruck gibt einen Punkt. Wenn ein nicht leuchtender Knopf gedrückt wird, wird ein Punkt abgezogen. Das sieht dann so aus:

Das von mir geplante System ist ähnlich aufgebaut. Nur dass die Spieler nicht gegenüber, sondern nebeneinander spielen und dass die Punkteanzahl an einem großen Fernseher dargestellt wird und nicht auf einer 7-Segementanzeige. Dazu wird das System in mehrere Submodule aufgeteilt.

• System-Controller (Raspberry-Pi)

• Bus-Interface (Differenzieller I²C Bus Treiber)

• Knöpfchen-Controller (STM32F030)

• Knöpfchen

• LED-Band-Controller

• Power Supply

System-Controller

Der Raspberry Pi übernimmt die Steuerung des Spiels und die Anzeige der Punkte am Bildschirm. Dazu wird das HDMI Interface in maximaler Auflösung (1920x1080) betrieben. Weiterhin hängt am Pi noch eine Webcam (USB) mit der die Spieler für die High-score Liste fotografiert werden.
Auf dem Raspberry steckt die DIIC Baugruppe. Das Bus-Interface Board
Bus-Interface

Bus-Interface

Um einen stabilen I2C Bus über alle Baugruppen zu bekommen, habe ich mich für einen Differenziellen Bustreiber entschieden. Dieser ist in der Lage die Eindraht-Signale der I2C Strecke auf zwei differenzielle Signale aufzuteilen. Diese sind wesentlich unempfindlicher gegenüber elektromagnetischer Störung. Das Bus-Interface Board besitzt die nötigen Stecker für den Knöpfchenspiel Bus, ein RJ45 Stecker, der über normale LAN-Kabel miteinander verbunden werden kann.

Knöpfchen

Das Knöpfchen ist ein 60mm durchmessender Plastik Druckknopf (Schließer), der von hinten beleuchtbar ist. Die Beleuchtung wird von einer weißen LED übernommen.

Knöpfchen Controller

Die 16 Knöpfchen sind an dem Knöpfchen-Controller angeschlossen. Der Controller ließt den Schaltzustand der Knöpfchen ein und vergleicht ihn mit den Lampen. Wenn die Lampe an war, wird der Punktestand um eins erhöht, wenn die Lampe aus war, wird der Punktestand reduziert, bis er bei 0 angekommen ist.
Auf dem Knöpfchen-Controller Board ist ein DC/DC Wandler, der die 12V Bus-Spannung auf 5V herab setzt. Die 5V werden dann mit einem linear Regler auf 3,3V für den Controller heruntergesetzt. Die Knöpfchen und Lampen in den Knöpfchen können mit 12V, 5V, oder 3,3V versorgt werden.
Der Controller besitzt ein I2C Slave-Interface, dass die Spielinformationen an den Spiel-Controller übertragen kann.

LED-Band-Controller

Um das Spiel von Außen attraktiver zu gestalten, habe ich vor eine LED-Leiste an der Kante anzubringen, ähnlich wie bei der oben gezeigten Variante. Dafür habe ich WS2812 LEDs als Leitungsband vorgesehen. Gesteuert werden die LEDs von einem eigenen Controller. Wahrscheinlich der Arduino Nano, den ich schon für die Bühnenkulisse verwendet habe. Den kann man über die USB -> UART Brücke auf dem Arduino vom Raspberry Pi ansprechen.
Für das System werden zwei AC/DC Netzteile eingesetzt. Ein 5V und ein 12V Netzteil. Das 5V Netzteil ist für die Versorgung des Raspberry Pis und LED-Band vorgesehen. Das 12V Netzteil übernimmt die Versorgung des Bus-Systems, Knöpfchen-Controller Boards und der Knöpfchen. Beide werden über den gleichen Kaltgeräte-Stecker angeschlossen und abgesichert.

Neuauflage von Herbert mit einem neuen Automatisierung Controller

Eine weitere Neuauflage von Herbert mit einem neune Automatisierung Controller. Die Hardware ist gleich geblieben, geändert hat sich die Software. Ein Raspberry Pi3 mit dem originalen 7" PCAP Display sind das Gehirn. Die Steuerung übernimmt Home Assistant. Die Software ist diesmal nicht auf Basis von Java geschrieben, sondern basiert auf Python 3. Die Konfiguration passiert mit Hilfe von Textdateien im YAML-Format. Home Assistant kommt anders als davor PiDome nicht mit einer grafischen Benutzeroberfläche, sondern HTML5. Chromium im Kiosk-Modus ist die Anzeige Plattform.

Teilausschnitt der neuen Herbert Oberfläche

Mit Python als Sprache für den Controller kann ich jetzt auch selbst Änderungen an der Software vornehmen ohne mir Java antun zu müssen. Mein D-Link Smart Plug hat keine Unterstützung für die Anzeige des aktuellen Energieverbrauchs wenn es als Schalter eingebunden ist. Mit einigen Änderung konnte ich den aktuellen Verbrauch als Sensor anlegen. Jetzt habe ich zwar den Sensor, aber die Schaltfunktion ist wieder weg. Ups.

Die Sonoff Schalter, die die Lichter ein und ausschalten sind jetzt mit einer Firmware geflashet, die auf der Arbeit von Tinkerman basiert. Die von ihm geschriebene ESPurna Software lässt sich mit platform.io erzeugen. Ein paar kleine Änderungen habe ich dennoch eingebaut. Der Schaltzustand ist beim Einschalten der Stromversorgung "An" und nach Verbindung mit der MQTT Server wird er alte Schaltzustand wieder hergestellt. So kann man bei einem Ausfall die Lichter alle wieder einschalten. Das ist mir nämlich passiert, als ich aus versehen ein nicht funktionierendes Firmware-Update auf alle Geräte gepusht habe. Ups.

Jetzt fehlt eigentlich nur noch die Funktion das Display auf Nachtmodus zu stellen, denn der neue, weiße Hintergrund ist nachts ziemlich hell.

Das Thermometer ist mit einer eigenne Firmware bestückt. Allerdings zeigt es in der Letzten Zeit immer mal wieder 100% Luftfeuchte. Wir sind doch nicht in den Tropen. Vielleicht sollte ich den Sensor Regen geschützt anbringen. Ups.

Herbert Update

Es geht weiter mit meinem kleinen Hausautomation-System Herbert. Es sind im Moment einige 220V Schalter eingebunden und einige Szenen festgelegt. Die Schalter sind hauptsächlich für Lichter verwendet. Im Arbeitszimmer habe ich die 3D Drucker und den PC angeschlossen. Uhrzeit kommt vom Raspberry Pi, der auch das Display betreibt. Das Wetter kommt von der OpenWeatherMap

Die Sonoff Geräte mit einer bearbeiteten Firmware sind die Schalter für die Netzspannung. Ich habe mich für die Hardware entschieden, da sie bereits ein Netzteil mitbringt und daher komplett autark vor die Lampe, oder in die Stromleitung angeschlossen werden kann. Zu empfehlen ist das allerdings nur bei Geräten der Schutzklasse II, also solche, die mit einem Flachen Eurostecker bedient werden. Die Sonoff-Schaltung hat keine Anschlüsse für den Schutzleiter!

Für Geräte mit Schutzleiter (alles was berührbare leitende Flächen hat) muss der Schutzleiter separat um den Schalter geführt werden.

Was ich als nächstes gerne machen möchte ist ein kleineres Gerät mit Display und Touchscreen bauen, dass über WLAN mit dem PiDome Server von Herbert sprechen kann und so etwas ähnliches wie die Hauptkonsole darstellen kann.

Herbert Mk3: An der Wand

Das neue und offizielle Raspberry Pi Touchscreen mit DSI Anbindung und kapazitivem Touch ist endlich auch für mich lieferbar gewesen. Nachdem ich fast einen Monat darauf gewartet habe kann ich die Schaltzentrale für meine Wohnung jetzt endlich an den Nagel hängen...

Raspberry Pi 7" TFT Gehäuse: Modell

Mit einem eigenenen 3D-gedruckten Gehäuse hängt der Raspberry Pi 2 mit Display jetzt im Flur. Mit an Board ist ein BLE Dongle, zwei WLAN Sticks und ein 64GByte Massenspeicher. Auf dem System läuft ein Raspbian mit LXDE und Iceweasel Browser als Frontend und openhab, mogodb, mosquitto, HerbertScanner und HerbertNode im Backend.

Openhab mit mosquitto habe ich ja bereits in älteren Posts bereits erwähnt und mongodb als Datenbank ist auch keine Besonderheit. Die zwei interessanten Softwarekomponenten sind HerbertScanner und HerbertNode.

HerbertScanner ist eine Applikation, die mit dem BLED112 von BlueGiga kommuniziert und die Advertisement Pakete der BLE Buttons im Umkreis registriert. Ein Advertisement Paket im richtigen Format wird an mosquitto, also als MQTT Nachricht weitergeleitet. So werden Daten von BLE Endpunkten a die openhab Zentrale geleitet.
Die Konfiguration der BLE Geräte muss zur Zeit manuell durchgeführt werden. Dazu muss der MQTT Kanal '/Herbert/#' abonniert werden.  Dort werden alle Nachrichten abgeliefert. Neue Geräte erscheinen da dann auch und können mit der ID registriert werden.

HerbertNode ist eine Applikation, die für das Konfigurieren der WLAN Endpunkte eingesetzt wird. HerbertNode scannt die WLAN Netzwerke in der Umgebung und findet die Accesspunkte von ESP2866 Geräten. Diese starten, wenn sie keine Konfiguration besitzen, oder das konfigurierte Netzwerk nach 30 Sekunden nicht gefunden wurde in den Accesspoint Modus. Sobald HerbertNode eine ESP2866 SSID sieht, verbindet er sich mit dem AccessPoint und stellt eine HTTP Anfrage nach '/info'. Das Gerät gibt dann Informationen über sich im JSON-Format an HerbertNode weiter. HerbertNode hat eine Liste der verfügbaren Geräte im Umkreis. Vom Benutzer kann in dieser Liste das Gerät ausgewählt und dem Netzwerk hinzugefügt werden, dazu wird dem Gerät die SSID und der Zugangsschlüssel für das Herbert-WLAN übertragen.

Der Code wird im Laufe der nächsten Wochen noch verfeinert und stabilisiert. Es treten teilweise noch Fehler auf, die noch behoben werden müssen, bevor Herbert zum ersten mal veröffentlicht wird.

ESP8266 - 2: Temperatur mit dem ESP8266 und DHT11

Das Hausautomationsteam in meiner Wohnung hat einen neuen Teamkollegen bekommen. Ein Tempertatur und Luftfeuchte Sensor. Der Sensor basiert auf einer kleinen Schaltung mit dem DHT11 Sensormodul und einem ESP-01 Board. Daran angeschlossen befinden sich zwei AA Akkus.

ESP-01 Modul mit DHT11 Sensor und 2 AA-Akkus

Die Software im ESP2866 wurde diesesmal nicht mit LUA und NodeMCU, sondern mit dem von ESP verfügbaren SDK erstellt. Ich habe dafür die Bibliothek für den DHT Sensor und den MQTT Client verwendet. Diese beiden Bibliotheken sind frei verfügbar und könne hier heruntergeladen werden.

Das System basiert immernoch auf einem MQTT Broker als zentraler Kommunikationshub. Die Sensoren besitzen alle eine eindutige Chip Indentifikationsnummer. Diese, kombiniert mit dem Systemnamen, bilden die Topics, auf denen die Sensoren Daten für das System bereit stellen. Eine Konfiguration des Sensors bei Inbetriebnahme ist auch in Arbeit. Dazu lauscht der Hauptknoten (Webserver, MQTT broker, Festplatte, usw.) auf WLAN Accesspoints die mit dem Namen ESP beginnen. Diese werden in einer bestimmten Liste angezeigt und können vom Hauptknoten angesprochen werden. Dabei verbindet sich der Knoten mit dem Sensor und überträgt die Daten, die für das eigentliche Netzwerk verwendet werden. Diese Kommunikation muss verschlüsselt stattfinden, daher wird auf die AES-Bibliothek des ESP2866 zurück gegriffen. Mit den Daten kann der Sensor sich dann am lokalen WLAN anmelden und seine Daten dem MQTT Broker zur Verfügung stellen.

Code für den Sensor gibt es hier. Eingestellt wird das ganze über die user_config.h
Der Code wacht auf, verbindet sich mit dem MQTT Broker (Herbert) und sendet seine Messwerte. Danach begibt er sich wieder in den Tiefschlaf. Es sind sicherlich noch Optimierungen möglich, so ist es mit einem unmodifizierten ESP-01 Modul nicht möglich aus dem Tiefschlaf wieder aufzuwachen.

Werte in Openhab auf Herbert

Herbert Reloaded: Haus Automation

Mein Projekt, die Wohnung komplett über ein Automationsbus zu steuern, geht langsam voran. Aber warum noch ein Haus Automations Bus? Weil die bereits verfügbaren nicht genau dem entsprechen, was ich gerne hätte. Einige sind auf eine dauerhafte Verbindung ins Internet angewiesen, andere sind zu teuer, oder nicht vollständig. Oder benötigen Datenleitungen zu den Knotenpunkten.

Herbert wird einmal die Wohnung steuern und dafür werde ich existierende Hardware umbauen, oder eigene Hardware entwerfen, die genau die Aufgaben erfüllt, die ich mir von einem Hausbus wünsche. Der Aufbau wird folgende Topologie besitzen:

Herbert Topologie V2.0

Das Zentrum von Herbert ist ein Raspberry Pi 2, der in einem externen Festplattengehäuse untergebracht ist. Die externe Festplatte ist immer noch in dem Gehäuse und wird die Speicherzentrale für das NAS. Der Pi hat leider nur langsames USB 2.0. Da das WLAN und die Festplatte über USB angeschlossen sind werden keine neune Geschwindigkeitsrekorde aufgestellt werden können. Für regelmäßige Backups ist es allerdings schnell genug.

Herbert 2.0

Neben dem NAS besitzt Herbert ein openHAB Interface. openHAB ist ein offenes Haus Automation System, dass in Java entwickelt wurde, dadurch ist es auf vielen Plattformen lauffähig. Es besitzt Module um viele bereits verfügbaren Systeme zusammen zu schließen und über die eine Plattform zu steuern. Ich habe mich entschieden die Kommunikation über MQTT zu lösen. MQTT ist eine Kommunikationsplattform für Maschine-zu-Maschine Kommunikation. Man kann sich ein einem Verteiler (Broker) anmelden und für verschiedene Nachrichten anmelden. Danach erhält man die Nachrichten auf diesem Kanal. Der Part des Brokers wird von der offenen Software Mosquitto übernommen, die ebenfalls auf dem Raspberry Pi läuft.

Die Firmware NodeMCU besitzt ein Lua Modul, dass die Kommunikation mit einem MQTT Broker sehr einfach gestaltet. Das Modul mqtt.Client() bietet Funktionen zum Anmelden für Nachrichten, als auch zum Verschicken von Nachrichten.

Diese Nachrichten werden an vereinbarte Topics gesendet. Diese sind in der Konfigurationsdatei von openHAB und in der Lua Quelltext abgespeichert. Weitere Funktionen des NodeMCU sind der Stromsparende Tiefschlafmodus und die Kommunikation über die serielle Schnittstelle. Beide dieser Funktionen werden an unterschiedlicher Stelle benötigt. Der Tiefschlaf ist für die Sensoren notwendig, wenn diese nur Nachrichten senden, aber keine Empfangen sollen. Die serielle Schnittstelle ist für die Kommunikation mit einem anderen Controller gedacht, der dem ESP die nötige Berechnungspower zur Verfügung stellen kann.

Der Auf/Zu Sensor ist in der Aktuellen Version dem Fensterwächter sehr ähnlich. Allerdings ist er noch nicht so weit veröffentlicht zu werden. Alle Module mit allen Programmen und Schaltungen werden aber in der nächsten Zeit hier zur Verfügung stehen. Der Code und die Konfigurationsdateien für Herbert liegen ebenfalls auf GitHub.

Resourcen:
Raspberry Pi Debian Variante: Rasbian
openHAB Dokumentation + Autostart Anleitung
MQTT auf dem Raspberry Pi installieren
NodeMCU API Dokumentation

Unboxing: Raspberry Pi 2 B++

Ich habe heute ein Paket mit dem neuen Raspberry Pi 2 B++ erhalten. Nachdem die Hardware des Raspberry Pi in der neuen Version 2 auf einen bessern CPU Chip geändert wurde sind die Schnittstellen zu USB und Ethernet die Flaschenhälse zum Controller gewesen. Mit der neuen Version des Raspberry Pi 2 B++ wurde das jetzt auch behoben. Wie angekündigt sind zu Beginn des zweiten Quartals 2015 die ersten Muster des neuen Modells mit Gigabit Ethernet und USB 3.0 verfügbar.

Der neue Raspberry Pi 2 B++

Home automation done in one afternoon

So there they are. The winter holidays. And you finally I have all the time to make that stuff I wanted to do. But what to do first.

Remote-control

The challenge is to build the things as fast as possible. So we start with the home automation thing I had in my mind for a few month now. First up we need a cool name so it does stick out of the masses. Well it's name is going to be Herbert.
Next up we need a processing base station for WiFi integration.

Remote-controlled Socket

This nice Raspberry Pi will do the job pretty well I guess. I have a collection of 6 remote controlled wall-adapters for the power sockets and a remote-control to toggle 3 of them individually on and off. the all-off button also exists. Dismantling the remote I found a circuit-board with an ASIC, 12V battery, four tactile switches, 434MHz crystal, one LED and a 8bit-dip switch bank.

Basically just an ASIC

 A quick glance at the backside of the PCB shows that 7 of the 8 switches are connected to the ASIC. Looks like some sort of channel selection. Nice. The operation voltage for the remote is 12V so we can not directly hook the Pi up.
I need some sort of isolation between the two circuits. Something like a optocoupler or a relay. I just happen to have two dual-relay-modules laying around so why not use them. A really quick solder-job later the tactile switches had a wire attached as well a a wire to short one of the channel-selectors. Now all six sockets can be operated with one remote module. the all-off switch is not connected. So I can not switch them all off at once. For now. A look inside the socket adapters show that they also consist of an ASIC. This one isn't even labeled! A switch mode power-supply and an antenna.

The socket-module seems not to answer the command in a way to determine of the signal was received. I will have a look into this later. For now one-way communication will have to be sufficient.

Everything hooked together like this:
5V -> Relay supply
3.3V -> Relay driver
GPIO -> Relay switch signal
The relays short the tactile switches ans one of the channel-selectors. 

The next step is software. The Pi I use has Raspbian installed. This is a Linux based on the Debian distribution and comes with python and bindings to access the GPIO directly from the script. With Python you get a HTTP-server up and running in no time.

from BaseHTTPServer import BaseHTTPRequestHandler,HTTPServer
import RPi.GPIO as GPIO
class myHandler(BaseHTTPRequestHandler):
    
    #Handler for the GET requests
    def do_GET(self):

        self.send_response(200)
        self.send_header('Content-type','text/html')
        self.end_headers()
        # Send the html message
        self.wfile.write("Hello World")
        GPIO.setmode(GPIO.BCM)
        GPIO.setup(4, GPIO.OUT, initial=1)
        GPIO.output(4, 1)
        
        return

try:
    #Create a web server and define the handler to manage the
    #incoming request
    server = HTTPServer('', 8000), myHandler)
    print 'Started httpserver on ', server.server_address
    
    #Wait forever for incoming http requests
    server.serve_forever()

except KeyboardInterrupt:
    print '^C received, shutting down the web server'
    server.socket.close()

With little additions the first version of Herbert was built. Have look at the git if you want.

Zeitraffer Aufnahmen mit dem RaspberryPi und einer PiCam

Es hat etwas faszinierendes dem 3D-Drucker dabei zuzuschauen, wie er Schicht für Schicht ein Teil erstellt. Allerdings ist der Prozess ein zeitintensives Unterfangen. Kleine Drucke sind in einigen Stunden gedruckt, größere Drucke dauern hingegen gerne mal etwas länger. 7 Stunden sind für einen mittelgroßen Druck eine realistische Zeit. Um den Prozess in seiner ganzen Faszination abzubilden können Zeitrafferaufnahmen gemacht werden. Dabei wird die Zeit, die benötigt wird auf ein einstellbares Minimum reduziert und die Entstehung des Objektes in seiner ganzen Pracht gezeigt. Das Hilfsmittel meiner Wahl ist ein RaspberryPi mit PiCam und die Software RPi-Cam-Webinterface. Die Installation der Software ist mit wenigen Eingaben, entweder über die Konsole des Pi's oder über SSH erledigt.

sudo apt-get update
sudo apt-get dist-upgrade
sudo rpi-update
mkdir ~/cam
cd ~/cam
git clone https://github.com/silvanmelchior/RPi_Cam_Web_Interface.git
cd RPi_Cam_Web_Interface
chmod u+x RPi_Cam_Web_Interface_Installer.sh
./RPi_Cam_Web_Interface_Installer.sh install

Jetzt sind alle benötigten Dateien und Programme installiert, sodass mit einem Webbrowser auf die Cam zugegriffen werden kann. Das sehr minimalistische Webinterface ermöglicht eine einfache Konfiguration und die Vorlage für Zeitrafferaufnahmen hat alles für einen schnellen Test bereits eingestellt. Wir wählen also unter 'Load Presets: Stf FOV, x30 timelapse' aus. Ein simpler Druck auf 'record video start' startet die Aufnahme.

RaspberryPi mit PiCam

Nach einiger Zeit hat sich auf Grund der hohen Auflösung der Kamera eine beachtliche Datenmenge angesammelt. Mein aktueller Druck läuft seit 4:30 Stunden und die dazugehörige Filmdatei ist bereits 3,6GB groß. Meine Speicherkarte wird also demnächst überlaufen und die Aufnahme abbrechen. Schade, denn der Druck wird noch einige Stunden laufen.

Eine weitere Möglichkeit ist, die Kamera nur Bildaufnahmen machen zu lassen. Eine Aufnahme mit voller Auflösung und 85% Bildqualität führt zu einer ungefähr 3MB großen Datei. Wenn alle 3 Sekunden ein Foto geschossen wird entsteht innerhalb einer Minute 60MB Daten. Eine Stunden sind dann 3,5GB. Auch hier ist uns nicht weitergeholfen. Um hochwertige Aufnahmen für den Zeitraffer zu bekommen werde ich wohl oder Übel den Speicher des RaspberryPi erweitern.