configdb crasht FHEM

Begonnen von Prof. Dr. Peter Henning, 02 Februar 2023, 07:15:50

Vorheriges Thema - Nächstes Thema

betateilchen

Zitat von: Prof. Dr. Peter Henning am 08 Februar 2023, 08:54:06
ich muss mir noch eine automatische Migrationslösung ausdenken.

Vielleicht so?


  • FileRead("ALARM.conf") ausführen
  • im Fehlerfall => alles ok, es existiert kein altes conf-File oder wurde schon migriert
  • im Erfolgsfall => Datei vorhanden, dann mit FileWrite("./conf/ALARM.conf") an den neuen Ort schreiben und mit FileDelete("ALARM.pm") am ursprünglichen Ort löschen

(Und in einer späteren Version diesen Mechanismus dann ausbauen, weil man irgendwann annimmt, dass alle bestehenden Installationen migriert haben.)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Lese hier auch schon eine ganze Weile mit (der Thread läuft seit einiger Zeit unter völlig falscher Flagge).

Wäre es nicht sinnvoll, eine Art API-Kommando "readConfigFile()" (Übergabe Dateiname bzw. Dateiname und alter Pfad+Dateiname) (bzw. "saveConfigFile()") einzubauen, das zum einen ggf. anstehende Verschiebungen macht, und/oder den Import nach configDB etc. (und ggf. den Hash entspechend erweitert)?

Hintergrund: Die Migration in Richtung configDB ist im laufenden Betrieb zumindest manchmal ein Problem (siehe unsere Diskussion (übrigens nach 2019!) zu lightScene), und für Verschiebe-Umbauten z.B. in RHASSPY oder msDialog fehlt mir grade die Lust, ebenso, "Übergangscode" einzubauen (und irgendwann wieder rauszunehmen). Aber diese zentrale Funktionalität des Verzeichnisses an sich zu nutzen, fände ich auch sinnvoll...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files