Mein FHEM

[fermoll]

Mein FHEM
Angeregt durch die Diskussion im Strang von Locutus
Entwicklung Sensor mit dem ESP8266   und nach dem Kauf von von zwei Breakboards beginne ich im Moment, mich mit dem Thema etwas genauer zu beschäftigen und meine FHEM-Konfiguration zu überdenken.

Istzustand

Meine bisherige Steuerung beinhaltet im Moment

1  .  FHEM auf einem Rpi 2 mit externer Festplatte
1.1  Betriebssystem und Programme auf SD
1.2  wechselnde Daten auf einer FP
2    Ca. 23 Max! HT´s an 2 Cubes
2.1  Parterre u. Keller  10St.
2.2  2. Stock  4 St.
2.3  Mietwohnung  8St. HT+ (im Moment nicht in FHEM eingebunden)
3  Homematic HMLAN (CCU) mit drei Rolladensteuerungen 2x HM-LC-Bl1PBU-FM, HC-LC-Bl1-FM
4  Locutus RPI-addon am RPI2 (CUL) mit 7 S300TH, EM 100-GZ(S).
5   CUNO mit 35cm Antene, im Moment nicht in Gebrauch
Geplant ist, diesen als Steuerung für den 2. Stock einzusetzen
6   2 MAX!-Fensterkontakte, im Moment nicht in Gebrauch
7  RPi u. RPi 2 zum Ausprobieren und Lernen.

Versorgt wird ein Haus mit vier Ebenen -Keller – 2.Stock mit LAN u. WLAN

1. Ergeschoss  FritzBox 6490
2.    2. Stock Fritzbox 7390 als Repeater. Die WLAN-Verbindung der 6490 wird durchgeschleift.
3. Ein älterer Edimax kann noch im Keller als Router installiert werden.
4. Synology DS212+ mit 6TB im Netz

Mein Problem

Mein Problem ist, was geschieht, wenn FHEM aussteigt, z.b. wenn der RPI streikt. Die HT´s arbeiten weiter, bei ihnen läuft ein Wochenprogramm. Bei den neueren HT+ von ELV ist m. W. sogar kein Cube zur Programmierung mehr notwendig. Was ist mit Homematik? Das Add On u. Cul -CUNO haben ebenfalls keine Intelligenz, sondern leiten nur Informationen an Aktoren weiter, die selbst auch keine Intelligenz haben.
Nun habe ich jedoch Informationen zum ESP-12E als NodeMCU gefunden.
http://www.msxfaq.de/verschiedenes/bastelbude/nodemcu.htm
Der Link bezieht sich zwar auf den ESP-12, der ESP-12E NodeMCU benutzt einen anderen USB-Seriell Chipsatz und hat wohl mehr GPIO-Pins.
Bestellte Version:http://www.smartarduino.com/the-newest-v3-nodemcu-based-on-esp-12e-from-esp8266_p94866.html
Handbuch:https://smartarduino.gitbooks.io/user-manual-for-esp-12e-devkit/content/index.html
Noch eins:https://smartarduino.gitbooks.io/development-of-nodemcu/content/index.html

Meine Überlegung

1. Da in meinem Haus WLAN-VERBINDUNG über alle vier Ebenen zur Verfügung steht, wäre eine Anbindung von Aktoren an FHEM    (RPI 2) sinnvoll. Den Einwand von PAH, was die Latenz angeht, finde ich nicht so wichtig, wenn man darauf achtet, die Aktoren möglichst so zu gestalten, dass sie ähnlich selbstständig sind, wie die MAX! HT's.

2. Meine Erfahrung mit 12 MAX! HT's und Cube im Hinblick auf die 1% Regel hat m.E. gezeigt, dass der Datenverkehr mit CUL, CUNO, Cube u.ä. Aber auch über WLAN auf das nötigste beschränkt werden sollte.
Wenn ich das richtig sehe, würde die Verwendung der NodeMCU mit 4mB Flash und ca. 90kB RAM  und ca. 10 nutzbaren GPIO's für die Entwicklung selbstständiger Aktoren, die von FHEM überwacht werden, sicher Sinn machen.
Das Zitat von Prof. Dr. Henning -"Außerdem halte ich es für Unsinn, das ganze 1-Wire-Protokoll in einem ESP abwickeln zu wollen. ,, kann ich in diesem Zusammenhang nicht nachvollziehen.

3. Des weiteren würde ich, wie in P.1 angedeutet, Aktoren so gestalten, dass ein Großteil der Schaltungen von den Aktoren selbst gesteuert werden, wie z.B. in den Max! HT's, die ihr Programm auch ohne Verbindung zu FHEM abspulen. FHEM hätte dann die Aufgebe, Änderungen am Programm der Aktoren vorzunehmen, die Kommunikation zwischen Aktoren zu gewährleisten, Daten, die von den Aktoren geliefert werden, zu verarbeiten .....

4. Für meinen Fall - FHEM auf dem RPI2 und Synology NAS im Netz - wäre auch noch die Frage wichtig, wie man den RPI dazu bringt, Sicherungen auf dem NAS anzulegen, um die Datensicherheit zu erhöhen.

[fermoll]

Da die momentane Konfiguration recht ordentlich läuft und ich mich im Moment verstärkt mit dem ESP8266 beschäftige, möchte ich hier die geplanten Projekte vorstellen:

1. Warmwasser Zirkulationspumpe

1.1  Messung der Temperatur Vor- u. Rücklauf
1.2  Schaltung der Pumpe (PWM?) mit Zeitprofil
1.3  Schaltung der Pumpe nach Bedarf über Smartphone

2. Kamin mit Wasserregister im Wohnzimmer

2.1  Im Moment wird das Wasserregister, das Wärme für den Warmwasserspeicher transportiert, durch eine separate Schaltung  (20 Jahre alt) gesteuert. Ich gehe davon aus, dass ein PT 100 (1000) die Wassertemperatur im Register des Kamins misst.
2.2  Diese Schaltung soll erhalten bleiben und ergänzt werden.
2.3  Beim Heizen des Wohnzimmers durch den Kamin entsteht ein Wärmegefälle von mehr als 3° C in dem fast 4m hohen Raum. Dazu habe ich einen speziellen Ventilator angeschafft

3. Überwachung einer Zisterne unter dem Wintergarten und Temperaturkontrolle in demselben

3.1  Wasserstend der Zisterne
3.2  Temperatur im Wintergarten
3.3  Temperatur in der(n) Keimschale(n)
3.4  Schaltung der Heizdrähte unter den Keimschalen

4. Steuerung der Pumpen und des Wasserstands im Teich

Meine grundsätzliche Idee war, zumindest für einige der Punkte einen AVR-Net-IO (Pollin einzusetzen. Nachteilig ist jedoch, dass dieses Gerät eine LAN-Verbindung braucht, was mit der Verlegung von vielen  Kabeln einhergehen würde.
Nächste Idee war, zu versuchen, das AVR-Net-IO wlanfähig zu machen, z.B. mit einem ESP8266. Ich hatte aus Locutus Projekt zwei Breakboards mit dem ESP-03 erworben. Hier beginnen jedoch meine massiven Zweifel, ob das ganze nicht durch die ESP-12e mit ihren vielen GPIO's alleine zu erledigen ist.
Da ich seit heute im Besitz einer NodeMCU V3 (LoLIn) bin, werde ich versuchen diese Projekte anzugehen, einmal mit dem AVR-Net-IO mit dem 1280er NC-Chip und mit der NodeMCU. Ich werde berichten.
Hier noch ein Link, der die verschiedenen Versionen der NodeMCU miteinander vergleicht:
http://frightanic.com/iot/comparison-of-esp8266-nodemcu-development-boards/
Hier ist noch ein Link zu Neil Kolban's Buch, meiner Meinung nach ein Muss für die Entwicklung mit dem ESP8266:
http://neilkolban.com/tech/esp8266/

[fermoll]

Die Ernüchterung kam heute morgen. Das NodeMCU sieht gut aus und passt auch in das Breadboard. Es ist nur ca. 5,2 mm zu breit. Denn es bleiben auf dem BB keine Reihen links und rechts übrig, an denen man die Pins abgreifen könnte. Es ist also ein zusätzliches BaseIobreakout nötig, um sinnvoll an die 30 Pins des Boards heranzukommen. Ich hoffe, dass das bei den china bestellten Boards anders ist, denn da gibt es die zusätzlichen Boards nicht. Ähnliches habe ich bei Locutus Boards festgestellt. Nur sind da nur die Hälfte der Pins zu verbinden. Rat an alle, die Platinen entwickeln, die Ausmaße der BB in beiden Ebenen zu berücksichtigen. Auf beiden Seiten der BB muss eine Reihe frei bleiben.

[fermoll]

Mit Locutus Board habe ich mich in den letzten Tagen etwas intensiver beschäftigt.
Hardware:
FTDI_Konverter :http://www.ebay.de/itm/321647516230?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

Anschluss nach Locutus:

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.

Zum Flashen GPIO0 auf GND.
Flashen mit nodemcu-flasher-master
Ausprobieren mit esplorer
Flashen funktioniert nicht.
Suche im Internet. Fehler gefunden:http://www.instructables.com/id/How-to-unbrick-an-ESP8266-Using-ESP-03-as-example/?ALLSTEPS
Step 1

Due to the limitation of the flash size, it's not possible to flash V1.0 or later firmware to it because they require at least 1M-byte of capacity.

Der ESP-03 hat 512 kB Speicher und muss mit der FW 0.9x geflasht werden.
Werde weiter berichten, vor allem von der NodeMCU mit 4 mB Speicher.
PS
Wenn man davon ausgeht, dass bei Locutus Board GPIO2 für 1-wire reserviert ist, bleiben m. E. GPIO12-14 für andere Aufgaben übrig.
Zusammen mit der Arduine Idee eine faszinierende Aussicht, bei der NodeMCU mit 4 mB und weiteren GPIO's weiter ausbaubar.

[fermoll]

Hier sind die Links zu zwei ebooks (auf Englisch), die ich für wert halte, zu lesen.

1. Kolban's book on the ESP8266, Freeware, wird regelmäßig aktualisiert. Gibt es als epub oder pdf.
http://neilkolban.com/tech/esp8266/

2.Rui Santos Home Automation Using ESP8266  (€ 14.95)
http://randomnerdtutorials.com/home-automation-using-esp8266/

Es ist ziemlich schwere Kost, aber ich glaube es lohnt sich.

[fermoll]

Mittlerweile ist es mir gelungen, die beiden Boards zu flashen. Dabei muss unter advanced die Baudrate auf 9600 , die Größe auf 512 kB und der Mode auf QIO eingestellt werden. Es werden 430 kB Flash von 512 verbraucht. Der zur Verfügung stehende Heap beträgt ca. 20 kB. Verwendet habe ich nodemcu_float_0.9.5_20150318.bin, da ich gelesen hatte, dass die neuen zu groß sein sollen.
Ob man die Float- oder die Integervariante verwenden will, hängt davon ab, ob man Fließkommazahlen in seinem Programm benötigt oder nicht.

Mittlerweile ist auch das Brakoutboard für mein LoLin-Nodemcu angekommen. Dort klappt das flaschen noch nicht so richtig.

Für mich sind nun folgende Fragen interessant. Besteht ein Unterschied zwischen der Ausführungsgeschwindigkeit des LUA und dem Arduino-Programm? Wie unterscheiden die sich in der Größe? Da werde ich mich  durch die beiden Bücher durcharbeiten müssen.

[fermoll]

Ich habe mich im Forum umgesehen, was die Nutzung der ESP angeht und kann  mich des Eindrucks nicht erwehren, dass die Argumentation nach dem Prinzip "Durch den Rücken durch die Brust ins Auge" erfolgt.
Als Beispiel soll der Strang dienen: http://forum.fhem.de/index.php/topic,32618.0.html.
Der beginnt im Januar, dann kommt eine ganze Weile nichts, bis ihn dann Familienpapi im Oktober nach oben holt.
Da wird ein ESP (ich nehme an, ein ESP-01) mit dem Arduino Pro mini verheiratet, um letzteren über Firmata zu steuern.
Ähnliches gilt für andere Threads, die vom ESP handeln. Im Laufe des Jahres hat sich aber viel getan. Der vorläufige Endpunkt ist der ESP-12e. Hier gilt es zu überlegen, inwiefern man diesen Chip anstelle des Arduino oder des AVR-Net-Io verwenden kann. Wenn man sich in Kolbans Buch etwas umgesehen hat, scheinen viele Möglichkeiten offen.
Ich habe mir mal erlaubt, einige Chips gegenüberzustellen, soweit ich Informationen gefunden habe (s. Bild). Es bleiben für mich allerdings noch viele Fragezeichen.
PS:
Den ESP-07 habe ich mit erwähnt, weil der einen Anschluss für eine externe Antenne hat.

[SpenZerX]

Es gibt nur einen ESP8266EX. Und der hat sich seit einem Jahr nicht verändert. Nicht zu kompliziert machen das ganze.

[fermoll]

Das ist ein typischer Beitrag von SpenZerX. Es ist unbestritten, dass der ESP8266EX in allen Varianten verbaut ist. Doch unterscheiden diese sich z.B. im Speicher. Der ist bei NodeMCU mit 4 mB recht ordentlich ausgefallen. Du solltest also mal den folgenden Link lesen:
http://www.instructables.com/id/How-to-unbrick-an-ESP8266-Using-ESP-03-as-example/.

Dann geht es darum, welche GPIO's angeboten werden.
Das Datenblatt:https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwj_3ue7qOPJAhXGcRQKHYieBwcQFggiMAA&url=https%3A%2F%2Fwww.adafruit.com%2Fimages%2Fproduct-files%2F2471%2F0A-ESP8266__Datasheet__EN_v4.3.pdf&usg=AFQjCNFL7uG-67i7NtnbWA9a5vVCZWpf7Q&sig2=Y6AyugKGywY1qVbI_QeCZA&bvm=bv.110151844,d.d24&cad=rjt
nennt auf S.17 deren 17 Stück. Die meisten sind mittlerweile beim NodeMCU V. 3 herausgeführt und können verwendet werden. Und nicht zuletzt ist es wichtig, wie komfortabel der Umgang mit dem Dingens ist. Deshalb ziehe ich die NodeMCU-Variante vor, die eine Spannungsversorgung und den FTDI eingebaut hat. Damit erübrigt sich die Friemelei mit dem Breadboard.
Eine andere Variante ist natürlich z.B. :http://shop.in-circuit.de/product_info.php?cPath=21&products_id=168. Die bieten ihn nackt an und verheiraten ihn wohl offensichtlich mit verschiedenen Arduinos, wenn ich das richtig gelesen habe.
"Durch den Rücken durch die Brust ins Auge"

[fermoll]

Ich möchte meine Überlegungen zur Verwendung des ESP - ich denke an die NodeMCU -an dem im 2. Beitrag angeführten Beispiel Wintergarten präzisieren.

1. Temperatur im WG
1.1  Ziel ist die Aufzeichnung der Temperatur in FHEM
1.2  Steuerung der Temperatur über den Max!Thermostaten bei starker Abweichung im Winter.
1.3  Steuerung der Temperatur im Sommer durch einen Wärmetauscher für das Brauchwasser. Die Temp. erreicht im Sommer Werte über 40° C. Werde ich wohl nicht mehr verwirklichen können.
2. Keimschalen
2.1  Temperaturmessung in zwei Keimschalen, die von Heizdrähten bei Bedarf geheizt werden.
  2.2   Steuerung von Heizdrähten unter den Keimschalen. Meine Überlegung PWM.
3. Messung des Wasserstands in der Zisterne – 6 Kunsstofftanks a 1200l.
3.1  Aufzeichnung in FHEM
3.2  Schaltung eines Relais, entweder zur Einspeisung von Trinkwasser oder Umschaltung der Versorgung der Toiletten im Haus bei zu geringem Wasserstand.

Meine Idee ist, alles so weit wie möglich innerhalb des ESP ablaufen zu lassen. Die gesammelten Daten sollten, wenn möglich in der vorhandenen Synology gespeichert werden. Wo die Daten ausgewertet werden, lasse ich erst einmal offen. FHEM würde in diesem Fall das Ganze nur überwachen. Ich habe gmerkt, wie die Synology überfordert war, als ich FHEM dort installiert hatte. Deshalb bin ich Auf RPI 2 umgestiegen. Aber auch dort ist das Speichern von Daten ein Problem, das ich allerdings im Griff habe, da ich eine Festplatte integriert habe.

[fermoll]

Ich habe mich nach reiflicher Überlegung entschlossen, den Strang zu teilen. Hier möchte ich meine Gedanken zur Funktion des FHEM, seine Möglichkeiten und auch seine Grenzen, entwickeln und zur Diskussion stellen. Meine Erfahrunugen mit ESP werde ich in der Bastelecke weiter öffentlich machen, da sich doch viele spezielle Sichtweisen ergeben.
Meine hauptsächlichen Erfahrungen mit FHEM beziehen sich auf das Max!System.
Dieses nutze ich seit ca. 2010, zuerst mit dem Interface von ELV, dann mit Max!Buddy, das wohl leider nicht mehr weitergeführt wird. Anfang 2013 bin ich dann auf FHEM aufmerksam geworden und dann umgestiegen. Meine Nutzung des Systems habe ich im ersten Beitrag deutlich gemacht.
Wenn man das Forum etwas länger verfolgt, geht es vor allem darum eine Haussteuerung mit vorhandener Hardware mit FHEM zu steuern. Dazu war es nötig, die Funktion der Komponenten, meist gegen die Intention der Hersteller. z.B. ELV, zu entschlüsseln, oft genug auch, um Mängel der Originalen SW auszubügeln. Das habe ich am Beispiel Max! intensiv mitverfolgt. Aber gerade an diesem Beispiel habe ich auch die Grenzen dieses Tuns erfahren. Ich selbst verwende bei Max! die Original Komponenten, die nicht verändert wurden, einen der beiden Cubes seit 2010. Die Funkreichweite ist auf zwei meiner vier Wohnebenen in einem Haus von ca. 1930 beschränkt, wahrscheinlich, weil noch wenig oder gar kein Stahlbeton verwendet wurde. Deshalb habe ich einen zweiten Cube installiert, da ich im Haus Netzkabel einziehen konnte. Schwierigkeiten habe ich mit den vielen HT's (ca. 23) gehabt, vor allen aber als ich John's Temperaturscanner ausprobiert habe. Mein Fazit aus dieser Erfahrung ist, dass man aus den Geräten nicht Dinge herauskitzeln sollte, die nicht implementiert sind. Folge dieses Tuns war, dass der Cube zum ersten Mal nach vier Jahren sein Gedächtnis verloren hat und nur mit Mühe wieder in Gang gesetzt werden konnte. M.E. wird in diesem Falle die Grenze des Funksystems mit der 1% Regel sehr wichtig, für mich mit ein Grund, die Möglichkeiten des ESP auszuloten. Unabhängig davon halte ich es für wichtig, bei großen FHEM Systemen die Aufgaben zu splitten, z.B. FHEM aufzuspalten oder mehr Aufgaben auf einzelne Systeme zu verlagern. NodeMCU bietet da in meinen Augen einen guten Ansatz. Es bietet einen schnellen 32 bit Prozessor, einen großen Program und auch Arbeitsspeicher. Auf diese Weise wären auch zeitkritische Applikationen möglich zu machen. Das Max!System mit den selbständigen HT's, vor allem HT+ wäre da ein gutes Vorbild.

[yamfhem]

Tach Fermoll,
den ESP12 wollte ich auch für die Aufnahme meiner Heizungstemperaturen (Vorlauf, Rücklauf, Wasser) verwenden. Aktuell habe ich einen Arduino Nano mit Ethernetshield und Firmata mit 3xDS18B20 laufen, aber das läuft nicht stabil. Deshalb der Umstieg. Kann der 8266 mit 1-Wire und den DS18B20 umgehen, hast Du das schon laufen?
Bzgl. durch den Rücken-Brust-Auge gebe ich Dir auf jeden Fall recht, in meinen Augen unsinnig, den ESP8266 mit einem Arduino wieder zu beschränken.

Gruß yam

[AndreasHH]

Moin,

ESP8266 in Verbindung mit DS18B20 ist kein Problem.
Nimmst Du Arduino IDE, mittels Boardmanager ESP-Unterstützung  hinzufügen und dann kannst Du div. funktionierende Beispiel-Sketche (auch für DS18B20) als Grundlage nehmen.


Gruss
Andreas

[fermoll]

Wie in dem anderen Thread http://forum.fhem.de/index.php/topic,46171.0.html
beschrieben, probiere ich erst einmal herum und teste an einem Beispiel - Keimkästen im Wintergarten.

[fermoll]

Ich möchte noch einmal auf meinen Beitrag "Teilung des Strnags"vom 21.12. zurückkommen,nachdem ich mich in den letzten Wochen intensiv mit der NodeMCU auseinandergesetzt habe. Es verfestigt bei mir der Eindruck den ich dort artikuliert habe. Verteilung der Aufgaben des FHEM auf Untereinheiten und Umstieg auf WiFi oder LAN. Die NodeMCU scheint dazu ein sehr gutes Werkzeug abzugeben, da es zusätzlich zum Station-Modus SOFTAP und STATIONAP ermöglicht. Mit dem letzteren kann man eine selbständige Untereinheit von mehreren Stationen aufbauen, die mit FHEM über die NodeMCU mit STATIONAP konferiert. Da scheinen sich noch viele Möglichkeiten zu ergeben. Mal sehen, wie sich das System noch entwickelt.