Hallo zusammen,
ich habe schon seit einiger Zeit die fhem.cfg per symlink auf einem USB-Stick ausgelagert. Das hat den Vorteil, wenn die SD-Karte zerschießt (was leider hin und wieder passiert), diese schnell gewechselt werden kann ohne große Dateien umzukopieren.
Die Log Dateien gehen auf einem SQL der Synology und die fhem.save auf einen gemountet Ordner von der Synology.
Gestern zickte der USB-Stick dann aber rum. Das ganze System (RPI3) läuft nicht mehr, weil er den Stick beim booten nicht eingebunden bekommt. :-\ Würde also davon gerne auch weg.
Dann habe ich die fhem.cfg mal per Symlink auf den gemountet Ordner gelegt. Leider ist es dann aber so, wenn die Synology mal neu gestartet wird, dass Fhem solange einfriert, bis die Diskstation wieder erreichbar ist. ::)
Gibt es dort noch eine bessere Lösung die fhem.cfg auszulagern? Umstellen auf ConfigDB wollte ich eigentlich ungern.
Schöne Grüße,
SteRa
Zitat von: stera am 23 August 2018, 08:25:50
Umstellen auf ConfigDB wollte ich eigentlich ungern.
Warum?
Ansonsten mache ich jeden morgen automatisch ein Backup von FHEM auf die Synology. Das kann man auch schnell wiederherstellen.
Und warum nicht einfach bei jedem save ein backup auf ein externes system oder Netz-Laufwerk schreiben?
Zitat von: marvin78 am 23 August 2018, 08:29:35
Und warum nicht einfach bei jedem save ein backup auf ein externes system oder Netz-Laufwerk schreiben?
Situation: Ich bin auf Arbeit, Frau Zuhause und das System kackt ab.. Dann kann sie einfach die SD-Karte tauschen und alles läuft wieder.
Ansonsten muss vor Start, erst alles wieder umkopiert werden.
Bei ConfigDB tue ich mir schwer. Ist ja doch wesentlich einfacher, mal schnell was zu ändern..
Zitat von: stera am 23 August 2018, 08:36:15
Situation: Ich bin auf Arbeit, Frau Zuhause und das System kackt ab.. Dann kann sie einfach die SD-Karte tauschen und alles läuft wieder.
Ansonsten muss vor Start, erst alles wieder umkopiert werden.
Bei ConfigDB tue ich mir schwer. Ist ja doch wesentlich einfacher, mal schnell was zu ändern..
Die SD-Karte musst du doch dann auch aktuell halten, FHEM-Updates usw.
Da kannst du doch die CFG auch mit rein nehmen. Oder Änderst du so viel am System?
Zitat von: stera am 23 August 2018, 08:36:15
Bei ConfigDB tue ich mir schwer. Ist ja doch wesentlich einfacher, mal schnell was zu ändern..
Das ist schlicht Quatsch.
Ich sage es immer wieder gerne: Ein Raspi mit SD Karte ist aus meiner Sicht nicht für einen wirklich produktiven Einsatz geeignet, falls FHEM Dinge tut, die ohne FHEM nicht funktionieren. Wichtige Dinge, wir Licht, Heizung und sonstiges, sollten immer auch ohne FHEM laufen. Dann gibt es auch mit dem Raspi kein Problem, wenn mal was ausfällt (was im Übrigen bei guten SD Karten so oft gar nicht vor kommt).
Zitat von: marvin78 am 23 August 2018, 08:43:36
Das ist schlicht Quatsch.
Ich sage es immer wieder gerne: Ein Raspi mit SD Karte ist aus meiner Sicht nicht für einen wirklich produktiven Einsatz geeignet, falls FHEM Dinge tut, die ohne FHEM nicht funktionieren. Wichtige Dinge, wir Licht, Heizung und sonstiges, sollten immer auch ohne FHEM laufen. Dann gibt es auch mit dem Raspi kein Problem, wenn mal was ausfällt (was im Übrigen bei guten SD Karten so oft gar nicht vor kommt).
Ich glaube dann gucke ich mir ConfigDB nochmal an.. Hatte das vor langer Zeit mal ausprobiert und da hat sich bestimmt einiges wieder verändert.
Bin jetzt auch seit gestern, wo der Vorfall mit dem USB Stick war, auf eine SSD umgestiegen.. Das sollte das SD-Problem schon mal minimieren ;o)
Generell bin ich mit dem RPI recht zufrieden. Die Zukunft wird sicherlich mal ein NUC oder ähnliches sein.. Mein Haus-AutomationsProjekt hat sich auch in letzter Zeit recht stark vergrößert ::)
..aber was ist, wenn ConfigDB auf dem SQL der Diskstaiton liegt und die mal nicht erreichbar ist? Weiß das jemand?
Lege ein PRESENCE Device für das NAS an und wenn das NAS nicht erreichbar ist, deaktiviere DBLog.
Ich würde, wenn ConfigDB läuft diese nicht auf einem externen Rechner ablegen.
Wenn die Netzverbindung mal weg ist, steht alles.
Wenn dann nur lokal.
Ich habe bei mir 2 Fhem Instanzen im Einsatz.
Eine Instanz für meine Heizungspumpen. Diese läuft auf der SD Karte, Änderungen habe ich schon länger keine mehr gemacht.
Davon gibt es Sicherungskopie auf einer anderen SD Karte. Zusätzlich wird das System täglich gesichert.
Log nur das normale Fhem Log. Geräte Stati frage ich am Hauptfhem ab. Ebenso die Temperaturwerte.
Das Hauptfhem ist meine Haussteuerung. Dies läuft auf einem Raspi 3 mit SSD.
DBLog und tägliche Sicherung. Zusätzlich mache ich alle 1- 2 Monate eine komplette Kopie der SSD auf eine andere SSD.
Somit habe ich immer eine lauffähige Kopie des Systems.
Raspberry ist auch immer auf Lager.
Beide Raspis laufen auf einem Batteriesystem, das auch mal ein paar Tage aushält.
60Ah BleiGel Batterie mit Ladegerät. Geladen wird nur Tagsüber, wenn PV Anlage Strom liefert.
Zitat von: maci am 23 August 2018, 09:20:52
Ich würde, wenn ConfigDB läuft diese nicht auf einem externen Rechner ablegen.
Wenn die Netzverbindung mal weg ist, steht alles.
Wenn dann nur lokal.
Bei mir läuft das genau so. Bei mir steht nie was.
Zitat von: marvin78 am 23 August 2018, 09:22:00
Bei mir läuft das genau so. Bei mir steht nie was.
Bist du ganz sicher, dass dein Netzwerk zu 100% verfügbar ist?
Ich sage, aus langjähriger Erfahrung, 100% gibt es nirgends. Auch Netzwerke sind mal überlastet oder fallen aus.
Nein. Muss ich auch nicht, weil ich auf Probleme reagieren kann.
Ich kann nur empfehlen, die Filesysteme auf der SD-Karte read-only zu betreiben. Dann ist an der Stelle schonmal Ruhe und die SD-Karten halten ewig.
Zitat von: stera am 23 August 2018, 09:05:06
Ich glaube dann gucke ich mir ConfigDB nochmal an.. Hatte das vor langer Zeit mal ausprobiert und da hat sich bestimmt einiges wieder verändert.
Nö.
Zitat von: marvin78 am 23 August 2018, 09:22:00
Bei mir läuft das genau so. Bei mir steht nie was.
Bei mir auch. Meine lokalen FHEM Installationen haben alle ihre configDB auf einem zentralen Server bei Amazon in Irland liegen.
Und wenn eine Netzwerkverbindung wirklich mal ausfällt, habe ich definitiv wichtigere Probleme als ein nicht funktionierendes FHEM :) (In den letzten drei Jahren ist die Verbindung bisher noch nie ausgefallen)
Zitat von: betateilchen am 23 August 2018, 11:17:33
Nö.
Bei mir auch. Meine lokalen FHEM Installationen haben alle ihre configDB auf einem zentralen Server bei Amazon in Irland liegen.
Und wenn eine Netzwerkverbindung wirklich mal ausfällt, habe ich definitiv wichtigere Probleme als ein nicht funktionierendes FHEM :) (In den letzten drei Jahren ist die Verbindung bisher noch nie ausgefallen)
Warum hostet du die configDB extern bei Amazon? Als Backup könnte ich es verstehen.
Dass das Internet mal ausfällt, kommt schon mal vor.
Zitat von: mark79 am 23 August 2018, 11:30:28
Warum hostet du die configDB extern bei Amazon?
Weil ich allen Unkenrufen hier im Forum zum Trotz die Zuverlässigkeit und Verfügbarkeit
in der Praxis testen wollte. Bisher habe ich keinen Grund zur Klage.
Hi,
ist es wirklich so, dass FHEM "einfriert", wenn die fhem.cfg nicht erreichbar ist? Ich gehe eigentlich davon aus, dass die fhem.cfg nur bei Start gelesen wird und dann nur noch, wenn man es explizit verlangt, also wenn man ein rereadcfg macht. Auch bei einem save kann ich mir vorstellen, dass es dann knallt. ...aber beides sollte man sowieso nur explizit bzw. manuell machen.
Gruß,
Thorsten
Für fhem.cfg ist das richtig, da wird nur beim Start gelesen.
Wer mit configDB arbeitet, sollte tunlichst dafür sorgen, dass die Datenbank permanent erreichbar ist, denn aus der Datenbank kommt nicht nur der Inhalt für die device-Konfiguration (define und attr) sondern noch eine ganze Menge mehr, z.B. gplot Dateien. Und die werden bei jeder Anzeige eines SVG erneut gelesen. Aber auch eventTypes, uniqueID und andere Dinge kommen aus der Datenbank bzw. werden dorthin geschrieben.
Zitat von: betateilchen am 23 August 2018, 19:04:08
Für fhem.cfg ist das richtig, da wird nur beim Start gelesen.
Wer mit configDB arbeitet, ...
Ok, das ist damit geklärt, aber der OP verwendet ja configDB nicht (oder hat es zumindest nicht verwendet), daher bleibt es ein Rätsel, warum FHEM steckenbleibt wenn fhem.cfg nicht "erreichbar" ist.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 23 August 2018, 14:07:59
Hi,
ist es wirklich so, dass FHEM "einfriert", wenn die fhem.cfg nicht erreichbar ist? Ich gehe eigentlich davon aus, dass die fhem.cfg nur bei Start gelesen wird und dann nur noch, wenn man es explizit verlangt, also wenn man ein rereadcfg macht. Auch bei einem save kann ich mir vorstellen, dass es dann knallt. ...aber beides sollte man sowieso nur explizit bzw. manuell machen.
Gruß,
Thorsten
Hätte garnicht gedacht,dass das Thema so Diskussions freudig wird :D.. Danke für die ganzen Antworten. Das mit dem einfrieren verstehe ich auch noch nicht, ist aber leider so. DB log läuft bei asynchron, daran liegt es nicht.. komisch komisch
Ich habe das gerade auf einem Testsystem nachgestellt. Selbst wenn ich die fhem.cfg im laufenden Betrieb komplett lösche, interessiert das FHEM überhaupt nicht.
Das freeze auf Deinem System vermute ich eher komplett auf Betriebssystemebene oder Du versuchst, noch andere Daten per Netzwerk in Dein FHEM zu bringen. Dass es an der fhem.cfg liegt, halte ich für völlig unwahrscheinlich.
Danke für das testen und die info. Dann liegt es evtl. an dem erstellten Symlink in auf Linux Ebene.. das werde ich nochmal weiter testen..
Ich würde gar nicht erst versuchen Workarounds zur SD-Karte zu finden sondern gleich ganz weg von der SD-Karte gehen?
Auf welcher Hardware läuft denn FHEM? Die Raspis ab 3 können mittlerweile auch von USB booten, da kann man auch via Adapter eine kleine SSD dranhängen.
Ansonsten ist der Cubietruck ne schöne Hardware, auch wenn er auch schon paar Tage älter ist ... GBit LAN, SATA, interner NAND, Anschluss für "Notstrom-Akku" mit entsprechender Ladeelektronik und es gibt schöne Gehäuse die auch Platz für den passenden Akku und SSD/HDD bieten.
Zitat von: roedert am 23 August 2018, 22:44:40
Ansonsten ist der Cubietruck ne schöne Hardware, auch wenn er auch schon paar Tage älter ist.
*unterschreib*
Läuft bei mir seit Jahren störungsfrei als DNS/DHCP Server im Netzwerk, stellt den FreeRadius Server zur Benutzerverwaltung in meinem WLAN und spielt die TimeMachine für MacBook und iMac.
Und jede Nacht synchronisiert er nebenbei noch mein Strato Hidrive auf seine interne 1TB Platte.
Zitat von: roedert am 23 August 2018, 22:44:40
Ich würde gar nicht erst versuchen Workarounds zur SD-Karte zu finden sondern gleich ganz weg von der SD-Karte gehen?
Auf welcher Hardware läuft denn FHEM? Die Raspis ab 3 können mittlerweile auch von USB booten, da kann man auch via Adapter eine kleine SSD dranhängen.
Ansonsten ist der Cubietruck ne schöne Hardware, auch wenn er auch schon paar Tage älter ist ... GBit LAN, SATA, interner NAND, Anschluss für "Notstrom-Akku" mit entsprechender Ladeelektronik und es gibt schöne Gehäuse die auch Platz für den passenden Akku und SSD/HDD bieten.
Das habe ich ja gemacht, wo dann der USB Stick sich danach verabschiedet hat.
Das System hat auch immer ohne Probleme gelaufen. Nach dem Update auf Stretch habe ich sporadisch mal den Fehler "cannot allocate memory" und danach läuft Fhem nicht mehr hoch. Habe leider den Fehler noch nicht gefunden und lt. Forum ist wohl auch die PerlVersion teilweise schuld. Danach habe ich dann die SD getauscht, dass erstmal wieder läuft..
Auffällig ist aber auch das der Swap-Speicher hin und wieder voll läuft. Den überwache ich aktuell jetzt mit sysmon.. Die letzten 2 Wochen ist dieser mir nicht mehr voll gelaufen.. Da warte ich noch...
Zitat von: stera am 24 August 2018, 13:55:21
Das habe ich ja gemacht, wo dann der USB Stick sich danach verabschiedet hat.
USB-Stick oder SD-Karte nimmt sich dich nix ... beide sind nicht für permanenten Schreibzugriff ausgelegt.
Dafür solltest HDD oder SSD nehmen.
Zitat von: roedert am 24 August 2018, 14:04:18
USB-Stick oder SD-Karte nimmt sich dich nix ... beide sind nicht für permanenten Schreibzugriff ausgelegt.
Dafür solltest HDD oder SSD nehmen.
Habe doch jetzt eine SSD genommen. Hatte ich am Anfang auch geschrieben ;)
Gruß Stefan
Darüber hinaus:
Zitatwenn die SD-Karte zerschießt (was leider hin und wieder passiert)
Warum ? Meine laufen jahrelang ohne Probleme.
1. Tipp: Bessere SD-Karten nehmen
2. Tipp: Logging etc. in den RAM auslagern
LG
pah