Entwicklung: Sensor mit dem ESP8266 WLAN-Funkmodul

[locutus]

Hallo zusammen,

WLAN-Module für Arduino und Mikrokontroller waren bisher jenseits der 30 Euro-Grenze angesiedelt. Das ESP8266 WLAN-Funkmodul ist schon ab 3 Euro erhältlich. Die UART-Schnittstelle und die Steuerung mit AT-Befehlen ermöglichen eine einfache Integration in Mikrocontrollerprojekte.
Ein Nachteil von WLAN-Modulen ist der hohe Stromverbrauch. Batteriebetriebene Sensoren wären praktisch sinn- und nutzlos. Ganz anders der ESP8266: der Stromverbrauch ist von 0,5 mA (Shutdown Mode) bis 215 mA (802.11b, CCK 1Mbps, POUT=+19.5dBm Mode) konfigurierbar. In Verbindung mit dem AVR Sleep Mode würde ein Lithium Akku oder aber zwei 1,5V Batterien nicht so schnell an Leistung verlieren.

Worauf ich hinaus will? Ich möchte einen WLAN-Sensor für FHEM entwickeln. Dabei übernehme ich gerne die Hardwareentwicklung.
Folgende Hardwarekonfiguration für den/die Prototypen schwebt mir vor:

ESP8266 WLAN-Funkmodul
ATmega328P mit Arduino Pro or Pro Mini (3.3V, 8MHz) Bootloader
Debug-Schnittstelle (Arduino SoftwareSerial Library)
Schnittstelle für USB zu TTL-Wandler
JST-Connector für Li-Po / Li-Ion Akku

Damit kein Chaos bei der Wahl der Sensoren entsteht, schlage ich I2C-Bus Breakout Boards von Adafruit und SparkFun vor (diverse kostengünstige China Klone sind bei eBay erhältlich).

Sensoren:
BMP085 / BMP180 (barometrischer Luftdrucksensor)
BH1750 (Umgebungslichtsensor)
DS18B20 (Temperatursensor)
DHT22 (Temperatur- und Feuchtesensor)
HTU21D (Temperatur- und Feuchtesensor)
HC-SR04 / DYP-ME007Y (Ultraschall Sensormodul)
CCS811 (Luftqualitätssensor)

Weitere (nicht zwingend erforderliche) Module:
SSD1306 OLED Display (I2C)
WS2812 (NeoPixel) RGB LED
Relais

Es klingt nach sehr viel Arbeit. Deshalb benötige ich auch kräftige Unterstützung bei der Softwareentwicklung. Der Developer übernimmt bitte die Programmierung mit der Arduino IDE. Ich kann nicht beurteilen, ob ein neues FHEM perl Modul benötigt wird. Eventuell genügt die Abfrage/Übergabe der Sensordaten an FHEM per GET.

Den/die ersten Prototypen könnte ich im ersten Quartal 2015 zur Verfügung stellen. Ist jemand interessiert?

Was halten die Experten von einem WLAN-Sensor mit dem ESP8266 Chip? Vorschläge für andere oder weitere Hardwarekomponenten?

Hier noch ein paar Weblinks:
http://www.mikrocontroller.net/articles/ESP8266
https://github.com/nodemcu/nodemcu-flasher

UPDATE 22.02.2015
Die Alpha-Version des Breakout Boards ist verfügbar.

UPDATE 20.09.2015
Ich habe die Weiterentwicklung der Hardware aus Kostengründen eingestellt.
Äquivalente Produkte anderer Hersteller: Adafruit Feather HUZZAH oder ESP8266 Thing - Dev Board

UPDATE 28.02.2016
LW12 RGB-Controller für 12V RGB LED Strip

UPDATE 26.06.2016
IR-WLAN-Gateway

UPDATE 19.03.2017
LW12 RGB-Controller Ver. 1.1

UPDATE 04.11.2017
LD382 RGB-Controller Ver. 2.0

[Dr. Boris Neubert]

Hallo,

ich habe hier ein ESP8266-Modul und ein paar Arduino Nano und Pro und FTDI-Adapterkabel herumliegen. Ich wollte damit ein wenig herumspielen, wenn ich Zeit habe. Einen konkreten Einsatzzweck habe ich noch nicht gefunden. Soweit ich das überblicke, ist hardwareseitig nicht viel mehr zu tun, als die Teile mit Dupont-Kabeln zusammenzustecken.

Ich hebe dennoch nicht die Hand, die Software zu entwickeln, weil ich nicht zuverlässig die dafür erforderliche Freizeit aufbringen kann.

Ich bin außerdem skeptisch bei proprietären Lösungen, auch wenn diese OpenSource-Hardware und -Software sind.

Ich persönlich würde auf 6LoWPAN mit Contiki als Unterbau setzen. Dazu braucht es einen ATmega1284P mit AT86RF212.

Schau Dir doch mal Blatt 6 von  https://github.com/mysmartgrid/hexabus/blob/master/schematics/HexaBus_Plug.pdf?raw=true an. Die Firmware existiert und ich habe eine Entwicklungsumgebung dafür, deren Aufbau ich auch dokumentiert habe. Und ich arbeite an einem FHEM-Modul dafür.

Viele Grüße
Boris

[kaihs]

Ich habe die Diskussion bei mikrocontroller.net auch verfolgt und mir Gedanken gemacht ob und wie man das einsetzen könnte.

Gerade für Sensoren habe ich aber keinen wirklichen Grund gefunden, die per WLAN anzubinden. WLAN bietet zwar eine viel höhere Bandbreite als andere Funkprotokolle, aber die wird für Sensoren ja i. A. gar nicht benötigt.
Dazu kommt der wahrscheinlich immer noch höhere Stromverbrauch und dass die Firmware von dem ESP8266 wohl noch nicht so ganz ausgereift ist.
Im übrigen hat der Mikrocontroller von dem Teil wahrscheinlich erheblich mehr Rechenleistung als der ihn steuernde ATmega
Theoretisch könnte man wohl eine einfache Sensorapplikation ganz auf dem  ESP8266 laufen lassen, ohne einen weiteren Controller.

Daher sehe ich eher andere (Spezial-)anwendungsfälle.

• Audioübertragung, z. B. für Sprachausgabe, Musikstreaming oder gar Spracheingabe
• Statusdisplays oder komplexere Eingaben

Da stellt sich dann aber schon wieder die Frage, ob man mit einem billigen Tablet von der Stange nicht besser bedient ist.

[locutus]

Produktbeschreibung
Das Breakout Board basiert auf einer programmierbaren MCU mit integriertem WLAN-Modul, einigen GPIOs und UART-Schnittstelle.

Hardwarevoraussetzung
Zur Kommunikation mit dem Breakout Board wird ein USB zu TTL-Wandler mit 3,3V-Logik (FTDI FT232RL).
http://www.exp-tech.de/catalogsearch/result/?q=ft232rl+breakout

Dabei ist zu beachten, dass die Eingänge des ESP8266 nicht 5V-tolerant sind.
Bei Verwendung von USB-Wandlern mit 5V-Logik wird zusätzlich ein 5V zu 3,3V-Pegelkonverter (Levelshifter) benötigt.

Anschluss
Es ergibt sich das folgende Anschlussschema (siehe FTDI.jpg):

ESP8266 < - > FTDI
------------------------
TX < - > RX
RX < - > TX
VCC < - > 3.3V
GND < - > GND

Hardwareseitig ist CH_PD mit VCC verbunden. GPIO15 ist mit GND verbunden.

AT-Kommandos
Die softwareseitige Verbindung zum ESP8266 stellt man mit z.B. mit CoolTerm her (siehe CoolTerm.jpg).
http://freeware.the-meiers.org/

1. CoolTerm starten
2. Auf Connection klicken und Options... wählen
3. Port und Baudrate (je nach Firmware Version 115200 oder 9600) wählen, auf OK klicken
4. Auf den Connect Button klicken

Es können nun AT-Kommandos abgesetzt werden (siehe ESP8266 AT Instrction Set.pdf).

NodeMCU
NodeMCU ist eine alternative Firmware für den ESP8266EX SoC.
https://github.com/nodemcu/nodemcu-firmware

1. Einstieg in den Flash-Mode
Dazu wird GPIO0 auf GND gelegt und das Board mit Spannung versorgt. Das Funkmodul befindet sich nun in dem "boot mode".
2. NodeMCU Firmware installieren
Zum Updaten wird der NodeMCU Flasher benötigt (siehe NodeMCU_Firmware.jpg):
https://github.com/nodemcu/nodemcu-flasher
3. COM Port auswählen und auf Flash(F) klicken.
Nach dem der Chip erfolgreich geflasht wurde, wird die Verbindung zur Spannungsversorgung getrennt. Un­mit­tel­bar danach wird die Verbindung zwischen GPIO0 und GND getrennt.

ESPlorer
Mit der Lua-IDE ESPlorer lassen sich Skripte unter NodeMCU aufspielen. Auch AT-Kommandos werden unterstützt.
http://esp8266.ru/esplorer/

Arduino
Arduino-kompatible IDE mit ESP8266 Unterstützung
https://github.com/esp8266/Arduino

[Wzut]

Als ich mit FHEM angefangen habe hat es mich geärgert das keine Sensoren auf so einer einfachen WLAN Basis gab (oder ich habe sie einfach nie gefunden) Die bekannten 433 oder 868 MHz Lösungen deckten mit einem USB Empfänger im Keller direkt am FHEM Server nie das ganze Haus ab, dazu war im ersten Stock dann doch  ein "Hilfs" Fhem auf Raspi Basis notwendig.
Ich habe mir letzte Woche zwei dieser Module bestellt und konnte am Samstag und Sonntag etwas damit spielen.
Erster Eindruck :
Ich bin begeistert, obwohl ich nur die einfache Ausführung ohne externe Antenne habe "sieht" das Modul alle meine APs plus drei aus den Nachbarhäusern ( mein Laptop sieht mit einer besseren Antenne noch zwei weitere ) , das bedeutet für mich  : Selbstbau Sensoren auf dieser Basis würden auf meinem ganzen Grundstück und im Haus vom Keller bis zum Dach funktionieren.
Die Firmware der Module scheint z.Z. noch ein paar Macken zu haben, unter anderem finden sich im Netz widersprüchliche Infos sowohl was den Anschluss betrifft als auch die Syntax der AT Befehle - was ich leider gar nicht gefunden habe war ein AT Befehl der nach einem erfolgreichen TCP Verbindungsaufbau  die serielle Schnittstelle transparent ( d.h. 1:1) durchreicht,  so wie es jedes normales Telefonmodem tut.
Wäre dies möglich, sehe ich bei mir denn ersten Einsatzfall als WLAN-CUL / WLAN-JeeLink / WLAN-Firmata oder WLAN-Fhemduino
D.h. der "Hifls" FHEM Server würde sterben und sein Platz würden WLAN-433/868 MHz Brücken einnehmen die die Kommunikation mit den gekauften Temp/Feuchte abwickeln. Ich denke bei den aktuellen Marktpreisen von 6-11 Euro für einfache Temp/Feuchte Sensoren lohnt sich ein Selbstbau für direktes WLAN nicht - das mag für die anderen Arten von vorgeschlagenen Sensoren schon wieder ganz anders aussehen, da ich dafür z.Z aber keinen direkten Bedarf habe fehlt mir auch das dazugehörige Wissen.   
Fazit :
IMHO lohnt es sich an den Thema ESP8266 dran zu bleiben, auch wenn die weitere Entwicklung hier im Forum vllt. nicht direkt in die von locutus vorgeschlagene Richtung gehen sollte, so bleibt doch genug Potenzial für andere Lösungen im Zusammenspiel mit FHEM         

[drdownload]

Hallo beisammen, für selbstentwickelte Sensoren scheinen derzeit ja

• Panstamp
• MySensors
• ESP8266]
  

am interessantesten zu sein. Die Eleganz beim ESP8266 kommt besonders in der Kombination der Standalone-Nutzung ohne extra Arduino mit einem MQTT Sketch heraus nach meiner Meinung: https://github.com/tuanpmt/esp_mqtt & https://scargill.wordpress.com/category/esp8266/

Der Vorteil von Wifi ist natürlich dass man keinen eigenen Receiver braucht und man sich über die Abdeckung relativ wenig Sorgen machen muss. Nachteil ist sicher, dass gerade bei Batterie-Devices ein Aktor nicht sinnvoll realisierbar sein wird (nachdem man das Wifi-Modul zum Stromsparen abdrehen muss die meiste Zeit)

Andere interessante Links:
http://harizanov.com/2014/12/wifi-iot-3-channel-relay-board-with-mqtt-and-http-api-using-esp8266/
http://dangerousprototypes.com/2015/01/07/a-world-of-mqtt-on-esp8266/
http://nathan.chantrell.net/20141230/wifi-mqtt-display-with-the-esp8266/
https://scargill.wordpress.com/2014/11/17/a-temperature-monitor-for-the-esp8266/

[REM!X]

Das klingt doch Super.

Mit dem ESP8266 könnte man doch günstig und einfach "funk" Temperatur und Feuchte Sensoren bauen.

Oder gibt das bessere alternativen?

Gruß

[drdownload]

Mysensors ist nochmal ein Eckerl günstiger (wenn man den ESP8266 zusammen mit einem Arduino verwendet)

[Wzut]

Mit dem ESP8266 könnte man doch günstig und einfach "funk" Temperatur und Feuchte Sensoren bauen.

lies mal im Anfängerforum http://forum.fhem.de/index.php/topic,32467.0.html
Der Autor (TorstenC) hat die ESPs anscheinend voll im Griff da er dort plant WLAN Schalter zu bauen, vllt sollte ihn mal jemand nach hier unten locken
Auf den zusätzlichen Arduino kann man wohl auch verzichten und den gesamten C Code direkt ins Modul packen

[locutus]

Äh, im Griff? Ich schließe mich dem Kommentar von hexenmeister an und halte den Beitrag für einen verfrühten Aprilscherz.

Kurzes Update zum Stand der Hardwareentwicklung:
Für den/die Prototypen habe ich ein einfaches Breakout Board in CadSoft Eagle erstellt. Die Schaltung ist auf ein Minimum an Bauteilen reduziert.
Den Grundbaustein bildet das ESP-03 Funkmodul. Die Spannungsversorgung erfolgt wahlweise über CN1 (z.B. Powerbank mit Mini-USB Stecker) oder CN2 (Lithium Akku mit JST-Stecker). IC1 stabilisiert die Spannung auf 3,3 Volt. JP1 und JP2 sind standardisierte 2,54 mm Pin Header. U2 kann mit einem DS18B20 1-Wire Temperatursensor bestückt werden.
Das Board kann sowohl als Standalone Gerät betrieben oder auch als Zusatzplatine für Mikrocontroller (Arduino) verwendet werden.
Für die Standalone-Lösung scheint mir NodeMcu sehr geeignet. Die Entwicklung und MQTT-Implementierung macht offenbar gute Fortschritte.

[SpenZerX]

Hallo,

wie sollte denn die optimale Anbindung ESP8266<-> Fhem aussehen?

Gibt es da Überlegungen? Welches Modul ist da als Muster zu empfehlen?

Jeden ESP wie ein Netzwerk CUL/CUNO ansprechen? -> Diese Module ändern?
Oder alle ESPs über ein CUL/CUNO und Schaltadresse = IP:PORT:IP:PORT?
Für jedes ESP Projekt ein FHEM Modul mit eigener Kommunikation schreiben? Würde das nicht das System blockieren? Beispiele für non Blocking UDP Kommunikation, gibts da welche?

Ist Zustand auf meinen ESP Projekten TCP-> HTTPDämon UDP->UDPCommando Dämon. 
Macht da ein TCPCommando Dämon mehr Sinn?

Würde gerne FHEM mit unterstützen - obwohl ich denke das bei einigen Ideen FHEM die Puste ausgeht.

[Prof. Dr. Peter Henning]

Schon vor einigen Monaten haben wir ein WIFI/1-Wire Interface beschrieben und gebaut, das Teil ist bei mir seit Monaten im Produktivbetrieb und versorgt einen ganzen 1-Wire-Bus mit ca. 10 Sensoren und mehreren Aktoren

Thread dazu siehe hier http://forum.fhem.de/index.php/topic,18996.285.html

Ansteuerung erfolgt über socat, beschrieben ist das hier http://www.fhemwiki.de/wiki/1W-IF-ETH

Und der Schaltplan ist hier angehängt.

LG

pah

[SpenZerX]

Also ich werde meine ESP Projekte jetzt an FHEM anbinden.  (ist natürlich ein Versuch)

Ich werde es über das HTTP Protokoll versuchen.

Gibt es dafür schon ein IODev?

Sollte dann folgende Kommandos verarbeiten:

Senderichtung: (mal durchgespielt)
Daten von Modul für Schalter/Dimmer "Switch.pm" an IODev "http.pm" ,sendet über HTTP an Gerät - HTTP Response Code als Bestätigung
Musterdaten:
192.168.000.054:80/EG.Heizungsraum.Heizkreis.1.set Postdata:value=50
oder
www.heizungsraum.de/EG.Heizungsraum.Heizkreis.1.set Postdata:value=50
oder
192.168.000.054:80/Switch.1.set Postdata:value=50
oder
www.heizungsraum.de/Switch.1.set Postdata:value=50

(wobei "Switch.1" nicht änderbar in der ESP Firmware codiert ist und ".1" die laufende Nummer ist (also Switch.1-8 bei 8er Relais-Karte)
und "EG.Heizungsraum.Heizkreis.1" der vom Nutzer und FHEM alternativ benannte "Switch.1" ist (=Name in FHEM). Alle Links würden aber das gleiche bewirken.

Empfangsrichtung:
Daten von Gerät über HTTP an IODev(HTTP-Daemon an Port xx) : (Response Code als Bestätigung)
Über regex "/Switch.X.par" an  Modul "Switch.pm" zum verarbeiten der empfangenen Daten zurückschicken.

Gibt es schon so ein IODevice in FHEM das ähnliches leistet?

Ist bei der Kommunikation über HTTP irgendwas zu beachten was man vorher berücksichtigen sollte ?

[Prof. Dr. Peter Henning]

Bitte ansehen ECMD /ECMDDevice.

LG

pah

[locutus]

Schon vor einigen Monaten haben wir ein WIFI/1-Wire Interface beschrieben und gebaut ...

Hallo pah,
ich brauche mehr Details! In der Wiki wird die Konfiguration des USR-WIFI232-A nicht erwähnt. Welche AT-Kommandos sind notwendig?
Diese Informationen wären sehr hilfreich für die Umsetzung des ESP8266-Projektes.