configDB und holiday-Dateien

[Morgennebel]

Moin Moin,


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

Code Auswählen Erweitern


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 Erweitern

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

Laut commandref  für Holiday (EN) sollte:

The 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 Erweitern


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]

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]

Code Auswählen Erweitern


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]

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]

Es scheint wohl am ersteren zu liegen. Ich würde das File einfach importieren

Ich auch.

[betateilchen]

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.

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]

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]

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 Erweitern

define ns holiday

liefert

Code Auswählen Erweitern


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 Erweitern


     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 Erweitern


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 Erweitern


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 Erweitern


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


Code Auswählen Erweitern


   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]

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.

Kannst du bitte was vorschlagen?

[betateilchen]

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]

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.

Kannst du bitte was vorschlagen?

Ja, aber gib mir ein bisschen Zeit

[rudolfkoenig]

Die 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.

Wieso legt FHEM ein holiday-device an

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

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.

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

Ja, 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]

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

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:

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]

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 Erweitern

define xyz holiday

liefert mir die Fehlermeldung

Code Auswählen Erweitern

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]

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.

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 Erweitern


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


Wenn ich nun versuche, ein

Code Auswählen Erweitern


define xyz holiday


auszuführen, bekomme ich als Antwort

Code Auswählen Erweitern


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 Erweitern


  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.

[Morgennebel]

Danke für die bisherige Analyse und Arbeit...

Wenn ich ConfigDB nutze und später eine Holiday-Datei definiere

Code Auswählen Erweitern

define xyz holiday

sollte diese dann nicht automatisch in die ConfigDB integriert werden? Die Commandref spricht davon, daß die ConfigDB Holidays unterstützt - oder ist es nur meine Erwartungshaltung?

In jedem Fall fände ich es sehr begrüßenswert, den Holiday-Teil der Commandref entsprechend um einen ConfigDB-Absatz zu ergänzen.

Danke, -MN

[betateilchen]

Wenn ich ConfigDB nutze und später eine Holiday-Datei definiere

Code Auswählen Erweitern

define xyz holiday

Damit definierst Du keine .holiday Datei, sondern ein holiday device.

sollte diese dann nicht automatisch in die ConfigDB integriert werden?

Nein.

Die Commandref spricht davon, daß die ConfigDB Holidays unterstützt - oder ist es nur meine Erwartungshaltung?

Es ist Deine falsche Erwartungshaltung.

configDB unterstützt das Modul holiday zu 100%.

Aber holiday Dateien entstehen nicht automatisch durch die Definition eines holiday devices. Das ist auch bei Verwendung von fhem.cfg nicht anders.

Für das Bereitstellen der von einem Modul zusätzlich benötigten Datei ist in der Regel der Anwender verantwortlich.

• bei der Arbeit mit fhem.cfg muss die Datei im Dateisystem erstellt werden
• bei der Arbeit mit configDB muss die Datei in die Datenbank importiert werden

Dieses Vorgehen ist auch in anderen Modulen, die zusätzliche Dateien verwenden, nicht anders. Beispielsweise legt auch das Modul 02_RSS.pm keine layout Datei automatisch an, nur weil sie in einem RSS-device als Quelle namentlich angegeben wird.

Und das ist alles auch ausreichend dokumentiert und überhaupt nichts configDB-spezifisches. Deshalb gibt es für mich auch keine Notwendigkeit dafür, dass irgendein Modul eine configDB-spezifische commandref-Beschreibung bereitstellen muss. Die configDB verhält sich bezüglich der zusätzlichen Dateien exakt so wie die dateibasierte Konfiguration auch: Wenn eine zugehörige Datei nicht vorhanden ist, funktioniert das eben nicht.

[Morgennebel]

Okay, Danke...

Ciao, -MN

[betateilchen]

Du kannst Dir als configDB-Nutzer die Arbeit erleichtern, falls Du öfters eigene .holiday Dateien benötigst.

• importiere eine beliebige holiday Datei in die Datenbank, falls dort noch gar keine solche Datei existiert
• öffne die importierte (oder eine beliebige bereits vorhandene .holiday) Datei in "Edit files", schmeiss den kompletten Inhalt raus und speichere die Datei mit "Save as" als "template.holiday" ab
• wenn Du eine neue (eigene) holiday-Datei erstellen möchtest, öffne die Datei template.holiday, bearbeite diese und speichere sie als "xyz.holiday" mit "Save as" ab

Die Schritte 1 + 2 sind nur einmalig auszuführen!
Da die Datei in Schritt 3 bereits aus der configDB gelesen wird, wird die neue Datei mit "Save as" auch automatisch wieder in die Datenbank zurückgeschrieben. Dieser Schritt kann beliebig oft ausgeführt werden.

[rudolfkoenig]

Sorry, etwas spaet, und ihr habt schon Etliches herausgefunden, aber vielleicht hilft die Beschreibung hier trotzdem.

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

Weil DefFn waehrend FHEM-Start sich anders verhaelt, als danach. Aus welchem Grund auch immer wird die eigentliche Definition per InternalTimer auf die Zeit nach Einlesen von fhem.cfg verschoben.

Da steht im Internal HOLIDAYFILE die Datei ./FHEM/SH.holiday
Wieso wird aber hier:
...
versucht, ein ganz anderes HOLIDAYFILE zu lesen, nämlich aus ./FHEM/holiday/SH.holiday

Das Modul versucht zunaechst FHEM/SH.holiday zu oeffnen, und falls das nicht existiert, dann FHEM/holiday/SH.holiday, diese aber read-only. HOLIDAYFILE enthaelt den Namen der erfolgreich geoeffneten Datei. Da HOLIDAYFILE ein Internal ist, gehe ich davon aus, dass FHEM nach der Umstellung auf configDB nicht neu gestartet wurde. Eine Alternative laut Programmcode waere, dass die Datei nicht mehr lesbar ist.

Die zweite Zeile ist aus configDB Sicht auch korrekt, weil holiday.pm keine Dateiliste aus der Datenbank abruft, um diese anzuzeigen.

Doch: wenn die Datei weder in FHEM, noch in FHEM/holiday zu finden ist, und configDBUsed() wahr ist, dann wird         

Code Auswählen Erweitern

@ret = cfgDB_FW_fileList($dir,".*.holiday",@ret);
aufgerufen, mit $dir=$attr{global}{modpath}."/FHEM/holiday";

In der Detailansicht des holiday device erscheint ein Link "Edit ns.holiday" der allerdings nicht funktioniert, weil eine falsche URL erzeugt wird.

Das habe ich gefixt, aber nicht getestet. Kannst du das bitte nachholen?

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

Habs getestet, ja tut es.

Es müsste eine Fehlermeldung in motd ausgegeben werden, dass beim Starten von FHEM Fehler auftraten?

Das nicht, weil das Geraet wg. der InternalTimer-Definition strenggenommen nach FHEM-Start definiert wird.

[betateilchen]

Hallo Rudi,

danke für Deine Antwort. Hattest Du den Thread auch weiter gelesen?

Das hier:

Doch: wenn die Datei weder in FHEM, noch in FHEM/holiday zu finden ist, und configDBUsed() wahr ist, dann wird         

Code Auswählen Erweitern

@ret = cfgDB_FW_fileList($dir,".*.holiday",@ret);
aufgerufen, mit $dir=$attr{global}{modpath}."/FHEM/holiday";

hatte ich schon richtiggestellt und beschrieben, warum die Liste meiner Meinung nach trotzdem nicht so funktioniert, wie man es erwarten würde.

https://forum.fhem.de/index.php/topic,86243.msg786857.html#msg786857

Das habe ich gefixt, aber nicht getestet. Kannst du das bitte nachholen?

Das scheint jetzt zu funktionieren, danke.



Bei diesem Test ist mir aber etwas anderes aufgefallen. Bis rev #15701 gab es eine Rückmeldung beim Speichern einer Datei, in der ein Hinweis enthalten war, wohin eine Datei gespeichert wurde.

Code Auswählen Erweitern


    $ret = ($ret ? "<h3>ERROR:</h3><b>$ret</b>" :
                "Saved the file $fileName to $forceType");


Seit rev #15710 gibt es diese Meldung nicht mehr, jetzt steht da nur noch "Saved <fileName>".

Es wäre schön, wenn Du den Zusatz mit dem Speicherort wieder einbauen könntest, denn bei Anwendern von configDB gibt es immer Dateien im Dateisystem UND in der Datenbank. Manchmal sogar Dateien mit gleichem Namen an beiden Stellen. Und da ist der Hinweis auf den Speicherort sehr hilfreich.

[rudolfkoenig]

danke für Deine Antwort. Hattest Du den Thread auch weiter gelesen?

Ja, aber ich habe eure "Entdeckungen" erst gesehen, nachdem ich mein Text schon formuliert habe, und ich habe ihn dann nicht mehr entfernt.

Es wäre schön, wenn Du den Zusatz mit dem Speicherort wieder einbauen könntest

Im Fall von configDB wird ab sofort wieder "Saved XXX to configDB" gemeldet, bei Filesystem-Speicherung bleibt es beim "Save XXXX", da ich "to file" albern finde.

[betateilchen]

passt schon, danke

Frohe Ostern!

[HeikoBayer]

Hallo Zusammen,

sorry, wenn ich dieses alte Thema nochmal aufgreife.
Prinzipiell funktioniert bei mir alles sehr gut!
Nun habe ich eine Frage zu holiday-Datei und configDB:
Ich benutze seit kurzem SSCAL (Synology Calendar für meine Urlaube.
Wie in der FHEM Wiki beschrieben (https://wiki.fhem.de/wiki/SSCal_-_Integration_des_Synology_Calendar_Servers) gibt es die Möglichkeit, Abwesenheiten direkt in die holiday-Datei zu schreiben.
Dazu werden 2 Routinen in 99__myUtils.pm eingefügt:

Code Auswählen Erweitern

###################################################################################################
###    Urlaubstermine auswerten mit 57_SSCal.pm
###    Aufruf der Funktion aus Notify
###   
###    $event = compositeBlockNumbers-$EVENT und enthält alle Blocknummern des Kalenders, z.B.
###    compositeBlockNumbers: 00 01 02 03 04 05 06 07 08 09 10 11 12 13
###
####################################################################################################
sub SSCalToHoliday($$$) {
   my ($name,$fName,$event) = @_;
   my $hash           = $defs{$name};
   my ($reading,$evt) = split(": ",$event,2);
   my (@bnr)          = split(" ",$evt);
   
   my @SigList        = qw/Urlaub Abwesend/;                             # Signalwörter im Kalender für "Abwesenheit"
   my @ul;   

   foreach my $bnr (@bnr) {
       last if($bnr eq "none");
       my $status  = ReadingsVal($name, $bnr."_17_Status",  "");         # Status
       my $summary = ReadingsVal($name, $bnr."_01_Summary", "");         # Summary
       my $begin   = ReadingsVal($name, $bnr."_05_Begin",   "");         # Starttermin
       my $end     = ReadingsVal($name, $bnr."_10_End",     "");         # Endtermin
   
       if($status =~ /upcoming|alarmed|started/) {                       # Termine beginnen in Zukunft, Signalwort aus
                                                                         # Liste enthalten ?               
           if (grep {$summary =~ /$_/} @SigList) {               
               my ($sy,$sm,$sd,$sh,$smin,$ss) = ($begin =~ /(\d{4})-(\d{2})-(\d{2}) (\d{2}):(\d{2}):(\d{2})/);
               my ($ey,$em,$ed,$eh,$emin,$es) = ($end   =~ /(\d{4})-(\d{2})-(\d{2}) (\d{2}):(\d{2}):(\d{2})/);
               
               if($sy != $ey) {                                          # wenn Jahreswechsel vorliegt zwei Sätze erzeugen
                   push(@ul, "4 $sm-$sd 12-31 $summary");                # 4 12-09 12-31 Urlaub Teil1
                   push(@ul, "4 01-01 $em-$ed $summary");                # 4 01-01 01-05 Urlaub Teil2
                   
               } else {
                   my $ue = "4 $sm-$sd $em-$ed $summary";
                   push(@ul, $ue);
               }
           }
       }
   }
   
   if (@ul) {
       Log3 ($name, 4, "$name - Argument list for SSCalWriteHoliday:");
       foreach my $i (@ul) {
           Log3 ($name, 4, "$name - $i");
       }
   } else {
       Log3 ($name, 4, "$name - No absence time detected. All absence will be deleted.");
   }
   
   SSCalWriteHoliday($name,$fName,@ul);
       
return;
}

############################################################################
###    Schreibroutine Urlaub in File (central.holiday)
############################################################################
sub SSCalWriteHoliday(@) {
  my ($name,$fName,@ul) = @_;
  $fName = $attr{global}{modpath}."/FHEM/".$fName;

  my $param = {
               FileName   => $fName,
               ForceType  => "file",
              };
 
  my ($err, @old) = FileRead($param);
  if($err) {
      Log3 ($name, 2, "$name - Couldn't read file: $err");
      return;
  }
 
  my @new;                                                             # neue Liste zum Schreiben
  my $del = 0;
 
  foreach my $l (@old) {
      if($l =~ m/^# Time of absence from Calendar $name/i) {
          $del = 1;
      }
 
      if($l =~ m/^# End Time of absence from Calendar $name/i) {
          $del = 0;
  next;
      }
     
      if ($del) {
          next;     
      } else {
          push (@new, $l);
          Log3 ($name, 4, "$name - add line: $l");
      } 
  }
 
  unshift (@ul, "# Time of absence from Calendar $name, updated: ".TimeNow());
  push    (@ul, "# End Time of absence from Calendar $name");
  push    (@new, @ul);

  Log3 ($name, 4, "$name - -> Start new list write into $fName <-");
  foreach my $i (@new) {
      Log3 ($name, 4, "$name - $i");
  }
  Log3 ($name, 4, "$name - -> End new list <-");

  $err = FileWrite($param, @new);
  if($err) {
      Log3 ($name, 2, "$name - Couldn't write holiday data into $fName: $err");
  }
 
return;
}

Wei hier bereits mehrfach erklärt, führt dieser Teil zum Fehler, da die Datei ja nun in der Datenbank liegt und nicht mehr im FHEM Verzeichnis:

Code Auswählen Erweitern

sub SSCalWriteHoliday(@) {
  my ($name,$fName,@ul) = @_;
  $fName = $attr{global}{modpath}."/FHEM/".$fName;


Seht Ihr hier eine Möglichkeit, as automatische Beschreiben der holiday-Datei in der BD zu ermöglichen?

Ich würe mich über eine Rückmelung sehr freuen.

Grüße,
Heiko Bayer

[betateilchen]

Nimm in SSCalWriteHoliday() die Zeile

Code Auswählen Erweitern

ForceType  => "file",

raus. Die ist kompletter Unfug.

Kann dieser komische Kalender auf der Synology eigentlich keine ics-Dateien liefern? Die könnte man einfach mit dem Calendar-Modul verarbeiten.

[HeikoBayer]

Nimm in SSCalWriteHoliday() die Zeile

Code: [Auswählen]
ForceType  => "file",

raus. Die ist kompletter Unfug.

Perfekt, das klappt. Vielen Dank für die schnelle Hilfe!

Kann dieser komische Kalender auf der Synology eigentlich keine ics-Dateien liefern? Die könnte man einfach mit dem Calendar-Modul verarbeiten.

Das kann ich leider nicht sagen. Habe eben erst mit den Kalendern angefangen um verschiedene Dinge zu automatisieren.

[betateilchen]

Habe eben erst mit den Kalendern angefangen um verschiedene Dinge zu automatisieren.

Gut, aber warum fängst Du dann nicht mit dem Modul an, das genau dafür gedacht ist?
Der Umweg, aus einem Kalender Einträge in ein holiday-File zu schreiben ist doch ziemlich abstrus.
Dafür war das holiday Modul nie vorgesehen.

[HeikoBayer]

Gut, aber warum fängst Du dann nicht mit dem Modul an, das genau dafür gedacht ist?

Hm. OK. Bitte klär mich auf. Was wäre denn dafür gedacht?
Vielleicht denke ich hier ja zu kompliziert.

[betateilchen]

Bitte klär mich auf. Was wäre denn dafür gedacht?

Das habe ich doch schon geschrieben?

ics-Dateien ... Die könnte man einfach mit dem Calendar-Modul verarbeiten.

Gib mal "help calendar" in die Befehlszeile ein.

[HeikoBayer]

Gib mal "help calendar" in die Befehlszeile ein.

Das habe ich alles schon gelesen, hilft mir aber bei meinem Thema so nicht weiter. Ich nutze ASC für die Rollosteuerung und brauche dafür ein Gerät für holiday2we das minimal today und tomorrow liefert.
Mit dem calendar device habe ich es bisher nur mittels div. dummies einigen notifies und einer sub in 99_myUtils geschafft.

Da erscheint mir die Lösung, die im SSCal beschrieben ist, deutlich charmanter.

Oder sehe ich den Wald vor lauter Bäumen nicht?!? Wie sollte ich sonst die verschiedenen Kalender (Feiertage, Ferien) in holiday2we verwenden?