[gelöst] Zu viele Raspberrys mit FHEM

Begonnen von Lorenz, 07 November 2014, 19:40:06

Vorheriges Thema - Nächstes Thema

Lorenz

Hallo liebe Leute,

ich brauche mal einen Tipp und Eure Erfahrungen zu meiner FHEM Landschaft:

Ich betreibe u.a. mehrere Raspberry Pis mit FHEM, welche mittels FHEM2FHEM im LAN an ein übergeordnetes FHEM auf einer Synology Diskstation gekoppelt sind.

Logging und plotting und Bedienung (rückwärts über RFHEM) findet nur auf der Diskstation statt.

Die Raspberrys wickeln die Kommunikation mit unterschiedlichen Schnittstellen ab. Ein System beschäftigt sich ausschließlich mit der seriellen Kommunikation mit einer Alarmanlage (zeitkritisch und überwacht, Erläuterung im weiteren Text), ein weiteres System spricht über ECMD mit der Buderus-Heizung und erfasst zusätzlich über GPIO den Gaszähler. Und das dritte System bedient ausschließlich einen 1-Wire Bus mit OWX zur Temperatur-Erfassung. Weiterhin gibt es noch eine FritzBox mit FHEM und CUL für FS20, aber die soll hier keine Rolle spielen.

Die Struktur ist über die (lange) Zeit gewachsen und läuft nun äußerst stabil.

Normalerweise fasst man sowas nicht an, trotzdem überlege ich, die beiden Systeme Heizung und 1-Wire zusammenzufassen, um einen Raspberry einzusparen (und neuen Aufgaben zuzuführen).
Das Alarmsystem soll in jedem Fall separat bleiben. Ich habe allein durch Abfrage von Wetterdaten  (DWS) im Zusammenhang mit Internetausfällen hier Stress gehabt - das braucht man insbesondere Nachts nicht bei den üblichen Wartungsfenstern.

Wie groß sind die Chancen OWX und ECMD gemeinsam auf einem Raspberry stabil zu bekommen? Ungern würde ich umbauen und anschließend den Rückweg antreten müssen, da damit auch diverse Änderungen in der Verkabelung notwendig werden.

Hat jemand eine ähnliche Kombination und damit Erfahrungen? Auf dem 1-Wire Bus sprechen z.Zt. 15 Sensoren im 5 Minuten Takt. ECMD spricht über telnet mit der gesprächigen Heizung (ca. 10 MB Traffic am Tag) und gelegentlich löst der Gaszähler über GPIO ein Event aus.

Das übliche Monitoring gibt dazu nicht viel her, da sehen die Systeme eher unterbeschäftigt aus.

Kann man eventuell Probleme vermeiden, indem man auf einem Raspberry 2 FHEM Instanzen einsetzt? Geht das überhaupt?
Wenn ja, könnte ich eventuell auch das Thema der sensiblen Alarmanlagen-Schnittstelle abkapseln ? (Dann wäre vielleicht noch ein Raspberry weg)
Hier ist aber ein genaues Polling erforderlich, da die Alarmanlage die Kommunikation überwacht und richtig Stress bei Störungen macht.
Da war der WAF (so zwischen 2.00 und 4.00 Uhr nachts) schnell sehr weit unten und ich bin vorsichtig geworden. ;)

Über Euer Feedback würde ich mich freuen.

LG
. . . . . .
Fhem auf NUC7i3BNH, Raspberry Pi B und B+, Raspberry Pi 2 B, Peripherie: FB7490, 1-Wire, Homematic, FS20, Lampen, Briefkasten, Klingel, Sonos, GardenaSmart, Unifi, Gaszähler an GPIO, Stromzähler EFR SGM-C4, Heizung Buderus GBH 172, Alarmanlage EMA und BMA von Bosch

rudolfkoenig

Falls du sorgen wg. der Stabilitaet hast, dann wuerde ich zwei FHEM Instanzen auf einem RPi starten.
Da diese nur Daten sammeln, sollte es mit der CPU kein Problem sein, und Hauptspeicher ist vermutlich auch kein Thema. Man muss bei den Instanzen darauf achten, dass die Portnummer unterschiedlich sind.
Ich wuerde auch zwei getrennte Verzeichnisse nehmen, dann kann man die FHEMs separat mit update begluecken.

Lorenz

Danke Rudolf für die Motivationshilfe.
Das ist mittlerweile auch meines Erachtens der richtige Weg.
Ich bin dabei eine 2. Instanz für den 1-Wire Teil auf dem Heizungs-Raspberry einzurichten. Momentan habe ich dabei noch Startschwierigkeiten.  Ich habe die Installation in ein separates Verzeichnis kopiert und alle Ports dieser Installation verändert. Init.d ist entsprechend erweitert. Aber ich komme noch nicht auf den Server. Hat da jemand noch einen Tipp für mich. Das könnte meine Forschungsarbeiten verkürzen. Vielleicht übersehe ich da noch was...

LG
. . . . . .
Fhem auf NUC7i3BNH, Raspberry Pi B und B+, Raspberry Pi 2 B, Peripherie: FB7490, 1-Wire, Homematic, FS20, Lampen, Briefkasten, Klingel, Sonos, GardenaSmart, Unifi, Gaszähler an GPIO, Stromzähler EFR SGM-C4, Heizung Buderus GBH 172, Alarmanlage EMA und BMA von Bosch

rudolfkoenig

Solche Probleme loese ich, indem ich FHEM mit "attr global logfile -" erstmal in einem Terminal starte, dann sieht man die Fehler direkt, und man kann die Parameter anpassen. Wenn es laeuft, dann kann man es wieder von init.d & co starten lassen.

Lorenz

Danke, der Tipp war gut und hat gezeigt, dass beim manuellen Start alles i.O. war. Mir fehlte nur die Zuordnung zum Runlevel für das neue Init Skript. Jetzt läuft auch der Autostart der 2. Instanz und ein Raspberry ist schonmal entfernt. Jetzt schau ich mir die Langzeitstabilität an ...

LG
. . . . . .
Fhem auf NUC7i3BNH, Raspberry Pi B und B+, Raspberry Pi 2 B, Peripherie: FB7490, 1-Wire, Homematic, FS20, Lampen, Briefkasten, Klingel, Sonos, GardenaSmart, Unifi, Gaszähler an GPIO, Stromzähler EFR SGM-C4, Heizung Buderus GBH 172, Alarmanlage EMA und BMA von Bosch

Deudi

Zitat von: Lorenz am 09 November 2014, 14:32:27
Jetzt schau ich mir die Langzeitstabilität an ...
Ich hatte auch massive Probleme während einer Internetstörung. Nun sind alle nicht HM Sachen auf einer zweiten Instanz und das läuft hier seit einem knappen Monat ohne Probleme.
Gigabyte Brix, Ubuntu 16.04.3 LTS, Homematic, Z-Wave, EnOcean, Shelly@MQTT, SIGNALduino, JeeLink DAVIS-Sketch

Prof. Dr. Peter Henning

Ein Cubieboard 2.

Darauf 1 ECMD für Heizungsabfrage, 5 verschiedene 1-Wire Busmaster unter OWX, HM-CFG-WLAN mit ca. 20 HomeMatic Devices, Alarmanlage, Fotovoltaikanlage über serielle Schnittstelle, 1 CUNO und 2 CUL mit ca. 30 FS20-Devices.

Und warum sollte das nicht stabil sein ? Bei mir ist es das jedenfalls.

LG

pah

Deudi

Zitat von: Prof. Dr. Peter Henning am 10 November 2014, 08:15:47
Und warum sollte das nicht stabil sein ? Bei mir ist es das jedenfalls.
Solange alle Module FHEM nicht längere Zeit blockieren, ist das auch stabil. Falls FHEM länger steht, halt nicht mehr.
Gigabyte Brix, Ubuntu 16.04.3 LTS, Homematic, Z-Wave, EnOcean, Shelly@MQTT, SIGNALduino, JeeLink DAVIS-Sketch