configDB gplot-Datei lässt sich nicht verändern

Begonnen von khk123, 16 April 2021, 12:51:52

Vorheriges Thema - Nächstes Thema

khk123

Nach Delete des SVG-Devices SVG_CoronaRM habe ich auch die zugehörige gPlot-Datei mit "configdb filedelete ./www/gplot/SVG_CoronaRM.gplot" gelöscht.
Mit "configdb filelist" wird die Datei auch nicht mehr aufgelistet. Aber "configdb fileshow" zeigt den alten Inhalt wieder an. Definiere ich eine SVG-Device mit dem
alten Namen erneut, wird auch das alte gplot-Datei angezogen. Ich kann auch keine Änderung vornehmen. Nach einem "write gPlot-Datei" bleibt alles auf dem vorherigen Zustand. Ich hatte vorher mit den SVGs etwas getestet und dabe auch das SVG-Device renamed. Evtl. ist dabei etwas schief gegangen oder ich habe etwas falsch gemacht bzw. übersehen. Kann ich den Fehler irgendwie korrigieren?

Viele Grüße
Karlheinz
FHEM6.2, RasPi4, RasPi Zero W,
CUL V3, HM, ZWave, IT, vcontrol, owntracks, alexa

betateilchen

#1
Zitat von: khk123 am 16 April 2021, 12:51:52
mit "configdb filedelete ./www/gplot/SVG_CoronaRM.gplot" gelöscht.
Mit "configdb filelist" wird die Datei auch nicht mehr aufgelistet.
Aber "configdb fileshow" zeigt den alten Inhalt wieder an.

Eine von den drei Aussagen kann nicht stimmen.

Mach doch mal ein "configdb filelist" und poste die Ausgabe.
Dazu bitte noch das list vom zugehörigen SVG device.

Dann schauen wir mal weiter.

Zitat von: khk123 am 16 April 2021, 12:51:52
Ich hatte vorher mit den SVGs etwas getestet und dabe auch das SVG-Device renamed. Evtl. ist dabei etwas schief gegangen

Beim Umbenennen eines SVG device wird normalerweise das verwendete gplot File nicht angetastet oder gar umbenannt.
Meine Vermutung: Du kommst im Moment mit den unterschiedlichen Namen der svg-devices und der gplot files durcheinander.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Um herauszufinden, welche gplot Dateien in Deiner FHEM Installation aktuell tatsächlich benutzt werden, kannst Du folgendes in die FHEM Befehlszeile eingeben:


{ my @files = defInfo('TYPE=SVG','GPLOTFILE');; return join("\n",@files) }


Diese Liste solltest Du dann mit der Liste der gplot Dateien abgleichen, die in der configDB gespeichert sind.
Erfahrungsgemäß wirst Du in der Datenbank gplot Dateien finden, die gar nicht mehr benutzt werden.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

khk123

Zitat von: betateilchen am 16 April 2021, 20:31:51
Eine von den drei Aussagen kann nicht stimmen.

Soweit ich das überblicke, stimmen meine Aussagen. Ich habe das Ganze aber nochmal durchgespielt:
Das altes SVG-Device SVG_CoronaRM ist geloscht. Eine Kopie SVG_CoronaRM_1 mit korrekter gPlot-Datei ist vorhanden.

configDB filist ergibt folgende Ausgabe:

./www/gplot/SVG_Bad_Waage.gplot
./www/gplot/SVG_CoronaRM_1.gplot
./www/gplot/SVG_DVES_954451.gplot

Erste Zeile der SVG_CoronaRM_1.gplot
# Created by FHEM/98_SVG.pm, 2021-04-16 23:35:15

Jetzt "copy SVG_CoronaRM_1 SVG_CoronaRM". Es kommt korrekt die Warnung "The .gplot file (SVG_CoronaRM_1) is used by multiple SVG devices (SVG_CoronaRM,SVG_CoronaRM_1), writing probably will corrupt the other SVGs. Remedy: execute set SVG_CoronaRM copyGplotFile".

Jetzt "set SVG_CoronaRM copyGPpotFile"

configDB filist ergibt jetzt folgende Ausgabe:

./www/gplot/SVG_Bad_Waage.gplot
./www/gplot/SVG_CoronaRM.gplot
./www/gplot/SVG_CoronaRM_1.gplot
./www/gplot/SVG_DVES_954451.gplot

Es wird anscheinend die alte Gplot-Datei wieder angezogen.
Erste Zeile der SVG_CoronaRM.gplot
# Created by FHEM/98_SVG.pm, 2021-04-10 21:15:15

Jetzt "delete SVG_CoronaRM"
und anschließend "configDB filelist"

./www/gplot/SVG_Bad_Waage.gplot
./www/gplot/SVG_CoronaRM.gplot
./www/gplot/SVG_CoronaRM_1.gplot
./www/gplot/SVG_DVES_954451.gplot

Jetzt "configDB filedelete ./www/gplot/SVG_CoronaRM.gplot"
Meldung: File ./www/gplot/SVG_CoronaRM.gplot deleted from database.

anschließend "configDB filelist"

./www/gplot/SVG_Bad_Waage.gplot
./www/gplot/SVG_CoronaRM_1.gplot
./www/gplot/SVG_DVES_954451.gplot

Jetzt "configDB fileshow ./www/gplot/SVG_CoronaRM.gplot"
Es wird die alte eigentlich gelöschte SVG_CoronaRM.gplot angezeigt.
Erste Zeile
# Created by FHEM/98_SVG.pm, 2021-04-10 21:15:15

Wenn ich jetzt "copy SVG_CoronaRM_1 SVG_CoronaRM" und "set SVG_CoronaRM copyGPlotFile" ausführe, ist dauch ie alte Gplot-Datei wieder aktiv
Erste Zeile der SVG_CoronaRM.gplot
# Created by FHEM/98_SVG.pm, 2021-04-10 21:15:15

Es werden kann auch keine Änderungen angenommen. Nach einem "write .gplot-file" werden die alten Definitionen wieder angezeigt.

Wie werden die Dateien in der Datenbank adressiert? Nach dem "filedelete" sollte doch ein "fileshow" nicht mehr möglich sein, oder?

VG
Karlheinz
FHEM6.2, RasPi4, RasPi Zero W,
CUL V3, HM, ZWave, IT, vcontrol, owntracks, alexa

khk123

Hab mir mal die Datenbank angesehen und finde dort in der Tabelle fhemb64filesave die alte gPlot-Datei noch (s. Screenshot). Oder ist der Datensatz nur logisch gelöscht?
FHEM6.2, RasPi4, RasPi Zero W,
CUL V3, HM, ZWave, IT, vcontrol, owntracks, alexa

betateilchen

#5
Leider bist Du in keinster Weise auf meinen in den vorherigen Beiträgen begonnenen Weg zur Fehlereingrenzung eingegangen.
Deine Experimente mit copy und copyGplotFile helfen mir bei meinen Versuchen, Dir zu helfen, nicht weiter.

Zitat
Jetzt "configDB filedelete ./www/gplot/SVG_CoronaRM.gplot"
Meldung: File ./www/gplot/SVG_CoronaRM.gplot deleted from database.

anschließend "configDB filelist"

./www/gplot/SVG_Bad_Waage.gplot
./www/gplot/SVG_CoronaRM_1.gplot
./www/gplot/SVG_DVES_954451.gplot

Zu diesem Zeitpunkt ist die Datei aus der Datenbank gelöscht - wie sowohl die Meldung als auch das Filelist bestätigen.

Zitat
Jetzt "configDB fileshow ./www/gplot/SVG_CoronaRM.gplot"
Es wird die alte eigentlich gelöschte SVG_CoronaRM.gplot angezeigt

Und genau das bezweifle ich, insbesondere das "Jetzt". Wenn filelist die Datei nicht mehr anzeigt, kann sie auch von fileshow nicht mehr gelesen werden.

Bei Dir läuft vermutlich irgendwas ganz anderes schief - aber im Moment habe ich keine Idee, was. Entweder es gibt zwei verschiedenen Datenbanken (eine mit der FHEM arbeitet und eine, in der Du manuell reinschaust) oder irgendwas anderes ist durcheinander.




Nochmal die Frage nach folgenden Informationen:

  • Bitte ein list der svg devices.
  • Bitte die Ausgabe der oben vorgeschlagenen Liste der verwendeten gplot Dateien




Was passiert, wenn Du

configDB filedelete ./www/gplot/SVG_CoronaRM.gplot

zweimal direkt hintereinander ausführst?


--
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

khk123

Ich dachte, ich hätte ganz gut den Ablauf beschrieben. Aber dann das Ganze nochmal. Alle Befehle sind direkt hintereinander ausgeführt worden, ohne weiter Änderungen an den Definitionen.

1. configDB filedelete ./www/gplot/SVG_CoronaRM.gplot

Ergebnis:
File ./www/gplot/SVG_CoronaRM.gplot not found in database.

2. configDB filedelete ./www/gplot/SVG_CoronaRM.gplot

Ergebnis:
File ./www/gplot/SVG_CoronaRM.gplot not found in database.


Danach direkt Ausführung ohne jegliche weitere Änderung:
configDB fileshow ./www/gplot/SVG_CoronaRM.gplot

Ergebnis:
# Created by FHEM/98_SVG.pm, 2021-04-10 21:15:15
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set ...

Danach direkt Ausführung ohne jegliche weitere Änderung:
list SVG_CoronaRM

Ergebnis:
No device named SVG_coronaRM found

Das mit der korrekt funktionierende SVG-Device:
list SVG_CoronaRM_1

Ergebnis:
Internals:
   .FhemMetaInternals 1
   DEF        LogDatabase:SVG_CoronaRM_1:HISTORY
   FUUID      607954e4-f33f-2526-ea38-075d6d36a29f385f
   FVERSION   98_SVG.pm:0.240970/2021-03-27
   GPLOTFILE  SVG_CoronaRM_1
   LOGDEVICE  LogDatabase
   LOGFILE    HISTORY
   NAME       SVG_CoronaRM_1
   NR         494
   STATE      initialized
   TYPE       SVG
Attributes:
   DbLogExclude .*
   fixedrange 8days
   room       Corona


{ my @files = defInfo('TYPE=SVG','GPLOTFILE');; return join("\n",@files) }

...
SVG_Bad_Waage
SVG_CoronaRM_1
SVG_F_Hz
...

Der Gplot-Record ist definitiv nicht gelöscht und ich verwende auch keine verschiedenen Datenbanken. Ich gebe dir recht: Da ist etwas anderes schief.
Wenn ich ein SVG-Device mit dem Namen SVG_CoronaRM anlege, erhalte ich sofort wieder die alte Gplot-Datei und auch jegliche Änderung daran geht nicht.
Warum wird direkt nach dem filedelete die alte Datei mit fileshow angezeigt, obwohl sie doch lt. Meldung gelöscht wurde? Kann ich zum Debuggen etwas
einstellen um zu sehen was beim filedelete wirklich passiert?

VG
Karlheinz
FHEM6.2, RasPi4, RasPi Zero W,
CUL V3, HM, ZWave, IT, vcontrol, owntracks, alexa

betateilchen

kannst Du bitte code Tags verwenden?

Vorher schaue ich mir Deinen letzten Beitrag nicht an, das ist eine Zumutung für jeden, der Dir helfen möchte.


--
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

khk123

Keep calm! :) Dann halt nochmal:




configDB filedelete ./www/gplot/SVG_CoronaRM.gplot
File ./www/gplot/SVG_CoronaRM.gplot not found in database.

configDB filedelete ./www/gplot/SVG_CoronaRM.gplot
File ./www/gplot/SVG_CoronaRM.gplot not found in database.

configDB fileshow ./www/gplot/SVG_CoronaRM.gplot
# Created by FHEM/98_SVG.pm, 2021-04-10 21:15:15
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set ...

list SVG_CoronaRM
No device named SVG_coronaRM found

list SVG_CoronaRM_1
Internals:
   .FhemMetaInternals 1
   DEF        LogDatabase:SVG_CoronaRM_1:HISTORY
   FUUID      607954e4-f33f-2526-ea38-075d6d36a29f385f
   FVERSION   98_SVG.pm:0.240970/2021-03-27
   GPLOTFILE  SVG_CoronaRM_1
   LOGDEVICE  LogDatabase
   LOGFILE    HISTORY
   NAME       SVG_CoronaRM_1
   NR         494
   STATE      initialized
   TYPE       SVG
Attributes:
   DbLogExclude .*
   fixedrange 8days
   room       Corona

{ my @files = defInfo('TYPE=SVG','GPLOTFILE');; return join("\n",@files) }
...
SVG_Bad_Waage
SVG_CoronaRM_1
SVG_F_Hz
...


Ich hoffe es sagt dir nun mehr zu.  :)
VG
Karlheinz
FHEM6.2, RasPi4, RasPi Zero W,
CUL V3, HM, ZWave, IT, vcontrol, owntracks, alexa

betateilchen

Du, ich bin völlig ruhig, denn ich habe ja kein Problem in meinem FHEM.

Du hättest einfach Deinen vorherigen Beitrag mit ein paar entsprechenden tags strukturieren und besser lesbar machen können. Jetzt alles in ein einziges tag zu packen, macht die Lesbarkeit nicht viel besser, aber sei es drum.

Fakt ist:

Die Datenbank meldet an configDB zurück, die Datei sei gelöscht worden. Deshalb bekommst Du beim mehrfachen Versuch, die Datei zu löschen, die zugehörige - korrekte - Fehlermeldung, dass die Datei in der Datenbank nicht existiert.

Offenbar ist aber das Löschen in der Datenbank technisch gar nicht erfolgt und damit die Rückmeldung an FHEM falsch. Das ist dann aber eher ein Problem Deiner Datenbank selbst, nicht von configDB.

Wenn Du eh schon manuell außerhalb von FHEM in der Datenbank unterwegs bist, lösche doch einfach mal den "falschen" Tabelleneintrag für das betroffene File von Hand. Offenbar betrifft das Ganze ja nur einen einzigen Eintrag.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

khk123

Liebes Betateilchen,

sorry, wenn ich meine Meinung zum Ton mal äußere:

Ich habe kein Problem mit FHEM oder den Definitionen. Aber evtl. gibt es ein Problem mit configDB. Deine Idee den Record einfach außerhalb von FHEM und configDB zu löschen, ist mir etwas zu einfach. Das hatte ich auch schon in Erwägung gezogen. Nur das löst das Problem nicht. Problematisch ist, dass configDB filedelete den Record nicht löscht, obwohl die Meldung ausgegeben wird.

Zitat von: betateilchen am 17 April 2021, 15:07:49
Fakt ist:

Die Datenbank meldet an configDB zurück, die Datei sei gelöscht worden. Deshalb bekommst Du beim mehrfachen Versuch, die Datei zu löschen, die zugehörige - korrekte - Fehlermeldung, dass die Datei in der Datenbank nicht existiert.

Offenbar ist aber das Löschen in der Datenbank technisch gar nicht erfolgt und damit die Rückmeldung an FHEM falsch. Das ist dann aber eher ein Problem Deiner Datenbank selbst, nicht von configDB.


Diese Meinung teile ich nicht. Woher nimmst du die Gewissheit, dass die Datenbank "gelöscht" zurückmeldet. Es mag ja sein, das in der Datenbank etwas nicht stimmt. Es kann aber auch sein, dass configDB hier eine Fehlersituation bei der Löschung des Records nicht korrekt abfängt. Das Ganze ist wohl durch das Kopieren von SVGs entstanden. Sei's drum. Ich kümmere mich selbst darum das Problem zu lösen und du kannst hoffentlich entschuldigen, dass ich helfen wollte eine evtl. generelle Fehlersituation zu beseitigen.

Im übrigen empfehle ich auch, selbst wenn keine code-Tags verwendet werden, den Text aufmerksam zu lesen und nicht gleich, ohne den Inhalt anscheinend verstanden zu haben, etwas harsch von oben herab zu reagieren und teilweise unsinnige Dinge zu fordern oder behaupten. Damit verschreckst du zwar nicht mich, aber mit Sicherheit andere Gemüter.

VG
Karlheinz
FHEM6.2, RasPi4, RasPi Zero W,
CUL V3, HM, ZWave, IT, vcontrol, owntracks, alexa

betateilchen

Zitat von: khk123 am 17 April 2021, 16:21:44
Woher nimmst du die Gewissheit, dass die Datenbank "gelöscht" zurückmeldet.

Weil mein Code in configDB die Rückmeldung prüft, die von der Datenbank nach dem delete zurückkommt.
Eine andere Möglichkeit habe ich nicht, das zu prüfen.

Zitat von: khk123 am 17 April 2021, 16:21:44
Aber evtl. gibt es ein Problem mit configDB. Deine Idee den Record einfach außerhalb von FHEM und configDB zu löschen, ist mir etwas zu einfach. Das hatte ich auch schon in Erwägung gezogen. Nur das löst das Problem nicht. Problematisch ist, dass configDB filedelete den Record nicht löscht, obwohl die Meldung ausgegeben wird.

Siehe oben - ich kann nicht mehr tun, als die von der Datenbank kommende Rückmeldung zu prüfen.
Glaube mir, bevor ich hier im Thread angefangen habe, Dir zu antworten, habe ich mehr als eine Stunde damit zugebracht, das von Dir beschriebene Verhalten zu reproduzieren - ohne Erfolg.
Und da Du der Erste und bisher Einzige bist, bei dem dieses Problem auftritt, gehe ich im Moment nicht von einem generellen Problem innerhalb von configDB aus.

Zitat von: khk123 am 17 April 2021, 16:21:44
Im übrigen empfehle ich auch, selbst wenn keine code-Tags verwendet werden, den Text aufmerksam zu lesen

Deine Empfehlungen brauche ich nicht.

Zitat von: khk123 am 17 April 2021, 16:21:44
und nicht gleich, ohne den Inhalt anscheinend verstanden zu haben,

ach so? Meinst Du wirklich?

Zitat von: khk123 am 17 April 2021, 16:21:44
etwas harsch von oben herab zu reagieren

Darüber, wer von uns beiden hier harsch und von oben herab reagiert hat, könnte man trefflich diskutieren.
Aber das ist mir inzwischen einfach zu blöd und dafür ist mir auch meine Zeit zu schade.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

khk123

#12
So hab ich mir deine Antwort vorgestellt. Passt zu der ursprünglichen Kommunikation. Hast ja keinen Fehler gemacht, bleib daher in deinem Elfenbeinturm und verschone mich mit einer weiteren Antwort. :-[
FHEM6.2, RasPi4, RasPi Zero W,
CUL V3, HM, ZWave, IT, vcontrol, owntracks, alexa

betateilchen

Zitat von: khk123 am 17 April 2021, 17:09:08
verschone mich mit einer weiteren Antwort

das könnte Dir so passen...

1. Schritt


copy SVG_dbLog_1 SVG_test
Note:The .gplot file (SVG_dbLog_1) is used by multiple SVG devices (SVG_dbLog_1,SVG_test), writing probably will corrupt the other SVGs. Remedy: execute set SVG_test copyGplotFile

DEF: dbLog:SVG_dbLog_1:HISTORY

"configdb filelist" liefert:
./www/gplot/SVG_dbLog_1.gplot
./www/gplot/SVG_dbLog_2.gplot
./www/gplot/template.gplot
./www/gplot/templateDB.gplot


2. Schritt


set SVG_test copyGplotFile

DEF: dbLog:SVG_test:HISTORY

"configdb filelist" liefert:
./www/gplot/SVG_dbLog_1.gplot
./www/gplot/SVG_dbLog_2.gplot
./www/gplot/SVG_test.gplot
./www/gplot/template.gplot
./www/gplot/templateDB.gplot


3. Schritt


configdb filedelete ./www/gplot/SVG_test.gplot
File ./www/gplot/SVG_test.gplot deleted from database.

"configdb filelist" liefert:
./www/gplot/SVG_dbLog_1.gplot
./www/gplot/SVG_dbLog_2.gplot
./www/gplot/template.gplot
./www/gplot/templateDB.gplot


4. Schritt


configdb fileshow ./www/gplot/SVG_test.gplot
Error on reading ./www/gplot/SVG_test.gplot from database!


Works as designed.

q.e.d.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

khk123

Na denn, dann probieren wir es noch mal.  :)

Es hat mir keine Ruhe gelassen, wenn auch das Problem durch meine Definitionen entstanden ist und evtl. das erste Mal so aufgetreten ist.
Ich denke ich habe die Ursache für das seltsame Verhalten gefunden. Aber ob es ein Fehler ist, must du entscheiden.

Ursache ist das Select-Statement mit LIKE in Zeile 381 von configDB.pm. LIKE ist in diesem Fall nicht casesensitive.


my $sth = $fhem_dbh->prepare( "SELECT content FROM fhemb64filesave WHERE filename LIKE '$filename'" );


Dadurch wird die Datei mit dem Gross- und auch Kleinbuchstaben gefunden. Die Delete und Upadatefunktionen werden korrekt ausgeführt. Durch das caseinsenitive LIKE werden aber beide Records gefunden
und der erste gefundene Record ist der zuletzt veränderte Record. Warum du beim Lesen mit Like arbeitest hat bestimmt andere Gründe, aber dadurch kommt es zu dem beschriebenen Verhalten.
Die Situation kann problemlos nachgestellt werden.

Siehe auch: https://database.guide/how-to-make-sqlites-like-operator-case-sensitive/

Falls die LIKE-Version nicht durch ein "=" ersetzt werden kann, wäre evtl. eine Möglichkeit vor dem SELECT

PRAGMA case_sensitive_like = true;

auszuführen und danach wieder auf

PRAGMA case_sensitive_like = false;

umzustellen. Ob das aber andere Auswirkungen hat, kann ich nicht beurteilen. In meinem kleinen Perl-Progrämmchen hat es jedenfalls funktioniert:

use strict;
use DBI;
my $dbargs = {AutoCommit => 0, PrintError => 1};
my $dbh = DBI->connect("dbi:SQLite:dbname=KhK_config.db", "", "", $dbargs);

# Gplot Records ausgeben casesensitive
my ($filename, $content) = "";
$dbh->do("PRAGMA case_sensitive_like = true;");
print("PRAGMA case_sensitive_like = true;\n");

my $res = $dbh->selectall_arrayref("SELECT filename, content FROM fhemb64filesave where filename like './www/gplot/SVG_CoronaRM%.gplot';");

foreach my $row (@$res) {
   ($filename, $content) = @$row;
    print("Name: $filename\n");
}

# Gplot Records ausgeben casesensitive
my ($filename, $content) = "";
$dbh->do("PRAGMA case_sensitive_like = false;");
print("PRAGMA case_sensitive_like = false;\n");

my $res = $dbh->selectall_arrayref("SELECT filename, content FROM fhemb64filesave where filename like './www/gplot/SVG_CoronaRM%.gplot';");

foreach my $row (@$res) {
   ($filename, $content) = @$row;
    print("Name: $filename\n");
}

if ($dbh->err()) { die "$DBI::errstr\n"; }
$dbh->disconnect();

und hier der Output:

pi@raspi3bplus:~/KhK_ConfigDB $ perl ./K_configDB.pm
PRAGMA case_sensitive_like = true;
Name: ./www/gplot/SVG_CoronaRM_1.gplot
PRAGMA case_sensitive_like = false;
Name: ./www/gplot/SVG_coronaRM.gplot
Name: ./www/gplot/SVG_CoronaRM_1.gplot



Ob es auch bei dem zweiten SELECT mit LIKE in Zeile 699 ebenfalls Probleme mit Gross- und Kleinschreibung gibt, habe ich nicht getestet.

Unten auch noch mal mein FHEM-Test-Szenario.

VG
Karlheinz

1.   

Edit files <irgeneine gplot-datei> und save as SVG_test.gplot
Saved SVG_test.gplot

configdb filemove ./www/gplot/SVG_test
64 bytes written from file ./www/gplot/SVG_test.gplot to database
File ./www/gplot/SVG_test.gplot deleted from local filesystem.


2.

configdb fileshow ./www/gplot/SVG_test.gplot
############################
# save as SVG_test.gplot
# 11:12


3.

Edit files SVG_test.gplot und save as SVG_Test.gplot
Saved SVG_Test.gplot to configDB


4.

configdb filelist
Files found in database:
------------------------------------------------------------
./FHEM/FhemUtils/uniqueID
./FHEM/template.layout
./log/eventTypes.txt
./www/gplot/SVG_Test.gplot
./www/gplot/template.gplot
./www/gplot/templateDB.gplot
/opt/fhem/db.conf


5.

configdb fileshow ./www/gplot/SVG_Test.gplot
############################
# Filename: SVG_Test.gplot
# 11:17


6.

Edit Files
Es wird in der Auswahlliste nur SVG_Test.gplot, SVG_test.gplot fehlt.


7.

configdb filelist (zeigt die Datei nach wie vor an)
Files found in database:
------------------------------------------------------------
./FHEM/FhemUtils/uniqueID
./FHEM/template.layout
./log/eventTypes.txt
./www/gplot/SVG_Test.gplot
./www/gplot/template.gplot
./www/gplot/templateDB.gplot
/opt/fhem/db.conf


8.

Edit files SVG_Test.gplot und save SVG_Test.gplot
Saved SVG_Test.gplot to configDB


9.

configdb fileshow ./www/gplot/SVG_test.gplot
############################
# Filename: SVG_Test.gplot
# 11:26




FHEM6.2, RasPi4, RasPi Zero W,
CUL V3, HM, ZWave, IT, vcontrol, owntracks, alexa