57_Calendar Fehler GoogleKalender

Begonnen von Brause, 24 Februar 2019, 10:20:04

Vorheriges Thema - Nächstes Thema

Brause

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

amenomade

Und was sagt die Log mit verbose 5?
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Mave


betateilchen

Ich auch - aber nur bei Google Kalendern. Sämtliche ownCloud Kalender laufen fehlerfrei.

Bin schon dran, nach dem Fehler zu suchen.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

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 :)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

#5
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Brause

So funktioniert es bei mir wieder.

DANKE

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

amenomade

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
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

betateilchen

#9
Setze mal bitte

attr UntisCal synchronousUpdate 1

und teste dann erneut.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

amenomade

Anbei die .ics Datei
Vielleicht hängt es an meiner Windows Testinstanz?
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

betateilchen

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


-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

amenomade

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.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

amenomade

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
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

amenomade

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.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

betateilchen

#18
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Dr. Boris Neubert

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
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

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
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Dr. Boris Neubert

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
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

betateilchen

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 hier im Unterforum.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Mave

Danke für die schnelle Problembehebung.

hf007

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?

amenomade

HTTP/1.1 404 Es wurde keine StandortID angegebenkommt wahrscheinlich nicht von Fhem.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

betateilchen

#27
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

hf007

Ursache war ein % Zeichen in der URL.
attr AbfallKalender quirks noWildcards
hat geholfen

betateilchen

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 :)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

yellowpinky

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

Gary

#31
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!

Dr. Boris Neubert

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
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Dr. Boris Neubert

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.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

mhx

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 data


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

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.

Otto123

#35
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!
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

mhx

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?

Otto123

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.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz