ConfigDB: Umzugserfahrungen und verlorene Konfigurationen...

[Morgennebel]

Moin Moin,


(das ist kein Gemecker, nur eine Zusammenfassung meiner heutigen Arbeit)

Ich hatte drei virtuelle Server im Einsatz: VM-SQL mit MariaDB, FHEM-MASTER und FHEM-INTERNET. FHEM-MASTER nutzt noch einige exotische Module aus dem Heizungsbereich: 39_VALVES, 39_STELLMOTOR, 72_XiaomiDevice und 63_Esera-*.

Heute habe ich viel Zeit damit beschäftigt, diese auf meinen neuen Thinclient umzuziehen. In meiner naiven Vorstellung dachte ich, ich installiere FHEM zweimal (/opt/fhem-master und /opt/fhem-internet) neu, hänge die neuen Installationen an die configDB (lokale MariaDB-Instanz), kopiere die SQL-Dumps und importiere diese und bin fertig.

Evtl. noch ein-zwei Perlpakete nachinstallieren, aber der Aufwand sollte gering sein...

Naja. Das installieren und der Umzug hat bis jetzt gut sechs Stunden gekostet. Viel Zeit und Nerven hat mich gekostet, daß FHEM "fehlerhafte" Definitionen einfach löscht und offenbar beim Shutdown fleissig in die ConfigDB schreibt. Da einige der Module nicht installiert waren, scheiterte die Definition der Devices. FHEM hat dann fleissig die Definitionen aus der ConfigDB gelöscht, während ich in den Logfiles nach den fehlenden Perlpaketen suchte und diese nachinstallierte (libperl-crypto-rijndael - mein geliebter Feind).

Während dieser Tests schrumpfte unbemerkt meine Konfiguration weiter und weiter. Mühsam habe ich mich dann (nachdem mir auffiel, daß das Haus nicht heizte) die einzelnen Definitionen aus alten Versionen der ConfigDB gefrickelt und mit RawImport wieder eingefügt.
Meine 99_MyUtils bleibt verschollen - ein configdb filelist zeigt diese nicht mehr an

Ein wenig Zeit kostete die Anpassung der init-Skripte aus dem config-Verzeichnis. Diese sind nicht für die ConfigDB vorbereitet und vermissen Abhängigkeiten zu MySQL (oder PostgreSQL) für mein Devuan mit klassischem InitV-System. Auch zwei FHEM-Instanzen zu starten und gezielt wieder zu stoppen, geht mit den mitgelieferten Scripten nicht - aber eine Lösung ward schnell gefunden (und ja, ich mag keine Container - die kann ich im Fehlerfall nicht so gut reparieren).

Ich würde es wirklich begrüssen, wenn die ConfigDB von FHEM unangetastet bleibt und einfach nur eine Fehlermeldung ausspuckt, wenn eine Definition mangels Paketen scheitert. Die Komplexität von FHEM steigt durch die vielen Zusatzmodule, durch die vielen neuen Features (was ich explizit toll finde und mich bei den Modulautoren für ihre Mühe bedanke) - aber wir haben vielleicht einen Punkt erreicht, in dem ein Serverumzug ohne Probleme wichtiger ist als das FHEM sofort neu startet. Die PIs werden von den neuen Features überfordert und viele wechseln in Richtung Thinclient, NUC oder Zotac-Boxen und kombinieren dies mit ConfigDB.

Danke, -MN

[Beta-User]

Hmm,

vorab mal: Glückwunsch, dass das im Prinzip jetzt erfolgreich abgeschlossen zu sein scheint!

Soweit ich das beurteilen kann, ist es auch bei configDB so, dass die Konfiguration nur dann gespeichert wird, wenn man das veranlaßt, und ganz normal auch nur Geräte in die Konfiguration geladen werden, für die das möglich ist - maW: das wäre genauso auch mit fhem.cfg passiert.

Die 99_myUtils könnte auch ganz normal im filesystem das Altsystems zu finden sein, die war evtl. gar nicht importiert.

Bei meinen eigenen diversen Umzügen hatte ich die files, v.a. auch die cfg, immer auch noch parallel "im Klartext" vorliegen, da geht ggf. dann der Nachimport von "verlorenen" Devices schnell (was aber nie erforderlich war, soweit ich mich entsinne). Für die aktuelle config einfach in "global" die configfile-Angabe ändern, save und dann FHEM mit dem Systemdienst (!) neu starten (shutdown restart aus FHEM liest die aktuelle configfile wieder ein, das klappt nicht). Die config liegt dann an dem angegebenen Ort...

Gruß, Beta-User

[Morgennebel]

Hi Beta-User,


die virtuelle Instanz lief vom Zeitpunkt der Installation des Tarballs mit ConfigDB - ich habe damals von fhem.cfg umgestellt. Alle Holidays und die 99_MyUtils waren nur in der MariaDB gespeichert. Daher war meine Erwartungshaltung genau wie bei Dir - die Konfiguration in der SQL-DB sollte unangetastet bleiben, auch wenn FHEM nicht startet oder Module nicht geladen werden können.

War aber nicht der Fall. VALVES, STELLMOTOR und Xiaomi musste ich mit "configdb search" suchen und mit RawImport wieder aktivieren, nachdem ich die vergessenen Module eingebunden hatte. Dazwischen gab es diverse Reboots von FHEM. SAVE habe ich nicht gedrückt, um meine alte Konfig nicht zu überschreiben.

Ich denke, dies ist eine Situation wo ConfigDB seine Stärken ausspielen könnte - ich tausche die Frontend-Server und verbinde diese wieder mit der SQL-Datenbank und alles läuft wie gewohnt. Leider "pfuscht" FHEM dazwischen und löscht die fehlerhaften Definitionen.

Die Abhängigkeit von MySQL in den Startupscripten kann ich gerne in die contrib-Verzeichnisse hinzufügen - wie mache ich das?

Danke, -MN

[LuckyDay]

global autosave beachten! bei mir steht es auf 0

[Beta-User]

global autosave beachten! bei mir steht es auf 0

An sowas hatte ich auch schon gedacht, aber eigentlich dürfte es das nicht sein, zumindest, wenn Otto Rudi da richtig zitiert hat:

Und ich zitiere nochmal Rudi

Zur Klarstellung:
- es geht um save, was von einem Programmstueck wie at/notify/etc gestartet, und nicht per Anklicken oder anderweitig manuell ausgeloest wird.
- autosave 0 verhindert in diesen Faellen das Speichern.
- autosave wird neuerdings auf 0 gesetzt, falls beim Starten was schiefgegangen ist, damit ein automatisches save (wie manche Module das ungefragt machen) nicht zum Verlust der Teile der Konfiguration fuehrt.

Da beim Starten manches nicht geladen wurde, sollte eigentlich automatisch die "0" dastehen...

Aber wir sind uns einig: von ganz alleine macht FHEM sowas nicht, und auch configDB nicht. Da ist irgend was anderes im Argen. Und meine Phantasie reicht auch nicht so weit, dass einfach so irgendwelche Dateien von der DB verschluckt werden.

[Morgennebel]

global autosave beachten! bei mir steht es auf 0

Das hatte ich nicht auf dem Radar.... Das kann natürlich sein, daß dieses auf 1 stand/steht...

Danke, -MN

[betateilchen]

configDB schreibt keine Konfigurationen in die Datenbank, wenn der Anwender dies nicht explizit veranlasst.

Daher war meine Erwartungshaltung genau wie bei Dir - die Konfiguration in der SQL-DB sollte unangetastet bleiben, auch wenn FHEM nicht startet oder Module nicht geladen werden können.

Auch in diesem Fall wird die Konfiguration in der Datenbank nicht "automatisch" verändert. Und selbst wenn der Anwender in diesem Fall ein SAVE ausführt, werden die Definitionen nicht aus der Datenbank gelöscht, da das SAVE automatisch eine neue Version der Konfiguration in der Datenbank anlegt. Es ist jederzeit möglich, eine vorherige Version vollständig wieder zu aktivieren - genau das ist eines der wichtigsten Features der  configDB.

Ein wenig Zeit kostete die Anpassung der init-Skripte aus dem config-Verzeichnis. Diese sind nicht für die ConfigDB vorbereitet und vermissen Abhängigkeiten zu MySQL (oder PostgreSQL) für mein Devuan mit klassischem InitV-System.

Die Standard-Skripte für FHEM wurden vor einiger Zeit offiziell auf systemd umgestellt. Die alten init-Skripte sind nur noch aus historischen Gründen vorhanden. Genau wir das alte upstart-Skript.

Die Abhängigkeit von MySQL in den Startupscripten kann ich gerne in die contrib-Verzeichnisse hinzufügen - wie mache ich das?

Gar nicht. Nicht jede FHEM Installation hat solche Abhängigkeiten. Insofern macht es keinen Sinn, diese Abhängigkeiten fest zu verdrahten.