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:
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:
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
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.
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.
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
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.
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.
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
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.
define ns holidayliefert
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.
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.
Internals:
CFGFN
HOLIDAYFILE ./FHEM/holiday/ns.holiday
NAME ns
NR 71
READONLY 1
STATE none
TRIGGERTIME 1522101602.01667
TYPE holiday
eine privateCopy der holiday Datei soll erzeugt werden
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
Files found in database:
------------------------------------------------------------
./FHEM/holiday/ns.holiday
./FHEM/ns.holiday
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.
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?
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:
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.
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 :)
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.
Und noch mehr Fragen, die sich bei genauer Betrachtung ergeben:
Zitat von: Morgennebel am 26 März 2018, 11:04:29
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:
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.
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?
define xyz holidayliefert mir die Fehlermeldung
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?
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:
Files found in database:
------------------------------------------------------------
./FHEM/holiday/ns.holiday
./FHEM/sh.holiday
Wenn ich nun versuche, ein
define xyz holiday
auszuführen, bekomme ich als Antwort
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:
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.
Danke für die bisherige Analyse und Arbeit...
Wenn ich ConfigDB nutze und später eine Holiday-Datei definiere
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
Zitat von: Morgennebel am 27 März 2018, 10:16:45
Wenn ich ConfigDB nutze und später eine Holiday-Datei definiere
define xyz holiday
Damit definierst Du keine .holiday Datei, sondern ein holiday device.
Zitat von: Morgennebel am 27 März 2018, 10:16:45
sollte diese dann nicht automatisch in die ConfigDB integriert werden?
Nein.
Zitat von: Morgennebel am 27 März 2018, 10:16:45
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.
Okay, Danke...
Ciao, -MN
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.
Sorry, etwas spaet, und ihr habt schon Etliches herausgefunden, aber vielleicht hilft die Beschreibung hier trotzdem.
ZitatWieso 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.
ZitatDa 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.
ZitatDie 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
@ret = cfgDB_FW_fileList($dir,".*.holiday",@ret);aufgerufen, mit $dir=$attr{global}{modpath}."/FHEM/holiday";
ZitatIn 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?
ZitatDie Meldung sollte doch dann eigentlich auch schon beim Starten von FHEM auftreten und im Log stehen?
Habs getestet, ja tut es.
ZitatEs 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.
Hallo Rudi,
danke für Deine Antwort. Hattest Du den Thread auch weiter gelesen?
Das hier:
Zitat von: rudolfkoenig am 27 März 2018, 23:07:15
Doch: wenn die Datei weder in FHEM, noch in FHEM/holiday zu finden ist, und configDBUsed() wahr ist, dann wird @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
Zitat von: rudolfkoenig am 27 März 2018, 23:07:15
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.
$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.
Zitatdanke 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.
ZitatEs 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.
passt schon, danke :)
Frohe Ostern!
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:
###################################################################################################
### 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:
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
Nimm in SSCalWriteHoliday() die Zeile
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.
ZitatNimm in SSCalWriteHoliday() die Zeile
Code: [Auswählen]
ForceType => "file",
raus. Die ist kompletter Unfug.
Perfekt, das klappt. Vielen Dank für die schnelle Hilfe!
ZitatKann 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.
Zitat von: HeikoBayer am 03 Dezember 2021, 13:44:54
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.
ZitatGut, 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.
Zitat von: HeikoBayer am 05 Dezember 2021, 10:18:58
Bitte klär mich auf. Was wäre denn dafür gedacht?
:o Das habe ich doch schon geschrieben?
Zitat von: betateilchen am 03 Dezember 2021, 12:22:31
ics-Dateien ... Die könnte man einfach mit dem Calendar-Modul verarbeiten.
Gib mal "help calendar" in die Befehlszeile ein.
ZitatGib 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?