FHEM > Automatisierung

31_LightScene.pm - patch für commandref-id und configDB

<< < (2/3) > >>

Beta-User:
An sich ist es kein Problem, eine Erweiterung des Lese-Codes dahingehend zu machen, dass bei fehlgeschlagenem Lesen aus der DB dann aus dem filesystem gelesen und ggf. dann direkt sogar ein Import angestoßen wird.
Mein "Problem": Sowas hatte ich für weekprofile schon mal vorgeschlagen und mir deutlichste Kritik von wissender Seite zugezogen...

Andererseits: Da entstehen im laufenden Betrieb keine Probleme, hier habe ich keine Idee, wie man das nachträglich gut reparieren kann (ohne einen extra setter+code zu generieren). Von daher werde ich mal die angehängte Fassung testen und die configFile aus der DB löschen. Dann sollte es bei einem Neustart wenigstens natlos weitergehen, ohne dass die alte File gelöscht wird...

betateilchen:
Es geht ja erstmal nichts verloren, die vorhandene Datei befindet sich ja nach wie vor im Dateisystem.

Man könnte nach der Feststellung, dass ein configfile fehlt, einen entsprechenden Logeintrag schreiben, in dem man den Benutzer auffordert, die Datei einmalig per "configdb filemove <dateiName>" in die Datenbank zu importieren.

Ähnliches Vorgehen hat sich in der Vergangenheit bei anderen Modulen bewährt.

Beta-User:

--- Zitat von: betateilchen am 27 Oktober 2021, 19:04:14 ---Es geht ja erstmal nichts verloren, die vorhandene Datei befindet sich ja nach wie vor im Dateisystem.

--- Ende Zitat ---
Ja und nein....

Das Problem bei LightScene ist in der Hinsicht, dass der aktuelle Zustand immer mit in die jeweilige stateFile geschrieben wird, wenn alles gespeichert wird. Das verhält sich also eher wie die "globale stateFile", was soviel bedeutet wie: ab dem 2. Start ist die dann da (in der configDB), aber halt mit dem falschen (leeren) Inhalt, und - noch ungeschickter - man kann auch nicht einfach so die alte laden oder importieren. Letzteres klappt zwar, ist aber nur wirkungsvoll, wenn man dann FHEM irregulär beendet...

Falls du Ideen hast, was ich übersehen habe: her damit ;) .

justme1968:
was spricht denn gegen das einmalige automatische importieren? als nicht configdb anwender erscheint es mir nicht fehleranfällig und das was ein anwender erwartet.

Beta-User:
Es spricht "nur" dagegen, dass es bei allen anderen Modulen anders ist und man dort was aktiv importieren muss.

Da hier m.E.
- gar kein befriedigendes Ergebnis mit einem nachträglichen Import zu erzielen ist, und
- alle ein Problem haben, die diese Kleinigkeit, dass man kurz noch die statefile importieren muss während/vor dem update übersehen,
macht es mAn. Sinn, diese "einmalig erforderliche Code-Sonderlocke" als dauerhaften Einbau in Kauf zu nehmen, und ggf. dann bei Version 6.3 darüber nachzudenken, die "drei Zeilen" wieder entfallen zu lassen. Denn sobald jemand die "configDB-Version" im Einsatz hatte, wird via migrate ja auch der Import angeschubst. Anders gesagt: das Problem wächst sich raus, und nur, wer nicht regelmäßig updates fährt, hat halt irgendwann ein Problem.

Nicht die reine Lehre, aber bis dato haben wir auch keinen besseren Vorschlag gehört, oder?

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln