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

[Beta-User]

Hallo justme1968,

anbei patch-Vorschlag mit den zwei Aspekten aus dem Thread-Titel. Vielleicht magst du ja das eine und/oder andere verwerten...

Grüße!

[Beta-User]

*push*

[justme1968]

danke für den schubs. ich schaue es mir an.

[Beta-User]

Gerne .

Vielleicht noch eine Anmerkung betr. das configDB-Thema: Da die LightScene-statefile beim Start gelesen wird und beim Beenden (zusammen mit der globalen) geschrieben, gibt es eine Lücke, wenn man configDB bereits nutzt und dann das Modul (z.B. per update) aktualisiert. Eigentlich müßte man dann zu diesem Zeitpunkt die LS-statefile importieren/importiert haben.
Beim nächsten Start wird dann nämlich aus der DB gelesen, was ohne diesen Zwischenschritt nicht klappt => alle Szenen sind weg.

An sich könnte man das durch eine entsprechende automatische Erkennung (hier: mit direktem Import) verhindern, aber sowas ähnliches hatte ich mal bei weekprofile vorgeschlagen, was aber nicht gerne gesehen gewesen war.
Vielleicht sollte man das bei UPDATE deutlich vermerken (oder gar manuellen import-Code anbieten?)

"migrate" sollte dagegen stressfrei funktionieren.

Also falls jemand Ideen hat...

[justme1968]

der patch an sich schaut gut und unproblematisch aus.

das potentielle verhalten beim update gefällt mir aber noch nicht. wenn man schon configdb nutzt und das modul aktualisiert sollte auf keinen fall etwas verloren gehen. ich könnte mir unterschiedliche varianten vorstellen:

- wenn configdb verwendet wird und beim starten kein lightscene config file gefunden wird, schaut das modul
  automatisch nach ob es ein echtes config file gibt und liest dieses.
- sobald es zum ersten mal in die db geschrieben wird könnte man dann das file in ...old umbenennen damit
  das nur ein mal passiert.
- ab da geht es nur noch mit configdb weiter.

falls das so passt... könntest du das mal probieren? ich verwende configdb nicht.

[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]

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

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?

[justme1968]

der id teil des patches ist eingecheckt. für den configdb teil würde ich gerne die automatische variante verwenden. bräuchte aber einen freiwilligen zum testen. ich verwende nirgendwo configdb.

[Beta-User]

So, in meiner Version von neulich war in der Tat noch ein Bug drin...

Wie folgt getestet:
- Start mit aktueller svn-Version, LightScene.save aus der configDB gelöscht.
- nach dem Start geprüft, ob wirklich die File nicht in der DB ist
- dann die angehängte Version über die svn-Version kopiert
- Neustart, (vorher kein reload)
- LightScene.save wird vom Dateisystem gelesen, alles da (ok)
- weiter keine File in configDB, auch nicht nach einem Neustart (m.E. auch ok)
- dann ein (allgemeines) "save" => File ist in configDB da. Alles erwartungsgemäß.

Will man einen Import forcieren, müßte man ab #406 auch noch einen internen Merker setzen, von wo die File kam, und das beim save dann wieder auswerten...
Fände ich nicht so intuitiv, aber wenn gewünscht, baue ich das auch noch ein...

[justme1968]

das schaut für mich erst mal gut aus. wenn es keine einwände gibt würde ich das nächste woche einchecken.

[Beta-User]

das schaut für mich erst mal gut aus. wenn es keine einwände gibt würde ich das nächste woche einchecken.

Gab es denn Einwände?

Hier auch noch eine HUEBridge-Fassung mit "id"-commandref.

Da sind noch ein paar Kleinigkeiten ergänzt. V.A. "updaterule" wäre einen Blick wert, und zu "eventstreamTimeout" ist mir nichts eingefallen...

[betateilchen]

für mich klingt das irgendwie furchtbar kompliziert...

Im Moment kann ich mir die vorgeschlagene Umsetzung nicht anschauen, ich hole das aber gerne Anfang der Woche nach.