2013.09.19 14:38:34 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:38:35 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:38:35 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:38:37 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:38:38 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:38:39 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:38:46 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:38:47 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:38:48 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:38:59 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:39:01 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:39:01 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:39:02 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:39:05 1: Calendar Kalender_Heizung: Not an ical file at URL
im angeblich nicht vorhandenen ical File steht folgendes:
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALNAME:FHEM_Heizung
X-WR-TIMEZONE:Europe/Berlin
X-WR-CALDESC:
BEGIN:VEVENT
DTSTART:20130919T130000Z
DTEND:20130919T200000Z
DTSTAMP:20130919T124351Z
UID:l04dplufsvk2rvo58c578vdh8k@google.com
CREATED:20130919T122822Z
DESCRIPTION:
LAST-MODIFIED:20130919T122822Z
LOCATION:22
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:wz_FHT_Climate
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR
Frage 1: Was geht da grundsätzlich schief?
Frage 2: Warum kommen die Fehlermeldungen im Sekundentakt und nicht im Intervall, das im define angegeben ist?
Frage 3: Warum hat das Ganze wochenlang ohne Fehlermeldung funktioniert und tut es jetzt nicht mehr (ich habe nichts geändert!) ?
Frage 4: Warum funktioniert das Ganze ohne jegliche Änderung in ca. 1 von 100 Fällen ohne Fehlermeldung?
Zitat von: betateilchen schrieb am Do, 19 September 2013 14:462013.09.19 14:38:34 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:38:35 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:38:35 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:38:37 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:38:38 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:38:39 1: Calendar Kalender_Heizung: Not an ical file at URL
2013.09.19 14:38:46 1: Calendar Kalender_Heizung: Not an ical file at URL
Frage 1: Was geht da grundsätzlich schief?
Das habe ich auch. Google hat vielleicht was geändert. Da hilft nur Debug. Bin dafür aber erst nächste Woche wieder am Rechner. Sachdienliche Hinweise nehme ich gerne entgegen.
Grüße
Boris
Ich bin schon dran.
Das Schwierige bei der Suche ist, dass es "manchmal" einfach funktioniert. Sehr mysteriös.
Das Schalten funktioniert auch nicht mehr, selbst dann nicht, wenn die Einträge mit "get <kalender> text all" korrekt angezeigt werden.
Meine Vermutung geht aktuell dahin, dass es mit einem permanenten Redirect zu tun hat, der bei Verwendung der privaten ICAL Adresse auftritt.
Wo wir grade dabei sind - ich hätte gerne das Modul um die Möglichkeit erweitert, bei
get <kalenderDevice> text all
einen zusätzlichen optionalen Parameter zur Angabe der maximalen Listlänge bei der Ausgabe mitzugeben.
Also in der Art
get <kalenderDevice> text all 4
um maximal die nächsten 4 Einträge zu bekommen.
Hintergrund ist, dass ich die Ausgabe in einer RSS Generierung brauche und dort maximal vier Zeilen Platz habe.
Hierzu hab ich auch schon einen funktionierenden Patch :)
Index: 57_Calendar.pm
===================================================================
--- 57_Calendar.pm (Revision 3932)
+++ 57_Calendar.pm (Arbeitskopie)
@@ -888,7 +888,7 @@
my $cmd= $a[1];
if(grep(/^$cmd$/, ("text","full","summary","location","alarm","start","end"))) {
- return "argument is missing" if($#a != 2);
+ return "argument is missing" if($#a < 2);
my $reading= $a[2];
# $reading is alarmed, all, changed, deleted, new, started, updated
@@ -912,7 +912,8 @@
push @texts, $event->startTime() if $cmd eq "start";
push @texts, $event->endTime() if $cmd eq "end";
}
- }
+ }
+ splice @texts,$a[3] if($a[3]);
return join("\n", @texts);
} elsif($cmd eq "find") {
Also bei mir funktioniert es noch.
Welche Adresse vom Google Kalender habt ihr denn in FHEM in der Def angegeben? Die private oder die public?
Ich habe die private mit https bei mir drin. Und das auch ohne irgendetwas nachzuinstallieren zwecks HTTPS.
Gruß
Christian
wie oben schon steht: die private ICAL Adresse. Und es funktioniert bei mir weder mit http noch mit https
Das Problem stellt sich technisch im Moment so dar:
Ich habe ein zusätzliches Logging eingebaut, um das Ergebnis des GetFileFromUrlQuiet aufzuzeichnen.
Im Log ist dann zu erkennen, dass $ics in vielen Fällen keinen Inhalt hat.
Aber irgendwann ist dann der Inhalt plötzlich wieder vorhanden.
2013.09.20 22:13:14 1: URL: https://www.google.com/calendar/ical/...%40group.calendar.google.com/private-.../basic.ics
ICS:
2013.09.20 22:13:14 1: Calendar Kalender_Schalter: Not an ical file at URL
2013.09.20 22:13:25 1: URL: https://www.google.com/calendar/ical/...%40group.calendar.google.com/private-.../basic.ics
ICS: BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALNAME:FHEM_Schalter
X-WR-TIMEZONE:Europe/Berlin
X-WR-CALDESC:
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
...
END:VEVENT
END:VCALENDAR
2013.09.20 22:13:26 1: URL: https://www.google.com/calendar/ical/...%40group.calendar.google.com/private-.../basic.ics
ICS:
2013.09.20 22:13:26 1: Calendar Kalender_Schalter: Not an ical file at URL
Warum wird beim GetFile... eigentlich das im Define angegebene Intervall (bei mir 600 Sekunden) von fhem komplett ignoriert?
Kann bitte jemand von den "Betroffenen" die hier angehängte Modulversion testen?
Bei mir herrscht damit wieder Ruhe im Logfile.
@Boris: weitere Infos siehe email
---
Zitat von: betateilchen schrieb am Fr, 20 September 2013 22:52Kann bitte jemand von den "Betroffenen" die hier angehängte Modulversion testen?
Bei mir herrscht damit wieder Ruhe im Logfile.
---
Ja, hat für mich auch funktioniert. Vielen Dank dafür!
im Moment grüble ich noch darüber, warum es Einträge mit und ohne googlecom im Inhalt gibt, meine notifies zum Ein- und Ausschalten triggern (auch) auf googlecom und das hat bisher auch prima funktioniert...
Readings: 2013-09-21 21:26:12 all
04h852mvhv0s2hfjh6di8jgmpkgooglecom;
67532BD3AF6A4CC8975BF58034E3BF93;
6m5tln2if86pg6l5tg61um119kgooglecom;
Meine Vermutung: Das passiert bei Kalendereinträgen, die nicht direkt in Google erstellt wurden, sondern z.B. im Kalenderprogramm von Mac OS und dann später synchronisiert werden. Der Sache muss ich mal nachgehen.
-----
EDIT: DEFINITV - die Ursache liegt in außerhalb von google erstellten Kalendereinträgen. Und ich hab mich die ganze Zeit gewundert, warum die Heizung vom Wasserbett dieses Wochenende nicht läuft...
----
Hallo,
das Problem war, daß Google mit einem "301 moved permanently" auf die "http"-URL reagiert. Ich habe das Problem dahingehend gelöst, daß CustomGetFileFromURL() in HttpUtils.pm nun darauf reagiert und der Umleitung folgt.
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert schrieb am So, 22 September 2013 19:58das Problem war, daß Google mit einem "301 moved permanently" auf die "http"-URL reagiert.
Danke für die Bestätigung.
Zitat von: betateilchenMeine Vermutung geht aktuell dahin, dass es mit einem permanenten Redirect zu tun hat, der bei Verwendung der privaten ICAL Adresse auftritt.
Für mich stellen sich aber immer noch zwei Fragen:
1. wieso hat es manchmal funktioniert, ohne einen Fehler zu produzieren?
2. wieso trat der Fehler bei mir auch bei Verwendung der direkten https-URL, die ich der redirect-Message entnommen hatte, auf?
Ich gebe zu, ich mag die HttpUtils nicht, weil die mir immer wieder an den verschiedensten Stellen in fhem Probleme machen.
Da wir hier grade aktuell über das Kalendermodul diskutieren, hänge ich die Frage aus einem anderen Bereich einfach mal hier dran:
Zitat von: gagga schrieb am Mo, 23 September 2013 23:34Unterstützt das Kalender Modul file:// URLs? Ich frage, weil ich fhem auf einem System betreibe, wo ich nicht so einfach SSLeavy für https URLs installieren kann...
Ciao,
Gagga
Teste mal bitte die hier angehängte Modulversion, da habe ich versucht, Deine Anforderung umzusetzen.
1. Lade das ics-File aus dem Google Kalender auf Deine Festplatte
2. Achtung - geänderte Syntax für Calender
define testKalender Calendar ical file c:/basic.icsEntscheidend ist das Schlüsselwort file anstatt url zu verwenden und den Pfad zur Datei anzugeben.
Wenn Du Deine Erfahrungen hier postest und der Modulverantwortliche (Boris) die vorgeschlagene Änderung auch gutheisst, denke ich schon, dass es kurzfristig in den Standard übernommen werden kann.
Zitat von: betateilchen schrieb am Di, 24 September 2013 10:10Entscheidend ist das Schlüsselwort file anstatt url zu verwenden und den Pfad zur Datei anzugeben.
Dokumentiert und mit Anpassungen eingecheckt!
Boris
Zitat von: betateilchen schrieb am So, 22 September 2013 20:57Ich gebe zu, ich mag die HttpUtils nicht, weil die mir immer wieder an den verschiedensten Stellen in fhem Probleme machen.
Rudi und ich legen Wert darauf, möglichst wenig Abhängigkeiten zu Perl-Modulen von Dritten zu schaffen. Daher bevorzugen wir den einen oder anderen Eigenbau.
Begründung:
- LWP::UserAgent zieht einen Rattenschwanz von Abhängigkeiten nach sich, die nicht alle in Lib mitgeliefert werden können.
- Es gibt Systeme, wo diese Module nicht standardmäßig installiert sind und die Nachinstallation einer Vielzahl von Anwendern nicht zugemutet werden kann.
- FHEM soll auch auf kleinen Systemen laufen und deswegen sparen wir Hauptspeicher, wo es nur geht.
- Weniger Abhängigkeiten => einfachere Fehlersuche und -behebung, weil wir nur eigenen Code warten müssen.
Es gibt auch Gründe, die für die Verwendung von Drittmodulen sprechen. Ich möchte an dieser Stelle jetzt keine Diskussion beginnen. Die Hürde, Abhängigkeiten zu anderen Drittmodulen zu schaffen, ist sehr hoch.
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert schrieb am Di, 24 September 2013 19:46Begründung:
- LWP::UserAgent zieht einen Rattenschwanz von Abhängigkeiten nach sich, die nicht alle in Lib mitgeliefert werden können.
- Es gibt Systeme, wo diese Module nicht standardmäßig installiert sind
Immerhin ist LWP::ua sogar auf der (in solchen Fragen immer wieder gerne als Negativreferenz zur Begründung ins Feld geführte) Fritzkotz vorhanden, deshalb habe ich überhaupt keine Hemmungen, diesen Vorteil in meinen Wettermodulen zu nutzen.
Eine Grundsatzdiskussion wollte ich auch nicht anfangen, ich wollte einfach nur rausfinden, warum man sich so sehr an diese ... HttpUtils klammert.
Danke für die Auskunft.
------------------------
Edit:
Hier mal spaßeshalber die Liste der Perl-Module, die ich bei mir - ausgehend von einer Debian Standardinstallation - bisher nachinstallieren musste:
# für GDS und openweathermap
sudo apt-get install libxml-simple-perl
# für GDS
sudo apt-get install libtext-csv-perl
sudo apt-get install liblist-moreutils-perl
# für openweathermap
sudo apt-get install libjson-perl (optional)
# für RSS
sudo apt-get install libgd-gd2-perl
Ich finde das durchaus überschaubar, wenn ich mir überlege, was ich alles an defines im System habe.
Zitat von: Dr. Boris Neubert schrieb am Di, 24 September 2013 19:39Dokumentiert und mit Anpassungen eingecheckt!
Boris
if($type eq "url"){
$ics= GetFileFromURLQuiet($url) if($type eq "url");
}
ein
if ($type eq "url") ist doppelt, das müssen wir abziehen :)
Hi,
gerade update gemacht, seitdem im log:
2013.09.26 12:48:23.061 1: Attempt to reload IO/Socket/SSL.pm aborted.
Compilation failed in require at (eval 335) line 2.
BEGIN failed--compilation aborted at (eval 335) line 2.
2013.09.26 12:48:23.448 1: Attempt to reload IO/Socket/SSL.pm aborted.
Compilation failed in require at (eval 336) line 2.
BEGIN failed--compilation aborted at (eval 336) line 2.
2013.09.26 12:48:24.702 1: Attempt to reload IO/Socket/SSL.pm aborted.
Compilation failed in require at (eval 337) line 2.
BEGIN failed--compilation aborted at (eval 337) line 2.
2013.09.26 12:48:30.065 1: Attempt to reload IO/Socket/SSL.pm aborted.
Compilation failed in require at (eval 338) line 2.
BEGIN failed--compilation aborted at (eval 338) line 2.
2013.09.26 12:48:36.570 1: Attempt to reload IO/Socket/SSL.pm aborted.
Compilation failed in require at (eval 340) line 2.
BEGIN failed--compilation aborted at (eval 340) line 2.
2013.09.26 12:48:39.885 1: Attempt to reload IO/Socket/SSL.pm aborted.
Compilation failed in require at (eval 341) line 2.
BEGIN failed--compilation aborted at (eval 341) line 2.
2013.09.26 12:48:43.128 1: Attempt to reload IO/Socket/SSL.pm aborted.
Compilation failed in require at (eval 342) line 2.
BEGIN failed--compilation aborted at (eval 342) line 2.
2013.09.26 12:48:44.072 1: Attempt to reload IO/Socket/SSL.pm aborted.
Compilation failed in require at (eval 343) line 2.
BEGIN failed--compilation aborted at (eval 343) line 2.
Auf einer Fritzbox.
Wie man sieht, wird das logfile kräftig zugemüllt.
FB kennt kein cpan, also kann ich nix nachinstallieren.
Was nun?
Gruß, Uli
Ich kann Dir einen patch schicken, den Du testen kannst, wenn Du das möchtest.
Hi,
na gerne doch :)
Nach Neustart der Fritte kommen übrigens die ständigen IO/Socket/SSL nicht mehr,
stattdessen nach Neustart nur einmalig im log
Can't locate Net/SSLeay.pm in @INC
=8-)
probier mal ob die tut :)
Hi,
geht leider nicht.
Hab die Datei in mehrere Verzeichnisse kopiert, die alle in @INC liegen.
Trotz Neustarts die Meldung:
Can't locate Net/SSLeay.pm
Das blöde ist, dass nun mein Produktivsystem nicht startet :(
Weisst Du, in welchem fhem-Programm die relevante Änderung liegt?
Sonst muss ich erst mal mein backup zurückspielen...
Gruß, Uli
Hi,
da sich fhem starten lässt, wenn ich statt GetFileFromURLQuiet über LWP::UserAgent gehe (danke an Udo für den fix), liegt's wohl an der Änderung in HttpUtils.
Da FB-user damit ihr fhem nicht starten können, sollte hier dringend ein fix ins update gehen.
Gruß, Uli
Zitat von: UliM schrieb am Do, 26 September 2013 15:32wenn ich statt ... über LWP::UserAgent gehe
au weia, er hat das böse Wort gesagt...
Zitat von: betateilchen schrieb am Do, 26 September 2013 16:00Zitat von: UliM schrieb am Do, 26 September 2013 15:32wenn ich statt ... über LWP::UserAgent gehe
au weia, er hat das böse Wort gesagt...
:->>
Uli, die URL vom Gugel-Kalender macht einen Redirect auf die
https://-Seite. Mangels SSL kannst Du die nicht laden. Daß Du überhaupt zur
https://-Seite kommst, ist einer Erweiterung von mir in den HttpUtils zu verdanken, welche dafür sorgt, daß Redirects gefolgt werden. Wäre das nicht so, bekämst Du beim Calendar massenweise Fehlermeldungen. Also: Pest oder Cholera.
Laßt uns bitte Gegenmaßnahmen im Developer-Forum diskutieren, weil es sich hierbei nicht um ein Calendar-Thema handelt.
Grüße
Boris
Zitat von: Dr. Boris Neubert schrieb am Fr, 27 September 2013 20:28Laßt uns bitte Gegenmaßnahmen im Developer-Forum diskutieren
ich hol schonmal das Popcorn, wird bestimmt lustig...
ZitatDaß Du überhaupt zur https://-Seite kommst, ist einer Erweiterung von mir in den HttpUtils zu verdanken,
Das hast Du falsch verstanden. Mit Deiner Erweiterung (der HttpUtils) kann Uli sein fhem überhaupt nicht mehr starten.
Hallo,
ich benutze das Calendar Modul erfolgreich seit über einen Jahr auf der Fritzbox (ohne Nachinstallationen) und würde es sehr begrüssen, wenn eine zukünftige Lösung dies auch wieder ermöglichen könnte. Das Calendar Modul stellt aus meiner Sicht eine ideale Schnittstelle zwischen verschiedenen "Domainen" (Home/Work/Verein) dar. Dank des Kalenders ist es möglich die verschiedenen Termine für alle Bewohner den FHEM (auf der FB) in einheitlicher Form zu Verfügung zu stellen. Dies hat sich für die Einbeziehung von Urlaub, Dienstreise, Sport und den täglicher Feierabend in die "Hausautomatisierung" gut bewährt.
Hoffentlich findet ihr eine Lösung im Development Forum. Vielen Dank im Voraus und last mich bitte wissen, ob ich was testen kann/soll.
Andreas
Hallo Boris!
Ich habe da noch zwei offene Fragen zum Kalender:
1. Wann löscht 57_Calendar eigentlich abgelaufene Einträge?
Ich bekomme bei "get <name> full all" regelmäßig abgelaufene Einträge mit angezeigt. Irgendwann verschwinden die aber.
Kurioserweise werden die Einträge auch noch nach eine Aktualisierung angezeigt, wenn sie bei Google bereits gelöscht sind, die Anzeige muss also irgendwoher aus fhem kommen.
2. Könnte man bei der Ausgabe "text" die Location mit ausgegeben?
VIele Grüße
Udo
get <name> full all
nmf8sk2lo80fvl7ps0gingvmdkgooglecom deleted end 28.09.2013 23:50:00-28.09.2013 23:55:00 wz_FHT 22
92DD2931B54141D5A950A6E538C84AF3 known start 29.09.2013 08:30:00-29.09.2013 22:00:00 wz_FHT 21
E6ECC5FF90894CDAA7E85472B9F5316F new start 29.09.2013 14:15:00-29.09.2013 15:20:00 wz_Test 17
tgqdr25md5ofieqktv0quibeh8googlecom known upcoming 30.09.2013 18:00:00-30.09.2013 22:00:00 wz_FHT 21
j7dpq50atu6e9lt0g5vu2n4stsgooglecom known upcoming 01.10.2013 18:00:00-01.10.2013 22:00:00 wz_FHT 21
d71ji3h02423f9358n0ttofk74googlecom known upcoming 02.10.2013 18:00:00-02.10.2013 22:00:00 wz_FHT 22
0d3dctbi41l6rpivq3ec2dn744googlecom known upcoming 06.10.2013 19:00:00-06.10.2013 22:00:00 wz_FHT 21
DB8D9212BF034A27A3836166A9B1F53F known upcoming 09.10.2013 18:00:00-09.10.2013 22:00:00 wz_FHT 21
lufpbhe37dcftuk4jlffj8p6h0googlecom known upcoming 10.10.2013 18:00:00-10.10.2013 22:00:00 wz_FHT 21
uhpvef08l3q28kj7cr5ora1nokgooglecom known upcoming 11.10.2013 18:00:00-11.10.2013 22:00:00 wz_FHT 21
pgjgivplvimcnebitp2n5e13kcgooglecom known upcoming 12.10.2013 08:30:00-12.10.2013 22:00:00 wz_FHT 21
get <name> text all
28.09.13 23:50 wz_FHT
29.09.13 08:30 wz_FHT
29.09.13 14:15 wz_Test 17
30.09.13 18:00 wz_FHT
01.10.13 18:00 wz_FHT
02.10.13 18:00 wz_FHT
06.10.13 19:00 wz_FHT
09.10.13 18:00 wz_FHT
10.10.13 18:00 wz_FHT
11.10.13 18:00 wz_FHT
12.10.13 08:30 wz_FHT
(bei wz_Test steht die 17 in summary, in allen anderen Einträgen in location)
---
Hallo Andreas,
Zitat von: wfas303 schrieb am So, 29 September 2013 14:20Hoffentlich findet ihr eine Lösung im Development Forum. Vielen Dank im Voraus und last mich bitte wissen, ob ich was testen kann/soll.
das Kalendermodul funktioniert ja weiterhin. Das Problem liegt im Herunterladen der ICal-Datei, wenn diese von Google nur via HTTPS angeboten wird. Das Herunterladen machen wir in
HttpUtils.pm und es gibt dort noch keine allgemein anerkannte Lösung, die auf allen Plattformen out-of-the-box läuft. Wir arbeiten daran.
Hilft Dir solange die Lösung von Udo (betateilchen)?
Grüße
Boris
Hallo Udo,
Zitat von: betateilchen schrieb am So, 29 September 2013 14:231. Wann löscht 57_Calendar eigentlich abgelaufene Einträge?
Ich meine, daß beim ersten Update nach dem Löschen/Ablaufen der Eintrag als "deleted" markiert wird (damit man auf dieses Ereignis reagieren kann) und daß deleted-Einträge dann beim nächsten Update aus der Liste entfernt werden.
Zitat2. Könnte man bei der Ausgabe "text" die Location mit ausgegeben?
Was hältst Du von einer superduperselbstkonfigurierbaren Lösung?
attr myCalendar customFormat uid,summary,location
get myCalendar all custom
Viele Grüße
Boris
Hallo Boris,
Zitat von: Dr. Boris Neubert schrieb am So, 29 September 2013 16:32Ich meine, daß beim ersten Update nach dem Löschen/Ablaufen der Eintrag als "deleted" markiert wird (damit man auf dieses Ereignis reagieren kann) und daß deleted-Einträge dann beim nächsten Update aus der Liste entfernt werden.
Das mit dem "deleted" ist korrekt, der zweite Teil nicht. Da mein Kalender alle 3600 Sekunden aktualisiert wird, hätte der Eintrag von gestern abend 23:50 Uhr heute mittag schon längst verschwunden sein müssen.
Zitat von: Dr. Boris Neubert schrieb am So, 29 September 2013 16:32Was hältst Du von einer superduperselbstkonfigurierbaren Lösung?
Geniale Idee. Am besten mit freiem Zugriff auf alle Parameter :)
Und bitte mit
get myCalendar all custom MAXViele Grüße
Udo
Danke. Das mit "file" geht problemlos.
Hiho,
wollte noch kurz vermelden, dass Calendar.pm nun in der per update ausgelieferten Version auch bei mir problemlos läuft, nachdem ich die perl-Distribution auf meiner FB aktualisiert habe (siehe hier (http://forum.fhem.de/index.php?topic=15012.0) ).
Gruß, Uli
in Deinem "hier" Link fehlt ein Doppelpunkt.
Zitat von: betateilchen schrieb am Di, 01 Oktober 2013 10:19in Deinem "hier" Link fehlt ein Doppelpunkt.
Jetzt nicht mehr :)
Ich habe einen Kalendereintrag-Zombie...
Das ist ein Termin, der im Google-Kalender gelöscht wurde, nachdem fhem ihn ausgelesen hatte, aber bevor er zur Ausführung kam. Das kann das Calendar-Modul irgendwie überhaupt nicht handhaben.
Hallo Ulli,
das Wochenende (incl schlechten Wetter) naht und damit wohl ein Update für FHEM vor der Heizsaison.
Wenn ich Rudi und dich richtig verstanden habe muss ich den obigen Schritten folgen um mein System nicht komplett zu verlieren.
Also 5.5 image herunterladen
2 mal auspacken
Dateien und Verzeichnis auf Fritzbox austauschen
Danach geht auch das mir wichtige Calender-Modul wieder :)
Eine Frage noch : Sollte man vorher oder erst nachher ein "update" durchführen ?
Und was mache ich mit FHEM.cfg ?
Danke
Andreas
Hi,
update betrifft ja nur fhem, nicht Perl. Ub Du also vorher oder nachher ein update machst ist wurscht. Ich würde es zeitlich entzerren (also mind. 1 Tag zwischen dem einen und dem anderen update), damit man bei evtl. Fehlern die Ursache leichter eingrenzen kann.
Im Zweifelsfall würd ich zuerst das Perl-update machen.
Gruß, Uli
Hallo Uli,
danke für den Ratschlag. Ich bin , wie oben von Rudi beschrieben, vorgegangen und es hat prima geklappt.
Die Fehlermeldungen scheinen verschwunden zu sein und die neue Version von FHEM ist installiert.
Ich denke ich werde aber noch bis zur Zeitumstellung ( in 14 Tagen ) warten bis ich das Kalender Modul wieder voll aktiviere. Bei wiederkehrenden Terminen über diesen Termin hatte ich hier schon Schwierigkeiten ( 1h Verschiebung ).
Danke
Andreas
Zitat von: wfas303 am 12 Oktober 2013, 18:38:07Bei wiederkehrenden Terminen über diesen Termin hatte ich hier schon Schwierigkeiten ( 1h Verschiebung ).
Hast Du in Deinem Kalender (und auf Deiner Hardware!) die Zeitzone und die Sommerzeiterkennung richtig eingestellt?
Im Google-Kalender selbst musst Du das Land und die Zeitzone richtig einstellen.
(http://up.picr.de/16146540qj.jpg)
Hallo,
dieses Thema wird für alle möglichen Themenstellungen in Zusammenhang mit dem Calendar-Modul benutzt. Das läßt sich nicht mehr überblicken. Ich habe das Thema daher geschlossen.
Bitte eröffnet jedesmal ein neues Thema im richtigen Forum, und bleibt bitte innerhalb eines Themas bei derselben Sache. Danke.
Boris