Herbert Reloaded: Haus Automation

6. April 2015 by Platinenmacher Leave a comment

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

ESP8266 – 1: Fensterwächter

26. März 2015 by Platinenmacher Leave a comment

Wie in einem früheren Beitrag schon beschrieben kann für die ESP8266 Module aus China die Entwicklungsumgebung für NodeMcu aufgesetzt werden. In diesem Beitrag werden wir das erste Projekt erstellen und den Controller programmieren.

Morgens mache ich das Schlafzimmerfenster immer auf, um zu lüften. Wenn ich dann vor dem ersten Kaffee schon auf dem Weg zur Arbeit bin, kann es passieren, dass das Fenster weiterhin offen ist. Mist. Also brauch ich etwas, dass mir sagt, dass das Fenster noch geöffnet ist. Ein Fensterwächter.

Mit Hilfe von einigen Komponenten, dem ESP-01 Modul, einem Mikroschalter und einer Batterie kann genau das erreicht werden.

Das ganze soll neben dem Fenster am Fensterrahmen befestigt werden. Dazu werde ich ein 3D gedrucktes Gehäuse verwenden, in dem alles untergebracht ist. Wenn das Fenster geöffnet wird, wird der Mikroschalter nicht mehr betätigt und schließt den Stromkreis zum Controller. Dieser startet und geht sofort für 10 Minuten in den Tiefschlaf. Wenn er daraus erwacht, ohne dass die Batteriespannung zwischendurch getrennt wurde, verbindet es sich mit dem WLAN Accesspoint und sendet eine Email, die dann auch meinem Mobiltelefon angezeigt wird.

Hardware

Wie schon beschrieben benötigen wir mehrere Komponenten für den Aufbau des Fensterwächters. Das ESP8266 Modul ESP-01 hat 8 Pins mit dem es die wichtigsten Signale nach Außen führt. Wie zu erkennen sind lediglich zwei GPIOs herausgeführt. Für unsere Zwecke benötigen wir aber genau keine. Für das Flashen der NodeMcu Software allerdings werden genau diese beiden Pins benötigt. Weiterhin ist der CH_PD Pin herausgeführt, der sorgt dafür, dass das Modul abgeschaltet ist, wenn er nicht auf VCC liegt. Für Experimentierzwecke habe ich den Pin über einen 100Ohm Widerstand mit VCC verbunden. Zu beachten ist, dass auf dem ESP-01 Modul der Pin zum Aufwecken des Controllers (GPIO 16) nicht mit dem RST Pin verbunden ist.

ESP-01 Pinbelegung

Das Modul kommt mit einer Firmware ausgestattet, die über die Serielle Schnittstelle angesprochen werden kann. Um diesen Betriebsmodus zu verwenden benötigt man dann noch einen zweiten Controller, der mit dem Modul kommuniziert. Wir wollen allerdings nur den einen Controller einsetzen, müssen also die darauf befindliche Firmware ändern. Das kann ganz einfach mit dem NodeMcu Flasher passieren. Dazu verbinden wir die Pins GPIO0 mit GND und GPIO2 mit VCC. Dadurch befindet sich der Chip nache einem Reset in einem Zustand indem der Bootloader über die serielle Schnittstelle eine neue Firmware in den Speicher des Moduls schreiben kann. Der Flasher übernimmt alles was dafür notwendig ist.

Mit dem ESPlorer kann jetzt die Lua Software auf dem Modul geschrieben werden. Das Erste was wir tun ist eine ‚init.lua‘ erstellen, die wird beim Start des Controllers ausgeführt.
Der grundlegende Programmablauf ist oben schon aufgeführt:

Power up
Deep Sleep für 10 Minuten
Wake up
Verbinde mit WLAN Router
Sende Email
Deep Sleep bis Power down

Die API von NodeMcu gibt Informationen über die benötigten Funktionen:

Es fehlt lediglich der Programmteil zum senden der Email-Warnung.

So weit zur Theorie. Ein Problem zeigt sich bei der Umsetzung des Email Versandes. Da der ESP sich nicht als SMTP Server behaupten kann, Eine Möglichkeit ist es die Kommunikation mit einem SMTP Server manuell zu programmieren, einfacher ist es jedoch einen bereits existierenden Service, wie zum Beispiel PushingBox.com zu nutzen. Dort kann man über eine HTTP API eine Notification, oder eine Email abschicken. Das Ganze ist dann auch von dem PC aus konfigurierbar und lässt auf dem ESP genügend Platz für andere Funktionen.

Gestartet wird immer in der ‚init.lua‚. Egal ob aus dem Power down, oder dem Tiefschlaf. Das führt dazu, dass nicht genau erkannt werden kann, aus welchem Vorzustand der Chip kommt. Es wird also nach dem Aufwachen ein Timer gestartet und der Chip befindet sich im idle Modus. Welche Folgen das für den Stromverbrauch und die daraus resultierende Batterielaufzeit hat, wird sich noch herausstellen. http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Sensoren/Fenster/FensterOffenWarner/init.lua?footer=minimal&slice=8:11
Nachdem die 10 Minuten, oder (600000 ms) abgelaufen sind, wird die Datei ‚fenster.lua‚ aufgerufen und interpretiert. Als erstes muss das WiFi-Modul gestartet werden. Dann wird die Verbindung mit dem Accesspoint hergestellt. http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Sensoren/Fenster/FensterOffenWarner/fenster.lua?footer=minimal&slice=5:8
Sobald die Verbindung zum Accesspoint besteht und das Modul eine IP-Adresse erhalten hat, soll die Funktion pollPushingBox() aufgerufen werden. Dazu verwenden wir einen neuen Timer: http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Sensoren/Fenster/FensterOffenWarner/fenster.lua?footer=minimal&slice=33:41
Die pollPushingBox() Funktion baut eine TCP Verbindung mit dem PushingBox Service auf und sendet einen API Request um einen Alarm auszulösen. http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Sensoren/Fenster/FensterOffenWarner/fenster.lua?footer=minimal&slice=12:26 http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Sensoren/Fenster/FensterOffenWarner/fenster.lua?footer=minimal&slice=28:31
Nachdem der Server geantwortet hat, geht das Modul in den unendlichen Tiefschlaf. Erst ein Wegfallen der Batteriespannung (durch Schließen des Fensters) wird der Chip resettet und bei erneutem Öffnen beginnt der Code wieder in der ersten Zeile der init.lua.

Der Code zeigt, wie einfach mit NudeMcu und Lua ein ESP2866 für einfache Zwecke verwendet werden kann.

Das ESP-12 3$ WiFi Modul, oder wo könnte man überall Internet einbauen

1. Februar 2015 by Platinenmacher Leave a comment

Seit geraumer Zeit gibt es, vor allem aus China, ein Modul, dass einen ESP8266 Mikrocontroller, ein Flashspeicher, onboard Antenne und einige GPIOs besitzt. Verfügbar ist das Modul in so weit ich herausgefunden habe 14 verschiedenen Ausführungen, vom blankliegenden Controller bis hin zum voll geschirmten Modulpaket, dass die GPIOs als Lötpunkte auf der unterseite besitzt. Die Module sind alle über die üblichen Kanäle zu beziehen. Dabei sind auch die üblichen Lieferzeiten zu erwarten.

Aufbau des Moduls

ESP-12 Modul mit Breakout-Board

Ich habe mir das ESP-12 Modul mit einem Breakout-Board bestellt. Dadurch ist es möglich das Modul im Steckbrett unterzubringen und so schnell eine akzeptable Verkabelung zu erreichen. Das Modul besitzt eine LED, eine PCB-Antenne und ist ansonsten unter einem Metalldeckel abgeschirmt. Dieser Schirm trägt die Kennzeichnung, dass das Modul die Modellnummer ESP826WLAN. Mit diesen Parametern ist es hervorragend geeignet in einem WLAN Netzwerk eingesetzt zu werden. Das Modul hat eine Größe von 16x24mm Die seitlich angebrachten Lötpads sind mit 2mm Abstand angeordnet und befinden sich nicht im Bereich der Antenne. Die LED kann über den Controller gesteuert werden. Die beiden Lötpads für SMD Widerstände sind einam mit GPIO 15 und Chpi_Enable verbunden. Sie können dauerhaft auf GND bzw. VCC gelegt werden. Wenn anstatt der hier verwendeten Lötbrücke ein 10k 0603 SMD Widerstand eingelötet wird, können die Pins auch noch verwendet werden. Ich hatte nur gerade keine griffbereit.
6MOD besitzt und von der Firma AI-THINKER hergestellt wurde. Es besitzt eine FCC-Zulassung, arbeitet auf dem ISM 2,4GHz Band, hat eine Sendeleistung von +25dBm und verwendet das Funkprotokoll IEEE 802.11b/g/n auch bekannt als

Espressif SDK und weitere Betriebsmodi

Die Firma Espressif Systems hat für den ESP8266 eine SDK herausgebracht, das es ermöglicht die Module in zwei verschiedenen Betriebsmodi zu verwenden. Einmal als eigenständiges Modul, dass mit UART Befehlen gesteuert werden kann. Andererseits biete das GitHub von Espressif ein SDK zur Entwicklung von Software mit Hilfe von FreeRTOS in C. Aufbauend auf diesem SDK wurde NodeMcu entwickelt. NodeMcu bringt die Skriptsprache Lua auf das System und ermöglicht es den Microcontroller mit einfach zu scheibenden Skripten zu verwenden. Auch dieses Projekt ist Open-Source und auf Github verfügbar.

Flashen der Firmware

NodeMcu Firmware Programmer

Das Flashen von Mikrocontrollern kam in der Vergangenheit immer etwas arbeitsaufwändig daher. Meistens wurden spezielle Programmieradapter verwendet, oder das Chip musste über einen JTAG Adapter angesprochen werden. Im Laufe der Zeit haben sich Bootloader etabliert, die in einem reservierten Bereich des Flashs sitzen und vor Ausführen des Hauptprogramms ein Programmieren über die serielle Schnittstelle zulassen. So auch bei diesem Modul. es ich möglich die Firmware von NodeMcu über die Serielle Schnittstelle zu flashen. Das Projekt stellt dazu sogar ein Windows Programm zur Verfügung, das völlig selbständig das Modul mit allen benötigten Speicherteilen beschriebt.

Kommunikation mit dem Modul

ESPlorer

Nachdem die NodeMcu Firmware auf das Modul geflasht wurde, kann über die Serielle Schnittstelle die Kommunikation mit dem LUA-Interpreter aufgenommen werden. Der Interpreter lauscht mit einer Baudrate von 9600 8 Bits, 1 Stop, kein Parity. Rund um den ESP8266 hat sich bereits eine große Gemeinschaft von Leuten gebildet, die alle mit zum Entstehen von großartiger Software beitragen. Zum Beispiel das ESPlorer Projekt, das eine leicht zu bedienende Oberfläche zum Programmieren der LUA Skripte entwickelt hat. Die für die Entwicklung nötigen Informationen finden sich ebenfalls auf GitHub und können dort im Wiki und der API Dokumentation nachgeschlagen werden.

Bei den bereits verfügbaren LUA Modulen befindet sich alles was man zur Entwicklung von WLAN fähigen Geräten benötigt. Jetzt bleibt nur noch die Frage zu klären, wo kann man überall noch WLAN einbauen und wie mache ich das, damit mein Nachbar mir nicht das Licht ausschalten kann.

Home automation done in one afternoon

26. Dezember 2014 by Platinenmacher Leave a comment

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.

[youtube https://www.youtube.com/watch?v=uea_XdWFsqE?version=3&f=user_uploads&c=google-webdrive-0&app=youtube_gdata&w=320&h=266]

WLANKaffee Code Repository

12. Februar 2014 by Platinenmacher 3 Comments

Wir haben vom Hersteller der Maschine die Auflage bekommen, die Informationen nicht öffentlich zur Verfügung zu stellen. Daher wird das Projekt und der Quellcode nicht mehr zur Verfügung stehen.

~~Ich habe den Code für den Arduino auf einer Google Code Projektseite hochgeladen.~~ Der Code ist teilweise ungetestet, da die Kaffeemaschine noch nicht vollständig verdrahtet ist. Diese Arbeit wir nächste Woche beendet. Der Zeitpunkt für den ersten Release ist dann auch der nächste Dienstag.
Aktuell sind für den ersten Release diese Funktionen geplant:

Yún

Arduino

Firmware die über die Console Klasse gesteuert werden kann.
Steuerung der Menüknöpfe am HID
Drehencoder wird ausgewertet
Drehencoder Impulse werden simuliert

Linino

Python mit Django
Webseite mit Benutzerverwaltung
Steuerung über Console Klasse des µController

Dokumentation

Python

SPI Protokoll für Display Frames

Arduino Yún, Linux mit Arduino auf einem Board

1. Februar 2014 by Platinenmacher Leave a comment

Für unsere Projektarbeit haben wir entschieden, dass ein Linux fähiges Board und ein Arduino Mikrocontroller zum Einsatz kommen soll. Um das ganze möglichst klein zu halten haben wir den Arduino Yún ausgewählt. Der Yún hat neben den Funktionen, die auch ein Leonardo mitbringt zusätzlich einen voll funktionsfähigen Computer an Board, der mit einem speziellen openWRT Distribution läuft. Das Besondere ist, dass die beiden Geräte miteinander kommunizieren können und somit beide Geräte direkt miteinander verbunden sind. Auf der Linuxseite bietet die Linino Distribution einiges an Funktionalität, wie zum Beispiel eine REST-Full API um die Pins des Arduinos direkt anzusteuern. Eine weitere großartige Funktion wird in der Bridge Bibliothek zur Verfügung gestellt. Die Kommunikation zwischen Mikrocontroller und Programmen auf der Linuxseite.

SSH Konsole des Yún mit Erweiterung für die Kaffeemaschine

In unserem Falle wird der Mikrocontroller die Ansteuerung der Kaffeemaschine übernehmen und bestenfalls den SPI Bus abhören und die übertragenen Displaydaten in einen seriellen Bytestream umwandeln. Die Linuxseite wird die komplette Benutzerschnittstelle bereitstellen, also ein Webinterface mit dem die Kaffeemaschine gesteuert werden kann. Außerdem wird die Webseite den Inhalt des Displays darstellen. Wie die Daten von der Maschine in ein Bild gewandelt werden, habe ich letzte Woche schon beschrieben.

Diese Woche habe ich mich mit dem SPI Interface beschäftigt. Die Displaydaten werden über den SPI Bus vom Benutzerpanel an den Displaycontroller gesendet. Diese Daten können vom Arduino aufgezeichnet werden. Um klein anzufangen, habe ich verschiedene Ansätze ausprobiert. Die Grundvoraussetzung war, dass der Bustakt von 1 MHz eingehalten wird. Dann werden alle 0,1 Sekunden 541 Bytes übertragen. Der genaue Aufbau des Protokolls lässt sich relativ kurz beschreiben. Zuerst bekommt das Display den Wert 0x89 übertragen. In den Datenblättern, die etwas mit dem Display zu tun haben könnten habe ich diesen Befehl leider nicht finden können. Weiter geht es mit dem Byte 0xB4 was laut Datenblatt die Speicherseite 4 als Startadresse angibt. Darauf folgen 134 Bytes mit Bilddaten, bis dann 0xB5 (page 5) übertragen und die nächste Speicherseite ausgewählt wird. Nach weitern 134 Bytes folgt 0xB6 (page 6) und nach weiteren 134 Bytes folgt 0xB7 (page 7). Die abschließende Speicherseite und somit die letzte ‚Zeile‘ des Displays hört auch hier nach genau 134 Bytes auf. Da das Display auf dem Benutzerpanel auf dem Kopf stehend eingebaut ist, sind auch die Daten ‚gekippt‘ Eine einfache Spiegelung hilft das Bild wieder sichtbar zu machen.

Der Arduino Yún

Um mit dem SPI Bus zu arbeiten, ohne die Maschine dabei zu haben, habe ich die Daten eines Frames in ein Arduino-Sketch geladen. Dieser Arduino macht nichts als ein und dasselbe Bild immer und immer wieder alle 0,1 Sekunde über den SPI Bus zu übertragen. Die nächste Aufgabe ist jetzt, die Daten mit dem Yún zu empfangen und zu verarbeiten. Da ich bis jetzt nur einen funktionierende SPI Kommunikation mit Yún als Master und einem Nano als Client zum Laufen gebracht habe, kann ich noch nicht davon berichten, in wieweit sich die Idee mit der Bildgenerierung verwirklichen lässt.

Das SPI Protokoll für das Kaffeemaschinen Display

19. Januar 2014 by Platinenmacher Leave a comment

Dieses Wochenende haben wir im Projektteam die Kommunikation vom Controller auf dem Benutzerboard zum Display genauer unter die Lupe genommen. Da wir keine genauen Informationen über die verwendeten Bauelemente hatten sind wir mit google auf die Suche nach Datenblättern von Displays ähnlicher Bauart gegangen. Die meisten Displays mit SPI Interface verstehen das gleiche Protokoll zum Setzen der Kofigurationswerte und Übertragene der Daten. Die Daten haben wir mit Hilfe des Logic Analyser ja schon das letzte mal aus der Maschine extrahiert. Nach einigen Anläufen haben wir im Datenbaltt eines Displaycontrollers (ST7565R) die Konfiguration des Display RAMs gefunden. Mit dem Wissen wie das Bild, das im Display angezeigt wird zu übertragen ist, gelang es uns den Datenstream so zu formatieren, dass wir das Bild des Displays gespiegelt auf dem Bildschirm sehen konnten. Mit ein wenig Bearbeitung der
Daten ist es gelungen das Bild, das am Display angezeigt wird zu rekonstruieren.

Der Inhalt des Datenstreams in serieller Formatierung

Datenübertragung in der Maschine

Die Maschine kommuniziert einmal mit der Steuerplatine und dann mit dem Display. Dabei ist die Verbindungsleitung zwischen den Platinen mit einem Enable
Signal verehen. Wenn dieses Signal High ist, ignoriert die Steuerplatine die Daten; wenn der Pin auf Low gelegt wird, sind die Daten am Bus für die Steuerplatine.
Vom Controller gehen, neben der Datenleitung MOSI, nicht nach Außen geführte Leitungen an das Display. Es ist also anzunehmen, dass dort auch eine Enable und/oder
Clock Leitung dabei ist. Die Daten, die über den SPI Bus bei dauerhaftem High Zustand auf Enable an der Controllerplatine gehen sind somit aller Wahrscheinlichkeit
nach an das Display gerichtet. Genauer betrachtet wurden jedes Paket 541 Bytes übertragen. Das Display hat eine Bildmatrix von 128 * 32 Pixeln, somit werden
4096 Bit zum Darstellen eines monochromen Bildes benötigt. Die übertragenen Bytes beinhalten diese Datenmenge und zusätzlich noch einige Steuerbefehle.

Das Bild steht noch auf dem Kopf und die Page-Select Befehle sind noch links sichtbar

Display RAM

Wichtig ist dabei zu beachten, dass die Pixelreihen des Display nicht wie erwartet seriell mit Daten bestückt werden, sondern der serielle Kommunikationsport nur vor den parallelen geschaltet wurde. Dadurch ergibt sich die Eigenschaft, dass die Daten ‚Zeilenweise‘ in den Speicher des Displays geladen werden. Zeilenweise
bedeutet dabei, dass der Speicher in 8 bit breite Pages eingeteilt wird. Jede Page wird zuerst ausgewählt und dann von Spalte 0 an aufgefüllt. Dadurch erscheinen die Bilddaten nicht waagerecht, sondern senktrecht und werden so zusammen gesetzt. Nachdem der Aufbau des Speichers bekannt war, konnten wir unsere Software danach ausrichten und haben den Displayinhalt ‚CAPPUCCINO‘ in den sortierten Matrxwerten erkennen können. Jede Zeile oder Page begann mit einem Page-Select Befehl, der getroßt ignoriert werden konnte. Der letzte Schritt war es, die Matrix der Bilddaten in ein PNG zu gießen um es später als Bild in einer Webseite verwenden zu können.

Die rekonstruierte Grafik des Maschinendisplays

Analyse des Protokolls zur Maschinensteuerung

Nachdem jetzt die Übertragung der Displaydaten bekannt ist, müssen noch die vorherigen 10 Bytes der Maschinensteuerung in einen Kontext gebracht werden. Mit Hilfe eines kleinen Scripts habe ich die Logic Analyser Mitschnitte in Kommando- und Bildabschnitte zerlegt. Das Bild wird generiert und die Kommandodaten werden daneben in einer Tabelle abgebildet. Jetzt müssen wir nur die passenden Befehle herausfinden. Dazu gibt es dann nächste Woche mehr.

Reverse Engineering einer Kaffeemaschine

15. Januar 2014 by Platinenmacher Leave a comment

Meine aktuelle Projektarbeit befasst sich mit dem Innenleben eines Kaffee Vollautomaten der Firma Severin, Genauer gesagt der KV8023 S2+. Ziel dieser Arbeit ist es die Kommunikation zwischen Bedienpanel und Kaffeemaschine zu analysieren und gegebenenfalls so zu manipulieren, dass die Maschine über einen Mikrocontroller ferngesteuert werden kann. Dazu habe ich die Maschine erst einmal geöffnet und zwei Flachbaugrupppen gefunden. Eine ist Netzteil, Netzspannung-Schaltung und Controller für die eigentliche Maschine, die andere ist ein Bedienpanel mit einem eigenen ATmega1284P an board. Das Flachbandkabel, mit dem beide Platinen verbunden sind deutet darauf hin, dass die Steuerung der Maschine über ein Bussystem gelöst ist. Wo die eigentliche Intelligenz steckt ist mit eines der ersten Punkte, die es herauszufinden gibt.


Geöffneter Vollautomat	Controller des Bedienpanels

Nach einer genaueren Betrachtung des Panels habe ich die Verbindungen der Bauteile in einem Plan aufgestellt. Dieser Plan zeigt alle Steckverbinder, das Displayinterface und die, an den Controller angeschlossene Hardware (Taster, Drehencoder und LED). Eine Erweiterung des Verbindungskabels mittels eines Schneidklemmsteckers erzeugt den Zugriff auf den vermeindlichen Bus. Dieses Kabel ist verbunden mit dem SPI Interface des Controllers, mit dem Display (hier fehlt noch die Belegung der Kontakte).

Ein kurzer Test mit dem Logic Analyser zeigt, dass auf dem SPI Bus tatsächlich reger Betrieb herrscht. Nach einigen Kaffees habe ich jetzt mehrere Minuten Kommunikation mitgeschnitten und werde im nächsten Schritt versuchen die Telegramme auszuwerten und zuzuordnen.

Mitschnitt zweier Telegramme der Buskommunikation

Die Übertragung startet zyklisch alle 0,126 Sekunden, es werden 10 Byte über den Bus mit Enable Low (An) übermittelt. Auf diese Bytes gibt es eine Antwort auf der MISO Leitung. Darauf folgen 540 Bytes ohne Antwort, bei denen der Enable des Flachbandkabels konstant auf High (Aus) liegt. Es liegt nahe, dass es sich hierbei um Daten für das Display handelt, denn auch dorthin ist MOSI des Controllers verbunden. Mit einem Arduino und einem kleinen Sketch kann ich also nächste Woche die 10 Byte Telegramme abfangen und zur Auswertung aussortieren. Dadurch reduziert sich die Menge der Telegramme auf ein Minimum und die Entschlüsselung ebendieser wird hoffentlich leichter fallen.

Um eine Fernsteuerung durchzuführen, muss die Kommunikationsverbindung unterbrochen werden, da sonst das Bedienpanel in die automatisierten Telegramme zusätzliche Telegramme schicken würde. Gleichzeitig muss dem Bedienpanel die Antwort der Maschine vorgespielt werden, da sonst ein Fehler angezeigt wird. Wie sich die Anzeige des Displays manipulieren lässt habe ich mir noch nicht überlegt, da der Enable Eingang des Displays nicht nach Außen geführt wird.

Sicherheit im Internet der Dinge (Fonera mit SSL)

4. Januar 2014 by Platinenmacher Leave a comment

Sollte es einmal so weit sein, dass sogar der Kühlschrank mit der Heizung und der Waschmaschine spricht um ein möglichst Strom effizientes Miteinander zu gewährleisten, wird das aller Wahrscheinlichkeit nach über Funk passieren. Doch eine Kommunikation über Funk ist alles andere als sicher und so muss der Sicherheitsaspekt von Beginn an in die Entwicklung internetfähiger Haushaltsartikel mit einfließen. Ich experimentiere zur Zeit mit einem kleinen Linuxboard, das unter anderem eine WLAN-Schnittstelle hat.

Sollte dieses Board einmal zum steuern eines Haushaltsgegenstandes verwendet werden, bleibt zu überlegen, wie die Kommunikation von der Kontrollstelle zum Board gesichert werden kann. Eine Möglichkeit wäre das erstellen eines abgeschlossenen WiFi Netzwerks das nur zur Steuerung der Geräte dient und nicht mit dem Internet verbunden ist. Das führt allerdings nicht dazu, dass das Gerät im Internet erreichbar ist, was unserem Ziel nicht gerecht wird. Eine zweite Möglichkeit ist eine normale HTTP Verbindung mit HTTP Auth zu implementieren. Somit ist schon mal eine einfache Sicherheitsebene dazugekommen und das Gerät steht nicht mehr jedem Internetteilnehmer zur Verfügung. Die nächste Schicht wäre eine Verschlüsselte Kommunikation über HTTPS. Dadurch wird das Passwort nicht mehr sichtbar übertragen und einem eventuellen Mithörer bleibt der Anmeldeprozess verborgen. Ein Passwort ist allerdings selten sicher, wenn man dem Benutzer keine vorgegebenen Grenzen setzt. Deshalb bietet sich die Kombination aus Passwort und Zertifikatslogin an. Dabei besitzt der Client ein Public / Private Schlüsselpaar und ein Passwort mit dem das Zertifikat im Client geöffnet werden kann.

Um eine SSL Verbindung über HTTPS zur Fonera zu ermöglichen, benötigt man einen anderen Webserver als den Busybox httpd. Ich habe mich für den mini-httpd entschieden, der bringt auch die Erweiterung für SLL nämlich matrixssl mit. Im OpenWrt Wiki findet sich eine gute Anleitung, wie man mini-httpd mit SSL durchführt. Anders als in der Anleitung angegeben muss allerdings das Paket mini-httpd-matrixssl anstelle von mini-httpd-openssl installiert werden. Ansonsten kann der Anleitung gefolgt werden. Jetzt steht auf der Fonera nur noch HTTPS mit einem eigenen Zertifikat zur Verfügung. Der nächste Schritt ist nun ein Frontend zu Anmeldung auf der Fonera zu programmieren.

GPIOs der Fonera

25. November 2013 by Platinenmacher Leave a comment

Heute habe ich ein wenig mit den GPIOs der Fonera gespielt. Um später das SoC der Fonera zum Steueren von anderen Hardwareprojekten zu verwenden, habe ich die vier am einfachsten zu erreichenden GPIO Kontakte mit einer Leitung verbunden. Dabei habe ich gleich noch die Kondensatoren nach Masse entfernt. Die bildeten mit dem Widerstand zusammen einen Tiefpass am Eingang und verhindern somit die Signalintegrität bei schnellen Schaltvorgängen.

Fonera mit LED an GPIO Ports

Die 8 IO Ports der Fonera sind teilweise schon von Hardware belegt, es bleiben jedoch fünf freie Ports übrig, die beliebig verwendet werden können. Vier dieser Kontakte sind auf den Steckplatz für SW1 geführt. Für die kleinen Experimente habe ich auch nur diese vier verbunden. Wenn komplexere Aufgaben gesteuert werden sollen, kann auch der serielle Port der Fonera verwendet werden um mit einer Mikrocontroller Schaltung zu kommunizieren.

GPIO Description
0    TP3
1    pin 5 of SW1
2    WLAN LED
3    pin 1 of SW1
4    pin 2 of SW1
5    RESET (!)
6    RESET button
7    pin 6 of SW1

Zum Steuern der GPIOs kann das Kommandozeilentool gpioctl verwendet werden. Dieses ist standardmäßig bei der openWRT Installation mit installiert worden und kann zum Beispiel über die SSH Verbindung ausgeführt werden.

gpioctl dirout 3
gpioctl set 3

Dadurch wird der Port 3 als Ausgang definiert und eingeschaltet. Der erste Pin von SW1 ist jetzt auf +3,3V. Nachdem die Funktion der GPIOs funktioniert, wenden wir uns im nächsten Artikel der Software zu und schauen, wie die Fonera dazu gebracht werden kann als Gateway für eben diese Schaltung zu agieren.