Ausprobiert: Netzwerkweites Adblocking mit Pi-hole

Von Pi-hole hatte ich schon hin und wieder gehört, mich aber bisher nie so recht damit befasst. Auf Twitter flog der Name nun mal wieder an mir vorbei, was ich zum Anlass nahm, die Software mal auszuprobieren.

Was ist Pi-hole?

Pi-hole ist ein Werbeblocker. Jedoch nicht zu vergleichen mit Werbeblockern wie Adblock Plus oder anderen Browser-Erweiterungen.

Pi-hole blockiert Werbung für quasi alle Geräte im Netzwerk, ohne dass dort etwas installiert oder konfiguriert werden muss.
Die Software muss auf einem Linux-Gerät im Netzwerk installiert und im Router als DNS-Server eingetragen werden.

Wird nun beispielsweise eine Website aufgerufen, geht die Anfrage an das Pi-hole, wird dort mit einer Blockliste verglichen und entsprechend beantwortet. Versucht der Browser, eine Domain aufzurufen, die auf der Blockliste steht, wird diese Anfrage geblockt und die Werbung oder das Tracking-Script nicht geladen.

Dadurch, dass es nicht nur eine Browser-Erweiterung ist, blockt es auch Werbung in Apps und sogar im Smart-TV.

Was braucht man?

Die Hardware ist fast egal. Ich nutze einen Raspberry Pi 3. Als Betriebssystem wird offiziell Debian, Ubuntu, CentOS, Fedora und Raspbian unterstützt. Ich nutze der Einfachheit halber Raspbian ohne Desktop.

Nach der Grundinstallation kann bereits die Installation von Pi-hole erfolgen, hierfür muss lediglich der Webinstaller über die Konsole aufgerufen werden:

curl -sSL https://install.pi-hole.net | bash

Die Installation erfolgt geführt und Nutzerfreundlich und ermöglicht auch die Einstellung einer festen IP, was ja für den Betrieb als DNS-Server zwingend erforderlich ist, außerdem wird auch das Webinterface eingerichtet.

Wichtig ist, dass bei der Installation ein lighttpd auf Port 80 eingerichtet wird, hier wird das Webinterface angezeigt. Es sollte also kein anderer Dienst bereits Port 80 nutzen.

Und dann?

Nach der Installation ist das Pi-hole grundsätzlich fertig eingerichtet. Jetzt muss nur noch im Router der DNS-Server auf die IPs des Pi-hole eingestellt werden, damit alle DNS-Anfragen von diesem geprüft und beantwortet werden können.

Einstellungen? Statistiken?

Geht alles entweder über die Konsole, oder über das Webinterface. Das Passwort wird bei der Installation angezeigt.

Webinterface von Pi-hole
Webinterface von Pi-hole

Fazit

Ich habe das Gerät seit gestern Abend im Netzwerk und bin bisher echt zufrieden und habe nur zu Anfang beim Cache-Aufbau eine Verlangsamung der Anfragen gespürt. Seitdem laden Seiten deutlich schneller und sind bisher zuverlässig Werbefrei.

Ach ja, Seiten mit Adblock-Blocker wie bild.de kann man mit einem Pi-hole nicht mehr nutzen. Noch ein Vorteil.

Huawei Watch (1) recovery bootloop und fix

Da es aktuell vermutlich (Android Wear 2.0 ist verfügbar) vermehrt dazu kommt, dass Anwender ihre Huawei Watch erster Generation über die android debug bridge (adb) flashen und es dabei offenbar zu einem gemeinen Bootloop im Recovery kommen kann, hier nun meine Lösung dieses Problems.

Voraussetzungen:

  1. Android SDK Platform Tools installiert und lauffähig
  2. „Non preview image“ der Huawei Watch von der Android-Wear Entwickler-Seite bei Google herunterladen und entpacken

Der Fehler stellt sich wie folgt dar:

Die Uhr startet nicht korrekt, es wird ganz kurz der liegende Android mit Ausrufezeichen angezeigt (wirklich nur für den Bruchteil einer Sekunde), dann startet die Uhr neu und endet wieder im oben genannten Zustand und wiederholt das in einer Endlosschleife. Bei langem Druck auf die Krone geht die Uhr nicht aus, sondern startet wieder in den genannten Bootloop.

Die Lösung:

Zuerst muss die Uhr in den Fastboot-Modus gebracht werden. Da im Fehlerfall kein Zugriff über den Computer möglich ist, muss dies manuell über die Krone der Uhr gemacht werden.

  1. Krone drücken und halten. Nach einigen Sekunden startet die Uhr neu, das Huawei-Logo erscheint. Die Krone weiter gedrückt halten.
  2. Während das Logo aufleuchtet, vibriert die Uhr für etwa eine Sekunde. Danach sofort die Krone loslassen und kurz erneut drücken, bevor die Uhr noch einmal vibriert. Drückt man zu spät, landet man wieder im Bootloop. Drückt man richtig, landet man im Fastboot-Modus.

Nun muss die Uhr in den USB-Adapter gelegt und an den PC angeschlossen werden. In der Konsole muss geprüft werden, ob die Uhr erkannt wird, dies geschieht per

fastboot devices

Nun sollte die Uhr angezeigt werden. Wird kein Gerät angezeigt, hat das nicht geklappt und die weiteren Schritte werden nicht funktionieren.

Nun muss zuerst den Bootloader (im eingangs heruntergeladenen Ordner) geflasht werden:

fastboot flash bootloader /pfad/zur/datei/bootloader-sturgeon-m6e69f.img
fastboot reboot-bootloader

Ist dies geschehen, wird das System-Image geflasht:

fastboot -w update /pfad/zur/datei/image-sturgeon-m6e69f.zip

Auch dies muss fehlerfrei durchlaufen. Ist es geschehen, ist die Uhr wieder im Auslieferungszustand und kann neu eingerichtet werden.

Kreditkarten-Brute-Force

Letzte Woche, ich war gerade beruflich unterwegs, bekam ich plötzlich komische Mails von Amazon, dass Zahlungen zurückgewiesen wurden, obwohl mit den Kreditkarteneinstellungen alles stimmte. Am Freitag kam zuhause dann ein Brief an, in dem meine Bank mir mitteilte, dass meine Karte vorübergehend gesperrt sei, da seltsame Aktivitäten festgestellt wurden. Ich sah sofort auf dem Konto nach und tatsächlich gab es ein paar Tage zuvor eine Abbuchung über knapp 50€, die ich nicht zuordnen konnte und die kurz darauf wieder gutgeschrieben wurde.

Ich meldete mich bei der im Brief genannten Telefonnummer an, wenig später wusste ich, dass es genau um diesen Umsatz ging und dass der Händler aus den USA die Abbuchung 33 mal probiert hat, bevor sie beim 34. Mal tatsächlich erfolgreich war. Der Händler hatte da wohl selbst erfasst, dass da etwas nicht stimmen kann und die Gutschrift selbst veranlasst. Später, als bereits alle Zahlungen abgewiesen wurden, wurde auch noch versucht, ein Netflix-Konto zu eröffnen.

Soweit war das alles ja kein Problem, die Bank hat den Betrug noch vor mir entdeckt und initiativ gehandelt, so wie es ja sein soll. Ich bekomme eine neue Karte und die Sache ist erledigt.

Heute morgen jedoch fiel mir auf dem Weg zum Bäcker etwas auf: Wieso wurde die Zahlung 33 mal abgelehnt und beim 34. Mal hat plötzlich alles geklappt? Das kam mir reichlich unlogisch vor, bis mir auffiel, dass meine Kartenprüfnummer (CVV2) die 033 war. Wenn man nun beim Bezahlen alle Kombinationen, beginnend mit 000 durchgeht, benötigt man genau 34 Versuche, um den Treffer zu landen. Natürlich ist das reine Vermutung, aber es scheint mir, als würden Kreditkartendatendiebe, die nur die Kreditkartennummer, nicht jedoch die Prüfziffer kennen, tatsächlich per Brute-Force-Attacke die Prüfziffer zu erraten versuchen. Vielleicht sollten die Banken (manche tun das offenbar) nicht nur auf seltsame Vorgänge achten, sondern die Karte bei mehrmals falsch eingegebener CVV2 direkt sperren. Prinzipiell ist ja auch hier alles gut gegangen, aber immerhin konnte der Betrüger tatsächlich eine Zahlung mit der Karte ausführen, ohne dass die vielen Falscheingaben auffielen…

Web-Enabled Weihnachtsbaum

So langsam wird es ja ganz fürchterlich weihnachtlich und so flog heute in der Mittagspause ein interessantes Weihnachts-Bastelprojekt durch meine Twitter-Timeline: Ein mit bunten LEDs geschmückter, äußerst hübscher Plastik-Weihnachtsbaum, der über ICMP-Pakete (also Ping-Anfragen) an diverse IPv6-Adressen in verschiedenen Farben blinkt und über einen Livestream beobachtet werden kann:

Die Bedienungsanleitung ist auf der Seite des Erfinders zu finden.

ESP8266 & NodeMCU (LUA) Tutorial – Temperatursensor DS18B20 abfragen

Dies ist Teil zwei meiner Tutorialserie zum ESP8266.
Teil eins ist hier zu finden: „ESP8266 & NodeMCU (LUA) Einstiegstutorial

Inhalt

  1. Einleitung
  2. Voraussetzungen
  3. Hardware-Vorbereitung
  4. Firmware flashen
  5. Das Programm

Einleitung

Im ersten Teil der Reihe habe ich beschrieben, was der ESP8266 ist, wie man die Firmware auf den Controller läd und sich in der Programmierumgebung ESPlorer mit dem Chip verbindet und die Verbindung überprüft.

Hier soll es nun darum gehen, ein einfaches Programm zu erstellen, um mehrere Temperatursensoren DS18B20 einzubinden und Daten wie Chip-Adresse und die Temperatur anzuzeigen.

Voraussetzungen

Als Hardware wird der ESP8266 in Form des ESP-01 genutzt, grundsätzlich funktioniert natürlich jedes andere Modul mit mindestens einem GPIO-Pin. Dieses Tutorial ist aber ausdrücklich für den ESP-01 geschrieben und auch nur auf diesem getestet.

Ansonsten gehe ich davon aus, dass sowohl das ESPTool zum flashen der Firmware, als auch der ESPlorer bereits installiert sind und funktionieren.

Praktisch wäre es natürlich auch, wenn zwei Temperatursensoren DS18B20 vorhanden sind, diese sind auf ebay sehr günstig aus China, oder etwas teurer aus Deutschland erhältlich. Außerdem wird ein 4,7 Kiloohm-Widerstand benötigt.

Hardware-Vorbereitung

Zuerst sollten wir die Hardware entsprechend zusammen stecken. Grundsätzlich ist der Aufbau sehr ähnlich der bereits aus dem ersten Teil bekannten Konfiguration, hinzu kommen nur ein 4k7Ω Widerstand, sowie die beiden DS18B20. Die Grafik sieht der Übersicht halber ein wenig anders aus, ist aber tatsächlich nur in den genannten Details unterschiedlich zur Grafik aus dem ersten Teil.

Der ESP8266 auf einem Breadboard mit dem zwei Temperatursensoren DS18B20
ESP8266 mit DS18B20

Auf dem Breadboard sieht das in etwas komprimierter Form bei mir so aus:

Der ESP8266 mit zwei DS18B20 zusammengesteckt auf einem Breadboard
ESP8266 mit DS18B20 auf Breadboard

Wie man sieht, habe ich die Sensoren direkt auf das Breadboard gesteckt, ebenso den Widerstand.

Firmware flashen

Hier soll es nicht darum gehen, wie die Firmware auf den Chip kommt, sondern darum, dass die korrekte Firmware auf den Chip kommt. Im weiteren Verlauf des Tutorials wird eine Bibliothek genutzt, die verschiedene Module in der Firmware des ESP8266 benötigt.

Die von mir genutzte Firmware enthält die Module

  • file
  • gpio
  • net
  • node
  • ow
  • tmr
  • uart
  • wifi

geflasht ist die float-Version, da dies für die genutzte Bibliothek des DS18B20 notwendig ist.

Wer mag, kann auch die von mir genutzte Firmware hier herunterladen, dann ist alles genau gleich.

Wie die Firmware auf den ESP8266 kommt, habe ich ja bereits geschrieben, dies sollte nun geschehen.

Das Programm

Nun sollte alles bereit sein: Die Hardware ist zusammengesteckt, die Firmware ist auf den ESP8266 geflasht und die Programmieroberfläche ESPlorer ist installiert und einsatzbereit.

Um die Sensoren über unser einfaches Programm abfragen zu können, benötigen wir die Bibliothek ds18b20.lua, die ich vor längerer Zeit mal im Git-Repo von NodeMCU heruntergeladen habe. Ich weiß leider nicht mehr genau, welche der Bibliotheken es war, daher stelle ich auch diese hier zum Download zur Verfügung. Die Bibliothek kann an beliebiger Stelle entpackt werden und dann im ESPlorer geöffnet werden. Hierzu einfach im Reiter „NodeMCU & MicroPython“ auf „Open“ klicken, zu der Datei navigieren, auswählen und öffnen:

Bibliothek ds18b20.lua in ESPlorer öffnen
Bibliothek ds18b20.lua in ESPlorer öffnen

Die geöffnete Datei muss nicht weiter angepasst werden, sie wird nun per Klick auf „Save to ESP“ in den Speicher des ESP8266 geladen und ist ab diesem Zeitpunkt auf dem Gerät nutzbar.

Nun schreiben wir das eigentliche Programm, welches die eben gespeicherte Bibliothek nutzt, um Daten von angeschlossenen DS18B20-Sensoren zu empfangen und auszugeben. Der Dateiname ist hier ds18b20-test.lua.

-- Testprogramm um mehrere DS18B20 zu lesen

-- GPIO-Pin festlegen
pin = 3

-- DS18B20-Modul und GPIO initialisieren
t=require("ds18b20")
t.setup(pin)
addrs=t.addrs()

-- Anzahl der DS18B20 ausgeben
print('Anzahl Sensoren: ' .. table.getn(addrs))

-- Adresse(n) der DS18B20 ausgeben
for k, v in pairs(addrs) do print('Adresse Sensor ' .. k .. ':', v:byte(1,8)) end

for k, v in pairs(addrs) do
print('Temperatur Sensor ' .. k .. ': ' .. t.read(v,C) .. ' Grad Celsius')
end

-- Alle Ressourcen wieder freigeben
t = nil
ds18b20 = nil
package.loaded["ds18b20"]=nil

Die Kommentare sagen eigentlich schon so ziemlich alles: Der nutzbare GPIO-Pin heißt in der Firmware Pin 3 und wird am Anfang des Programms festgelegt. Die eben auf das Gerät geladene Bibliothek wird geladen und der Pin übergeben. Nun wird gezählt, wieviele Sensoren gefunden wurden, die Zahl wird ausgegeben, danach die Adressen der Sensoren, sowie der Temperaturwert.
Zum Schluss werdend die Ressourcen wieder freigegeben.

Auch dieses Programm kann hier heruntergeladen werden, da vermutlich Hochkommata etc. hier falsch dargestellt sein dürften.

Diese Datei muss nun wie schon die Bibliothek per Klick auf „Save to ESP“ in den Speicher des ESP8266 geladen werden. Ist dies geschehen, wird das Programm bereits ausgeführt. Es sollte also in etwa so aussehen:

Das Programm wird im ESPlorer in den Speicher geladen und danach automatisch ausgeführt.
Das Programm wird gespeichert und ausgeführt

Wir sehen also, dass die beiden Sensoren funktionieren und uns neben ihrer Adresse auch die Temperatur melden.

Um das Programm nun über den ESPlorer ausführen zu lassen, müssen wir nur den Befehl

dofile("ds18b20-test.lua");

in der Befehlszeile unten im ESPlorer ausführen und bekommen schon unser gewünschtes Ergebnis zurück:

Das Programm wird im ESPlorer mit dem Befehl dofile("ds18b20-test.lua"); ausgeführt.
DS18B20 abfragen über ESPlorer

Damit geht dieses Tutorial auch wieder zuende, im (hoffentlich bald folgenden) nächsten Teil steigen wir dann etwas tiefer ein und lassen das Programm zyklisch auf dem Controller laufen und die Werte über eine einfache Webseite im LAN/WLAN ausgeben.

ESP8266 & NodeMCU (LUA) Einstiegstutorial

Vor ein paar Wochen stolperte ich über einen Chip mit dem klangvollen Namen ESP8266. Julian Ilett stellte ihn in einem Video vor und kurz darauf machten sich zwei Module aus China auf den Weg zu mir.
Da der ESP8266 ein für Bastler ziemlich interessanter Chip ist, habe ich mich entschlossen, ihm ein paar Artikel zu widmen, dies ist der erste.

Inhalt

  1. Der ESP8266
  2. Das Tutorial
  3. Die Hardware
  4. Zusammenstecken
  5. NodeMCU Firmware flashen
  6. Die Programmierumgebung

Der ESP8266

Vom ESP8266 wird häufig als WLAN-Modul gesprochen und tatsächlich sieht man im Netz viele Projekte, die ihn als reine Seriell-zu-WLAN-Schnittstelle für beispielsweise einen Arduino nutzen.
Der ESP8266 ist allerdings deutlich mehr, denn neben der WLAN-Funktionalität ist er ein kompletter Microcontroller, der mit verschiedenen Firmwares geflasht und dann beispielsweise in C, C++ oder LUA programmiert werden kann.

Der Microcontroller hat soweit ich weiß 12 GPIO-Pins, die unter anderem I2C, SPI, UART, GPIO und PWM bereitstellen und einen 3,3V-Pegel führen. In Verbindung mit seiner WLAN-Schnittstelle eignet er sich damit ziemlich gut als Controller für die ganzen modischen IoT-Dinge, wie beispielsweise einen WLAN-Temperatursensor oder -Lichtschalter.

Der Microcontroller wird auf verschiedenen Breakout- und Devboards angeboten, die mal mehr, mal weniger Funktionen des Chips unterstützen.

Das Tutorial

In diesem Tutorial soll es darum gehen, den Chip über eine Serielle Schnittstelle (UART) mit dem Computer zu verbinden und zwei der wichtigsten Tools in Betrieb zu nehmen.

Ich benutze in diesem Tutorial ein Breakout-Board mit dem Namen ESP-01, welches neben der UART-Schnittstelle und den für den Betrieb wichtigen Pins nur einen nutzbaren GPIO-Pin nach außen führt. Dafür bekommt man es für einen niedrigen, einstelligen Euro-Betrag aus China oder auch aus Deutschland.

Frontansicht des ESP-01 Breakout-Boards
Der ESP8266 als ESP-01 Breakout-Board

Natürlich können auch andere Ausführungen genutzt werden, populär ist beispielsweise das Development-Kit von NodeMCU, welches schon eine eigene USB-zu-Seriell-Schnittstelle mitbringt und neben den 5V per USB keine weitere Spannungsversorgung benötigt. Außerdem hat dieses Dev-Board einen Reset-Knopf und einen Knopf für GPIO0, welcher zum Flashen neuer Firmware benötigt wird, doch dazu später mehr.

Der ESP8266 aufgelötet auf ein Development-Board von NodeMCU
ESP8266 auf dem NodeMCU-Devboard

Ich benutze in diesem Tutorial einen Linux-PC, manche verwendete Software gibt es für Windows eventuell nicht und bei der Installation ist die Vorgehensweise sicherlich eine andere.

Die Hardware

Neben dem schon angesprochenen ESP8266 benötigen wir entweder eine Serielle Schnittstelle und einen Pegelwandler wie einen MAX3232, um auf den vom ESP8266 benötigten LVTTL-Pegel von 3,3V zu kommen, oder einen USB-Adapter, der beispielsweise per FTDI-Chip direkt LVTTL-Pegel hat. Einen solchen USB-zu-TTL-Adapter gibt es auch auf ebay für wenig Geld.

Um die Teile unkompliziert zusammen stecken zu können, sollte man auf ein Breadboard, also ein Elektronik-Steckbrett und fertige Jumper-Kabel zurückgreifen. Beides gibt es sehr günstig in tausendfacher Ausführung bei ebay.

Außerdem benötigt das Modul selbst noch eine Spannungsversorgung. Viele USB-zu-TTL-Platinen bringen eine zwischen 5V und 3,3V einstellbare Versorgungsspannung mit, diese ist jedoch zu instabil und der benötigte Strom übersteigt meistens die Kapazität der Platine. Es sollte also eine externe 3,3V-Spannungsquelle genutzt werden. So etwas gibt es auch bei ebay fertig für die Verwendung mit Breadboards.

Zusammenstecken

Das Modul ESP-01 ist leider nicht Breadboard-freundlich, muss also entweder fliegend verdrahtet, oder per selbstgebautem Adapter auf das Breadboard gesteckt werden. Ich nehme hier die erste Lösung und verbinde das Modul fliegend mit Jumperwire.

Da die Module üblicherweise völlig undokumentiert verschickt werden und das ESP-01 oft auch kein gedrucktes Pinout hat, habe ich hier einen Belegungsplan gemacht.

Pinout des ESP8266 ESP-01 Moduls
Pinout des ESP-01 Moduls

Nun müssen die Pins des ESP8266 über das Breadboard mit dem FTDI-Modul und der Spannungsversorgung verbunden werden. Wichtig ist, dass die Spannungsversorgung auf 3,3V eingestellt ist, 5V würden das Modul zerstören. Das Schema sieht wie folgt aus:

Der ESP8266 angeschlossen an das Breadboard und verbunden mit einer FTDI-Schnittstelle
ESP8266 ESP-01 an FTDI

GND wird mit GND auf dem Breadboard verbunden, VCC mit +3,3V, ebenfalls an 3,3V wird der Pin CH_PD angeschlossen.

RXD und TXD werden gekreuzt mit RXD und TXD des FTDI-Adapters verbunden, GND der Schnittstelle muss auf jeden Fall auch zu GND auf dem Breadboard gebrückt werden. Wie weiter oben schon beschrieben, sollte man nicht versuchen, den ESP8266 über die Spannungsversorgung des FTDI-Adapters zu betreiben, VCC des Adapters bleibt also unbelegt.

RST am ESP8266 ist der Reset-Anschluss, der genutzt wird, um das Programm auf dem Chip neu zu starten. Dies kann später auch Softwareseitig geschehen, der Pin kann freigelassen werden.

GPIO0 ist ein Pin, der leider nicht für externe Anwendungen genutzt werden kann. Er wird auf GND verbunden, um in den Flash-Modus zu gelangen. Im Normalbetrieb ist er nicht belegt.

GPIO2 ist der tatsächlich nutzbare GPIO-Pin, der für externe Anwendungen wie OneWire, Digital I/O usw. genutzt werden kann. Dazu in weiteren Tutorials mehr.

NodeMCU Firmware flashen

Im Auslieferungszustand ist der ESP8266 vermutlich mit der AT-Firmware geflasht. Bei den billigen China-Modulen kommt es auch vor, dass überhaupt keine lauffähige Firmware vorhanden ist und das Modul darüber nicht ansprechbar ist.

Nun heißt dieses Tutorial aber „ESP8266 & NodeMCU (LUA) Einstiegstutorial“, also sollte auch die NodeMCU-Firmware auf den Chip kommen. Wir benötigen folgendes dazu:

  • Firmware
  • Flash-Tool

Die Firmware kann entweder aus dem Sourcecode gebaut werden, oder aber über eine bequeme Weboberfläche zusammen geklickt werden. Der Einfachheit halber entscheiden wir uns hier für letztere Option und lassen uns die Firmware von der Seite nodemcu-build.com bauen und per Mail zusenden. Die ausgewählten Module reichen eigentlich aus, um den Chip in Betrieb zu nehmen und auch eine LED blinken zu lassen.

Achtung: Vor dem Flashen muss der Pin GPIO0 mit GND verbunden werden, andernfalls kann die Firmware-Ebene nicht erreicht werden.

Das Flash-Tool ist ein Python-Programm, das über pypi installiert werden kann (Vorausgesetzt ist Python >= 2.7 und pip):

pip install esptool

Ist das Flash-Tool installiert und die Firmware vorhanden, starten wir den ESP8266 und verbinden die serielle Schnittstelle mit dem Computer. In der Konsole sollte dmesg nun als eine der letzten Zeilen etwas derartiges ausgeben:

FTDI USB Serial Device converter now attached to ttyUSB0

Wir wissen also, dass der PC den Adapter erkannt hat und dass er die Gerätedatei /dev/ttyUSB0 bekommen hat.

Nun müssen wir nur noch die Firmware flashen. Die Syntax dafür ist:

python esptool.py --port /dev/ttyUSB0 write_flash 0x00000 /pfad/zur/firmware.bin

Das sieht dann in natura so aus:

Konsole mit der Ausgabe des esptool beim Flashen des ESP8266
NodeMCU-Firmware auf den ESP8266 flashen mit esptool

Nun ist die neue Firmware auf dem ESP8266 und kann nach einem Neustart genutzt werden. Nicht vergessen, GPIO0 wieder von GND zu trennen, um in den Betriebsmodus zurückzukehren.

Die Programmierumgebung

Der ESP8266 kann nun über LUA programmiert werden. Um die Verbindung herzustellen und einige Helferlein an die Hand zu geben, gibt es eine Programmierumgebung namens ESPlorer. Die Software benötigt Java und läuft auf allen Betriebssystemen, die das unterstützen. Herunterladen kann man ESPlorer bei GitHub.

Programmieroberfläche ESPlorer, links der Code-Editor, rechts der serielle monitor
Programmieroberfläche ESPlorer

Oben kann nun die serielle Schnittstelle ausgewählt werden, über „Open“ verbindet sich die Oberfläche mit dem ESP8266. Dieser Antwortet mit so etwas wie:

NodeMCU custom build by frightanic.com
	branch: master
	commit: c8037568571edb5c568c2f8231e4f8ce0683b883
	SSL: false
	modules: file,gpio,net,node,ow,tmr,uart,wifi
 build 	built on: 2016-05-27 20:54
 powered by Lua 5.1.4 on SDK 1.4.0
lua: cannot open init.lua

Eventuell wird auch erst eine Fehlermeldung angezeigt. Startet man den ESP8266 neu, sollte er aber mit der Oberfläche kommunizieren. Meldet er sich nicht korrekt an, heißt das nicht, dass es nicht funktioniert hat, das kommt schon mal vor. Tippt man unten in das Textfeld neben dem grünen „Send“ Knopf

=node.chipid()

sollte der ESP mit der Chip-ID antworten. Tut er das, scheint es auch geklappt zu haben.

ESPlorer zeigt die Begrüßung der Firmware, aber auch Fehlermeldungen an
Der ESPlorer verbunden mit dem ESP8266

Damit ist dieses Tutorial schon beendet, der Chip wurde angeschlossen, geflasht und kann mit dem ESPlorer verbunden werden. ESPlorer unterstützt nun die Programmierung des Chips mit LUA-Scripts. Interessante Scripts und Bibliotheken findet man im GitHub der NodeMCU-Firmware.

Ich hoffe, ich konnte den Einstieg einigermaßen sinnvoll erklären, bei Fragen bitte einfach einen Kommentar hinterlassen.

Service-Kabel z.B. für Wago-Controller sehr günstig „selbst gemacht“

In einem meiner letzten Beiträge schrieb ich noch darüber, wie das Kommunikations-Kabel von Wago (ein USB-Kabel mit proprietärem Stecker für die Service-Schnittstelle auf diversen Controllern) unter Virtualbox genutzt werden kann und auch, dass es sich eigentlich nur um einen USB-zu-TTL-Adapter handelt.

Patrik stellte per Kommentar die Frage, ob man dann nicht auch statt des teuren Kabels einen normalen USB-zu-TTL-Adapter nutzen kann. Natürlich kann man.

Wer also statt des etwa 50€ teuren Kabels, das dann an 364 Tagen im Jahr irgendwo in einer Kiste verstaubt, lieber einen kleinen USB-Adapter für 2€ nutzen möchte, kann das problemlos tun.

USB-zu-TTL-Converter FTDI FTD1232 am Service-Port einer Wago 750-841
Einfacher USB-zu-TTL-Converter an einer Wago 750-841

Ich habe hier einen FTDI-Adapter für 2,20€ aus China, der per Mini-USB (da musste ich erstmal nach einem Kabel suchen, alles Micro-USB inzwischen) an den Computer angeschlossen wird. Er wird erkannt als:

ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

Benötigt werden die Pins VCC, GND, TX und RX. Die Belegung am Wago-Controller ist von oben nach unten:

  • TxD
  • RxD
  • +5V
  • GND
Pinout der Wago-Service-Schnittstelle
Pinout der Wago-Service-Schnittstelle

TxD und RxD werden logischerweise mit TX und RX verbunden, jedoch üblicherweise gekreuzt (was natürlich darauf ankommt, ob der genutzte Adapter auf der „Pin-Seite“ noch 1:1 belegt ist), VCC wird mit +5V verbunden, GND mit GND.

Pinout des FTDI USB-zu-TTL-Adapters
Pinout des FTDI USB-zu-TTL-Adapters

Das wars, mehr ist nicht zu tun. Das Kabel wird unter Windows beispielsweise in den Wago Ethernet Settings erkannt und kann zur Kommunikation genutzt werden.

Das Low-Cost Kabel wird in den Ethernet Settings erkannt und kann zur Kommunikation genutzt werden
Der USB-zu-TTL-Adapter in den Ethernet Settings

Selbst gemacht steht übrigens aus dem Grund in Anführungszeichen, weil man ja hier nicht wirklich etwas selbst macht, außer einen FTDI-Adapter zu kaufen und anzuschließen.

HTML5-Visualisierungen auch mit CoDeSys 2.3

CoDeSys in der Version 2.3 (also der klassischen Version, die unter anderem von den meisten WAGO-Controllern ausschließlich unterstützt wird) bringt eine eigene Webvisualisierung mit. Die Visu kann über CoDeSys zusammengesetzt werden, sie wird mit dem Programmdownload auf den Controller übertragen.

Das Problem daran: Die Visu besteht aus einem Java-Applet, das von manchen Browsern überhaupt nicht ausgeführt wird, unter anderem von Chrome oder mobilen Browsern.

CODESYS 3.5 bringt eine neue Visualisierung auf HTML5-Basis mit, die deutlich besser funktioniert. Jedoch laufen die „klassischen“ WAGO-Controller nicht mit CODESYS 3.5, wer nicht gerade einen PFC200 oder PFC100 einsetzt, wird davon nichts sehen.

Es gibt ein Projekt namens WebVisu auf sourceforge, das sich dieses Problems annimmt. Es stellt auf dem integrierten Webserver der Controller eine HTML5-Visu bereit, die mit CoDeSys 2.3 zusammenarbeitet und in wenigen Schritten auf den Controller „installiert“ werden kann.

Installiert insofern in Anführungszeichen, als dass diese Installation lediglich aus dem Kopieren einer einzelnen HTML-Datei auf den Controller besteht. Laut Wiki ist WebVisu kompatibel mit der WAGO 750-841 und dem Beck IPC, zufällig besitze ich einen uralten Controller 750-841 bei dem leider die Buskontakte nicht mehr besonders zuverlässig sind, aber zum Testen reicht es allemal.
Vermutlich funktioniert die Visu auch bei den anderen 750-8xx Controllern mit CoDeSys-WebVisu, davon habe ich allerdings kein Gerät zum spielen.

Die WebVisu.html wird einfach auf dem Controller unter /webserv abgelegt und ist danach unter der IP des Controllers unter /webserv/WebVisu.html zu finden.

Die Visualisierung wird unter CoDeSys ganz normal erstellt, das JAVA-Applet ist nachher auch problemlos nutzbar. Die HTML5-WebVisu ist nur zusätzlich vorhanden.

Zum Test habe ich einfach einen inkrementierenden Wert auf eine 8-fach Ausgangsklemme geschrieben und diesen Wert außerdem in der Visu als Zahlenwert, als LED-Zustand und als Kreisdiagramm dargestellt. Außerdem habe ich noch einen Toggle-Taster mit einer booleschen Variable eingefügt, um auch diesen Fall testen zu können.
Direkt in CoDeSys sieht das so aus:

Webvisualisierung und ST-Programm in CoDeSys 2.3
Webvisualisierung und ST-Programm in CoDeSys 2.3

In Chrome fehlt das Kreisdiagramm, generell werden neben dynamischen Formen wie dem Kreissegment auch Tabellen und Skalen nicht angezeigt. Vermutlich fehlen diese Darstellungen in der HTML5-WebVisu einfach:

HTML5 WebVisu in Chrome auf dem Desktop
HTML5 WebVisu in Chrome auf dem Desktop

Auf dem Smartphone wird die WebVisu quasi identisch dargestellt:

HTML5 WebVisu in Chrome auf einem Android Smartphone
HTML5 WebVisu in Chrome auf einem Android Smartphone

Die Bedienung der Schaltfläche funktioniert übrigens einwandfrei, sowohl im Desktop-Browser als auch auf dem Smartphone und die Grafikaktualisierung ist ziemlich flott und ohne Ruckeln.

Alles in allem also eine sehr passende Lösung für Leute, die eine einfache Webvisualisierung unter CoDeSys 2.3 erstellen wollen, die auch ohne JAVA-Applet und damit auch auf mobilen Geräten bedienbar ist.

WAGO USB Service Cable unter Linux in einer Virtualbox benutzen

Um mit SPS-Komponenten zu kommunizieren gibt es verschiedene Wege und fast alle führen zum Ziel. Bei bestimmten Einstellungsarbeiten oder Firmware-Updates ist es aber sinnvoll, die meistens vorhandene Service-Schnittstelle der Controller zu nutzen.

Jeder Hersteller bietet Service-Kabel an, die zu den eigenen Schnittstellen passen, die Kabel sind natürlich immer unterschiedlich.
Auch WAGO bietet ein „WAGO USB Service Cable“ an. Für Windows gibt es einen speziellen Treiber für dieses Kabel, für Linux nicht. Ich bin mir ziemlich sicher, dass dieser Artikel auch auf Siemens S7 und LOGO, sowie auf die meisten anderen SPS-Hersteller anwendbar ist, davon habe ich allerdings keine Altgeräte zum Basteln da.

Ich bin mir sicher, außer mir gibt es noch viele andere SPS-Menschen, die Zuhause Linux nutzen und zum Herumprobieren eine Virtuelle Maschine mit Windows laufen haben, in der die Entwicklungsumgebung läuft. Das Kommunikationskabel läuft allerdings in z.B. Virtualbox nicht ohne nachzuhelfen, wobei es sich wirklich um eine Kleinigkeit handelt.
Denn: Auch wenn jeder Hersteller ziemlich teure Kommunikationskabel in verschiedenen Ausführungen anbietet, eines haben sie gemeinsam: Es sind ziemlich stinknormale USB (oder RS232) auf TTL Konverter, die unter Debian als ttyUSB erkannt werden. Es muss lediglich der Virtualbox-Benutzer in die Gruppe dialout aufgenommen werden, damit er es benutzen darf:

usermod -aG dialout BENUTZERNAME

In der Virtualbox erscheint es bei installiertem Windows-Treiber dann ganz normal in der USB-Geräte-Auswahl:

WAGO USB Service Cable in den USB-Geräten von Virtualbox
WAGO USB Service Cable in den USB-Geräten von Virtualbox

Aktiviert man es dort, kann man es beispielsweise in den WAGO Ethernet Settings als Kommunikationsschnittstelle nutzen:

Virtualbox: WAGO USB Service Cable in den Ethernet Settings
Virtualbox: WAGO USB Service Cable in den Ethernet Settings

ownCloud für Android hat Probleme mit Sonderzeichen

Ich betreibe seit langer Zeit ownCloud-Instanzen, um damit Daten zwischen diversen Geräten zu synchronisieren. Installation und Konfiguration sind sehr einfach und es gibt (neben WebDAV) native Clients für alle von mir genutzten Betriebssysteme.

Vor einiger Zeit habe ich ein Passwort geändert. Die Desktop-Clients unter Windows 7 und Debian funktionierten mit dem neuen Passwort anstandslos, ownCloud für Android hingegen nicht. Nach einigem Herumprobieren fand ich heraus, dass es eine hochgestellte 3 war (³), die das Problem verursachte. Ich änderte daraufhin das Passwort erneut (es enthielt weiterhin Sonderzeichen) und es funktionierte auf allen Geräten.

Seitdem ist einiges an Zeit vergangen und letztens erinnerte mich meine Passwort-Routine, das ownCloud-Passwort mal wieder zu ändern. Gesagt, getan und oh Wunder, ein Sonderzeichen funktionierte auf dem Android-Client nicht.

Dieses Mal war meine Neugier größer, ich deaktivierte die Zwangsumleitung auf HTTPS und schnitt den Netzwerkverkehr der App beim Einloggen über eine unverschlüsselte Verbindung mit. Die Login-Daten mit einigen Sonderzeichen sehen in der App so aus:

ownCloud-Login mit Sonderzeichen
ownCloud-Login mit Sonderzeichen

Im Mitschnitt sieht man schnell, wieso das Passwort nicht funktionieren kann (abgesehen davon, dass der Nutzer nicht existiert):

Netzwerk-Mitschnitt vom Login bei ownCloud mit Sonderzeichen
Netzwerk-Mitschnitt vom Login bei ownCloud mit Sonderzeichen

Halten wir also fest: Bestimmte Sonderzeichen werden von der „originalen“ ownCloud-Android-App zu Fragezeichen umgewandelt und so gesendet. Die „Standard-Sonderzeichen“ wie ?$% usw. scheinen zu funktionieren.

Da die App sowieso nicht unbedingt meine Definition einer guten Synchronisations-App erfüllt: Kann mir jemand eine gute WebDAV-App nennen, die unter Android die Verbindung mit ownCloud übernimmt und vielleicht auch mit den spezielleren Sonderzeichen klar kommt?