Da immer wieder Fragen in irgendwelchen Beiträgen gestellt werden, die mit dem Beitrag nichts zu tun haben, möchte ich hier eine Lösung anbieten.
Also mache ich hier eine Off-Topic Ecke auf. Mal sehen, ob das läuft 🙂
Nachdem ich Code für den ESP8266 publiziert habe (klick), der einen NTP Zeitserver abfragt, sind immer wieder Anfragen gekommen. Die NTP Abfrage liefert UTC Zeit und die Fragesteller wollten eine Umrechnung auf lokale Zeit inklusive automatischer Sommer/Winterzeit Umstellung.
Ich es jetzt endlich mal geschafft aus einem noch nicht publizierten Projekt ein Demoprogramm für die Fragestellung zu bauen.
Der Demo-Code basiert auf dem Webserver Beispiel. Für die Uhrzeit Funktionalität werden drei Komponenten benutzt:
1. Der NTP Code aus dem o.g. Beispiel.
2. Die timelib Bibliothek von M. Margolis. Diese kann über die Arduino IDE installiert werden.
3. Die Timezone Bibliothek von J. Christensen. Diese muss manuell installiert werden; die Bibliothek gibt es hier: https://github.com/JChristensen/Timezone
Die Programmlogik:
In der timelib Bibliothek kann man einen sogenannten Sync-Provider definieren. Diese Funktion gibt die aktuelle Uhrzeit zurück. Weiterhin wird definiert, wie oft die Uhrzeit synchronisiert werden soll. Wir setzen das Intervall auf täglich (86400 Sekunden). In der Funktion wird die Zeit von einem NTP Server abgefragt. Die timelib Bibliothek ist damit auf UTC gesetzt.
Wenn die Webseite aufgerufen wird, wird die Zeit mit Hilfe der timezone Bibliothek umgerechnet. Die Funktionen der timelib können genutzt werden, um die umgerechnete Zeit in ein lesbares Format umzuwandeln.
Der ESP8266 Webserver ist per http://localtime/ erreichbar, wenn der Router lokale Netzwerknamen unterstützt (@Vodafone: Eure Easyboxen sollten das so langsam mal lernen – AVM kann’s doch auch). Ansonsten die IP aus dem seriellen Log nehmen.
Hier gibt es den Code: ESP_NTP_LocalTime_Demo
Viel Erfolg!
Ich bin günstig an einen einen XciteRC Rocket 400 Quadrocopter (aka Cheerson CX20) gekommen. Mit im Paket war eine „720p 5MP tiltable Camera“. Diese Kamera nimmt während des Flugs Videos auf. Die Kamera kann während des Flugs mit der Fernbedienung über den Aux1 Drehknopf nach oben und unten geneigt werden.
Drei Punkte haben mich genervt:
Die Fernbedienung hat noch einen unbenutzten Aux2 Drehknopf und der Quadrokopter auch einen unbenutzten Servo Ausgang.
Bastelziel:
– Video mittels Aux2 auch während des Fluges an (Aux2 rechts)
– Mit Aux2 Fotoserien während des Fluges machen (Aux2 links).
– Video/Fotomodus stoppen (Aux2 Mitte)
Analyse der verbauten Kamera & Elektronik:
Mit Googles Hilfe war die Kamera relativ schnell identifiziert. Es handelt sich um eine 5MP Foto / 1MP Video Kameraboard mit der Bezeichnung „2501“. Die Kamera ist bei den typischen China Stores unter 10€ gelistet. Die Kamera selbst ist eine OV5640 (das hat auch nochmal ein Potential – vielleicht für ein späteres Projekt). Das 2501 Board selbst ist nicht wirklich ideal. Die JPEG Kompression im Video Modus ist zu stark und funktioniert nicht ideal; insbesondere ist die Datenrate für die resultierende Bildqualität zu hoch. Das Board kann statt 720p@60Hz auch 1080p@30Hz aufnehmen. Leider scheint die entsprechende Umschaltung durch eine angepasste Firmware in der Fabrik zu erfolgen. Schade.
Offenbar hat sich XciteRC/Cheerson eine besondere Firmware für die Kamera machen lassen. Im China-Datenblatt des Kameramoduls ist von einem 4-Draht Interface die Rede (5V, GND, Video on low (3.3V!), Photo on low (3.3V!)). Diese Ansteuerung versteht unsere Version nicht. Statt dessen erzeugt ein kurzer Pulse (>100ms) auf Pin3 ein Foto. Ein längerer Druck (ca. 2 Sekunden) startet ein Video.
Wichtig ist noch, dass der/die Datenpins einen Schaltvorgang durch Ziehen auf Masse erzeugen und im High-Zustand auf 3.3V liegen. Das Datenblatt weist explizit darauf hin, dass die Moduspins nur 3.3V kompatibel sind.
Weiterhin sind im Datenblatt Blinkmuster für die LEDs auf der Platine definiert.
Diese LEDs sind bei der Quadrokopter Kamera auch nach außen gelegt. Die Anschlussbelegung sieht so aus:
Notwendiges Material
Arduino Mini Pro (ATmega 168 langt, 328 geht auch) – ca. 1.20€
1 Jumperkabel weiblich – 1 Cent (40 Stück gibt es für 50ct)
Widerstände (1/8 Watt) 2.2kOhm und 1kOhm – einige Cent (100 Stück gibt es für 60ct)
(Preise Stand 05/17 auf aliexpress/ebay)
Sonstiges:
Doppelseitiges Klebeband / Heisskleber
Elektroniklötkolben + Lötzinn
kleiner Kreuzschraubenzieher
Modifikation des Kamerakabels:
Die Kamera hat zwei Anschlusskabel. Eines für den Servo der die Neigung steuert. Das zweite Kabel versorgt die Kamera mit Strom. An dem entsprechenden Stecker fehlt das dritte Kabel für das Servo Signal. Der Stecker hat einen leeren Platz. Man kann ein weibliches Jumperkabel nehmen, die Plastikummantelung auf einer Seite ausklipsen und den Metallstecker in den leeren Platz einklipsen. Die andere Seite wird einfach abgekniffen und später am Arduino angelötet.
Umbau der Kamera:
Die Kamera baut man für die Aktion am besten vom Quadrokopter ab. Auf der Unterseite befinden sich vier kleine Kreuzschrauben. Diese lösen und die Gehäuseschale inklusive Rückseite & Vorderseite (Linse) herausheben. Das sieht dann so aus:
Die Platine kann man entnehmen. Die Unterseite hat die Anschlüsse, an die wir heran wollen.
Die Kontakte sind mit einer silikonartigen Masse verklebt. Diese Masse muss man vorsichtig entfernen.Die Kabel für den kleinen Schalter habe ich komplett entfernt. Die Kamera wird in Zukunft über die Fernbedienung bedient.
Das folgende Verkabelungsschema muss jetzt realisiert werden:
Der Arduino Mini Pro wird parallel zur Kamera an +5V und GND angelötet: +5V VCC & GND GND. Bei den LED Kabeln am LED Modul bitte beachten, dass das schwarze Kabel nicht GND/Masse ist. Das positive Potentiale für die externen LEDs sind am schwarzen & am roten Kabel. Das schwarze Kabel kommt an den Anschluss D2 (meistens steht 2 dran). Das rote Kabel mit D3 verbinden. Die LED Anschlüsse haben ein Potential von ca. 2.9V wenn sie leuchten. Das langt, um bei mit 5V betriebenen Arduino eine Eins (High) zu signalisieren.
Zwischen D4 und GND kommen die beiden Widerstände wie im folgenden Bild gezeigt. Dabei kommt der 2.2kOhm Widerstand an GND und der 1kOhm Widerstand an. Zwischen den Widerständen wird ein Kabel angelötet. Dieses wird mit dem Tasteranschluss auf dem Kameraboard verbunden. Durch den die Widerstände wird ein Spannungsteiler realisiert, der am Mittelangriff ca. 3.3V erzeugt. Dieses Potential ist für den Kameraeingang geeignet.
Schließlich wird noch das Servokabel an D12 angeschlossen.
Der Mini Pro wird dann mit dickem doppelseitigem Klebeband auf dem Kameramodul fixiert.
Der Spannungsteiler & die Anschlüsse werden dann noch mit etwas Heißkleber vergossen. In der unteren Gehäuseschale muss noch der mittlere Plastikpin vorsichtig gekürzt werden. Dieser Pin hält die Platine. Da wir den Aufbau erhöht haben, muss er Pin verkürzt werden. Der Pin soll am Ende aber die Platine noch fixieren, also nicht zuviel abknipsen.
Das Arduino Programm:
Der Code für den Arduino ist simpel aufgebaut – ganz ohne Interrupts, Timer etc. Für diese Problemstellung ist das ausreichend. Am Anfang wartet der Code erst mal 20 Sekunden, bevor irgendetwas passiert. In diesem Zeitraum startet der Quadrokopter und die Fernbedienung wird gepairt. Eventuell muss man die Aux Regler auch noch richtig einstellen.
Danach wird per pulseIn die Länge des Servopulses gemessen und der Ausschlag berechnet. Ausgewertet wird so:
Im Foto Modus wird ein ein Foto gemacht. Danach wartet der Arduino bis die FotoLED aus geht. Danach wird noch eine Sekunde gewartet und wieder ein Foto gemacht. Die Fotoserie wird fortgesetzt, solange der Fotomodus aktiv ist. Der Video Modus wird gestartet, in dem der Kamerapin auf Masse gezogen wird, bis die VideoLED das erste Mal aus geht (diese blinkt im Videomodus). Dadurch wird das Video robust gestartet. Das Video läuft, bis der Modus durch Aux2 beendet wird.
Es findet im Code keine Prüfung statt, ob eine SD Karte eingelegt ist. Es ist letztlich auch egal, da die Kamera dann schon mit beiden LEDs blinkt.
Hier gibt es den Code: XciteRC_HD_Cam_Remote_Control
Der Code wird über einen Programmieradapter eingespielt. Fertig. Wer genau hinschaut, kann erkennen, dass ich bei dem Programmierer-Anschluss die 5V Verbindung weggeknipst habe. Wenn man den Arduino am PC hat und parallel den Quadrokopter mit Batterie betreibt, sollte man die +5V Potentiale trennen. Wer einfach nur den Arduino programmieren will, braucht das nicht. Das Kamerakabel für den Servoanschuss sollte dann aber vom Quadrocopter abgezogen sein.
Wenn alles umgebaut und programmiert ist, sieht die Kamera so aus:
Der Anschluss am Quadrokopter erfolgt als Servo 2:
Hier sind noch zwei Bilder zum Vergleich. Die Bilder aus dem Videomodus habe ich mittels VLC (Frame speichern) erzeugt.
Klick auf die Bilder öffnet sie größer.
Foto:
Video:
Viel Erfolg beim Nachbau. Auf ähnliche Art und Weise sollten sich auch andere Kameras über die Fernsteuerung ansprechbar machen lassen.
P.S.: Falls jemand Aux1 & 2 tauschen möchte: Einfach die beiden Servoanschlüsse am Quadrocopter auch vertauschen (nicht die Polung! -> S1 <->S2).
Ich habe einen HP Pavilion 17-F Laptop dessen technischen Daten sich ganz ordentlich lesen: Intel i7 5500 CPU, 8GB RAM, GeForce 840M GPU, 1GBit LAN, FullHD IPS Panel
ABER beim PCIe WiFi Adapter hat HP unnötig gespart:
Broadcom BCM43142 mit nur 1×1 Stream und nur 2.4GHz Band Unterstützung. Ergo ist die maximale Datenrate 72MBit/s.
Der WiFi Chip macht weiterhin unter Windows 10 (64Bit) noch viel Ärger: Treiber nach Erwachen aus dem Sleepmode öfters unter 10 MBit, Abstürze, WiFi Adapter weg bis Reboot, HD Streams vom Sat Receiver instabil. Irgendwann hatte ich die Nase voll und habe eine WiFi Aufrüstung beschlossen.
Ziel der Umrüstung neben der Problembeseitigung:
– 3×3 Mimo Streams
– 450MBit Datenrate meiner Fritzbox bei 2.4GHz nutzbar
– Support für 5GHz WiFi
Für ganze 7,86€ hat es geklappt.
Ich habe dann zunächst nach PCIe Karten mit halber Länge, 3×3 MIMO Streams und AC Unterstützung geschaut. Leider gibt es solche Karten fast nicht. Und die wenigen Angebote liegen bei 60-70€ für die Karte. Die Alternative ist eine 3×3 Karte mit WiFi N Standard. Im 2.4GHz Band besteht kein Unterschied. Im 5GHz Band kann man damit ebenso wie bei 2.4GHz „nur“ maximal 450MBit erreichen. Eine AC Karte könnte hier mehr. Für mich langt die N Karte: Es wurde eine Intel Centrino Ultimate-N 6300 PCIe Karte für 5,86€ inkl Versand über Aliexpress.
Laptop geöffnet, PCIe Karte getauscht und MIST: HP hat ein zweites Mal gespart. Es ist nur eine WiFi Antenne verbaut, obwohl es das Modell auch mit 2 MIMO Streams gab. Im Bild sieht man die eingebaute Karte und dahinter das einzige Antennenkabel.
Immerhin hat das HP UEFI BIOS keine Beschränkung der einsetzbaren WiFi Karten mehr. Eine Zeit lang hatten einige Hersteller darunter HP den Tausch des WiFi Kartenmodells unterbunden. Falls Ihr eine solche Umrüstung bei einem anderen Laptop durchführen wollt, könnte eine solche Sperre vorliegen. Die Karte lief bei mir nach dem Einbau direkt; Windows 10 hat die passenden Treiber an Bord.
Für zweimal 1€ habe ich dann zwei WiFi Antennen mit IPEX Anschluss nachbestellt. Eine Antenne ist ja schon drin.
Diese Antennen habe ich dann erst einmal in das Gehäuse das Laptops eingebaut – um es vorwegzunehmen: So klappt es nicht gut.
Die Tests mit diesem Aufbau waren sehr ernüchternd. Der Grund ist auch schnell auszumachen. Zur Funkentstörung ist das Gehäuse mit Metall bedampft. Von oben sind die Antennen von der Tastatur überdeckt, die auf der Unterseite mit einer Abschirmung versehen ist. Die Antennen sitzen so in einem Metallkäfig.
Die Lösung liegt darin, eine Position für die Antennen zu finden, die nicht abgeschirmt ist. Die Originalantenne ist wie bei den meisten Laptop als Drahtantenne im Displayrahmen verbaut. Eine entsprechende Aufrüstung wäre als Alternative auch denkbar. Bei dem vorliegenden HP Pavilion 17-F bietet sich eine Montage der Antennen im Bereich der Lautsprecher an:
Dieser Bereich ist nicht abgeschirmt und die Antennen können auf den Bassreflexkästen aufgeklebt werden.
Mit dieser Position ist der Empfang gut und hohe Datenraten werden auch über größere Distanzen erreicht.
Um die volle Datenrate im 2.4GHz Band zu erreichen, muss man noch im Router und im Windows Treiber der Karte die Unterstützung für 40MHz Kanäle aktivieren. Für den Router ist das eine routerspezifische Einstellung. In Windows 10 findet man die passende Einstellung hier; der Wert muss von 20MHz auf auto gestellt werden:
Mit diesen Einstellungen sieht der WiFi Status an meiner Fritzbox 7362 im 2.4GHz Band so aus:
Die 450MBit/s sind sicherlich der theoretische Maximalwert. Die Fritzbox bestätigt im WLAN Menü Connects zwischen 400-450Mbit auch im Nachbarraum des Routers. Ebenso sind 450MBit Connects im 5GHz Band möglich. Als praktisches Ergebnis sind alle oben beschriebenen Probleme verschwunden 🙂
Es wird mal wieder Zeit für einen Beitrag. Der noch nicht publizierte Projektstau ist groß, aber im Job ist gerade viel los 🙂
Ich habe vor einiger Zeit die ITEAD WiFi Homeautomation Produkte entdeckt, die auf dem ESP8266 beruhen. ITEAD stellt für die Produkte auch die volle Dokumentation inkl. Schaltpläne zur Verfügung. Genauer gesagt geht es hier um die WiFi Steckdose mit dem Namen Sonoff S20 und den Sonoff Switch, der ein WLAN Schalter in Form eines Schnurschalters ist.
Der Preispunkt der Produkte ist ziemlich gut. Ein Eigenbau für den Preis dürfte schwierig bis unmöglich sein. Die WiFi Steckdose bekommt man für 13€, den Schalter für unter 7€. Die Produkte haben kein CE Zeichen. Der innere Aufbau ist aber sehr gut und ein CE dürfte nach meine Meinung kein Problem sein, wenn es denn beantragt würde. Zur ITEAD Original Firmware kann ich nichts sagen. Ich habe bisher alles sofort auf meine Firmware umgeflasht. Es wird dazu auch noch ein Post folgen.
Netterweise hat ITEAD auf den Platinen schon vorgesehen, dass man eine Stiftleiste einlöten kann. Stiftleisten gibt es bei ebay für weniges als nen Appel und nen Ei. Das Öffnen der Gehäuse ist einfach. Der Schalter ist nur geklipst, die Steckdose ist geklipst und hat eine zusätzliche Schraube.
Auf der Platine der Steckdose ist die Pinbelegung angegeben. Beim Schalter habe ich sie auf dem Foto notiert. Beim Schalter ist zusätzlich noch GPIO14 herausgeführt.
Und jetzt kommt die obligatorische Warnung:
Die Geräte bieten einen sehr einfachen Zugang zur Heimautomatisierung. ABER die 230V Netzspannung sind kein Spass. Die nötige Sachkunde ist Voraussetzung. Auf keinen Fall dürfen die Geräte offen an 230V betrieben werden. Keines Falls darf man die Platinen mit dem Rechner programmieren, wenn sie an 230V angeschlossen sind.
Keine gute Idee: Pins aus dem Gehäuse herausführen.
Die Programmierung der Boards erfolgt analog zu einem normalen ESP8266 Board, siehe auch:
https://blog.thesen.eu/esp8266-wlan-microcontroller-mit-der-arduino-ide-programmieren/
Generell kann ich eine Programmierung ohne Programmierboard nicht empfehlen. Es gibt immer wieder Anleitungen, welche ESP8266 Boards direkt an FTDI oder CH340 Chips hängen, weil diese ja einen 3.3V Ausgang haben. Das ist nicht empfehlenswert, weil diese Pins bis maximal 50mA belastbar sind. Der ESP8266 zieht im Mittel 80mA (wenn WiFi an ist) und bis über 200mA als kurze Pulse. Ein Programmierboard sorgt für eine stabile Spannnung und eine Wandlung der Pegel zwischen 3.3V und 5V.
Wer ein ESP8266 Programmierboard hat, kann das einfach mit ein paar Jumperkabeln verwenden.
Hier sind einfach die Anschlüsse eines Programmierboards für einen ESP8266-01 genommen worden. GPIO14 hängt in diesem Beispiel auf der Seite des Programmierboards in der Luft. Der ESP8266-01 würde auf dem Foto mit der Antenne nach unten zeigen.
Um in den Programmmiermodus zu kommen, muss man aber ein wenig tricksen. GPIO0 und Reset des Programmierboards sind ja nicht verbunden. Es geht aber ganz einfach. GPIO0 ist über den Taster auf der Sonoff Platine erreichbar. Und statt Reset kann man einfach den USB Stecker neu anstecken. Konkret:
Danach kann man das Board ganz normal z.B. mit der Arduino IDE programmieren.
Die GPIO Belegung:
Hardware Ausstattung:
Es ist also der selbe großer Flash Baustein verbaut wie im ESP8266-12. Es sollten als alle ESP Projekte laufen.
Viel Erfolg!
Mit einem Amazon Echo oder Echo Dot wird es eigentlich erst interessant, wenn man Lichter, Steckdosen & Rolladen steuern kann. Von Haus aus unterstützt der Echo einige WLAN-fähige Produkte direkt. So kann man Echo kompatible WiFi Steckdosen kaufen oder auch mit einer Hue Bridge das Philips Hue System einbinden. Die Komponenten sind allerdings meistens etwas teurer und teilweise man noch eine spezielle Bridge kaufen.
Mit einem Rasperry Pi kann man mit ein wenig Konfigurationsarbeit so ziemlich jedes WLAN-fähige Gerät mit dem Echo zusammenbringen. Alternativ kann man auch Alexa Skills programmieren. Das ist aber nicht ganz trivial und so habe ich mich entschieden erst einmal eine Basiskompatibilität mit Hilfe von HABridge herzustellen.
Im Folgenden gehe ich davon aus, dass ein Pi erfolgreich am Netz läuft. Auf dem Pi kann man einen Service namens HABridge installieren. HABridge ist ein Emulator für diverse Smarthome Protokolle, wie z.B. Philips Hue. Somit kann HABridge eine Philips Hue Brigde emulieren („nachmachen“). In HABridge eingetragene Geräte werden vom Echo erkannt („Alexa, erkenne Geräte“). So gut das klingt, muss ein Wort der Warnung hier hin: HABridge hat aktuell eine massive Sicherheitslücke und exponiert root Rechte auf dem Webinterface an jeden Nutzer im Netz.
Java prüfen & installieren:
HABridge erfodert java. Das ist auf den meisten Pi Installationen nicht drauf. Ein Test ist einfach:
pi@raspberrypi ~ $ java -version java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) Client VM (build 25.0-b70, mixed mode)
Wenn statt dessen eine Fehlermeldung kommt, muss zunächst java installiert werden:
pi@raspberrypi ~ $ sudo apt-get update &amp;amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;amp; sudo apt-get install oracle-java8-jdk
Das dauert eine Weile.
HABridge installieren:
Wenn java installiert ist, kann man die HABridge installieren. Es gibt mehrere Varianten auf github. Ich habe diese hier genommen: https://github.com/bwssytems/ha-bridge/
pi@raspberrypi:~ $ cd pi@raspberrypi:~ $ mkdir habridge pi@raspberrypi:~ $ cd habridge pi@raspberrypi:~/habridge $ wget https://github.com/bwssytems/ha-bridge/releases/download/v3.5.1/ha-bridge-3.5.1.jar
HABridge automatisch starten:
Wie auf der github Seite von HABridge beschrieben wird, geht ein automatischer Start per rc.local schief, weil zum Startzeitpunkt das Netzwerk des Pi noch nicht funktioniert. Dort ist auch beschrieben, wie man einen automatischen Start per systemctl einrichtet. Diese Methode klappt aber mit vielen Distributionen nicht. Die Alternative ist die Einrichtung als Daemon über init.d. Hier ist ein passendes Starterscript: habridge
Dazu die beiliegende Datei nach /etc/init.d kopieren, den Besitzer auf root ändern und die Nutzerrechte anpassen. Zu schnell? – Ok:
Die Date habridge auf Eurem Windows Rechner in einem Texteditor öffnen und alles kopieren. Dann per putty auf dem pi einloggen und:
pi@raspberrypi ~ $ sudo nano /etc/init.d/habridge
Es ist nun ein Editor aufgegangen. Dort kann man per rechter Maustaste die kopierten Inhalte einfügen. Danach mit Strg+X und bejahen der Frage (je nach Sprache Y und J) abspeichern. Nun noch die Rechte anpassen:
pi@raspberrypi ~ $ sudo chmod 755 /etc/init.d/habridge
HABridge wird jetzt bei einem Neustart automatisch hochgefahren. Es geht auch manuell:
pi@raspberrypi ~ $ /etc/init.d/habridge start
HAbridge ist jetzt auf Port 81 konfiguriert. Damit bleibt Port 80 für Webserver Anwendungen frei.
HABridge konfigurieren & Gerätenamen wählen:
Mit einem Browser auf dem PC sollte jetzt ein Zugriff auf habridge klappen. Falls Euer Pi den Netzwerknamen raspberrypi trägt, geht das so: http://raspberrypi:81
Es erscheint die HABridge Hauptseite; hier ein Screenshot. Bei der ersten Einrichtung sind natürlich noch keine Geräte eingetragen.
Nun muss ein Bridge Gerät hinzugefügt und eingerichtet werden. Folgende Einträge steuern eine Lampe an, die per fhem gesteuert wird. fhem ist dabei auf dem selben pi installiert.
Wenn das Gerät erfolgreich hinzugefügt wurde, erscheint es auf der HABridge Hauptseite und kann mit Test ON und Test OFF gesteuert werden.
Alles was sich mit eine URL steuern lässt, kann man so in HABridge eintragen. Die entsprechende URL im HABridge Konfigurationsdialog als On URL bzw Off URL eintragen. Bei FHEM kann man sich die Kommandos von der eigenen FHEM Webseite per „Link kopieren“ besorgen. Programme, die auf dem Pi selbst laufen, bekommen die IP 127.0.0.1 (=localhost) zugewiesen. Mit den weitern Feldern im Konfigurationsdialog kann man auch komplexere Paramterübergaben realisieren. Für die meisten WLAN Steckdosen kann entsprechende URLs im Netz finden. Damit man die Geräte zielsicher erreichen kann, muss man dafür sorgen, dass sie eine konstante IP Adresse vom Router zugewiesen bekommen. Wie das geht, hängt vom Routermodell ab; also bitte im Menü des Routers nachsehen.
HABridge und Scripte auf dem Pi:
Man kann mit HABridge alternativ auch ein Script auf dem Pi starten. Dazu stellt man den Device Type auf Execute Script/Program stellen. Das folgende Beispiel zeigt die Konfiguration, um das script tf.sh im home Verzeichnis des Nutzers pi auszuführen.
Warnung – HABridge hat ein massives Sicherheitsloch
An dieser Stelle muss ich eine deutliche Warnung anbringen. Die Scripte werden von HABridge mit root Rechten ausgeführt. Somit stellt HABridge ein frei zugängliches Webinterface zur Verfügung, welches Scripte auf dem Pi mit root Rechten ausführbar macht. Keinesfalls sollte ein Pi mit HABridge vom Internet her zugreifbar sein. Im Heimnetz ist HABridge nur akzeptabel, wenn alle Nutzer 100% vertrauenswürdig sind. Auf Dauer sollte hier unbedingt ein Passwortschutz her, allerdings reagieren die Macher von HABridge bisher nicht.
Alexa anlernen:
Einfach: „Alexa, Geräte erkennen“
Nach ein paar Sekunden meldet Alexa die erkannten Geräte. Erster Test: „Alexa, Licht anschalten“.
Alexa kommt nicht mit jedem Gerätenamen klar. Aktuell sind Umlaute problematisch. Ebenso mag Alexa keine Gerätenamen, die man nicht im Wörterbuch findet.
Ein paar Beispiel, die bei mir gut funktionieren: Licht, Stehlampe, Jalousie, Weihnachtsbaum. Nicht gut gehen: Rolladen, Deckenfluter, Schrank
Vermutlich wird sich die Amazon Spracherkennung noch verbessern. Aktuell muss man ein wenig probieren. Wenn man die Namen in HABridge per edit ändert, einfach danach Alexa nochmal nach den Geräten suchen lassen.
Tipp: Von HABridge aus „My Echo“ gehen. Dann auf Einstellungen –> Verlauf. Dort kann man sehen, was Alexa verstanden hat.
Aktuell bekommt man in Deutschland die Echo Produkte nur auf Einladung und damit praktisch nicht zu kaufen. Dürfte wohl ein etwas merkwürdiges Markteinführungsvorgehen von Amazon sein, denn in den USA bieten sie die Echo Dots in 5er Packs an.
Ich habe einen Echo Dot als Black Friday Deal für $39,95 in den USA erstanden und mitgebracht. Vorher habe ich nirgendwo herausgefunden, ob man denn den US Echo Dot problemlos in Deutschland auf Deutsch ans Laufen bekommt.
Geht problemlos. Hier die Details:
1. Stromversorgung:
Anders als der Echo hat der Echo Dot einen MicroUSB Stromanschluss. Es ist also kein Problem, den Dot mit einem anderen Netzteil zu versorgen. Zu beachten ist allerdings, dass das Amazon Netzteil bis zu 1.8A liefert. Man sollte also zu einem, 2A Handynetzteil greifen. Alternativ kann man auch das US Netzteil verwenden. Dieses ist von 100-240V Wechselstrom geeignet. Man braucht dann natürlich einen Adapter für den Stecker. Was wirklich günstiger ist, dürfte vom Einzelfall abhängen.
2. Einrichtung:
Die Einrichtung geht problemlos über die Alexa App. amazon.com und amazon.de sind nicht die identischen Plattformen. Die Geräteliste scheint aber übergreifend realisiert. Kauft man auf .com einen Echo, so erscheint er nach dem Versand auch in der .de „Meine Apps und Geräte“ Liste.
3. Eindeutschen
Mein Echo Dot sprach denn zunächst Englisch mit mir. Die Umstellung auf Deutsch und deutsche Einheiten geht über die Alexa App:
Einstellungen –> Mein Echo Dot –> Sprache auf Deutsch, Einheiten auf metrisch.
Für diese Änderungen muss der Echo online sein.
Hier nochmal als Bildfolge:
Fertig. Alexa spricht Deutsch.
Letztes bin ich gefragt worden, ob ich eine Nikon Coolpix S2800 mit defekten LCD Display reparieren könnte.
Hier ist die Dokumentation der Reparatur. Ein passendes Ersatzdisplay konnte ich auf aliexpress für knapp 5€ inkl. Versand bekommen. Nach 4 Wochen war das Ersatzteil da.
Zur Reparatur:
Eine Warnung vorne weg. Die Kamera enthält einen fest verbauten Blitzkondensator (nicht der normale Akku). Dieser ist typischerweise auf ~300V aufgeladen. Wenn man die passenden Kontakte anfasst, bekommt man ordentlich einen „gewischt“. Wer diesbezüglich unsicher ist, lässt die Kamera mit ausgebautem Akku eine Woche liegen.
Am Anfang den Akku herausnehmen und die SD Karte entfernen. Nun werden 6 kleine, schwarze Kreuzschrauben am linken, rechten und unteren Gehäuserand entfernt.
Danach kann man die Vorderseite der Kamera abnehmen. An der unteren Seite beginnen und die vordere Schale anheben. Oben ist die Schale eingeklipst. Sie muss mit etwas Gefühl ausgehakt werden.
Bei der Demontage fällt wahrscheinlich die kleine Streuscheibe der Fokus-LED heraus. Bitte aufpassen, dass die kleine Scheibe nicht verloren geht. Sie wird beim Zusammenbau an der passenden Stelle in den Kameracorpus eingesetzt. Von vorne lassen sich die zwei silbernen Schrauben oben im silbernen Rahmen entfernen.
Nun kann man die hintere Gehäuseschale abnehmen; auch hier wieder unten beginnen.
Die zwei silbernen Halteschrauben des Tastenfeldes entfernen.
Das Tastenfeld wird seitlich heraus geschoben. Es ist mit zwei Rastlaschen neben dem Display fixiert und muss auf der Außenseite der Kamera etwas angehoben werden.
Das Tastenfeld lässt ich jetzt hochklappen. Ich habe die Blechwinkel am Tastenfeld leicht verbogen, um besser an die Platine unter dem Tastenfeld zu kommen. Die Blechwinkel lassen sich beim Rückbau leicht wieder zurückbiegen. Das Display lässt sich aus der Halterung heben; es ist nur geklemmt und wird vom Gehäuse gehalten.
Man erkennt unter dem Tastenfeld den Anschlussstecker für das Display. Um das Kabel zu entfernen, muss der Stecker entriegelt werden. Dazu muss man VORSICHTIG die schwarze, längliche Abdeckung auf dem Stecker nach oben klappen. Dabei bitte drauf achten, diese Abdeckung nicht zu zerstören.
Wenn die Abdeckung 90 Grad nach oben gekappt wurde, kann man das Flachbandkabel des Displays herausziehen. Das Kabel des neuen Displays einschieben und die schwarze Klappe wieder nach unten klappen und einrasten. Nicht vergessen die Schutzfolie vom neuen Display abzuziehen. Die Kamera wird wieder in umgekehrter Reihenfolge zusammengebauen. Die Streuscheibe (s.o.) dabei nicht vergessen 🙂
Ergebnis:
Viel Erfolg
Amazon hat vor 3 Tagen begonnen in Deutschland Dash Buttons zu verkaufen. Ich habe direkt einen bestellt und probiert, wie man statt Ariel zu bestellen Kommandos auf dem Raspberry Pi auslösen kann. Hier sind die ersten Ergebnisse.
Im Prinzip sind die Infos im Netz vorhanden. Allerdings gibt es doch einige Fallstricke. Da es mittlerweile zwei Hardware Versionen des Dash Buttons gibt, sind die meisten Anleitungen nicht mit der in Deutschland verkauften Version JK29LP kompatibel. In diesem Beitrag wird der Dash Button so wie in den allermeisten Internet Einträgen nicht ge-„hackt“. Der Button selbst wird also nicht verändert.
Was ist an dem neuen Dash Butteon JK29LP anders?
Zunächst einmal ist eine andere Hardware verbaut, wie dieser Blog Beitrag zeigt.
In Kürze:
Amazon hat aber auch eine Reihe von Änderungen vorgenommen, die den Einsatz am Pi verändern und zum Teil auch erschweren:
1. Der Dash Button ist ohne Trick nicht mehr deaktivierbar ohne dabei die WLAN Konfiguration zu löschen.
2. Der Button meldet sich im Netz nicht mehr per Address Resolution Protocol (ARP), sondern per UDP Bootstrap Protokoll (bootp) an.
Hier also ein Vorgehen, das klappt:
MAC-Adresse des Dash Buttons herausfinden:
Die meisten Router zeigen im Log an, welche WLAN Geräte sich mit dem Netz verbinden. Wenn man den Dash Button normal per Amazon App einrichtet, so sind beim Abschuss der Einrichtung die letzten Einträge vom Dash Button.
Bei der Fritzbox: System->Ereignisse->WLAN; aber vorher noch „Auch An- und Abmeldungen protokollieren“ anhaken.
Internet Zugriff des Dash Buttons nach Konfiguration sperren:
Wie schon erwähnt beruhen die meisten Infos im Netz auf dem alten Dash Button und einer alten Firmware. Dieser Idee der Hacks ist es, den konfigurierten und im WLAN registrierten Dash Button in der Amazon-App auf „keine Bestellung“ zu setzen. Diesen Eintrag gibt es bei dem neuen Button und der aktuellen App nicht. Entweder ein Button ist für einen Kaufvorgang konfiguriert, oder er muss deaktiviert werden. Wenn man einen Dash Button in der Amazon App deaktiviert und den Button das nächste Mal drückt, so nimmt der Button ein letztes Mal Kontakt mit dem Amazon-Server auf. Der Amazon-Server teilt dem Button dann mit, dass er deaktiviert wurde und der Button löscht die bestehende WLAN Konfiguration. Damit ist der Button nicht mehr im heimischen WLAN registriert und auch nicht mehr nutzbar.
Der Trick: Den Button normal per App aktivierten. Dann in der Router Konfiguration den Internet Zugang des Dash Buttons unterbinden. Bei einer Fritzbox geht dies, in dem man den Button in den Einstellungen für die Kindersicherung auf „gesperrt“ stellt. Der Button kann jetzt noch in das lokale Netzwerk, aber nicht mehr mit Amazon kommunizieren. Der Dash Button behält dann seine WLAN Konfiguration, weil das Löschkommando nicht kommt. Um diese Einstellung vornehmen zu können, braucht man die MAC Adresse des Dash Buttons.
Wenn man die MAC erfolgreich gesperrt hat, leuchtet der Dash Button nach dem Drücken zunächst weiss auf und blinkt dann rot (=Bestellung nicht erfolgreich).
LED Verhalten des Dash-Buttons:
Zur Fehlersuche habe ich hier noch kurz das LED Blink/Leuchverhalten notiert, soweit es sich mir erschlossen hat.
LED leuchtet nach einem Tastendruck
nur rot -> Button ist nicht konfiguriert (oder hat das Deaktivierungskommando bekommen und ist somit nicht mehr konfiguriert).
blau -> Button wurde lange gedrückt und ist im Konfigurationsmodus für die Amazon App
weiss, dann grün -> Button hat erfolgreich eine Bestellung bei Amazon getätigt.
weiss, dann rot -> Button hat sich ins WLAN eingeloggt, konnte aber keine Bestellung bei Amazon auslösen.
Der „Hack“ auf dem Pi:
Die üblichen „Hacks“ beruhen auf dem Verhalten des Dash Buttons. Der Button ist ohne Tastendruck in einem Schalfmodus und nicht im WLAN. Wenn man die Taste drückt, loggt sich der Button im WLAN ein. Diesen Vorgang kann man im Netzwerk erkennen und darauf reagieren. Es finden sich im Netz eine Menge python Scripte, die dies für ARP leisten. Diese Protokolle funktionieren mit dem aktuellen Button nicht mehr, da dieser per bootp arbeitet.
Bevor wir loslegen können, muss man zwei Pakete nachladen; dies geht per:
sudo apt-get install scapy
sudo apt-get install tcpdump
Nach der Installation läuft das folgende Script; einfach als dash.py ablegen. Der Code ist an einigen Beispielen im Netz orientiert und macht den Pi zu einem Netzwerksniffer, der auf das passende Paket wartet.
import datetime
import logging
import urllib2
# Constants
timespan_threshhold = 3
# Globals
lastpress = datetime.datetime(1970,1,1)
logging.getLogger("scapy.runtime").setLevel(logging.ERROR)
from scapy.all import *
def button_pressed_dash1():
global lastpress
thistime = datetime.datetime.now()
timespan = thistime - lastpress
if timespan.total_seconds() > timespan_threshhold:
current_time = datetime.datetime.strftime(thistime, '%Y-%m-%d %H:%M:%S')
print 'Dash button pressed at ' + current_time
urllib2.urlopen('http://pi:8083/fhem?cmd.LED=set%20LED%20toggle&room=Haussteuerung')
lastpress = thistime
def udp_filter(pkt):
options = pkt[DHCP].options
for option in options:
if isinstance(option, tuple):
if 'requested_addr' in option:
# we've found the IP address, which means its the second and final UDP request, so we can trigger our action
mac_to_action[pkt.src]()
break
mac_to_action = {'ac:63:be:ac:23:1c' : button_pressed_dash1}
mac_id_list = list(mac_to_action.keys())
print "Waiting for a button press..."
sniff(prn=udp_filter, store=0, filter="udp", lfilter=lambda d: d.src in mac_id_list)
if __name__ == "__main__":
main()
WICHTIG: In dem Script die MAC des eigenen Dash Buttons eintragen und auf KLEINSCHREIBUNG der Buchstaben achten.
Änderung 21.12.2016: Code erweitert, um wiederholte Login Versuche abzufangen. Teilweise gab es mehrere Events aufgrund eines Tastendrucks.
Dann wie folgt starten:
sudo python dash.py
Ein Druck auf den Dash Button sollte jetzt innerhalb von ca. 2 Sekunden erkannt werden. So lange dauert die Registrierung im WLAN.
Beispiel: fhem Server mit dem Dash Button ansteuern
Wenn man das Script um zwei Zeilen ergänzt, kann man zum Beispiel einem fhem Server Kommandos geben.
Bei den Imports ergänzen:
import urllib2
Hinter dem print im Erfolgsfall ergänzen:
urllib2.urlopen('http://127.0.0.1:8083/fhem?cmd=set%20Wohnzimmer_Lampe%20toggle')
Wer etwas anderes auslösen will, kann an dieser Stelle ansetzen.
Mit dem ESP8266 Mikrocontroller kann man sehr günstig und einfach Anwendungen im WLAN realisieren und steuern oder messen. Bei einigen Aufbauten hatte ich Stabilitätsprobleme und das Netz steht voll von Problemschilderungen um neustartende oder crashende ESPs. Mit den folgenden drei Methoden habe ich bisher alle Schaltungen stabil bekommen, so dass die ESPs auch monatelang ohne Reboot laufen.
Problem 1 – die Reset-Leitung ist ein Sensibelchen
Die Reset Leitung des ESP ist ungewöhnlich sensibel. Man sollte die Reset Leitung des ESP auf jeden Fall über einen Widerstand (z.B. 10kOhm) auf 3.3V ziehen. Das langt aber nicht immer. Es hängt von der konkreten Boardversion ab, wie der ESP sich verhält. Insbesondere die etwas älteren Module sind sehr empfindlich, weil hier offenbar keine Stützkondensatoren für die Resetleitung auf den Boards eingebaut sind. Der Test ist einfach: Mit einem Schraubenzieher oder Stück Draht einfach mal an die Reset Leitung gehen, während der ESP läuft. Wenn ein instabiles Board vorliegt, kann man so einen Neustart auslösen – auch wenn man die Reset Leitung mit 10k an 3.3V gelegt hat. Klingt ungewöhnlich, liegt aber daran, dass der ESP sehr hochohmige Eingänge hat und auf sehr kurze Pulse mit geringer Amplitude reagiert.
Die Lösung ist ein 100nF Stützkondensator, der möglichst nahe am Reset-Eingang angelötet wird in Kombination mit 10k auf 3.3 Volt. Minimale Kabellängen zum Kondensator sind Pflicht, weil der ESP „nervig“ sensibel ist. Das folgende Bild zeigt als Beispiel zwei 100nF Kondensatoren, die direkt an einem ESP8266-12 angelötet sind. Die Metallabschirmung liegt auf Masse. Der linke Kondensator stützt die Reset Leitung. Der rechte die 3.3V Versorgungsspannung.
Mit den Stützkondensatoren sollte die Sensitivität der Reset-Leitung auf Berühungen behoben sein.
Problem 2 – instabile Versorgungsspannung
Der ESP8266 hat recht hohe Anforderungen an die Versorgungsspannung. Im Mittel werden 80mA benötigt, kurzfristig zieht der ESP aber bis zu 250mA. Deshalb sollte die 3.3V Versorgungsspannung mit einem großen Elko gestützt werden. Ich nehme mindestens 470 Mikrofarad, meistens aber 3300 Mikrofarad. Ich habe mit einen Satz Elkos mit 3300Mikrofarad für maximal 6.3V besorgt. Diese sind noch relativ klein und günstig zu bekommen.
Mit einem solchen Elko und einen zusätzlichen 100nF Stützkondensator direkt am 3.3V Eingang des ESP, ist ein Spannung bei einem typischen Handynetzteil (5V) und einem LM1117-3.3 als Spannungsregler stabil genug.
Problem 3 – Relaisboard stabil schalten
Genau wie oft im Netz beschrieben hatte auch ich das Problem, dass das Schalten von 230V über ein Relaisboard den ESP ziemlich zuverlässig gecrasht oder neu gestartet hat. Dabei habe ich über ein übliches Relaisboard mit Optokoppler einen Klingeltrafo geschaltet.
Das Problem läßt sich lösen, wenn man einen Entstörkondensator parallel zum Verbraucher schaltet. Wichtig: Der Kondensator muss mit dem Verbraucher verbunden bleiben, auch wenn das Relais abschaltet. Sonst wirkt der Kondensator nicht.
Ohne Kondensator entstehen beim Abschalten von induktiven Lasten leicht einige tausend Volt. Diese hohe Spannung sorgt in Kombination mit den sehr hochohmigen Eingängen des ESP für die Probleme. In der Praxis scheinen schon sehr kleine Induktivitäten auszureichen, um den ESP zu „ärgern“.
Bitte keinen einfachen Kondensator von der Stange nehmen, sondern einen sogenannten X2 oder FX2 Kondensator (EN132400). Diese sind zur Entstörung geeignet und bis zu einigen kV durchschlagsfest. Ein geeigneter 0.47 Mikrofarad FX2 Kondensator ist im folgenden Foto abgebildet. Mit einem solchen Kondensator konnte ich bisher alle Probleme lösen.
