Erfahrungsbericht: fhem auf Synology mit und ohne Docker

Begonnen von micomat, 29 Januar 2020, 08:42:48

Vorheriges Thema - Nächstes Thema

micomat

Servus,

nachdem ich das SD Sterben auf RasPi (3) leid war und meine DS216j ohnehin zum Austausch gegen eine DS218+ stand, lag die Idee nahe, auch fhem dorthin zu portieren. Ich hatte bereits einen Unifi Controller und einen PiHole Docker am laufen, da kam die fhem Implementierung gerade recht.

Nach kurzer Recherche habe ich dann gesehen, dass es ein fertiges Paket fuer Syno gibt und mich entschlossen fhem, aus Gruenden der Flexibilitaet, nicht im Container laufen zu lassen.

Der Umzug gestaltete sich auch super einfach. Auf dem bisherigen RasPi die CULs als Ser2Net verbunden, Parallelbetrieb beider Installationen hergestellt und dann nach und nach die Devices migriert.
Ein Backup und Restore kam nicht in Frage, die Config hatte so viele unnuetze Devices ueber die Jahre angesammelt, dass ich bedarfsorientiert migrieren besser fand. Seit Ser2net 3.2 kann man mehrere Connections zum gleichen Serial Device konfigurieren, was fuer den vorruebergehenden Parallelbetrieb ganz gelegen kam. Auch die THZ sowie einige OBIS und ein MBus Modul haben meckerfrei mit dem neuen Ser2Net beide fhem bedient.

Gescheitert bin ich dann aber am SMAInverter Modul. Ich habe es auch nach tagelangem Versuch und Irrtum, ipkg und cpan installation, Voodoozauber und Globuli in die Syno nicht geschafft, das perl DateTime (libdatetime-perl) oder XString auf der Syno zu installieren. Genervt habe ich mich an den Docker Container erinnert und mich letztendlich dann dafuer entschieden, die nun auf der Syno laufende Config an den Container zu uebergeben, dort funktionieren alle Module wie erwartet.

Haette ich nicht den Umweg ueber das FHEM Syno Paket gemacht waere das ganze in einem Tag wohl erledigt gewesen.

Performance: Man hat bei großen Plots bzw logs durchaus die Grenzen der Leistung des RasPi3 gemerkt. Bei der Syno ist das jetzt alles ohne merkbare Latency erledigt.

Containersettings: max 4GB RAM (meine Syno hat 12GB)
CPU Prio mittel:
Verwendung der LAN Interfaces ohne Docker NAT
Gemountet habe ich das /opt/fhem des Containers auf /docker/fhem der Syno

Vielleicht findet das ja mal jemand bei gleicher Ueberlegung hilfreich ;)

Update: Das Setup laeuft jetzt seit 4 Wochen stabil und natuerlich auch deutlich performanter als auf einem RasPi.
Synology DS218+ with fhem+iobroker in docker, 2x RasPi w. ser2net, CUL433+868, IT, EGPM2LAN, THZ/LWZ, FB_Callmonitor, HMS100TF, Homematic, 2x TX3-TH, Pushover, USB-IR-SML-Head, SONOS, GHoma, MBus, KLF200

flummy1978

Hallo Micomat,

vielen Dank für das Teilen Deiner Erfahrung. Bei mir steht demnächst der Umzug vom RasPi auf mene neue DS 918+ bevor und da bin ich immerwieder froh Erfahrungsberichte, mögliche Stolpersteine usw zu lesen.

Hab ich das soweit richtig verstanden / nachvollzogen, dass Du mit Ser2Net die bisherige Hardware (Culs etc) am Raspi weiter hast laufen lassen, während Du das an der Diskstation eingerichtet hast und configuriert hast ? Also quasi zu dem Zeitpunkt 2 Installation gleichzeitig hattest, die auf die Hardware zugegriffen haben ?
Gibt es da was zu beachten, weil man 2x auf die Hardware zugreift oder ? ....

Vielen Dank und viele Grüße
Andreas

micomat

Hallo,

ja, das ist richtig. Ab Version 3.2 von ser2net kann man mit mehreren Clients gleichzeitig auf die verbundenen Schnittstellen zugreifen. Das hat bei mir auch problemlos funktioniert :)

Zu beachten gibt es nichts, nur eben eine Version 3.2 oder spaeter von ser2net nutzen. Und in der ser2net.conf den Parameter "max-connections" konfigurieren. ich hatte hier 10 eingestellt damit bei einem Verbindungsabbruch die Verbindung sofort wieder aufgebaut werden kann.
Synology DS218+ with fhem+iobroker in docker, 2x RasPi w. ser2net, CUL433+868, IT, EGPM2LAN, THZ/LWZ, FB_Callmonitor, HMS100TF, Homematic, 2x TX3-TH, Pushover, USB-IR-SML-Head, SONOS, GHoma, MBus, KLF200

stera

Hallo,

ich habe 4 Fhem Instanzen über Docker auf einer DS218+ laufen. Verbunden sind diese über ein MQTT-Server(Docker). Das war in meinen Augen ein riesen Sprung der Verbesserung, alleine über HyperBackup mit der Timeline ältere Stände zurückspulen usw.. :D

Das einzige was ich noch nicht raus bekommen habe, wie ich die Lokale IP (z.B. 172.17.0.1) im Docker festlege (Nach einem Restart stimmen die meist nicht mehr und bekommen eine neue freie)

Hat da jemand vllt. ein Tip? Für den FritzBox SipGate und Amad Module ist das sehr entscheidend.

Schöne Grüße,
Stefan


Rossi

Hi, klingt sehr interessant, habt ihr ein Anleitung oder Links, wie die Installation auf der Synology abläuft?
Wäre sehr hilfreich, ich würde es auch gerne probieren.[emoji6]

Gesendet von meinem SM-G960F mit Tapatalk


TWART016

Zitat von: stera am 27 April 2020, 22:23:25
ich habe 4 Fhem Instanzen über Docker auf einer DS218+ laufen. Verbunden sind diese über ein MQTT-Server(Docker).
wie verbindest du die über MQTT?

Zitat von: stera am 27 April 2020, 22:23:25
Das war in meinen Augen ein riesen Sprung der Verbesserung, alleine über HyperBackup mit der Timeline ältere Stände zurückspulen usw.. :D
Du sicherst nur die Volumen? Ich nutze bisher Active Backup for Business. Welche Vorteile haben Hyper Backup?

Zitat von: stera am 27 April 2020, 22:23:25
Das einzige was ich noch nicht raus bekommen habe, wie ich die Lokale IP (z.B. 172.17.0.1) im Docker festlege (Nach einem Restart stimmen die meist nicht mehr und bekommen eine neue freie)
Mit docker run kann eine IP zugewiesen werden: --ip 192.168.178.38

Ich benutze die Container bisher in 2 Netzwerken, die zweite kann man damit hinzufügen:
docker network connect netzwerk2 fhem --ip 192.168.178.38


Zitat von: Rossi am 28 April 2020, 08:02:54
Hi, klingt sehr interessant, habt ihr ein Anleitung oder Links, wie die Installation auf der Synology abläuft?
Wäre sehr hilfreich, ich würde es auch gerne probieren.[emoji6]
Ich benutze das so. Das network muss existieren oder kann einfach weggelassen werden.

sudo mkdir /volume1/docker/fhem
docker run -d --name fhem --network=Infrastruktur --ip 192.168.11.51 -p 8083:8083 -v /volume1/docker/fhem:/opt/fhem fhem/fhem

stera

#6
Für MQTT habe ich den "eclipse-mosquitto" vom Docker Hub laufen.
In den FhemInstanzen jeweils ein Client

defmod mqtt2_ga MQTT2_CLIENT 192.168.10.65:1883
attr mqtt2_ga alias MQTT2 Client Broker
attr mqtt2_ga autocreate no
attr mqtt2_ga devStateIcon .*active:none:disconnect .*disconnected:none:connect
attr mqtt2_ga group MQTT
attr mqtt2_ga icon mqtt
attr mqtt2_ga room 06_MQTT
attr mqtt2_ga verbose 0


In den einzelnen Devices dann über die MQTT-Attributen steuern.

FHEM Instanz1:
defmod Status.Home dummy
attr Status.Home event-on-change-reading .*
attr Status.Home group 01_Status
attr Status.Home mqttPublish *:topic={"FHEM/$device/$reading"}
attr Status.Home room 01_Anwesenheit

FHEM Instanz2:
defmod Status.Home dummy
attr Status.Home alias MQTT->Status.Home
attr Status.Home group 01_Status
attr Status.Home mqttSubscribe *:topic={"FHEM/$device/$reading"}
attr Status.Home room 01_Anwesenheit


Das ganze läuft erstaunlicherweise sehr sehr gut. Bin sehr zufrieden.

Das Active Backup kenne ich gar nicht bzw. habe ich noch mit gearbeitet. Mir reicht bis jetzt der "Fhem Ordner". Den in einen Volumen zu packen und jeden Tag zu sichern. Dann kann ich sehr schnell beliebige Stände wieder zurückholen.

Das mit der zweiten IP werde ich nochmal testen. Vielen Dank.


duke-f

Hi @micomat,
auch von mir: Besten Dank für das Teilen der Erfahrung.
Ich habe ja ein QNAP und wollte mich auch schon gelegentlich dazu verleiten lassen, dort entweder auf einem Container oder als virtuelle Maschine meine Hauptinstallation von FHEM laufen zu lassen. Hab' mich aber dann doch immer wieder dagegen entschieden. Grund dafür: Auf meinem NAS läuft so einiges und - zwar selten, aber doch eben gelegentlich - gibt's da Probleme bei einem Neustart oder andere ungünstige Situationen. Daher komme ich immer wieder dazu, die Zentrale meiner Hausautomation auf einem getrennten, praktisch unabhängigen Gerät laufen zu lassen. Habe dafür einen Cubietruck mit (maßlos überdimensioniertem) SSD-Laufwerk.

Weiter habe ich mittlerweile 3 Raspberries mit Slave-FHEM. Den ersten davon seit ca 2014. Bisher hatte ich da noch absolut nie Probleme mit der SD-Card. Allerdings habe ich mir ziemlich schnelle dafür eine der teuersten - angeblich besten - mit ausreichen Kapazität gekauft und schreibe schon länger nur sehr wenig Logfiles darauf. Im wesentlichen werden diese Raspberries aber genutzt, meine CULs im Haus zu verteilen und diese auch per ser2net einzubinden an die Hauptinstallation.

Dein Beitrag lässt mich jetzt aber wieder nachdenken, eventuell doch auch mal eine parralel-Installation im Container anzudenken, zumindest um notfalls ein Fallback-System für den Notfall parat zu haben.
Cubietruck, 3 Raspberry Pis,
CUL868, RFXtrx433, CUL433, SCC868, HM-USB,
IRTrans, EZcontrol XS1, IguanaWorks USB IR Transceiver
ESPEasy, Fritz!Box, Samsung TV+BD, LMS, Squeezelite

micomat

Danke für das Feedback ;)
Mittlerweile hab ich schon einiges durch mit meinem FHEM im Docker: Stromausfall, versehentliche Reboots der Synology, Crashen der abgesetzten PIs an denen die CUL hängen, usw... aber, ich muss gestehen, es läuft problemlos weiter. Ich hab's nicht bereut bisher.

Besonders beim Neustart ist das FHEM auf dem Syno deutlich flotter wieder da als es auf dem RasPi gewesen ist. Der war da einfach etwas schwächer auf der Brust.
Synology DS218+ with fhem+iobroker in docker, 2x RasPi w. ser2net, CUL433+868, IT, EGPM2LAN, THZ/LWZ, FB_Callmonitor, HMS100TF, Homematic, 2x TX3-TH, Pushover, USB-IR-SML-Head, SONOS, GHoma, MBus, KLF200