Guten Morgen zusammen
Seit dem heutigen update holt das Modul meine GoogleKalender nicht mehr.
Habe im Log dann diese Meldungen
2019.02.24 09:26:48 1: Calendar xx.CAL.Privat: retrieval failed with HTTP response code 400
2019.02.24 09:26:48 1: Calendar xx.CAL.Privat: retrieved no or empty data
2019.02.24 09:26:48 1: Calendar xx.CAL.Abfall: retrieval failed with HTTP response code 400
2019.02.24 09:26:48 1: Calendar xx.CAL.Abfall: retrieved no or empty data
2019.02.24 09:26:49 1: Calendar xx.CAL.Heizung: retrieval failed with HTTP response code 400
2019.02.24 09:26:49 1: Calendar xx.CAL.Heizung: retrieved no or empty data
Den Outlook-Kalender holt es ohne Probleme.
Habe erstmal die alte Version zurück gespielt und alles ist wieder normal.
Zum Schluss noch ein list von einem Device
Internals:
DEF ical url https://calendar.google.com/calendar/ical/xxx%40gmail.com/private-xxx/basic.ics
FUUID 5xxxx
NAME xx.CAL.Privat
NOTIFYDEV global
NR 380
NTFY_ORDER 50-xx.CAL.Privat
STATE letztes Update: 2019-02-24 10:03:57
TYPE Calendar
.attraggr:
.attrminint:
.fhem:
iCalendar BEGIN:VCALENDAR
....
END:VCALENDAR
interval 3600
lastUpdate 2019-02-24 10:03:57
lastid 150
lasturl https://calendar.google.com/calendar/ical/xxx%40gmail.com/private-xxx/basic.ics
lstUpdtTs 1550999037.71348
nextUpdate 2019-02-24 11:03:57
nextWake 2019-02-24 11:03:57
nextWakeTs 1551002637.71348
nxtUpdtTs 1551002637.71348
type url
url https://calendar.google.com/calendar/ical/xxx%40gmail.com/private-xxx/basic.ics
vevents:
READINGS:
2019-02-24 10:03:58 calname xxxx@gmail.com
2019-02-24 10:03:58 lastUpdate 2019-02-24 10:03:57
2019-02-20 15:30:00 modeAlarm
2019-02-22 17:00:00 modeAlarmOrStart
2019-02-20 15:09:58 modeAlarmed
2019-02-22 17:10:08 modeChanged
2019-02-24 10:03:58 modeEnd
.....
2019-02-22 17:10:08 modeEnded
2019-02-22 17:00:00 modeStart
2019-02-22 16:10:08 modeStarted
2019-02-24 10:03:58 modeUpcoming 29mb409v2gs96rgin0q115j9vrgooglecom;73e27qgcgf9euu0pfs9ovotdh7googlecom
2019-02-24 10:03:58 nextUpdate 2019-02-24 11:03:57
2019-02-24 10:03:58 nextWakeup 2019-02-24 11:03:57
2019-02-24 10:03:58 state triggered
Attributes:
DbLogExclude .*
group Kalender
hideOlderThan 1
icon im_user
room hidden
stateFormat letztes Update: lastUpdate
verbose 3
Gruss Brause
Und was sagt die Log mit verbose 5?
Habe denselben Fehler....
Ich auch - aber nur bei Google Kalendern. Sämtliche ownCloud Kalender laufen fehlerfrei.
Bin schon dran, nach dem Fehler zu suchen.
ok, ich weiß, woher der Fehler kommt: In google Kalendern kommen Prozentzeichen vor, das kollidiert mit der neu eingebauten Ersetzung von wildcards.
Jetzt muss ich mir nur noch eine Lösung dafür ausdenken :)
Ich habe gerade eine Lösung eingecheckt, die das Problem mit Google Kalendern umgeht. Um diese Lösung zu aktivieren, muss im device des Google Kalenders, das Attribut "quirks" den Wert "noWildcards" enthalten. Damit ist dann die Verwendung von Wildcards in Google Kalendern nicht möglich.
Wer die Möglichkeit hat, die Datei aus dem SVN zu holen, kann dann das ab sofort tun.
Ansonsten gibt es die Moduldatei auch hier zum Download: https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/57_Calendar.pm
Sorry für die Umstände - ich hatte viele Kalender getestet, nur Google nicht, da ich schon länger nicht mehr damit arbeite.
So funktioniert es bei mir wieder.
DANKE
Das Problem ist gelöst.
Gerade habe ich eine Modulversion eingecheckt, die bei google Kalendern automatisch die wildcards Auswertung unterbindet. Damit muss das Attribut quirks nicht mehr manuell gefüllt werden. Ab sofort gilt die Regel: "Keine wildcards bei Google Kalendern!"
Das Attribut quirks wird trotzdem auch weiterhin ausgewertet, falls ein ähnliches Problem noch bei anderen Kalendern auftreten sollte, die ebenfalls % Zeichen in der URL haben, ohne dass damit ein wildcard gekennzeichnet wird.
Die Änderungen und die Verwendung des Attributes wurden in der commandref dokumentiert.
Bei mir geht die neue Version aus export/HEAD/trunk nicht. Fhem stoppt.
Die problematische DEF:
define UntisCal Calendar ical file ./log/untis.ics
setuuid UntisCal 5c61dc6c-f33f-6837-1c94-7dcc25f9f9d5e407
Nehme ich beide Zeilen von fhem.cfg weg, funktioniert alles.
Mit verbose 5:
2019.02.24 12:29:58 4: Calendar UntisCal: Wakeup
2019.02.24 12:29:58 4: Calendar UntisCal: Updating...
2019.02.24 12:29:58 4: Calendar UntisCal: Getting data from file ./log/untis.ics
2019.02.24 12:29:58 5: Calendar UntisCal: file retrieval successful
2019.02.24 12:29:58 4: Calendar UntisCal: parsing data asynchronously (PID= -12440)
2019.02.24 12:29:58 5: Calendar UntisCal: control passed back to main loop.
Mehr nicht
Setze mal bitte
attr UntisCal synchronousUpdate 1
und teste dann erneut.
Hab grade mal ein ics file angelegt und getestet:
2019.02.24 13:08:17 4: Calendar UntisCal: Wakeup
2019.02.24 13:08:17 4: Calendar UntisCal: Updating...
2019.02.24 13:08:17 4: Calendar UntisCal: Getting data from file ./log/untis.ics
2019.02.24 13:08:17 5: Calendar UntisCal: file retrieval successful
2019.02.24 13:08:17 4: Calendar UntisCal: parsing data asynchronously (PID= 6951)
2019.02.24 13:08:17 5: Calendar UntisCal: control passed back to main loop.
2019.02.24 13:08:18 4: Calendar UntisCal: got result from asynchronous parsing.
2019.02.24 13:08:18 4: Calendar UntisCal: asynchronous parsing finished.
2019.02.24 13:08:18 4: Calendar UntisCal: merging data
2019.02.24 13:08:18 4: Calendar UntisCal: 2 records processed, 2 new, 0 known, 0 modified, 0 changed.
2019.02.24 13:08:18 4: Calendar UntisCal: creating calendar events
2019.02.24 13:08:18 4: Calendar UntisCal: Checking times...
2019.02.24 13:08:18 4: Calendar UntisCal: process ended.
scheint also kein generelles Problem mit dem Modul selbst zu sein.
Anbei die .ics Datei
Vielleicht hängt es an meiner Windows Testinstanz?
Zitat von: amenomade am 24 Februar 2019, 13:33:26
Vielleicht hängt es an meiner Windows Testinstanz?
Wer macht denn auch sowas... 8)
Hast Du den Vorschlag mit dem Attribut für synchrone Verarbeitung getestet?
Edit: es funktioniert bei mir auch mit der von Dir geposteten Datei.
2019.02.24 13:37:15 4: Calendar untisCal: Wakeup
2019.02.24 13:37:15 4: Calendar untisCal: Updating...
2019.02.24 13:37:15 4: Calendar untisCal: Getting data from file ./log/untis.ics
2019.02.24 13:37:15 5: Calendar untisCal: file retrieval successful
2019.02.24 13:37:15 4: Calendar untisCal: parsing data asynchronously (PID= 7082)
2019.02.24 13:37:15 5: Calendar untisCal: control passed back to main loop.
2019.02.24 13:37:16 4: Calendar untisCal: got result from asynchronous parsing.
2019.02.24 13:37:16 4: Calendar untisCal: asynchronous parsing finished.
2019.02.24 13:37:16 4: Calendar untisCal: merging data
2019.02.24 13:37:16 4: Calendar untisCal: 31 records processed, 31 new, 0 known, 0 modified, 0 changed.
2019.02.24 13:37:16 4: Calendar untisCal: creating calendar events
2019.02.24 13:37:16 4: Calendar untisCal: Checking times...
2019.02.24 13:37:16 4: Calendar untisCal: process ended.
Zitat von: betateilchen am 24 Februar 2019, 13:34:39
Wer macht denn auch sowas... 8)
::) Jemand, der kein Bock hat, jedes mal seine Linux VM zu starten :P
Aber gut so: sonst hättest Du nicht gewusst, dass es mit Windows nicht funktioniert 8)
Zitat
Hast Du den Vorschlag mit dem Attribut für synchrone Verarbeitung getestet?
Jetzt ja, und damit geht es.
Dein "Problem" kommt daher, dass mit dem heutigen Update die Verarbeitung per default von synchron auf asynchron umgestellt wurde. Das scheint bei Windows offenbar nicht zu funktionieren.
Ok, ich werde also noch eine Prüfung einbauen, die eine asynchrone Verarbeitung unter Windows unterbindet.
Falls nötig: ein bisschen mehr in der Log mit global verbose 5:
2019.02.24 13:44:50 4: Calendar UntisCal: Wakeup
2019.02.24 13:44:50 4: Calendar UntisCal: Updating...
2019.02.24 13:44:50 4: Calendar UntisCal: Getting data from file ./log/untis.ics
2019.02.24 13:44:50 5: Calendar UntisCal: file retrieval successful
2019.02.24 13:44:50 5: Starting notify loop for UntisCal, 1 event(s), first is retrieved
2019.02.24 13:44:50 5: createNotifyHash
2019.02.24 13:44:50 5: End notify loop for UntisCal
2019.02.24 13:44:50 5: SubProcess -6708 created.
2019.02.24 13:44:50 4: Calendar UntisCal: parsing data asynchronously (PID= -6708)
2019.02.24 13:44:50 5: Calendar UntisCal: control passed back to main loop.
2019.02.24 13:44:50 5: SubProcess -6708 started.
2019.02.24 13:44:50 5: SubProcess -6708 ended.
Hier stoppt Fhem
Kannst Du mal bitte mit dieser Version und ohne gesetztes Attribut testen: https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/betateilchen/57_Calendar.pm
Jepp, geht
2019.02.24 14:03:17 4: Calendar UntisCal: Wakeup
2019.02.24 14:03:17 4: Calendar UntisCal: Updating...
2019.02.24 14:03:17 4: Calendar UntisCal: Getting data from file ./log/untis.ics
2019.02.24 14:03:17 5: Calendar UntisCal: file retrieval successful
2019.02.24 14:03:17 4: Calendar UntisCal: parsing data synchronously
2019.02.24 14:03:17 4: Calendar UntisCal: merging data
2019.02.24 14:03:17 4: Calendar UntisCal: 31 records processed, 31 new, 0 known, 0 modified, 0 changed.
2019.02.24 14:03:17 4: Calendar UntisCal: creating calendar events
2019.02.24 14:03:17 4: Calendar UntisCal: Checking times...
2019.02.24 14:03:17 4: Calendar UntisCal: process ended.
Macht synchrone, ohne dass das Attribute gesetzt wird.
Ok, danke fürs Testen. Bis auf weiteres wird unter Windows immer synchron verarbeitet.
Eventuell eine Baustelle für Boris, falls eine asynchrone Verarbeitung unter Windows überhaupt umsetzbar ist.
Hallo,
habe das Modul aktualisiert (per Update, nicht aktuell aus dem Repo) und bekomme auf Debian im Raspberry mit asynchronem Kalender-Update auch meinen Google-Kalender nicht mehr:
2019.02.24 20:51:32 4: Calendar Calendar: Updating...
2019.02.24 20:51:32 4: Calendar Calendar: Getting data from URL <hidden>
2019.02.24 20:51:32 1: Calendar Calendar: retrieval failed with HTTP response code 400
2019.02.24 20:51:32 5: Calendar Calendar: HTTP response header:
HTTP/1.0 400 Bad Request
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Date: Sun, 24 Feb 2019 19:51:32 GMT
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
Alt-Svc: quic=":443"; ma=2592000; v="44,43,39"
2019.02.24 20:51:32 1: Calendar Calendar: retrieved no or empty data
Irgendetwas ist da noch faul. Mit
attr Calendar synchronousUpdate 1
geht es auch nicht. Mit wget kann ich meinen Kalender herunterladen.
Viele Grüße
Boris
Hallo Boris,
mit dem synchronousUpdate hat Dein google Problem nichts zu tun. Wenn Du die Datei aus dem heutigen Update verwendest, läufst Du mit Deinem Google Kalender genau in den gleichen Fehler wie alle anderen User (inklusive mir selbst) auch. Warum sollte das bei Dir anders sein als bei allen anderen Anwenden?
Heute im Laufe des Tages habe ich das Problem mit den google Kalendern behoben, die Lösung kommt morgen früh per Update.
Das Problem mit dem synchronen Update ist ein zweites Thema, das durch die Umstellung des Standardverhaltens von synchron auf asynchron auftrat. Das betrifft aber nur Anwender, die FHEM auf Windows betreiben. Auch das ist inzwischen behoben und im morgigen Update enthalten.
Oder Du holst Dir die aktuelle Moduldatei aus dem svn repository, dann funktioniert auch Dein google Kalender wieder.
Man beachte die Zeitachse:
- gestern wurden die eingebauten Änderungen eingecheckt.
- heute im Update wurde die neue Modulversion ausgeliefert
- heute wurden zwei Probleme festgestellt, die behoben wurden und im repository zur Verfügung stehen
- morgen werden per Update die vorgenommenen Korrekturen ausgeliefert
Ach so, ich dachte, dass es nur unter Windows nicht liefe. Dann habe ich das nicht richtig gelesen. Habe die Version aus dem Repo genommen und die funktioniert. Danke.
Boris
Und das Modul hat seit gestern eine aktualisierte deutsche commandref.
Die Lorbeeren dafür gehen an die Community, die sich darum gekümmert hat - siehe commandref-Thread (https://forum.fhem.de/index.php/topic,96634.0.html) hier im Unterforum.
Danke für die schnelle Problembehebung.
Hallo zusammen,
nach einem Update geht die Kalenderabfrage bei mir auch nicht mehr.
Folgende Fehlermeldung
2019.03.01 21:51:19 4: Calendar AbfallKalender: Updating...
2019.03.01 21:51:19 4: Calendar AbfallKalender: Getting data from URL <hidden>
2019.03.01 21:51:19 1: Calendar AbfallKalender: retrieval failed with HTTP response code 404
2019.03.01 21:51:19 5: Calendar AbfallKalender: HTTP response header:
HTTP/1.1 404 Es wurde keine StandortID angegeben
Date: Fri, 01 Mar 2019 20:51:19 GMT
Server: Apache
Cache-Control: private, must-revalidate
pragma: no-cache
expires: -1
X-Hostname: x104-lamp32
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 55
Connection: close
Content-Type: text/html; charset=UTF-8
2019.03.01 21:51:19 1: Calendar AbfallKalender: retrieved no or empty data
2019.03.01 21:51:19 4: Calendar AbfallKalender: Checking times...
Hängt das mit dem Update zusammen oder eine Änderung auf Anbieterseite?
HTTP/1.1 404 Es wurde keine StandortID angegebenkommt wahrscheinlich nicht von Fhem.
Sagen wir mal so: sie wird nicht von FHEM verursacht, sondern von FHEM nur ausgegeben.
Spontan würde ich sagen, die URL die im calendar device verwendet wird, ist falsch oder unvollständig. Bei meinem Anbieter hat sich die URL neulich auch geändert. Deshalb habe ich den Kalender für 2019 von der Webseite exportiert und dann in FHEM als file eingebunden.
Ursache war ein % Zeichen in der URL.
attr AbfallKalender quirks noWildcards
hat geholfen
Nur mal interessehalber: welche Anbieter ausser google verwenden noch Prozentzeichen in der URL?
Edit: erledigt. Es ging um einen Abfallkalender. Da kommen eh die merkwürdigsten Dinge vor :)
Wollte heute den Filter limit:when=today einbringen.
Dabei ist mir augefallen das auch die ganztägigen Termine des nächsten Tages ausgegeben werden.
Sollte eigentlich nicht so sein.. oder hab ich einen Gedankenfehler?
yellowpinky
Ein alter Thread aber das gleiche Problem besteht leider noch bei ,,limit:when=tomorrow" – da werden auch ganztägige Termine des übernächsten Tages mit ausgegeben. Diese haben für Start und Ende jeweils Uhrzeit 0:00 (beim verwendeten Google-Kalender).
Das oben beschriebene Problem für ,,today" wurde offenbar gefixed, indem eine Sekunde von der Endzeit abgezogen wird (Zeile 2055 im File 57_Calendar.pm).
Ich habe das bei mir testweise nun auch für ,,tomorrow" gemacht und für mich funktioniert diese Änderung in der Zeile 2059:
$from = DAYSECONDS - Calendar_GetSecondsFromMidnight();
$to = $from + DAYSECONDS - 1;
Bitte um Prüfung und ggfls. Übernahme. Danke!
Zitat von: Gary am 29 Dezember 2020, 13:50:13
Das oben beschriebene Problem für ,,today" wurde offenbar gefixed, indem eine Sekunde von der Endzeit abgezogen wird (Zeile 2055 im File 57_Calendar.pm).
Ich habe das bei mir testweise nun auch für ,,tomorrow" gemacht und für mich funktioniert diese Änderung in der Zeile 2059:
$from = DAYSECONDS - Calendar_GetSecondsFromMidnight();
$to = $from + DAYSECONDS - 1;
Bitte um Prüfung und ggfls. Übernahme. Danke!
Danke, Gary, für den Hinweis. Ich werde mich in einigen Tagen darum kümmern können.
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert am 05 Januar 2021, 11:19:37
Ich werde mich in einigen Tagen darum kümmern können.
Änderung eingespielt.
Da ich beim über die Suche nach der Fehlermeldung immer in diesem Thread gelandet bin, lasse ich die Lösung gerade mal hier.
Nach einem Stromausfall vor ein paar Tagen ging plötzlich meine über einen Google-Kalender gesteuerte Kaffeemaschine nicht mehr. Ein Blick ins Logfile zeigte Fehlermeldungen seit dem 1. Juli:
2021.07.01 00:03:09 1: Calendar calendar.coffee: retrieval failed with HTTP response code 404
2021.07.01 00:03:09 1: Calendar calendar.coffee: retrieved no or empty dataIch hatte irgendwie erst FHEM im Verdacht (trotz 404) und bin hier gelandet, nach kurzer Überprüfung der URL war dann aber klar, dass diese einfach nicht mehr funktioniert. Dazu fand ich dann bei Google (https://support.google.com/calendar/answer/37648):
ZitatImportant: As part of a recent security enhancement update, the Google Calendar settings page has been improved to ensure that the secret address is now displayed in the hidden format. By July 1, 2021, we're going to reset the secret address for all calendars that are shared with other applications. If you're using the secret address to view the calendar in other applications, like Microsoft Outlook or Apple Calendar, you'll need to update them with the new secret address to allow continued access.
Nach einem Update der URL funktioniert die Kaffeemaschine wieder zuverlässig. 8)
Bis zum Stromausfall waren die Kalendereinträge vermutlich noch gecached und daher waren die fehlgeschlagenen Update-Versuche kein Problem.
Danke fürs posten der Erklärung - ich hatte exakt das gleiche Verhalten vor 10 Tagen.
Es betrifft offenbar nur private Kalender, meine öffentlichen (z.B. Abfallkalender) sind nicht verändert.
Oder es ist ein "we're going" - fortlaufender Prozess der irgendwann eintritt? Ich habe einen privaten Kalender der ist (noch?) nicht betroffen. ::)
Wobei ich gesehen habe, die Meldung 404 trat schon früher auf, bevor der Kalender nicht mehr funktionierte.
Man sollte sich also eine Überprüfung mit Problemmeldung einbauen, wenn die Funktion des Kalenders wirklich wichtig ist!
Zitat von: Otto123 am 22 Juli 2021, 10:34:05
Wobei ich gesehen habe, die Meldung 404 trat schon früher auf, bevor der Kalender nicht mehr funktionierte.
Genau, bei mir fingen die Fehlermeldungen *exakt* um Mitternacht am 1. Juli an (wie von Google angekündigt).
Allerdings stehen in dem Kalender nur sich wöchentlich wiederholende Einträge, die nur sehr selten verändert werden, und die hatte das Kalendermodul wohl noch intern gespeichert. Erst nach dem Neustart vom FHEM vor ein paar Tagen gab es dann wirklich Probleme, weil die Einträge nicht mehr da waren.
Kann es sein, dass deine Probleme auch mit einem Neustart von FHEM korrelieren?
bei mir war es der 26.6. erstmalig. Aber das "Problem" trat erst nach einem Neustart am 9.7. von FHEM zu Tage. Die Termine in dem betroffenem Kalender sind aber auch schon lange eingetragen.