Hallo Zusammen,
ich hatte vor einiger Zeit mal einen FHEM-Installation z.B. mit Nextcloud, Lets Encrypt und diese mittels Tool für alle Fälle gesichert.
Da ich nun mit einer anderen Anwendungen auf der Installation Probleme hatte wurde die Sicherung wieder eingespielt.
Alles Module oder Anwendungen funktionieren ohne Probleme, nur macht das Modul "Caldendar" bei der Nextcloud-Kalender-Abfrage-Probleme.
Die Nextcloud-Installation läuft wie vorher auch auf den Raspberry. Eine Kalender-Abfrage mit anderen Tools oder Geräten funktioniert ohne Probleme.
Irgendwie finde ich die Lösung nicht mehr.
Zitat
PERL WARNING: Use of uninitialized value $t in numeric lt (<) at ./FHEM/57_Calendar.pm line 2217.
2018.10.10 06:56:37.892 1: stacktrace:
2018.10.10 06:56:37.892 1: main::__ANON__ called by ./FHEM/57_Calendar.pm (2217)
2018.10.10 06:56:37.892 1: main::Calendar_RearmTimer called by ./FHEM/57_Calendar.pm (2602)
2018.10.10 06:56:37.892 1: main::Calendar_CheckAndRearm called by ./FHEM/57_Calendar.pm (2570)
2018.10.10 06:56:37.892 1: main::Calendar_ProcessUpdate called by FHEM/HttpUtils.pm (593)
2018.10.10 06:56:37.893 1: main::__ANON__ called by fhem.pl (723)
Hat jemand eine Idee oder ist bei möglichen Updates irgendwas nicht richtig upgedatet worden?
Auch wurde die Zeile:
attr global httpcompress 0
eingefügt.
Danke für die Hilfe
Hallo,
die nicht zugewiesene Variable ist auf eine Nachlässigkeit in der Programmierung zurückzuführen. Bitte verschiebe im Code die Zeile 2573
$hash->{".fhem"}{t}= $t;
unmittelbar vor die Zeile 2567
if($errmsg or !defined($ics) or ("$ics" eq "") ) {
Das eigentliche Problem ist aber, dass er Deinen Kalender nicht lesen kann. Bitte gib bei Deiner Antwort einen aussagekräftigen Ausschnitt aus dem Log mit Verbosity 5 mit.
Viele Grüße
Boris
Hallo Herr Dr. Neubert
schonmal Danke für Ihre schnelle Hilfe.
Wie gesagt hatte die Installation im Juni mit Sicherung erstellt und diese nun wieder eingespielt.
Irgendwann habe ich die Calendar-Abfrage ohne Probleme aktiv gehabt aber ich finde den Weg dahin nicht mehr.
Ob ich was bei Nextcloud oder wo anders geändert habt habe ich leider nicht aufgeschrieben.
Die Nextcloud-Synchronisation mit anderen Systemen funktioniert.
Das Calendar-Update wurde vor dem Log durchgeführt.
vom eventMonitor:
2018-10-12 06:42:17.131 Calendar InformationenICAL reload
2018-10-12 06:42:17.955 Calendar InformationenICAL error (retrieval failed with HTTP response code 404)
2018-10-12 06:42:17.979 Calendar InformationenICAL error (no or empty data)
2018-10-12 06:42:18.139 ABFALL Informationen Keine Abholungen
2018-10-12 06:42:18.155 Calendar InformationenICAL triggered
2018-10-12 06:42:18.180 Calendar InformationenICAL nextWakeup: 2018-10-12 07:42:16
2018.10.12 06:42:17.825 1: Calendar InformationenICAL: retrieval failed with HTTP response code 404
2018.10.12 06:42:17.826 5: Starting notify loop for InformationenICAL, 1 event(s), first is error (retrieval failed with HTTP response code 404)
2018.10.12 06:42:17.826 5: createNotifyHash
...
2018.10.12 06:42:17.956 5: End notify loop for InformationenICAL
2018.10.12 06:42:17.957 5: Calendar InformationenICAL: HTTP response header:
HTTP/1.0 404 Not Found
Date: Fri, 12 Oct 2018 04:42:17 GMT
Server: Apache/2.4.25 (Raspbian)
Set-Cookie: ochievpguacq=ar39tn66chkd84rjrksres0np4; path=/nextcloud; secure; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: oc_sessionPassphrase=....; path=/nextcloud; secure; HttpOnly
Content-Security-Policy: default-src 'none';
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Robots-Tag: none
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
Set-Cookie: nc_sameSiteCookielax=true; path=/nextcloud; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
Set-Cookie: nc_sameSiteCookiestrict=true; path=/nextcloud; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
Set-Cookie: ochievpguacq=bratm04bdu9jr7pc7hv1lrkjn3; path=/nextcloud; secure; HttpOnly
Set-Cookie: cookie_test=test; expires=Fri, 12-Oct-2018 05:42:17 GMT; Max-Age=3600
Content-Length: 256
Connection: close
Content-Type: application/xml; charset=utf-8
2018.10.12 06:42:17.957 1: Calendar InformationenICAL: retrieved no or empty data
2018.10.12 06:42:17.957 5: Starting notify loop for InformationenICAL, 1 event(s), first is error (no or empty data)
2018.10.12 06:42:17.981 5: End notify loop for InformationenICAL
2018.10.12 06:42:17.981 4: Calendar InformationenICAL: Checking times...
2018.10.12 06:42:17.982 5: Starting notify loop for InformationenICAL, 1 event(s), first is triggered
2018.10.12 06:42:18.182 1: PERL WARNING: Use of uninitialized value $t in numeric lt (<) at ./FHEM/57_Calendar.pm line 2217.
2018.10.12 06:42:18.182 1: stacktrace:
2018.10.12 06:42:18.182 1: main::__ANON__ called by ./FHEM/57_Calendar.pm (2217)
2018.10.12 06:42:18.182 1: main::Calendar_RearmTimer called by ./FHEM/57_Calendar.pm (2602)
2018.10.12 06:42:18.183 1: main::Calendar_CheckAndRearm called by ./FHEM/57_Calendar.pm (2570)
2018.10.12 06:42:18.183 1: main::Calendar_ProcessUpdate called by FHEM/HttpUtils.pm (593)
2018.10.12 06:42:18.183 1: main::__ANON__ called by fhem.pl (723)
Bin leider nicht so erfahren mit Lunix oder Programmieren.
sonst hätte ich sicher mehr zwischen den Zeilen lesen und verstehen können.
Danke
Hallo,
das Problem steht hier:
2018-10-12 06:42:17.955 Calendar InformationenICAL error (retrieval failed with HTTP response code 404)
Unter der angegebenen URL lässt sich kein Kalender abrufen. Und ich weiß auch nicht, wie man das bei Nextcloud hinbekommt. Im Forum gab es - meine ich - dazu mal einen Beitrag - ggf. hilft die Suche oder ein neues Thema mit einer spezifischeren Frage.
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert am 12 Oktober 2018, 09:30:56
Und ich weiß auch nicht, wie man das bei Nextcloud hinbekommt.
Im Prinzip nix Ungewöhnliches...
Internals:
CFGFN
DEF ical url https://admin:admin@demo.nextcloud.com/wid0ohgh/remote.php/dav/calendars/admin/personal/?export
NAME nc
NOTIFYDEV global
NR 49
NTFY_ORDER 50-nc
STATE triggered
TYPE Calendar
Helper:
DBLOG:
calname:
dbLog:
TIME 1539344331.40983
VALUE Persönlich
lastUpdate:
dbLog:
TIME 1539344331.40983
VALUE 2018-10-12 13:38:51
modeAlarmOrStart:
dbLog:
TIME 1539344331.43644
VALUE A4DF7CSLG4KX8BC2FU3UH
modeEnd:
dbLog:
TIME 1539344295.81518
VALUE 0I8OHW5VT77OZZM32E81HO
modeStart:
dbLog:
TIME 1539344331.43644
VALUE A4DF7CSLG4KX8BC2FU3UH
nextUpdate:
dbLog:
TIME 1539344331.40983
VALUE 2018-10-12 14:38:51
nextWakeup:
dbLog:
TIME 1539344331.45718
VALUE 2018-10-12 14:38:51
state:
dbLog:
TIME 1539344331.43644
VALUE triggered
READINGS:
2018-10-12 13:38:51 calname Persönlich
2018-10-12 13:38:51 lastUpdate 2018-10-12 13:38:51
2018-10-12 13:35:26 modeAlarm
2018-10-12 13:38:51 modeAlarmOrStart A4DF7CSLG4KX8BC2FU3UH
2018-10-12 13:35:26 modeAlarmed
2018-10-12 13:35:26 modeChanged
2018-10-12 13:38:15 modeEnd 0I8OHW5VT77OZZM32E81HO
2018-10-12 13:35:26 modeEnded
2018-10-12 13:38:51 modeStart A4DF7CSLG4KX8BC2FU3UH
2018-10-12 13:35:26 modeStarted
2018-10-12 13:35:26 modeUpcoming
2018-10-12 13:38:51 nextUpdate 2018-10-12 14:38:51
2018-10-12 13:38:51 nextWakeup 2018-10-12 14:38:51
2018-10-12 13:38:51 state triggered
Attributes:
Dieser nc-Kalender wird sich in 60 Minuten selbst zerstören...
Servus,
also wenn diese Meldung keine Auswirkung hat:
2018.10.12 06:42:18.182 1: PERL WARNING: Use of uninitialized value $t in numeric lt (<) at ./FHEM/57_Calendar.pm line 2217.
2018.10.12 06:42:18.182 1: stacktrace:
2018.10.12 06:42:18.182 1: main::__ANON__ called by ./FHEM/57_Calendar.pm (2217)
2018.10.12 06:42:18.182 1: main::Calendar_RearmTimer called by ./FHEM/57_Calendar.pm (2602)
2018.10.12 06:42:18.183 1: main::Calendar_CheckAndRearm called by ./FHEM/57_Calendar.pm (2570)
2018.10.12 06:42:18.183 1: main::Calendar_ProcessUpdate called by FHEM/HttpUtils.pm (593)
2018.10.12 06:42:18.183 1: main::__ANON__ called by fhem.pl (723)
ist nun alles super.
Ich benötige wohl morgens doch einen Kaffee oder einfach Schicht-8-Fehler!!!
Zitat
das Problem steht hier:
Code: [Auswählen]
2018-10-12 06:42:17.955 Calendar InformationenICAL error (retrieval failed with HTTP response code 404)
Ich habe die Zeile gesehen und gelesen.Noch gedacht, dass 404 eigentlich immer bedeutet Seite nicht vorhanden
aber ich war fest davon überzeugt an der Nextcloud kann es nicht liegen.
Da ich bei der Nextcloud für jedes Gerät einen Benutzer angelegt habe,
funktionierten die Kalender auf alles Geräten außer auf dem Raspberry.
Die Kalender hatte ich vergessen auch für den Raspberry zu teilen >:(
Bitte dieses Thema schließen
Es gibt keinen Grund, das Thema zu schleßen.
Du könntest aber im ersten Beitrag hier einfach den Titel anpassen und ein (gelöst) davor schreiben.
Habe die Änderung aus meinem ersten Beitrag eingebaut und eingecheckt.
Bonus: Betateilchens Hinweis auf Nextcloud-Kalender ist jetzt in der Commandref.
Zitat von: betateilchen am 12 Oktober 2018, 13:43:11
Im Prinzip nix Ungewöhnliches...
Internals:
CFGFN
DEF ical url https://admin:admin@demo.nextcloud.com/wid0ohgh/remote.php/dav/calendars/admin/personal/?export
NAME nc
NOTIFYDEV global
NR 49
NTFY_ORDER 50-nc
STATE triggered
TYPE Calendar
Helper:
DBLOG:
calname:
dbLog:
TIME 1539344331.40983
VALUE Persönlich
lastUpdate:
dbLog:
TIME 1539344331.40983
VALUE 2018-10-12 13:38:51
modeAlarmOrStart:
dbLog:
TIME 1539344331.43644
VALUE A4DF7CSLG4KX8BC2FU3UH
modeEnd:
dbLog:
TIME 1539344295.81518
VALUE 0I8OHW5VT77OZZM32E81HO
modeStart:
dbLog:
TIME 1539344331.43644
VALUE A4DF7CSLG4KX8BC2FU3UH
nextUpdate:
dbLog:
TIME 1539344331.40983
VALUE 2018-10-12 14:38:51
nextWakeup:
dbLog:
TIME 1539344331.45718
VALUE 2018-10-12 14:38:51
state:
dbLog:
TIME 1539344331.43644
VALUE triggered
READINGS:
2018-10-12 13:38:51 calname Persönlich
2018-10-12 13:38:51 lastUpdate 2018-10-12 13:38:51
2018-10-12 13:35:26 modeAlarm
2018-10-12 13:38:51 modeAlarmOrStart A4DF7CSLG4KX8BC2FU3UH
2018-10-12 13:35:26 modeAlarmed
2018-10-12 13:35:26 modeChanged
2018-10-12 13:38:15 modeEnd 0I8OHW5VT77OZZM32E81HO
2018-10-12 13:35:26 modeEnded
2018-10-12 13:38:51 modeStart A4DF7CSLG4KX8BC2FU3UH
2018-10-12 13:35:26 modeStarted
2018-10-12 13:35:26 modeUpcoming
2018-10-12 13:38:51 nextUpdate 2018-10-12 14:38:51
2018-10-12 13:38:51 nextWakeup 2018-10-12 14:38:51
2018-10-12 13:38:51 state triggered
Attributes:
Dieser nc-Kalender wird sich in 60 Minuten selbst zerstören...
Hallo betateilchen,
ich wollte meinen nextcloud Kalender auch mal von file auf url umstellen.
ical url https://user:pass@server/remote.php/dav/calendars/sebastian/sebastian/?export
Allerdings bekomme ich einen Timeout in FHEM:
2018.11.19 09:29:41.901 1: Calendar test1: retrieval failed with error message read from https://<server>.co:443 timed out
2018.11.19 09:29:41.903 1: Calendar test1: retrieved no or empty data
Über einen Browser (Chrome) funktioniert der URL-Aufruf und der Export der .ics-Datei aber problemlos.
Hast du eine Idee, wie ich FHEM etwas geduldiger machen kann? Oder muss ich die Timeout-Einstellungen in nextcloud anfassen?
VG Sebastian
Zitatical url https://user:pass@server/remote.php/dav/calendars/sebastian/sebastian/?export
ist da ein Fehler in deiner URL? zum Ende muss es sebastian?export lauten. Ohne
/ dazwischen.
So habe ich das zumindest bei mir
Zitatist da ein Fehler in deiner URL? zum Ende muss es sebastian?export lauten. Ohne / dazwischen.
Wie gesagt, wenn ich dir url genauso in Chrome eingebe kommt nach etwa 30s die .ics-Datei zum Download.
Im Bsp. von betateilchen ist auch noch ein / vor dem ?export.
Ich probier es nochmal mit einem nahezu leeren Kalender...
VG Sebastian
Also mit einem fast leeren Kalender (2 Termine) funktioniert die url. :o
Internals:
DEF ical url https://user:pass@server/remote.php/dav/calendars/sebastian/fhemtest/?export
NAME test
NOTIFYDEV global
NR 28
NTFY_ORDER 50-test
STATE triggered
TYPE Calendar
READINGS:
2018-11-19 13:25:56 calname fhemtest
2018-11-19 13:25:56 lastUpdate 2018-11-19 13:25:56
2018-11-19 13:18:40 modeAlarm
2018-11-19 13:18:40 modeAlarmOrStart
2018-11-19 13:18:40 modeAlarmed
2018-11-19 13:18:40 modeChanged
2018-11-19 13:18:40 modeEnd
2018-11-19 13:18:40 modeEnded
2018-11-19 13:18:40 modeStart
2018-11-19 13:18:40 modeStarted
2018-11-19 13:25:56 modeUpcoming OJ4YH29H7ZOHAKFAYYJOSI;AKHMB5GHWNV3QJ7VNS50D
2018-11-19 13:25:56 nextUpdate 2018-12-01 03:12:35
2018-11-19 13:25:56 nextWakeup 2018-11-19 22:00:00
2018-11-19 13:25:56 state triggered
Attributes:
Scheint also wirklich in ein Timeout zu laufen. Versuche mal heute Abend weiter zu testen.
VG Sebastian
Hallo,
nachdem ich neulich dachte, ich hätte es nach tagelangem Lesen und Probieren hinbekommen, klappt der Zugriff auf einen (wie ich dachte) dann leistungsfähigen und https-gesicherten Server beim Provider leider nicht.
https://Testuser:passwort@privat.server.de/remote.php/dav/?export
https://Testuser:passwort@privat.server.de/remote.php/dav?export
Weder der Zugriff mit der angegebenen "Primären CalDAV-Adresse" mit / oder ohne /
noch der mit der iOS/macOS CalDAV-Adresse mit/ oder ohne bringt was.
https://Testuser:passwort@privat.server.de/remote.php/dav/principals/users/Testuser/?export
https://Testuser:passwort@privat.server.de/remote.php/dav/principals/users/Testuser?export
Nextcloud ist Version 15.
Ich hab Forum gelesen, commandref und alle mir einfallenden Szenarien durch ... Bin für jeden Tipp dankbar.
Zitat von: fstefan1960 am 15 Februar 2019, 11:31:16
Hallo,
nachdem ich neulich dachte, ich hätte es nach tagelangem Lesen und Probieren hinbekommen, klappt der Zugriff auf einen (wie ich dachte) dann leistungsfähigen und https-gesicherten Server beim Provider leider nicht.
https://Testuser:passwort@privat.server.de/remote.php/dav/?export
https://Testuser:passwort@privat.server.de/remote.php/dav?export
Weder der Zugriff mit der angegebenen "Primären CalDAV-Adresse" mit / oder ohne /
noch der mit der iOS/macOS CalDAV-Adresse mit/ oder ohne bringt was.
https://Testuser:passwort@privat.server.de/remote.php/dav/principals/users/Testuser/?export
https://Testuser:passwort@privat.server.de/remote.php/dav/principals/users/Testuser?export
Nextcloud ist Version 15.
Ich hab Forum gelesen, commandref und alle mir einfallenden Szenarien durch ... Bin für jeden Tipp dankbar.
Und wie siehts hiermit aus:
https://Testuser:passwort@privat.server.de/remote.php/dav/calendars/Testuser/Kalendername/?export
So komme ich auf meinen nextcloud Server (15.04) drauf...
VG Sebastian
Das Problem ist, dass das Calendar Modul keine webdav Implementierung besitzt (was für die korrekte Funktion aber auch nicht erforderlich ist)
Deshalb können diese url
https://privat.server.de/remote.php/dav/
https://privat.server.de/remote.php/dav/principals/users/Testuser/
aus technischen Gründen nicht funktionieren. Solche Adressen werden normalerweise in einer mehrstufigen Verarbeitung zur endgültigen url
https://privat.server.de/remote.php/dav/calendars/Testuser/
aufgelöst. Im Log des webservers sieht das Ganze so aus:
[15/Feb/2019:16:33:14 +0100] "PROPFIND /remote.php/dav/principals/users/udo/ HTTP/1.1" 207 5298 "-"
[15/Feb/2019:16:33:14 +0100] "PROPFIND /remote.php/dav/principals/groups/shared/ HTTP/1.1" 207 1540 "-"
[15/Feb/2019:16:33:15 +0100] "PROPFIND /remote.php/dav/calendars/udo/ HTTP/1.1" 207 14513 "-"
In der letzten Antwort (die mit den 14513 Bytes) hast Du direkt das nächste Problem: Es kommt als Antwort eine xml-Datei mit der Liste der verfügbaren Kalender zurück.
Erst mit einer vollständigen webdav Implementierung können dann die in der xml-Datei gefundenen vier einzelnen Kalender ausgelesen werden:
[15/Feb/2019:16:35:50 +0100] "PROPFIND /remote.php/dav/calendars/udo/personal/ HTTP/1.1" 207 5945 "-"
[15/Feb/2019:16:35:51 +0100] "REPORT /remote.php/dav/calendars/udo/personal/ HTTP/1.1" 207 4356 "-"
[15/Feb/2019:16:35:52 +0100] "PROPFIND /remote.php/dav/calendars/udo/reisen/ HTTP/1.1" 207 5951 "-"
[15/Feb/2019:16:35:53 +0100] "REPORT /remote.php/dav/calendars/udo/reisen/ HTTP/1.1" 207 10791 "-"
[15/Feb/2019:16:35:55 +0100] "PROPFIND /remote.php/dav/calendars/udo/dienstplan/ HTTP/1.1" 207 5943 "-"
[15/Feb/2019:16:35:56 +0100] "REPORT /remote.php/dav/calendars/udo/dienstplan/ HTTP/1.1" 207 5994 "-"
[15/Feb/2019:16:35:57 +0100] "PROPFIND /remote.php/dav/calendars/udo/events/ HTTP/1.1" 207 5935 "-"
[15/Feb/2019:16:35:58 +0100] "REPORT /remote.php/dav/calendars/udo/events/ HTTP/1.1" 207 4598 "-"
Aus diesem Grund muss im Calendar device in FHEM immer die vollständige url inklusive des Kalendernamens angegeben werden, so wie von binford6000 vorgeschlagen.
@Boris: vielleicht sollten wir mal eine webdav Implementierung für 57_Calender.pm bauen 8)
define myCal Calendar webdav url https://...
und damit werden dann alle gefundenen Kalender auf dem webdav Server automatisch in FHEM angelegt.
Zitat von: betateilchen am 15 Februar 2019, 16:42:44
@Boris: vielleicht sollten wir mal eine webdav Implementierung für 57_Calender.pm bauen 8)
define myCal Calendar webdav url https://...
und damit werden dann alle gefundenen Kalender auf dem webdav Server automatisch in FHEM angelegt.
Gerne Udo, weißt Du wie das geht? Wäre der WebDAV-Layer nicht was für in die HttpUtils?
Ich wollte schon immer ein Kalendermodul, wo mehr als ein Kalender in einem Device sind.
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert am 15 Februar 2019, 17:19:07
Gerne Udo, weißt Du wie das geht?
jetzt bloss nix Falsches sagen... *auf-die Zunge-beiss*
Kommst Du zum Treffen nach Karlsruhe?
Hallo,
Aus diesem Grund muss im Calendar device in FHEM immer die vollständige url inklusive des Kalendernamens angegeben werden, so wie von binford6000 vorgeschlagen.
Das will ich ja gerne. Aber wie finde ich die "vollständige URL" heraus, wenn es doch offenbar keine der angegebenen ist?
In den hier hin und her gehandelten Beispielen stehen ja immer Platzhalter. Natürlich bringt https://admin.admin@ zum Beispiel bei mir ja nichts, weil mein User ja nicht admin heißt und schon gar nicht das Passwort admin hat. Meine Domain heißt natürlich auch nicht privat.domain.de. Ist doch selbstverständlich, dass hier Ersatztexte stehen.
Und wie weiß ich jetzt, welche Teile der URL
https://Testuser:passwort@privat.server.de/remote.php/dav/calendars/Testuser/Kalendername/?export
Platzhalter sind und welche tatsächlich rein müssen?
Da müsste doch dann irgendwie stehen
https://<username>:<passwort>@<subdomain.domain.tld>/remote.php/<protokoll>/<???>/<username>/<???>/?export
oder so ...
Irgendwie scheinen Teile ja individuell von der Installation abhängige Teile zu sein (wie Username und Passwort) und andere irgendwoher zu kommen, wozu ich keine Doku finde ....
Hier ist in der Dokumentation m.E. noch Luft nach oben ...
Ich teste mal weiter ...
Mach doch nicht alles so kompliziert, Du bist bisher offenbar der Einzige, der das nicht verstanden hat.
gegeben sei:
Username = blaUser
Passwort = blaPasswort
url = mein.kalenderserver.de
Kalendername = Dienstplan
daraus ergibt sich folgende url:
https://blaUser:blaPasswort@mein.kalenderserver.de/remote.php/dav/calendars/blaUser/dienstplan/?export
Achtung: Der Name des Kalenders in Kleinbuchstaben ist kein Schreibfehler von mir!
Vielen Dank
Zitat von: Dr. Boris Neubert am 15 Februar 2019, 17:19:07
Ich wollte schon immer ein Kalendermodul, wo mehr als ein Kalender in einem Device sind.
warum?? hat das vorteile??
ich bin bisher jedenfalls so zufrieden wie es ist :)
evtl. sehe ich nur den anwendungsfall nicht, darum die frage....
Zitat von: betateilchen am 15 Februar 2019, 19:28:10
jetzt bloss nix Falsches sagen... *auf-die Zunge-beiss*
zunge noch dran?? ;D ;D ;D
Hi,
Zitat von: nils_ am 20 Februar 2019, 13:00:54
warum?? hat das vorteile??
evtl. sehe ich nur den anwendungsfall nicht, darum die frage....
ich habe einen persönlichen Kalender bei Google und einen Familienkalender. Und ich will in meinem RSS-Frame die Termine aus beiden angezeigt bekommen.
Grüße
Boris
Zitat von: Dr. Boris Neubert am 20 Februar 2019, 20:57:48
ich habe einen persönlichen Kalender bei Google und einen Familienkalender. Und ich will in meinem RSS-Frame die Termine aus beiden angezeigt bekommen.
und das funktioniert nur aus einem calendar device??
dann bräuchten wir dafür einen Termin-Merger 8)
Zitat von: nils_ am 21 Februar 2019, 09:07:06
dann bräuchten wir dafür einen Termin-Merger 8)
Ich lese die Termine aus dem einem Kalender, lese die Termine aus dem anderen Kalender. Fertig. Muss ich "nur" programmieren in 57_Calendar.
define calendarDevice ical url "https://path_to_first_calender"
attr <calendarDevice> add "https://path_to_another_calendar"
und das "attr ... add" kann beliebig oft ausgeführt werden eine Liste von weiteren URLs enthalten.
Warum attr und nicht set? Weil attr beim "save config" mit gespeichert wird.
Zitat von: betateilchen am 21 Februar 2019, 20:42:12
define calendarDevice ical url "https://path_to_first_calender"
attr <calendarDevice> add "https://path_to_another_calendar"
und das "attr ... add" kann beliebig oft ausgeführt werden eine Liste von weiteren URLs enthalten.
Warum attr und nicht set? Weil attr beim "save config" mit gespeichert wird.
Das mit dem attr ist absolut korrekt!
Ich würde allerdings lieber den Teil
ical url "https://path_to_first_calender"
im define optional machen und mit
attr <calendarDevice> calendar ical url https://path_to_first_calendar;ical url https://path_to_another_calendar;ical file /path/to/third_calendar
arbeiten oder den semikolongetrennten Sermon gleich im Define erlauben.
Hinweis: ical ist Noise, aber vielleicht lesen wir ja eines Tages noch andere Formate (z.B. eine schlichte CSV-Datei), und Typ ist zwingend.
Zitat von: Dr. Boris Neubert am 21 Februar 2019, 20:47:33
Ich würde allerdings lieber den Teil ... im define optional machen und mit
Zitat von: Dr. Boris Neubert am 21 Februar 2019, 20:47:33
oder den semikolongetrennten Sermon gleich im Define erlauben.
Das Problem ist, dass bereits das Intervall ein optionaler Parameter ist und am Ende des define steht. Eine erste URL im Define mitgeben zu müssen, fände ich jetzt nicht so schlimm. Das im define angegebene (optionale) Intervall wird dann für alle Kalender verwendet.
Zitat von: Dr. Boris Neubert am 21 Februar 2019, 20:47:33
Hinweis: ical ist Noise, aber vielleicht lesen wir ja eines Tages noch andere Formate (z.B. eine schlichte CSV-Datei), und Typ ist zwingend.
Dann müssen wir aber die komplette Verwaltung der Internals (format / type / url) auf einen hash umbauen. Meine Idee war, dass alle Kalender in einem Sammelkalender vom gleichen Typ und Format sein müssen.