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
http://192.168.0.101:8123
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.

Sonoff, S20, POW und SC mit neuer Firmware flashen

Von Itead.cc gibt es seit einiger Zeit verschiedene WiFi Smart Home Geräte. Einige dieser habe ich auch bei mir im Einsatz:

Allerdings läuft bei mir nicht die originale Firmware sondern Espurna. Diese gibt es aktuell in der Version 1.7 und stellt für mich alle gewünschten Funktionen bereit.

  • MQTT Interface für alle Daten
  • Webinterface für die einfache Konfiguration
  • OTA Update

Das Beste daran ist, dass die Firmware ohne Anpassungen mit Home Assistant kompatibel ist.

Hier mein Workflow für den Sonoff POW

Als erstes wird das Sigel gebrochen. Zurückschicken lohnt sich eh nicht.
Auf der Platine sind am Rand vier Punkte zu sehen. Diese sind folgendermaßen belegt:

Ein USB auf Serial Konverter mit 3.3V Signal (Amazon) wird angeschlossen. Wichtig ist, dass die Platine nicht von Außen mit Strom versorgt, oder sogar noch am Netzkabel hängt! Mit gedrücktem Knopf wird die Versorgungsspannung zugeschaltet. Jetzt befindet sich der ESP im Bootloader Modus und kann neu programmiert werden. Das mache ich mit Atom, der PlatformIO IDE.

Nachdem das Firmware Image geladen wurde, wiederhole ich die Prozedur mit Versorgungsspannung stecken, während der Knopf gedrückt ist. Jetzt ist das Dateisystem an der Reihe, das beinhaltet die HTML Applikation zum Steuern der Schalter und anzeigen der Sensordaten.

Wenn dann das Dateisystem geflasht wurde, startet die Software einen WiFi Access Point. Mit dem Passwort „fibonacci“ kann man sich dort anmelden. Mit dem Netzwerk verbunden kann man das Gerät unter der Adresse 192.168.4.1 erreichen. Dort muss das Standardpasswort geändert werden und ein neues vergeben. Anschließend kann man unter dem Menüpunkt WiFi das gewünschte WiFi Netzwerk eintragen, in dem sich der Schalter aufhalten soll.

Anschließend befindet sich der Schlater im Netzwerk. Unter MQTT kann dann noch die Adresse des MQTT Brokers eingetragen werden. Dieser übernimmt die Kommunikation zwischen den Geräten und Home Assistant.

Die Konfiguration für Home Assistant wird um folgende Punkte erweitert:
homeassistant:
#[…]
  customize:    
    sensor.sonoffpowa03803_leistung:
      friendly_name: Leistung
    sensor.sonoffpowa03803_spannung:
      friendly_name: Spannung

    sensor.sonoffpowa03803_relay:
      friendly_name: Schalter
#[…]

switch:
  – platform: mqtt
    state_topic: „/Herbert/switch/SONOFF_POW_A03803/relay/0“
    command_topic: „/Herbert/switch/SONOFF_POW_A03803/relay/0“
    name: „sonoffpowa03803_relay
    qos: 0
    payload_on: „1“
    payload_off: „0“

#[…]

sensor:
  – platform: mqtt
    state_topic: „/Herbert/switch/SONOFF_POW_A03803/voltage“
    name: „sonoffpowa03803_spannung“
    qos: 0
    unit_of_measurement: „V“
  – platform: mqtt
    state_topic: „/Herbert/switch/SONOFF_POW_A03803/power“
    name: „sonoffpowa03803_leistung“
    qos: 0
    unit_of_measurement: „W“

Nach einem Neustart stehen nun drei weitere Elemente Home Assistant zur Verfügung. Viel Spaß beim Nachbauen

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.

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.

Review of Sonoff Smart Home Schalter mit Wifi

Ich habe vor ein paar Tagen ein Sonoff Schalter bestellt. Dieser ist im Grunde ein ESP8266 Modul mit einem Relais. Zusätzlich bringt es alles mit, was man benötigt, um an Netzspannung betrieben zu werden. Es eignet sich also um direkt vor ein Gerät geschaltet zu werden.

Im Lieferumfang des Sonoff befindet sich auch eine App mit der man den Schaltzustand des Relais über das Internet auslesen und ändern kann. Die Konfiguration ist denkbar einfach. Das Sonoff mit Netzspannung versorgen, dann den Knopf am Gehäuse für ca. 3 Sekunden drücken und die LED blinkt schnell. Gleichzeittig öffnet das Sonoff einen WLAN Access Point. Mit der App wird dann der Accesspoint gefunden und sich damit verbunden. In der App kann dann konfiguriert werden, welches WLAN Netzwerk als Zugang zum Internet verwendet werden soll. Dazu wird die SSID ausgewählt oder eingegeben, Der Zugangsschlüssel, sowie die Einstellung ob feste IP oder DHCP verwendet werden soll, werden ebenfalls vorgenommen. Anschließend verbindet sich das Sonoff mit dem angegebenen Netzwerk und kann über die App im Netzwerk gefunden werden. Über einen Webdienst kann dann der Schalter betätigt werden.

Das ganze für 8€ ist natürlich ein Angebot, dass es vertretbar macht. Vergleichbare schaltbare Steckdosen sind wesentlich teuerer. Allerdings wäre es eine Verbesserung, wenn das Schalten auch über das lokale Netz funktioniert und nicht unbedingt eine Verbindung in das Internet voraussetzt. Hier kommt Herbert Mk3 ins Spiel. Darauf läuft ein MQTT Server. Dieser kann Nachrichten an MQTT Clients verteilen. Dazu muss das Sonoff allerdings auch MQTT sprechen können. Das ist allerdings in der aktuellen Firmware nicht vorgesehen.

Für den Einsatz mit MQTT muss also eine andere Firmware auf das Sonoff programmiert werden. Mit Hilfe des ESP8266 Arduino Projekts ist die Software kein Problem. Die Schaltung des ESP8266 auf dem Sonoff wurde von Peter Scargill veröffentlicht.

Mit einem handelsüblichen FTDI 3V3 Seriellen Kabels habe ich mich an die Pins gehängt und konnte so den Inhalt des SPI-Flash auslesen (Backup der originalen Firmware) und anschließend eine eigene Firmware aufspielen.

Für die Sonoff Plattform gibt es bereits verschiedene Firmwares. Hier zeige ich euch zwei Alternativen zur ITead Firmware und der eWeLink App. Außerdem die Firmware, die ich weiterentwickelt habe.

Sonoff-MQTT-OTA von arendst

Auf Basis der ESP Entwicklungsumgebund oder der Arduino Bibliothek für den ESP8266 kann mit dieser Firmware das Sonoff mit vielen neuen Features ausgestattet werden.

Kommunikation wird über das MQTT Protokoll abgewickelt. Dabei gibt es folgende Befehle:

  • Relais ein-, aus- oder umschalten
  • MQTT Topic ändern
  • OTA Firmwareupdate URL ändern
  • OTA Firmwareupdate ausführen
  • Status anzeigen

Der Knopf am Gerät wird verwendet für

  • Relais umschalten
  • Wifi Smartconfig
  • OTA Update durchführen
  • Gerät zurücksetzen
Da ich mal wieder Lust hatte in einer anderen Sprache als C zu programmieren, habe ich noch eine weitere Firmware herausgesucht.

nodeMCU Sonoff von Frederic HARS

Diese Firmware bietet auf Basis des LUA-Interpreters von NodeMCU den Schlatzustand über ein Webinterface oder MQTT zu ändern. Die Verbindung zum MQTT Server wir in einer globalen Konfigurationsdatei eingetragen und dann von NodeMCU hergestellt.
Der MQTT Broker kann mit dieser Firmware lediglich den Schaltzuusand zusenden. Das Sonoff kann den Knopf nicht auslesen, also auch nicht vor Ort betätigt werden.
Die LED zeigt den Schaltzustand an.
Die MQTT Verbindung unterstützt keine Passwortgesicherte Verbindung, es sollte also nur im privaten Netzwerk eingesetzt werden. die Konfigurationsdatei kann über das Webinterface können die LUA Skripte geupdated werden. Die NodeMCU Firmware bleibt allerdings fix und muss über eine Kabelverbindung geupdatet werden.
Aus Basis dieser Firmware habe ich Anpassungen gemacht, die meine Sonoffs für mein Hausautomationsprojekt funktionsfähig machen. Der Fork von mir beinhaltet nicht nur kleine Änderungen für die Funktionsweise des MQTT, sondern auch die Funktion des Knopfes zum Umschalten des Relais.

Diese weitern Funktionen werden noch kommen:

  • Wifi Smartconfig
  • Wifi Autoconfig für Herbert/PiDome
  • Konfiguration über MQTT
  • Speichern des letzten Schattzustands
  • OTA Script
  • OTA Verwaltung für Herbert/PiDome

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.

Converting a CC26xx Example Project Into Something Shareable


The example projects that are shipped with TI’s BLE SDK are great. They show a huge variety of use cases for the BLE stack. The codes provided are great resources when it comes to information on how to build software for the CC26xx chip family. Doing so many examples leaves us with code that is used more often than once and so it is linked into the project. Basically every file that consists of some code is a virtual link to a file on the folder structure. That leaves us with the problem that sharing the project with an SVN or GIT server only gives us the few local files and none of the code that is important. Changing the code is possible but you have to remind yourself, that the files are not considered to have changed when submitting to a version control system. 
To conquer this issue we need to have some of the files we are going to change or that are not part of the SDK in a local version on our file system. Luckily we can just copy the files to a folder in the project of the workspace. This way the files are preserved and as a next step we delete the links to the files in the project explorer.
I moved the following files to local folders:
  • simpleBLEPeripheral.c /.h
  • board_key.c /.h
  • simpleGATTprofile.c /.h
  • main.c
  • Board.c /.h
  • appBLE.cfg
You now have to add the local folders to the include paths of your project so the files can be found during build. Especially the Board.h which contains the information on how the chip is integrated in the circuit. Remember to remove all the unnecessary folders from your include paths. If your project uses available files from the example projects (like profiles and utils) you can leave the links in you project. To share the project you can use Subclipse or Git. You will have to install the same version of the SDK if you want to compile the project we created.
You can read up on this instructions on how you can create your own GATT Profile.

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

ESP8266 – 2: Ferngesteuerte Steckdose

Ein anständiger Name für eine Steckdose

Nachdem der Fenstersensor so weit funktioniert benötigen wir noch einen Aktor, der anhand des Signals sinnvolle Aufgaben erledigen kann. Wie zum Beispiel die Abzugshaube abschalten, wenn das Fenster geschlossen wird. Das ist ziemlich praktisch, wenn man nicht möchte, dass die Abzugshaube Luft durch den Kamin zieht. Daher die Regel, wenn das Fenster in der Küche offen ist, kann man die Abzugshaube einschalten, wenn nicht, dann nicht. Herzstück der Steckdose wird wieder ein ESP8266 Modul sein. Zusätzlich ein AC/DC Converter, der aus der Netzspannung eine akzeptable 5V macht. diese wird über einen LDO auf 3,3V für den Controller heruntergeregelt. Das Relais, dass die Phase schaltet wird aus den 5V versorgt und über einen Transistor gesteuert. Die Schaltung ist also so simpel, dass es sich noch nicht einmal lohnt einen Schaltplan zu zeichnen. Nichtsdestotrotz gibt es hier einen.

Der Aufbau auf Lochraster ist wenig Spektakulär, nur dass darauf zu achten ist, möglichst zu keiner Zeit die Netzspannung in der Nähe des Digitalteils zu haben. Das kann sehr schnell zu magischem Rauch führen.

Aufbau der Hardware im Inneren der Steckdose.

Der Code für den ESP ist wieder auf GitHub zu finden. Es besteht aus zwei Dateien, dem Startup Script und dem eigentlichen Program.
http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Aktoren/Steckdose/Timeout/init.lua?footer=minimalNach der Initialisierung wird der WiFi Accesspoint eingerichtet. http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Aktoren/Steckdose/Timeout/AP.lua?footer=minimal&slice=1:6Eine Funktion zum ausschalten der Steckdose durch ein Timeout wird festgelegt http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Aktoren/Steckdose/Timeout/AP.lua?footer=minimal&slice=7:11Der Server, der auf Port 80 nach Verbindungen lauschen soll wir über eine Zeile gestartet. Der Accesspoint hat nach vorgabe der NodeMCU Software die IP_Adresse 192.168.4.1, sie muss also nicht gesondert festgelegt werden. Zusätzlich wird noch ein Event-Handler angegeben, wenn der Server ein Request erhält. Fertig ist der Software Teil dieses zugegebenermaßen sehr einfachen Aktors. Allerdings kann die Hardware auch dazu verwendet werden, um in das Herbert-Netzwerk eingebunden zu werden. Allerdings ist Herbert am Einsatzort dieser Steckdose noch nicht verfügbar. http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Aktoren/Steckdose/Timeout/AP.lua?footer=minimal&slice=13:29

Wichtig ist, dass nach einem vollendeten Projekt der Schreibtisch in den Ursprungszustand zurück 
gesetzt wird, um beim Nächten Projekt alles wieder vor Ort zu finden.