57_Calendar treibt mich zur Weißglut

[betateilchen]

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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?

[Dr. Boris Neubert]

Code Auswählen Erweitern

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


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

[betateilchen]

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

Code Auswählen Erweitern

get <kalenderDevice> text all

einen zusätzlichen optionalen Parameter zur Angabe der maximalen Listlänge bei der Ausgabe mitzugeben.

Also in der Art

Code Auswählen Erweitern

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 :)

Code Auswählen Erweitern


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") {


[crissiloop]

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

[betateilchen]

wie oben schon steht: die private ICAL Adresse. Und es funktioniert bei mir weder mit http noch mit https

[betateilchen]

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.

Code Auswählen Erweitern


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


Code Auswählen Erweitern


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


Code Auswählen Erweitern


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?

[betateilchen]

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


---

[d-man]

Kann 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!

[betateilchen]

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

Code Auswählen Erweitern


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

----

[Dr. Boris Neubert]

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

[betateilchen]

das Problem war, daß Google mit einem "301 moved permanently" auf die "http"-URL reagiert.

Danke für die Bestätigung.

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

[betateilchen]

Da wir hier grade aktuell über das Kalendermodul diskutieren, hänge ich die Frage aus einem anderen Bereich einfach mal hier dran:

Unterstü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

Code Auswählen Erweitern

define testKalender Calendar ical file c:/basic.ics

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

[Dr. Boris Neubert]

Entscheidend ist das Schlüsselwort file anstatt url zu verwenden und den Pfad zur Datei anzugeben.

Dokumentiert und mit Anpassungen eingecheckt!
Boris

[Dr. Boris Neubert]

Ich 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

[betateilchen]

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

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:

Code Auswählen Erweitern


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