Jetzt wird’s bunt

Am Prime Day diesen Jahres habe ich mir eine neue Beleuchtung für den Schreibtisch und die Terrasse gegönnt.

Für den Schreibtisch wollte ich eine indirekte Beleuchtung der Tastatur und Umgebung, das habe ich mit Hilfe der Phillips Hue Ambient* Lichter erreicht. Diese stehen hinter den Monitoren und strahlen an die Wand. Dadurch entsteht ein dimmbares und in der Farbe anpassbares Licht, dass sich mit Hilfe der Hue App, oder von Home Assistant einstellen lässt.

Für die Terrasse habe ich einen wasserdichten RGB LED Streifen* gekauft, dieser wird über WLAN angebunden und kann auch von Home Assistant gesteuert werden. Ähnlich der Schreibtischbeleuchtung ist der Leuchtstreifen in der Farbe anpassbar. Somit kann im Garten eine stimmungsvolle Beleuchtung erreicht werden, ohne zu viele verschiedene Apps zu verwenden.

Home Assistant Konfiguration

Die Konfiguration für Home Assistant zur Unterstützung von Hue ist denkbar einfach. Im Integrationsmenü muss lediglich die Adresse der Hue Bridge im lokalen Netzwerk ausgewählt werden und schon stehen alle Geräte, die normalerweise über die Hue App gesteuert werden müssen auch in Home Assistant zur Verfügung.

Ähnlich ist es mit der Aktivierung des RGB LED Streifens. Die kleine Box, die die Ansteuerung übernimmt, und die von vielen asiatischen Anbietern in unterschiedlicher Ausführung verkauft wird, ist als Flux LED unterstützt. Um die Komponente zu aktivieren, muss in der configuration.yaml diese Zeilen in der light Kategorie hinzugefügt werden:

# Example configuration.yaml entry
light:
  - platform: flux_led
    automatic_add: true

Anschließend Home Assistant neu starten und die Lampen sind als Elemente für die Oberfläche verfügbar.

* alle Produkte sind Amazon Affiliate Links

Home Assistant auf Samsung ARTIK 520: Zigbee

Weiter geht es mit dem ARTIK Board. Wir haben das letzte Mal das System aufgesetzt, aktualisiert und Home Assistant installiert. Jetzt starten wir Home Assistant bei jedem Boot, updaten die Firmware des Zigbee Controllers um mit Home Assisatant zusammen zu arbeiten und konfigurieren Zigbee für eine Philips hue Glühlampe.

Um nach dem Power-up Home Assistant direkt zu starten, müssen wir dem Initialisierungs-Dämon mitteilen, dass hass ausgeführt werden soll. Das machen wir ähnlich dem wifi mit Hilfe von einem Initialisierungsscript. Dazu erzeugen wir einen Service mit Namen home-assistant

vi /etc/systemd/system/home-assistant@homeassistant.service

[Unit]
Description=Home Assistant
After=network-online.target

[Service]
Type=simple
User=%i
ExecStart=/srv/homeassistant/bin/hass -c „/home/homeassistant/.homeassistant“

[Install]

WantedBy=multi-user.target



Wie der vi Editor verwendet wird, wurde im letzten Artikel kurz erklärt, weitere Informationen findet ihr hier.

Der eben erzeugte Service muss noch initialisiert werden, dazu müssen wir den Dienst neu starten

systemctl –system daemon-reload

Danach können wir den Dienst in den Autostart laden

systemctl enable home-assistant@homeassistant

Jetzt können wir einen reboot durchführen und Home Assistant wird beim Neustart automatisch gestartet.

Das ARTIK 520 Modul hat einen NCP (Network Co-Processor) für Zigbee. Dabei handelt es sich um den EM3587 von Silabs. Dieser hat in der aktuellen Konfiguration eine Firmware geladen, die mit RTS und CTS eine Hardware Flusskontrolle erfordert. Home Assistant hat dafür keine Unterstützung, daher müssen wir die Firmware des NCP (NCP Firmware 2017-04-25) ändern. Für das ARTIK 520 Modul gibt es leider nur die RTS/CTS Firmware, also nehmen wir das Image des ARTIK 710 Moduls. Das ist kompatibel und kommt mit Software Flusskontrolle. Es ist dadurch kompatibel mit Home Assistant. Also entpacken wir ARTIK710NCP.zip aus dem Set der Firmwaren.

Die Dateien müssen wir jetzt auf das Modul übertragen werden. Dazu verwenden wir die SD Karte aus dem ersten Teil. Auf diese kopieren wir die Dateien

flash_firmware
ncp-uart-xon-xoff-use-with-serial-uart-btl-5.7.4.ebl

Die SD-Karte legen wir wieder in den Slot auf dem ARTIK 520 Board und hängen die SD-Karte in das System ein, kopieren die zwei Dateien und machen das Flash-Programm ausführbar.

mkdir /mnt/SD
mount /dev/mmcblk1p1 /mnt/SD
cp /mnt/SD/flash_firmware /root/
cp /mnt/SD/ncp* /root/
chmod +x /root/flash_firmware
umount /mnt/SD

Jetzt müssen wir die Schnittstelle zum NCP frei bekommen. Dazu beenden wir den Zigbee Dienst und deaktivieren ihn. Ebenso stoppen wir Home Assistant.

systemctl stop zigbee-daemon
systemctl disable zigbee-daemon
systemctl stop home-assistant

Das Firmware-Update Tool wird als nächstes ausgeführt und updatet den Co-Prozessor

cd /root
./flash_firmware -p /dev/ttySAC1 -f \
  ncp-uart-xon-xoff-use-with-serial-uart-btl-5.7.4.ebl



Do you want to start firmware flashing application? Say Y(es) or N(o): Y



============================================
image transfer is completed (version : 0.1)
============================================

Das Firmwareimage ist erfolgreich übertragen worden und der NCP kann jetzt von Home Assistant verwendet werden.

Dazu schalten wir die Komponente zha ein. Diese verwaltet verschiedene Zigbee Komponenten wie Schalter, Lichter und Sensoren.

Dazu editieren wir die Datei configuration.yaml

vi /home/homeassistant/.homeassistant/configuration.yaml

Dort fügen wir ans Ende die folgenden drei Zeilen ein:

zha:
  usb_path: /dev/ttySAC1
  database_path: /home/homeassistant/.homeassistant/zigbee.db

Abspeichern, Home Assistant starten und laden lassen. Dieser Schritt dauert wieder einige Zeit.

systemctl start home-assisatant@homeassistant

Nach einer Weile ist die Webseite wieder erreichbar und wir können die Dienste Tools anwählen.

Dort können wir den zha Dienst mit der Funktion permit auswählen und so Home Assistant anweise auf neue Verbindungen aus dem Zigbee Netzwerk zu lauschen. Nach einem Druck auf CALL SERVICE werden für 60 Sekunden neuen Zigbee Geräte im Netzwerk akzeptiert.

Jetzt ist es an der Zeit unsere Zigbee Geräte einzuschalten, oder in diesem Fall einzudrehen.

Nach einigen Sekunden ist diese dann auch von alleine im Home Assistant Dashboard erschienen. Das Ein- und Ausschalten hat auch bereits automagisch funktioniert.

Somit haben wir Zigbee erfolgreich in Betrieb genommen und können weitere Geräte dem Netzwerk hinzufügen.

Home Assistant auf Samsung ARTIK 520 installieren

Ich habe zuhause bei mir viele Funktionen mit Hilfe von Home Assistant automatisiert. Darunter fällt: Licht, Heizung, Fenster Überwachung und Thermometer. Das System läuft bei mir in einem Docker System unter Ubuntu Server auf einem Intel NUC PC. Mit SSD und 4GB Ram ist das eine performante und einfach zu wartende Sache. Letze Woche war die Embedded World in Nürnberg, eine der größten Elektronik und Embedded System Messen der Welt. Von dort habe ich ein ARTIK 520 Evaluations-Board mitgebracht. Samsung hat mit dem ARTIK System eine Komplettlösung für alle IOT Belange geschaffen. Neben kleinen Modulen im Endgerät über Sicherheit bis in die Cloud ist alles dabei um ein IOT-Gerät zu entwickeln.

Das ARTIK 520 Evaluations-Board hat ein Modul, jede Menge Antennen (4 Stück) für WiFi, Bluetooth, ZigBee, Z-Wave, Thread, Arduino Headers, Micro SD-Karten Slot und ein UART USB Interface. 
Dazu gibt es dann eine vollintegrierte Software Toolchain, die auf Eclipse basiert und weitere Tools zur Software-Entwicklung.
Auf dem ARTIK 520 Modul arbeitet ein 1GHz dual Core Cortex-A7 mit GPU, 512MB DDR3 RAM und 4GB eMMC Speicher. Zusätzlich zu dem Rechenkern gibt es noch je einen WiFi und Zigbee Co-Prozessor.

Das System ist leistungsfähig genug um eine Home Assistant Instanz laufen zu lassen. Dazu sind einige Schritte notwendig.
Mit einer SD-Karte ist es sehr einfach das System upzudaten. Das Image, dass auf das Modul geladen werden soll kann hier heruntergeladen werden: Downloads 

Wir benötigen ARTIK 520 Firmware Image A520-OS-2.0.0 (Fedora)

Um das Image auf eine SD-Karte schrieben zu können, benötigen wir eine Software wie zum Beispiel Etcher. Wenn die SD-Karte fertig beschrieben ist, steckt man sie einfach in den passenden Slot und schaltet auf SD-Boot Option. Dazu müssen beide Schalter von SW2 auf  „ON“ geschoben werden.

Der Debug USB Anschluss bietet uns eine serielle Konsole an, über die wir die Ausgaben des Moduls verfolgen können. Dazu einfach ein USB Kabel einstecken und mit zum Beispiel PuTTY eine Verbindung aufbauen.

Jetzt schalten wir das Board an und drücken den POWER Knopf für eine Sekunde. Auf der seriellen Konsole bekommen wir den Bootlaoder zu sehen, dort steht relativ weit am Anfang:

Checking Boot Mode … SDMMC

Das zeigt uns, dass die SD-Karte als Boot-Gerät eingestellt und erkannt wurde. Wenn das Update beendet ist, erscheint die Anzeige:

Please turn off the board and convert to eMMC boot mode

Jetzt also ausschalten, SD-Karte raus, die Schalter von SW2 zurück in die Ausgangsstellung und wieder einschalten und den POWER Knopf für eine Sekunde drücken. In der seriellen Konsole wird der normale Bootvorgang angezeigt, der mit einer Loginaufforderung endet. Wir melden uns als root mit dem Passwort root an.


Als nächstes benötigt das System Internetzugang um sich selbst weiter zu aktualisieren. Zum Glück bringt es direkt Wi-Fi mit, so können wir das Netzwerkkabel sparen. Die Einrichtung von Wi-Fi ist ein wenig kompliziert, da viele Informationen dem System zur Verfügung gestellt werden müssen. Außerdem wollen wir auch, dass das System nach einem Neustart noch weiß, wohin es sich verbinden soll. Die Login Informationen für das Wi-Fi Netzwerk werden in die Datei wpa_supplicant.conf eingetragen:

cd /etc/wpa_supplicant/
wpa_passphrase „SSID“ „PASSWORT“ >> wpa_supplicant.conf

Die beiden Befehle wechseln das aktuelle Verzeichnis in das wpa_supplicant Konfigurationsverzeichnis und ergänzen dann die Daten in wpa_supplicant.conf mit den Zugangsdaten (PASSWORT) für das WLAN mit dem Namen SSID.
Wichtig ist zusätzlich noch die Informationen zur Gruppe und zum Control Interface. Das checken wir mit

cat /etc/wpa_supplicant/wpa_supplicant.conf

Die Ausgabe sollte ergeben

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel

update_config=1

network={
        ssid=“SSID“
        #psk=“PASSWORD“
        psk=1e5ed3c450c25eb08xxxxxxxxxxxxxxxxxxxx878bcd17f3b5f797a2ab4fd1292
}

Das sind die vollständigen Konfigurationsdaten für den Wi-Fi Zugang. Mit einem Neustart durch reboot werden die Daten auf den eMMC geschrieben und permanent gespeichert.

Um nach jedem Neustart Wi-Fi zu aktivieren muss der wpa_supplicant Dienst gestartet werden. Das geht mit

systemctl start wpa_supplicant
systemctl status wpa_supplicant

Der zweite Befehl zeigt uns, ob der Dienst gestartet wurde oder nicht. Wenn der Dienst läuft, benötigen wir noch eine IP Adresse für das Wi-Fi-Interface diese bekommen wir über DHCP mit

dhclient wlan0

Nach einiger Zeit hat das WLAN-Interface eine IP bekommen. Um das zu checken fragen wir den Netzwerkdienst

ip a

Ganz unten wird uns das wlan0 Interface angezeigt

6: wlan0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 30:07:4d:84:d0:b3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.101/24 brd 192.168.0.255 scope global dynamic wlan0
       valid_lft 43151sec preferred_lft 43151sec
    inet6 fd0f:5a7d:267f:0:3207:4dff:fe84:d0b3/64 scope global dynamic
       valid_lft forever preferred_lft forever
    inet6 fe80::3207:4dff:fe84:d0b3/64 scope link
       valid_lft forever preferred_lft forever

Hier wurde uns die IP 192.168.0.101 zugewiesen. Das ist alles schön und gut, aber wir wollen, dass sich das System nahc dem Booten automatisch beim WLAN anmeldet und eine IP bezieht. Dazu müssen wir ein Startscript anlegen. Das funktioniert mit Hilfe des Init Dämons, der die Initialisierung des Systems übernimmt. Wir legen dazu eine Datei im Verzeichnis /etc/init.d an.

vi /etc/init.d/wlan

Der Befehl startet den Editor vi und legt die Datei wlan im /etc/init.d Ordner an. Im vi Editor geben wir diese Befehle ein: mit der Taste i schalten wir in den ‚Einfügen Modus‘ und können den unten stehenden Text hinzufügen (hier Strg+c und in PuTTY mit Rechtsklick einfügen)

#! /bin/bash
#chkconfig: – 99 10
start()
{
/usr/sbin/dhclient wlan0
}
stop()
{
kill dhclient
}
restart()
{
stop
start
}
case „$1“ in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
*)
echo „Usage:$0 {start|stop|restart}“
esac
exit 0 

Der Druck auf Esc und 😡 mit anschließendem Druck auf Enter speichert die Datei und schließt den Editor.
Jetzt fehlt nur noch dass das System das Skript als Programm erkennt und der Moment im Bootvorgang in dem der Init-Dämon das Programm laden soll.

chmod a+x /etc/init.d/wlan
chkconfig –add wlan
chkconfig –level 12345 wlan on

Der erste Befehlt schaltet das Skript auf ausführbar, der Zweite fügt es zur Initialisierung hinzu und der letzte Befehl aktiviert es für alle Run-Levels. Ein weiterer reboot konserviert die Änderung und startet das WLAN beim Booten.

Jetzt können die aktuellsten Updates eingespielt werden. Das erfolgt durch das Programm DNF

dnf upgrade

Das kann eine Weile dauern, je nachdem wie viele Updates seit Fertigstellung des SD-Karten Images veröffentlicht wurden.

Wenn das alles geschafft ist, können wir mit der Installation von Home Assistant beginnen. Dabei sind einige Dinge zu beachten, denn Home Assistant benötigt Python Version 3.5 und das ARTIK System arbeitet viel mit Python 2.7. Beide sind nicht sonderlich kompatibel. Daher begrenzen wir die Home Assistant Installation auf eine abgeschlossenes Python Umgebung, eine so genannte virtual environment. Darin wird ann auch jedes von Home Assistant benötigtes Python Paket geladen und verwaltet, ohne mit der Pyhton Installation des Systems zu interagieren.

dnf install python-devel
dnf install redhat-rpm-config
dnf install libffi-devel
dnf install python3-devel

Nachdem die Softwarepakete installiert wurden, legen wir einen Benutzer für unsere Home Assistant Instanz an, da wir des Dienst nicht als root ausführen wollen und können.

useradd -rm homeassistant

Home Assistant benötigt ein Installationsverzeichnis. Das legen wir unter /srv an

cd /srv
mkdir homeassistant

Danach geben wir dem Verzeichnis den Besitzer homeassisatant

chown homeassistant:homeassistant homeassistant

Um auf USB Sticks und Dongles zugreifen zu können fügen wir den Benutzer noch der dialout Gruppe zu
usermod -a -G dialout homeassistant
Im homeassistant Verzeichnis legen wir dann die virtuelle Python Umgebung an.
cd /srv/homeassistant
su -s /bin/bash homeassistant
pyenv-3.5 .
source bin/activate
Der zweite Befehl startet eine Benutzereingabe als homeassistant, denn ab sofort wollen wir Befehle in diesem Benutzerkontext ausführen. Der dritte Befehl legt die eigentliche Python Umgebung an. Mit der letzten Zeile wechseln wir aus dem Linux Umfeld in die virtuelle Umgebung für Home Assistant in Python 3.5. Die Kommandozeile sollte jetzt so aussehen:
(homeassistant) [homeassistant@localhost homeassistant]$
Hier können wir jetzt endlich Home Assistant installieren. Das machen wir unter Zuhilfenahme von PIP.
pip3 install homeassistant
pip install sqlalchemy
Nachdem alle Pakete heruntergeladen und entpackt wurden können wir Home Assistant das erste mal starten. 
hass –script check_config
Der Befehl startet Home Assistant, installiert ein zusätzliches Paket (jetzt sind die Ausgaben in verschiedenen Farben markiert), führt einen Check der Konfiguration durch, und beendet sich dann wieder mit einem Fehler. Wir haben nämlich noch gar keine Konfiguration angelegt. Also starten wir Home Assistant nochmal auf den normalen Weg, diesmal mit hübschen farbigen Meldungen.
hass
Jetzt wird das Konfigurations-Verzeichnis .homeassistant unter /home/homeassistant angelegt und mit eine Standardkonfiguration geladen. Fehlende Pakete werden im Verlauf des ersten Starts installiert. Das ganze kann eine Weile in Anspruch nehmen. Bei mir hat es über 5 Minuten gedauert alle Komponenten zu laden. In der Ausgabe ist irgendwann die Zeile
2018-03-07 15:43:11 INFO (MainThread) [homeassistant.bootstrap] Home Assistant initialized in 322.72s
zu sehen. Jetzt können wir unter der IP die wir über DHCP erhalten haben die Weboberfläche von Homeassistant erreichen
Herzlichen Glückwunsch, Home Assistant läuft jetzt auf dem ARTIK Board. Da ich den Haupt-Server jedoch nicht ablösen möchte, werde ich die Instant auf dem ARTIK Board als Gateway zu den Schnittstellen nutzen, die der Intel NUC nicht mitbringt. Also Zigbee, Thread und Z-Wave. Jetzt brauche ich allerdings erst einmal ein paar Sensoren, die diese Protokolle verwenden.

Smarte WiFi-Steckdose S20 mit ESP8266

Ich habe mir die smarte WiFi-Steckdose S20 von itead bestellt.

Das Board in der Steckdose von vorne und hinten

Bei betrachten der Leiterplatte sieht man, dass ähnlich wie beim Sonoff Smart Switch ein AC/DC Konverter verbaut ist. Der Controller für die LEDs, den Schaltzustand und WiFi ist ein ESP8266. Der Programmier-Port ist auf 2,54mm Raster herausgeführt. So kann mit einem einfachen USB auf UART Kabel die Programmierung vorgenommen werden. Wichtig ist, dass zur eigenen Sicherheit die Programmierung nur vorgenommen wird, wenn das Board nicht in der Steckdose steckt!

Jetzt auf Amazon kaufen: Sonoff Smart Home WLAN Wifi Strom Schalter
Der Siebdruck zeigt, wie die Serielle Schnittstelle verbunden werden muss. Dazu kann entweder eine Stiftleiste eingelötet werden, oder eingepresst. Ich habe mich für die zweite Variante entschieden und eine 2,54mm Stiftleiste leicht mit der Zange verbogen, sodass die Pins nicht ganz sauber in einer Reihe sind, sondern leicht versetzt. So werden die Pins in den Löchern an die Oberfläche gedrückt und stellen eine Verbindung her.

Angeschlossen wird der USB auf UART Adapter wie folgt:

VCC – VCC
RX – TX
TX – RX
GND – GND

Wichtig ist, dass RX und TX also Receive und Transmit jeweils getauscht sind, nur so können die beiden Geräte miteinander kommunizieren. Um den ESP8266 in den Bootloader-Modus zu bringen, muss beim Power-Up der GPIO0 Pin auf Masse gezogen sein. Das ist beim S20 mit dem An/Aus Taster gelöst. Wenn der Taster gedrückt ist, wenn Spannung angelegt wird, schaltet der ESP8266 den Boot-Loader an und kann über die Serielle Schnittstelle programmiert werden.

Programmieren kann man den ESP8266 über viele Wege. Ich habe in einem früheren Blog-Post bereits davon gesprochen, dass ich mit hilfe der NodeMCU LUA Umgebung die Sonoff Smart Switches programmiert habe. Davon bin ich jedoch wieder weg, da ich kein vernünftig funktionierenden Update-Mechanismus hatte. Ich habe darauf hin dieses Projekt gefunden und erfolgreich bei mir eingesetzt.

So lässt sich mit diesen Schritten die S20 Smarte WiFi-Steckdose umprogrammieren.

Schritt 1: Firmware Image herunterladen

Ich habe heute versucht mit der aktuellesten Version der espurna Firmware ein Image zu erstellen. Das hat aber nicht funktioniert. Ich habe allerdings noch eins, das schon etwas älter ist, aber gut funktioniert. Das habe ich hier hochgeladen. Zum programmieren des S20 Controllers benötigt man beide .bin Dateien: fimware.bin und spiffs.bin. Das Programm mit dem die Firmware-Images auf den Speicher des S20 Boards geladen werden kann findet man auf GitHub, Ich habe idie Links für die 32bit und 64bit Version rausgesucht und kann ebenfalls unter dem Link gefunden werden. Ansonsten könnt ihr das Programm esptool verwenden. Das kann man auch im Internet kostenlos finden.

Schritt 2: S20 anschließen und Firmware hochladen

Wenn ihr die beiden Firmware Images und das Programmiertool heruntergeladen habt, müsst ihr nun ein Konsolenfenster öffnen und in das passende Verzeichnis wechseln.

Jetzt müsst ihr den passenden COM Port für das USB auf UART Interface finden. Ich verwende Linux und da heißt das Interface /dev/ttyUSB0 unter Windows heißt es COM16 oder eine andere Zahl.

Anschließend stecken wir das S20 Board mit gedrückter Taste an den USB Anschluss. Der ESP8266 startet jetzt im Bootloader-Modus. Das Programmiertool kann jetzt ein neues Firmware Image auf den Speicherchip laden.

Mit dem nodeMCU Firmware Programmer kann man unter Windows ganz einfach den ESP8266 programmieren. Dazu müsst ihr nur beide Images angeben und den Offset für das spiffs.bin Image eintragen.

Um mit dem esptool zu arbeiten, muss folgende Zeile im Konsolenfenster ausgeführt werden:

esptool -vv -cd ck -cb 115200 -cp „COM16“ -cf firmware.bin

Darauf hin wird das Firmware Image übertragen. Als nächstes müssen wir einen Reset durchführen, also USB Kabel wieder abziehen und erneut mit gedrücktem Taster einstecken. Jetzt ist der Controller wieder im Bootloader Modus und wir können das Dateisystem hochladen.

esptool -vv -cd ck -cb 115200 -cp „COM16“ -ca 0xbb000 -cf spiffs.bin

Danach ist das S20 Board komplett umprogrammiert und kann über ein eigenes Netzwerk erreicht werden.

Schritt 3: Netzwerk-Zugang einrichten

Wenn das S20 neu programmiert wurde, kennt es noch keine Netzwerk-Zugänge. Daher startet es im AP Modus. Das heißt, es erzeugt einen Access-Point. Dieser heißt S20-XXXXXX. Die X sind abhängig von der MAC Adresse des ESP8266 und bei jedem Gerät unterschiedlich. Es handelt sich um ein Netzwerk, dass mit dem Passwort „fibonacci“ gesichert ist.

Wenn ihr mit dem Netzwerk verbunden seid, könnt ihr unter der IP Adresse 192.168.4.1 das Admin-Interface der Smarten Steckdose finden. Dort können unter dem Punkt WIFI bis zu drei verschiedene Netzwerk-Zugänge angelegt werden. Wenn nach einem Neustart oder Verbindungsabbruch der ESP8266 eine neue Verbindung herstellen muss, werden diese drei Zugänge der Reihe nach ausprobiert. Wenn keine Verbindung erfolgt, wird wieder auf den AP-Modus ausgewichen.

Schritt 4: Schalten des Relays

Das Relay kann über mehrere Methoden geschalten werden. Die einfachste ist das Schalten über eine HTTP Adresse

http://192.168.0.145/relay/on 
http://192.168.0.145/relay/off

Die IP-Adresse ist natürlich an die Adresse der S20 Steckdose anzupassen.

Die Software bietet auch die Möglichkeit in ein MQTT Netzwerk integriert zu werden. Das verwende ich bei mir den damit kann man viele verschiedene Geräte mit einem gemeinsamen Protokoll zu verwalten. Im Admin-Interfache der Steckdose findet man auch den Punkt MQTT. Dort können die Zugangsdaten für den MQTT Server eingetragen werden. Die Software verbindet sich dann automatisch mit dem Broker und die Steckdose kann über MQTT Nachrichten gesteuert werden.

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
http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Sensoren/Temperatur/dht112mqtt/include/user_config.h?footer=minimal&slice=10:46 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++

Gleich zu Beginn sieht man, die Muster wurden schnell verpackt, um dem Liefertermin gerecht zu werden. Neben dem relativ aussagelosen Ettikett, dass einfach auf die Verpackung geklebt wurde finden sich keine Hinweise zu der neuen, bessern Embedded-Hardware-Plattform, die im Inneren auf uns wartet. Schnell aufmachen, um die trostlose Erscheinung der Verpackung hinter uns zu lassen und zu sehen, wie die Performance des neuen Gigabit Ethernet im Vergleich zum Alten Pi 2 abschneidet.

ESD – Schutzverpackung im passenden Kartonausschnitt

Der Pi 2 B++ ist in einer ESD-Schutzhülle verpackt und wird in einem Kartonträger geliefert. Was die trostlose Kartonhülle zu erwarten ließ wurde vom Inhalt weit überboten. Das Auspackerlebnis gleicht dem eines hochwertigen Apple Produktes. Nach genauer Betrachtung zeigt sich, dass die Module einfach nur mit auf das Board gebracht wurden. Die Hardware unterstütz zwar USB 3.0 allerdings erkennt der Kernel des aktuellen Rasbian den USB 3.0 und Ethernet Controller nicht. Doch wie bereits angekündigt soll das nächte major Release von Rasbian (RasbiAF) die nötige Software mitbringen.

rPi 2 B++ mit USB 3.0 und Gigabit Ethernet

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

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

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.

WLANKaffee Code Repository

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