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.

[fermoll]

Aus gegebenem Anlass (Einbruchserie MG) mache ich mir im Moment Gedanken, mein Haus (2-3 Wohneinheiten) einbruchsicher zu gestalten.

1. Umbau und Sicherung des Hauseingangs- und der Wohnungstüre.

2. Überwachung der Fenster

3. Videoüberwachung im Garten

Bei den Punkten 1. u. 2. spielt im Moment die NodeMCU eine besondere Rolle. Wie ich an anderer Stelle schon einmal angeführt habe, stelle ich mir das so vor:

Meine Idee:

ESP mit mehreren GPIO-Pins. Pro Fensterflügel zwei oder drei Reed Kontakte.
Einer oben, einer unten, einer am Griff.
Oben offen  und Griff offen --> Meldung Fenster auf Kipp an FHEM
Alle drei offen  --> Fenster offen
Griff offen  --> Fenster nicht verriegelt.
ESP im DEEP Sleep. Wacht nur auf und macht Meldung, wenn ein Kontakt geöffnet oder geschlossen wird (Batterie) oder wenn FHEM abfragt. Wenn viele Fenster versorgt werden sollen, kann man ESP's als APStation zwischenschalten.

Das dürfte m.E. auch so zu gestalten sein, dass die Stromversorgung gesichert ist. Für jeden Flügel wären drei Reed-Kontakte nötig und für jeden ein GPIO.
Aufwändiger wäre da schon die Türsicherung. Als Schloss käme z.B. folgendes infrage:
http://www.fuhr.de/fuhr/de/produkte/prod_tuer_881.php?navid=9 Als Zugangskontrolle stelle ich mir die Verwendung von iButtons vor:
Z.B. folgende:
http://shop.wiregate.de/ibutton/ibutton-probes-touch-and-hold-mit-bicolour-led-2.html Die Steuerung übernimmt ein ESP-12e(f).
Die Verbindung zu FHEM würde dann für beide Beispiele ein ESP-12x als Staion AP übernehmen.
Wäre dann noch die Gestaltung der Klingelanlage zu überlegen.

Die Videoüberwachung würde ich mit der Surveillance Station von Synology gestalten und wenn möglich in FHEM einbinden.

[fermoll]

Da ich endlich die neue Version von FHEM installieren wollte, habe ich mich entschlossen, auch Raspbian auf  Jessie umzustellen. Vor allem reizt mich die Möglichkeit, auf dm Rpi mit Node-Red zu spielen, vor allem im Hinblick auf NodeMCU und ESP.

1.   Verwendete Hardware

RPI 2  2x
Logilink UA 0124 USB-Hub mit 3,5A 2x
2 Samsung IDE Festplatten 75 GB an Logilink AU 0006c(D)
2x Sandisk Ultra mSD 8GB   
Logilink ID 0104 kabellose Maus u. Tastatur 1x
1 Monitor
Den Rpi habe ich mit dem Hub 2-fach verbunden, einmal Datenleitung und Stromversorgung mit Mikro-USB. Das läuft jetzt fast ein Jahr zusammen mit einer FP ohne Pause runfd um die Uhr.

2. Installation Jessie

Jessie als ZIP heruntergeladen https://www.raspberrypi.org/downloads/raspbian/
Image mit Win32DiskImager auf die SD aufgespielt und gestartet.
Im Gegensatz zu Wheezy erscheint Jessie mit der GUI als User pi anstatt der Kommandozeile raspi-config auf dem Bildschirm. Die Konfiguration erfolgt mit der GUI.
Bild1
Deshalb bin ich auf die Idee gekommen, einen Remote Desktop auf meinem Windows Rechner zu installieren, der da schon vorhanden ist.
http://jankarres.de/2014/02/raspberry-pi-remote-desktop-installieren/
Das geschieht in gewohnter Weise mit der Kommandozeile im LX-Terminal.
Wenn xrdp installiert und der Rchner neu gestartet ist, braucht es den extra Bildschirm nur noch, wenn der Rpi mal nicht mit der GUI
hochfährt. Die Menüs der GUI erscheinen teils auf Deutsch oder Englisch, ebenfalls die Erläuterungen im LX-Terminal.
Die Konfiguration beschränkt sich erst einmal auf das Fenster in Bild 2, und zwar auf die Reiter System, Interfaces und Localisation. Allerdings steht auch raspi-config in root zur Verfügung.
Im nächsten Beitrag geht es um die Einbindung der Festplatte als /root und den weiteren Verlauf der Konfiguration.

[betateilchen]

Im nächsten Beitrag geht es um die Einbindung der Festplatte als /root und den weiteren Verlauf der Konfiguration.

Man bindet niemals eine Festplatte als /root ein. Zumindest nicht, wenn man die Sicherheitskonzepte von Linux verstanden hat.

[fermoll]

@Betateilchen

Kannst du das etwas erläutern oder mir einen Link geben, wo ich das nachlesen kann. Ich verwende seit 1985 DOS bzw. Windows Rechner. Mir geht es darum, die Anfälligkeit der SD-Karte zu umgehen. Da mir nicht klar ist, wie Raspbian Programme speichert, die häufig Daten verändern, habe ich diesen Weg gewählt.

PS: Meinst du sowas?   https://wiki.ubuntuusers.de/Sicherheitskonzepte/
Werde ich mich mit beschäftigen.

[fermoll]

Unabhängig von Betateilchens Einwand habe ich /root, also /dev/mmcblk0p2 auf die Festplatte übertragen.

Festplatte formatieren auf ext4

Verwendet habe ich Minitool Partition Wizard free auf meinem Windows Rechner. Auf einer mit ext4 formatierten Festplatte werden Rechte genaus so vertreilt wie auf der SD. Irgendwo habe ich gelesen, dass Linux auf Windows Partitionen nur eingeschränkt Dateirechte vergeben kann. Deshalb ext4. Damit ist wohl Betateilchens Einwand hinfällig.
Die Anleitung habe ich hier gefunden: http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_Laufwerke.html
Zuerst mit sudo fdisk -l geprüft, wie sie erkannt wird. Da sie als einzige angeschlossen ist, ist es /dev/sda1.
Da Jessie beim Neustart die Platte unter /dev/media mounted, habe ich sie erst einmal ausgehängt: sudo umount /dev/sda1.
Dann auf /mnt gemounted: sudo mount /dev/sda1 /mnt.
Bei Netzmafia werden drei Möglichkeiten des Kopierens angezeigt. Die ersten beiden habe ich verworfen, da die Kapazität der Platte eingeschränkt ist und es mir zu aufwändig war, die Partition zu vergrößern. Für die 2. fehlte auf meiner Tastatur der senkrechte Slash. Bei Wheezy habe ich das probiert und es hat nicht geklappt.
Mit sudo rsync -axv / /mnt hat es dann funktioniert, allerdings nur mit Logilink AU 0006c(D). Mit einem USB Gehäuse hat es nicht funktioniert.

Als nächstes muss die Datei cmdline.txt auf der SD geändert werden. Das habe ich auf meinem Windws Rechner mit dem Speedcommander erledigt.

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 ↵
  console=tty1 root=/dev/sda1 rootfstype=ext4 ↵
  elevator=deadline rootwait rootdelay=5
Änderungen in rot.
Allerdings habe ich letztendlich den rootdelay weggelassen. Der könnte vielleicht sinnvoll sein, wenn man WLAN verwendet.

Zuletzt muss die Datei /etc/fstab geändert werden. Dabei muss man darauf achten, dass die Version auf der Festplatte unter /mnt geändert wird und nicht die aud der SD.
proc            /proc           proc    defaults          0       0
/dev/sda1       /               ext4    defaults,noatime  0       1
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
#/dev/mmcblk0p2  /               ext4    defaults,noatime  0       1

Die 1 in der 2.Zeile habe ich durch eine 0 ersetzt, da sonst das Booten unendlich lange dauert, da jesdesmal die Platte überprüft wird.
Beim reboot wird dann die Festplatte eingesetzt, was man daran erkennen kann, dass die innere der beiden LED's auf dem Rpi dunkel bleibt.
Sollte es nicht klappen, muss man die cmdline.txt wieder verändern. Wie gesagt. Es hat bei zwei Rpi's funktioniert.

[betateilchen]

Unabhängig von Betateilchens Einwand habe ich /root, also /dev/mmcblk0p2 auf die Festplatte übertragen.

Diese Aussage ist völliger Quatsch!

Du hast nicht /root auf die Festplatte übertragen sondern / und das ist ein gewaltiger Unterschied, den man zwingend kennen sollte, bevor man solche Aussagen macht und "Anleitungen" erstellt!

[fermoll]

Die Installaton von FHEM habe ich nach der Anleitung im Wiki erledigt:
http://www.fhemwiki.de/wiki/Raspberry_Pi
ab Punkt FHEM.
In meinen Augen ist auch die Rechtevergabe wichtig, die hier beschrieben ist: http://www.fhemwiki.de/wiki/FHEM_auf_Raspberry_PI_mit_COC_betreiben, und zwar ab Punkt 14.
Mit dem Kopieren der Config Datei konnte bis auf die Anbindung des Locutus Add-on boards der vorherige Zustand wiederhergestellt werden.
Der nächste Schritt war, die momentane Installation zu sichern. Das habe ich mit Hilfe einer weiteren ext4 Festplatte erledigt.
Festplatte eingestöpselt. Wird als /dev/sdb1 erkannt. Sollte mit fdisk überprüft werden. Auf /mnt gemounted. Mit rsync -axv / /mnt root auf der FP gespeichert.
Der nächste Schritt ist, Locutus add-on Board einzu binden, das er leider nicht mehr produziert. Was ich allerdings nachvollziehen kann.
Ich habe die Anleitung von Jan. 2015 verwendet. Die erscheint mir die aktuelle zu sein. Da muss natürlich viel verändert werden, vor allem auch auf Betriebssystemebene. Da arbeite ich dran.
Gerade dieser Punkt wirft die Frage nach der Datensicherung auf. Was muss gesichert werden. Wenn das System streikt, ist die Frage, ob es vollkommen neu aufgesetzt werden muss. Dann hilft es wenig, wenn nur FHEM gesichert wird. Bei der Installation werden so viele Veränderungen außerhalb von FHEM vorgenommen, dass eine Sicherung der gesamten /root unabdingbasr erscheint.
In meinem Fall der oben angeführten Sicherung wäre dann sinnvoll, bei einer weiteren nur die veränderten oder neuen Dateien zu sichern. Da arbeite ich noch dran. Die weitere Frage ist, ob es unbdingt nötig ist, die FHEM-Log Dateien zu sichern. M. E. ist die Sicherung der cfg schon zielführend. Das habe ich mit WINSCP erledigt. Um die Sicherung zu beschleunigen, wäre es wichtig, dass nur veränderte oder neue Dateien kopiert werden. Ich muss mich also mit rsync genauer beschäftigen. https://wiki.ubuntuusers.de/rsync/ Der nächste Schritt wäre, statt der FP die Sicherung auf der Synology zu speichern und dabei die oben genannten Einschränkungen zu beachten.

[fermoll]

Ich halte leider deinen Einwand für wenig zielführend, vor allem aber für pädagogisch völlig unmöglich. Wenn du dein eigenes Zitat richtig gelesen hättest, wäre eigentlich deutlich geworden, was ich auf die Festplatte kopiert habe, auch wenn es ein fachlicher Fehler gewesen sein sollte.
PS:
Ich meinte natürlich den root-Ordner, der alle Dateien der mmcblk0p2-Partition der SD-Karte enthält.

PPS:
Ich bin natürlich offen für Kritik, doch sollte sie weder verletzend sein,  noch am Ziel vorbei schiessen.

[betateilchen]

Du kannst behaupten, was Du willst, aber den Unfug "/root übertragen" hast Du hier einfach viel zu oft gebracht, um es nur als Versehen stehen zu lassen.

Ich meinte natürlich den root-Ordner, der alle Dateien der mmcblk0p2-Partition der SD-Karte enthält.

Nein, Du meintest das gesamte Dateisystem.

Das Schlimme ist: es gibt ja tatsächlich einen Ordner namens /root - und der hat mit dem, was Du hier beschreibst, absolut nichts zu tun! Hast Du Dir mal darüber Gedanken macht, welche pädagogischen Auswirkungen solche total falsch verwendete Begriffe bei Anwendern haben, die noch weniger Linux Verständnis haben als Du? Also hör bitte auf, mich vollzumaulen.

[fermoll]

Also hör bitte auf, mich vollzumaulen.

Wenn du das als pädagogische Anleitung meinst, bist du auf dem falschen Dampfer. Also lass das  bitte. Wenn du deine Einlassung zumindest ansatzweise erläutert hättest, wäre es der Sache besser gedient gewesen.

[fermoll]

Installation von Raspbian Jessie auf SD: Damit steht node-red zur Verfügung, das ich auf dem Rpi ausprobieren möchte.
Der Versuch des  Upgrade der bestehenden Wheezy- Installation, die seit einem Jahr auf Festplatte läuft, hat diese leider zerschossen.
Mittlerweile läuft Jessie auf 2 Rpi's mit 75GB Ide-Platten, die am Logilink Adapter hängen. Ein vorhandener Adapter in einem Gehäuse funktioniert nicht. Andere Platten habe ich nicht probiert. Die SD wird nur zum Bootvorgang benötigt und kann auf mmcblk0p1 beschränkt werden. Es genügt also eine kleine Mikro SD, FAT formatiert, da nur weniger als 100mb gebraucht werden.
Da bei der Installation von FHEM, vor allem auch Locutus Add-On einiges an Raspbian verändert wird, halte ich es für sinnvoll, den Inhalt der Festplatte vollständig zu sichern.
Da ich noch nicht gelernt habe, wie man den Rpi an das NAS anbindet, mache ich das mit einer zusätzlichen Festplatte, die mit ext4 formatiert ist.

Festplatte eingestöpselt. Wird als /dev/sdb1 erkannt. Sollte mit fdisk überprüft werden. Auf /mnt gemounted. Mit rsync -axv / /mnt root auf der FP gespeichert.

Aber Vorsicht. Bevor man die Platte entfernt umount verwenden. Da das System 24/7 läuft, sollte man vor der Sicherung ein reboot durchführen, das sdxx bei jedm Anstöpseln hochrechnet "b,d,....". Auch ist es nicht sinnvoll, die zusätzliche Platte oder den Stick beim Booten schon eingesteckt zu haben, da es passieren kann, dass sda1 dann nicht das System ist.
Sollte man hier nochmal nachlesen:http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_Laufwerke.html
Ich hoffe,ich konnte einigen behilflich sein. Da ich keine Lust habe, über Linux zu debattieren, vor allem in dem angeschlagenen Ton, beende ich hiermit den Stang