Autor Thema: 31_LightScene.pm - patch für commandref-id und configDB  (Gelesen 792 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16342
31_LightScene.pm - patch für commandref-id und configDB
« am: 20 September 2021, 22:45:49 »
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!
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16342
Antw:31_LightScene.pm - patch für commandref-id und configDB
« Antwort #1 am: 10 Oktober 2021, 20:09:25 »
*push*
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20876
Antw:31_LightScene.pm - patch für commandref-id und configDB
« Antwort #2 am: 26 Oktober 2021, 17:04:15 »
danke für den schubs. ich schaue es mir an.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16342
Antw:31_LightScene.pm - patch für commandref-id und configDB
« Antwort #3 am: 26 Oktober 2021, 17:17:13 »
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...
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20876
Antw:31_LightScene.pm - patch für commandref-id und configDB
« Antwort #4 am: 27 Oktober 2021, 12:27:12 »
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.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16342
Antw:31_LightScene.pm - patch für commandref-id und configDB
« Antwort #5 am: 27 Oktober 2021, 13:03:21 »
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...
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17562
  • s/fhem\.cfg/configDB/g
Antw:31_LightScene.pm - patch für commandref-id und configDB
« Antwort #6 am: 27 Oktober 2021, 19:04:14 »
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.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Lesen gefährdet die Unwissenheit!

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16342
Antw:31_LightScene.pm - patch für commandref-id und configDB
« Antwort #7 am: 27 Oktober 2021, 20:01:06 »
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 ;) .
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20876
Antw:31_LightScene.pm - patch für commandref-id und configDB
« Antwort #8 am: 31 Oktober 2021, 09:24:33 »
was spricht denn gegen das einmalige automatische importieren? als nicht configdb anwender erscheint es mir nicht fehleranfällig und das was ein anwender erwartet.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16342
Antw:31_LightScene.pm - patch für commandref-id und configDB
« Antwort #9 am: 01 November 2021, 07:36:12 »
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?
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

 

decade-submarginal