configDB und holiday-Dateien

Morgennebel · 26 März 2018, 11:04:29

Moin Moin,

ich habe seit langer Zeit eine holiday-Definition mit meiner eigenen Datei im Dateisystem:


Internals:
   CFGFN      
   HOLIDAYFILE ./FHEM/SH.holiday
   NAME       SH
   NR         273
   READONLY   1
   STATE      none
   TRIGGERTIME 1522015202.15387
   TYPE       holiday
   READINGS:
     2018-03-25 22:49:23   state           none
     2018-03-25 22:49:23   tomorrow        none
     2018-03-25 22:49:23   yesterday       none
Attributes:
   room       Haus

vermutlich seit meiner Migration nach configDB läuft diese nicht mehr. Ein get SH tomorrow führt zu der Ausgabe:

Code Auswählen

Error on reading ./FHEM/holiday/SH.holiday from database!

Laut commandref für Holiday (EN) sollte:

ZitatThe module will try to open the file <name>.holiday in the modpath/FHEM directory first, then in the modpath/FHEM/holiday directory, the latter containing a set of predefined files. This list of available holiday files will be shown if an error occurs at the time of the definition, e.g. if you type "define help holiday"

Zum einen wird hier configDB nicht erwähnt, zum anderen schlägt die Prüfung auf die Datei in modpath/FHEM/SH.holiday fehl.

Laut commandref für configDB wird Holiday dort verwaltet und sollte automatisch importiert werden. Hat bei mir irgendwie nicht geklappt:

Code Auswählen


Files found in database:
------------------------------------------------------------
./FHEM/FhemUtils/uniqueID
./FHEM/template.layout
./www/gplot/SVG_FileLog_Aussen.Brightness_1.gplot
./www/gplot/SVG_FileLog_DI_EG.HWR.FussbodenpumpeAnforderung_1.gplot
./www/gplot/SVG_FileLog_D_vThings.AirOG_1.gplot
./www/gplot/SVG_FileLog_EG.Arbeitszimmer.Wandthermostat_1.gplot
./www/gplot/SVG_FileLog_EG.Flur.Tagstrom_1.gplot
./www/gplot/SVG_FileLog_EG.HWR.Wandthermostat_1.gplot
./www/gplot/SVG_FileLog_EG.Heizung.Mischer.Vorlauf_1.gplot
./www/gplot/SVG_FileLog_EG.Keller.Gaszaehler_1.gplot
./www/gplot/SVG_FileLog_EG.Wintergarten.AudioSubwoofer_1.gplot
./www/gplot/SVG_FileLog_EG.Wintergarten.Wandthermostat_1.gplot
./www/gplot/SVG_FileLog_Fussboden_1.gplot
./www/gplot/SVG_FileLog_Gewaechshaus.Katzenhaus_1.gplot
./www/gplot/SVG_FileLog_HMLAN1_1.gplot
./www/gplot/SVG_FileLog_HM_EG.KUECHE_PowerMKuehlschrank_1.gplot
./www/gplot/SVG_FileLog_HM_OG.BADEZMR_Wandthermostat_1.gplot
./www/gplot/SVG_FileLog_HM_OG.BADEZMR_Wandthermostat_2.gplot
./www/gplot/SVG_FileLog_HM_OUT.GEWAECHS_KatzenhausTempHum_1.gplot
./www/gplot/SVG_FileLog_LuftdatenScheune_1.gplot
./www/gplot/SVG_FileLog_MQTT.BrightnessAussen_1.gplot
./www/gplot/SVG_FileLog_OG.Badezimmer.Wandthermostat_1.gplot
./www/gplot/SVG_FileLog_OG.Flur.Wandthermostat_1.gplot
./www/gplot/SVG_FileLog_OG.Ineke.Arbeitszimmer.Wandthermostat_1.gplot
./www/gplot/SVG_FileLog_OG.Ineke.Arbeitszimmer.Wandthermostat_2.gplot
./www/gplot/SVG_FileLog_OG.Ineke.Schlafzimmer.Wandthermostat_1.gplot
./www/gplot/SVG_FileLog_OG.Lennart.Wandthermostat_1.gplot
./www/gplot/SVG_FileLog_OG.Schlafzimmer.Wandthermostat_1.gplot
./www/gplot/SVG_FileLog_OG.Wohnzimmer.Wandthermostat_1.gplot
./www/gplot/SVG_FileLog_PWM.FussbodenHeizung_1.gplot
./www/gplot/SVG_FileLog_Spritpreise_1.gplot
./www/gplot/template.gplot
./www/gplot/templateDB.gplot

Danke, -MN

rudolfkoenig · 26 März 2018, 11:10:52

holiday.pm verwendet FileRead, was die Datei je nach Konfiguration vom Filesystem oder aus der Datenbank liest.
Die Fehlermeldung weist auf ein Problem in der Datenbank hin. Das kann natuerlich auch sowas banales sein, wie Datei in der DB nicht vorhanden. Ich faende es nett, wenn die DB-Fehlermeldung ein bisschen mehr Details verraten wuerde, was unter "Error" zu verstehen ist.

CoolTux · 26 März 2018, 11:16:42

Code Auswählen


Error on reading ./FHEM/holiday/SH.holiday from database!

Eigentlich steht doch schon genau da was das Problem ist. Er kann das File aus der DB nicht lesen. Also entweder gibt es das File dort nicht oder aber ...

Es scheint wohl am ersteren zu liegen. Ich würde das File einfach importieren und gut ist. Am besten so das es aus dem Filesystem raus ist.

Morgennebel · 26 März 2018, 11:51:16

Zitat von: CoolTux am 26 März 2018, 11:16:42
Es scheint wohl am ersteren zu liegen. Ich würde das File einfach importieren und gut ist. Am besten so das es aus dem Filesystem raus ist.

Ja, das ist eine Lösung. Nur warum wurde es bei der Migration auf configDB nicht automatisch gemacht und warum erwähnt die commandref von holiday nicht die Abhängigkeit von configDB?

Kleine Erweiterungen der Doku beugen Haarausfall vor...

Danke, -MN

betateilchen · 26 März 2018, 11:51:47

Zitat von: CoolTux am 26 März 2018, 11:16:42
Es scheint wohl am ersteren zu liegen. Ich würde das File einfach importieren

Ich auch.

betateilchen · 26 März 2018, 11:56:41

Zitat von: Morgennebel am 26 März 2018, 11:51:16
Ja, das ist eine Lösung. Nur warum wurde es bei der Migration auf configDB nicht automatisch gemacht

Das kann ich Dir nicht beantworten. In der Vergangenheit hat das immer funktioniert, vorausgesetzt, das holiday device war schon zum Zeitpunkt der Migration vorhanden.

Meine Vermutung ist, dass es gar nicht mit der Migration selbst zusammenhängt, sondern mit der geänderten Suchreihenfolge, die das Modul holiday.pm seit einiger Zeit benutzt, um die holiday Dateien zu finden.

Das Phänomen werde ich mir demnächst mal in Ruhe anschauen. Bei mir funktionieren alle holiday Dateien in allen meiner configDB Installationen korrekt.

Zitat von: Morgennebel am 26 März 2018, 11:51:16
und warum erwähnt die commandref von holiday nicht die Abhängigkeit von configDB?

Weil das eine Aufgabe ist, die von configDB zu lösen ist und nicht von holiday. Und in der commandref zu configDB sind seit Ewigkeiten alle Modultypen aufgeführt, bei denen es ein Zusammenwirken gibt.

Morgennebel · 26 März 2018, 12:00:36

Zitat von: betateilchen am 26 März 2018, 11:56:41
Warum wundert es mich eigentlich nicht, dass ausgerechnet Du schon wieder mit einem offenbar nur bei Dir existierenden "configDB-Problem" um die Ecke gemobbbt kommst?

Ach, Schnucki, ich hab nicht gemobbt. Ich habe auf Verbesserungsmöglichkeiten hingewiesen, den Fehler selbst eingegrenzt und nicht auf configDB geschimpft. Nur auf die Doku und fehlenden Kreuzhinweise hingewiesen.

Warum sitzt Du eigentlich immer unter dem Tisch und greinst "Du doof", wenn jemand mit configDB nicht so viel Ahnung wie Du selbst hast?

Ciao, -MN

betateilchen · 26 März 2018, 12:45:53

Zitat von: Morgennebel am 26 März 2018, 12:00:36
wenn jemand mit configDB nicht so viel Ahnung wie Du selbst hast?

Nur, wenn dieser jemand aus einer gleichbleibenden Gruppe von ca. 5 Personen kommt. Ausserdem erwarte ich von KEINEM Anwender, dass er genau soviel Ahnung über die configDB haben muss wie ich.

Zurück zum Thema.

1. Test: ein neues holiday soll in einer bestehenden configDB Installation erzeugt werden.

Code Auswählen

define ns holiday

liefert

Code Auswählen


Error on reading ./FHEM/holiday/ns.holiday from database!
Available holiday files:

Die erste Zeile ist ok, denn die Datei existiert noch nicht.
Die zweite Zeile ist aus configDB Sicht auch korrekt, weil holiday.pm keine Dateiliste aus der Datenbank abruft, um diese anzuzeigen. Aber das Verhalten sollte in holiday.pm geändert werden.

Was tun, um das device doch definieren zu können? Ganz logisch: die fehlende Datei muss in die Datenbank importiert werden.

Code Auswählen


     configdb fileimport ./FHEM/holiday/ns.holiday

liefert als Rückmeldung:

     267 bytes written from file ./FHEM/holiday/ns.holiday to database

ein erneutes

     define ns holiday

legt das device nun korrekt an.

Code Auswählen


Internals:
   CFGFN      
   HOLIDAYFILE ./FHEM/holiday/ns.holiday
   NAME       ns
   NR         71
   READONLY   1
   STATE      none
   TRIGGERTIME 1522101602.01667
   TYPE       holiday

2. Test: eine privateCopy der holiday Datei soll erzeugt werden

Code Auswählen


set ns createPrivateCopy

führt dazu,

dass die holiday Datei innerhalb der Datenbank an die richtige Stelle kopiert wird, um sie bearbeitbar zu machen
dass das Internal HOLIDAYFILE sich ändert und auf die bearbeitbare Datei zeigt

Code Auswählen


Files found in database:
------------------------------------------------------------
./FHEM/holiday/ns.holiday
./FHEM/ns.holiday

Code Auswählen


   CFGFN      
   HOLIDAYFILE ./FHEM/ns.holiday
   NAME       ns
   NR         71
   READONLY   0
   STATE      none
   TRIGGERTIME 1522101602.23688
   TYPE       holiday

In der Detailansicht des holiday device erscheint ein Link "Edit ns.holiday" der allerdings nicht funktioniert, weil eine falsche URL erzeugt wird.
In der Liste, die man unter "Edit files" in der Navigation findet, wird die Datei angezeigt und ist auch bearbeitbar.

@Rudi: an den rot markierten Stellen bestehen ToDos, um die wir uns nochmal kümmern müssen.

Zum Thema Migration.

Bei einer Migration wird für jedes bestehende holiday-device genau die Datei automatisch in die Datenbank importiert, die im Internal HOLIDAYFILE des device steht. Falls es das Internal nicht gibt (kann bei sehr alten FHEM Installationen der Fall sein) wird die Datei "./FHEM/<deviceName>.holiday" in die Datenbank importiert.

Das Verhalten, dass nach einer Migration ein vorher bestehendes holiday device nicht mehr funktioniert, weil die .holiday Datei fehlt, konnte ich bei meinen eben durchgeführten Tests und Migrationen nicht reproduzieren.

rudolfkoenig · 26 März 2018, 12:55:16

ZitatDie zweite Zeile ist aus configDB Sicht auch korrekt, weil holiday.pm keine Dateiliste aus der Datenbank abruft, um diese anzuzeigen. Aber das Verhalten sollte in holiday.pm geändert werden.

Kannst du bitte was vorschlagen?

betateilchen · 26 März 2018, 13:01:24

Zitat von: Morgennebel am 26 März 2018, 11:04:29
vermutlich seit meiner Migration nach configDB läuft diese nicht mehr. Ein get SH tomorrow führt zu der Ausgabe:

Code Auswählen Erweitern
Error on reading ./FHEM/holiday/SH.holiday from database!

@Rudi - da fallen mir aber auch noch Fragen ein.

Die Meldung sollte doch dann eigentlich auch schon beim Starten von FHEM auftreten und im Log stehen?
Es müsste eine Fehlermeldung in motd ausgegeben werden, dass beim Starten von FHEM Fehler auftraten?
Wieso legt FHEM ein holiday-device an / wieso kann FHEM das device überhaupt anlegen, wenn die zugehörige holiday-Datei nicht vorhanden ist? Wenn man das "manuell" versucht, wird definitiv kein device erzeugt.

betateilchen · 26 März 2018, 13:03:24

Zitat von: rudolfkoenig am 26 März 2018, 11:10:52
Ich faende es nett, wenn die DB-Fehlermeldung ein bisschen mehr Details verraten wuerde, was unter "Error" zu verstehen ist.

Das fände ich auch nett, aber in 99,9% aller Fälle gilt der Tatbestand, dass die Datei einfach nicht in der Datenbank vorhanden ist.

Zitat von: rudolfkoenig am 26 März 2018, 12:55:16
Kannst du bitte was vorschlagen?

Ja, aber gib mir ein bisschen Zeit

rudolfkoenig · 26 März 2018, 13:12:02

ZitatDie Meldung sollte doch dann eigentlich auch schon beim Starten von FHEM auftreten und im Log stehen?

Davon gehe ich aus. get liest die Datei aber nochmal.

ZitatWieso legt FHEM ein holiday-device an

Wie kommst du auf diese Idee? Ich meine das nicht rhetorisch.

ZitatDas fände ich auch nett, aber in 99,9% aller Fälle gilt der Tatbestand, dass die Datei einfach nicht in der Datenbank vorhanden ist.

Na dann sollte es auch in 99% der Faelle das so dastehen

ZitatJa, aber gib mir ein bisschen Zeit (https://forum.fhem.de/Smileys/default/smiley.gif)

Gerne, ich habe auch viel Anderes zu tun, lass mich nur leider einfach von lustigeren Sachen ablenken.

betateilchen · 26 März 2018, 13:13:37

Und noch mehr Fragen, die sich bei genauer Betrachtung ergeben:

Zitat von: Morgennebel am 26 März 2018, 11:04:29
Code Auswählen Erweitern
Internals: CFGFN HOLIDAYFILE ./FHEM/SH.holiday NAME SH NR 273 READONLY 1 STATE none TRIGGERTIME 1522015202.15387 TYPE holiday

Da steht im Internal HOLIDAYFILE die Datei ./FHEM/SH.holiday

Wieso wird aber hier:

Zitat von: Morgennebel am 26 März 2018, 11:04:29
Ein get SH tomorrow führt zu der Ausgabe:

Code Auswählen Erweitern
Error on reading ./FHEM/holiday/SH.holiday from database!

versucht, ein ganz anderes HOLIDAYFILE zu lesen, nämlich aus ./FHEM/holiday/SH.holiday

Das ergibt für mich überhaupt keinen Sinn - und ich glaube nun auch nicht mehr, dass es sich wirklich um einen Fehler handelt, der bei der Migration aufgetreten ist.

betateilchen · 26 März 2018, 13:18:08

Zitat von: rudolfkoenig am 26 März 2018, 13:12:02
Wie kommst du auf diese Idee? Ich meine das nicht rhetorisch.

Ich verstehe Deine Frage nicht, aber ich probiers nochmal.

Wieso kann FHEM ein holiday-device anlegen, wenn es keine zugehörige .holiday Datei gibt?

Code Auswählen

define xyz holiday

liefert mir die Fehlermeldung

Code Auswählen

Error on reading ./FHEM/holiday/xyz.holiday from database!

Wieso hat der Anwender trotzdem ein existierendes holiday device, bei dem aber ein "get" nicht funktioniert?

betateilchen · 26 März 2018, 14:44:26

Zitat von: betateilchen am 26 März 2018, 12:45:53
~~Die zweite Zeile ist aus configDB Sicht auch korrekt, weil holiday.pm keine Dateiliste aus der Datenbank abruft, um diese anzuzeigen~~. Aber das Verhalten sollte in holiday.pm geändert werden.

Zitat von: rudolfkoenig am 26 März 2018, 12:55:16
Kannst du bitte was vorschlagen?

Dieses Thema ist etwas komplexer als gedacht.

die durchgestrichene Aussage ziehe ich zurück. holiday.pm sendet sehr wohl eine Anfrage an die Datenbank, um eine Liste zu bekommen.
trotzdem funktioniert die Anzeige der Liste nicht, wie erwartet.

Gegeben sei:

Code Auswählen


Files found in database:
------------------------------------------------------------
./FHEM/holiday/ns.holiday
./FHEM/sh.holiday

Wenn ich nun versuche, ein

Code Auswählen


define xyz holiday

auszuführen, bekomme ich als Antwort

Code Auswählen


Error on reading ./FHEM/holiday/xyz.holiday from database!
Available holiday files: ns

In der Liste der verfügbaren Dateien wird also immer nur die Liste der .holiday Dateien aus ./FHEM/holiday/ angezeigt, alle in ./FHEM/ vorhandenen .holiday Dateien werden nicht berücksichtigt.

Das Verhalten dürfte sowohl bei fhem.cfg als auch bei configDB bestehen und ist im Quellcode begründet:

Code Auswählen


  my $dir = $attr{global}{modpath} . "/FHEM";
  my ($err, @holidayfile) = FileRead("$dir/$name.holiday");
  if($err) {
    $dir = $attr{global}{modpath}."/FHEM/holiday";
    ($err, @holidayfile) = FileRead("$dir/$name.holiday");
    $hash->{READONLY} = 1;
  } else {
    $hash->{READONLY} = 0;
  }

  if($err) {
    if($showAvailable) {
      my @ret;
      if(configDBUsed()) {
        @ret = cfgDB_FW_fileList($dir,".*.holiday",@ret);
        map { s/\.configDB$//;$_ } @ret;
      } else {
        if(opendir(DH, $dir)) {
          @ret = grep { m/\.holiday$/ } readdir(DH);
          closedir(DH);
        }
      }

Zuerst wird versucht, eine bestimmte Datei in $dir ( <modPath>/FHEM ) zu finden.
Im Fehlerfall wird die Variable $dir geändert auf ( <modPath>/FHEM/holiday)
Dann wird erneut versucht, eine bestimmte Datei in $dir zu finden.
Im erneuten Fehlerfall wird eine Liste verfügbarer Dateien in $dir erzeugt.

Diese Liste wird also immer nur aus dem Verzeichnis <modPath>/FHEM/holiday erzeugt.

Meine Erwartungshaltung wäre:

dass in beiden möglichen Verzeichnissen nach .holiday Dateien gesucht wird.
dass eine Datei nur einmal aufgeführt wird, falls sie in beiden Verzeichnissen vorhanden ist.