Calendar verursacht scheinbar 100% CPU Last über 10 Minuten

Begonnen von RatisBow, 22 Januar 2021, 11:16:20

Vorheriges Thema - Nächstes Thema

Dr. Boris Neubert

Hallo, auch das ist verständlich, denn

2021.01.31 16:31:27 4: Calendar Cal.GoFrank: 19451 records processed, 0 new, 0 known, 19451 modified, 0 changed.


es wurden 19.451 Termine verändert. Wie kommt es denn, dass diese Termine sich ändern innerhalb von 10 Minuten? Das scheint ein Bug in der Quelle zu sein, die den Kalender ausliefert. Zum Glück gibt es dafür ein Attribut:

attr Cal.GoFrank quirks ignoreDtStamp

Bitte versuche es damit. Der zweite Aufruf sollte dann keine modifizierten Ereignisse mehr liefern.

Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

RatisBow

Das geht ja schnell hier erst noch einmal Danke und das am Wochenende.


attr Cal.GoFrank quirks ignoreDtStamp

hat leider nichts gebracht.

Das Listing:

Internals:
   DEF        ical url https://calendar.google.com/calendar/ical/f.name%name.de/private-e960a9d735af6bd9965ff049543f670b/basic.ics
   FUUID      5dbff2e4-f33f-7b43-6a2c-9b0e935748440705
   NAME       Cal.GoFrank
   NOTIFYDEV  global
   NR         43
   NTFY_ORDER 50-Cal.GoFrank
   STATE      triggered
   TYPE       Calendar
   READINGS:
     2021-01-31 18:18:39   calname         f.henderkes@henderkes.de
     2021-01-31 18:18:39   lastUpdate      2021-01-31 18:16:01
     2021-01-29 12:15:00   modeAlarm       
     2021-01-29 13:15:03   modeAlarmOrStart
     2021-01-29 11:28:36   modeAlarmed     
     2021-01-29 13:29:00   modeChanged     
     2021-01-31 18:18:39   modeEnd         805e1267bk79jiik83vpbfet94googlecom;ckom6p336hi68bb265hmab9k68r30b9pchijgb9j68qj8c3570r68opgc4googlecom;tp9dli47btelopk1uhvr8ck0cggooglecom;to5mr6rv2u9bg5uni28uailgr4googlecom;eqav50g1g1ckqal3krp644hutogooglecom;g16htsldmoi72ljbs1jamnjqlsgooglecom;cpi3cdpp64qjibb56krj4b9k6ko34bb274rj0b9ic8o32cpg6gq38c9gccgooglecom;l8tt7a9vdvsiu5hbd5nekroruogooglecom;6cp3aob5chj6cbb6chij2b9kc9hj2bb26lgm2b9k6lijicb46srm4c9l64googlecom;6q55rocghspadlldneb1a1tg5kgooglecom;cgrj6chg6di6abb461h64b9k60p3gbb16cpjcb9n6ph62cb16li3ed1lc4googlecom;k7dcj3lm5n842i3sta2l6t2u28googlecom;0d7k1amap0lnmjdoasvl6jnmrggooglecom;o419cp7oh8tvdlui9pko8cdhlogooglecom;qjp9mggjkh563iqip3ebtp81isgooglecom;d2u7tkjljshk58cs58r09b7b3sgooglecom;c8p34e9o69h6ab9lc8q30b9kcko36b9pc5hmcb9g64qjec9k61i64ohgckgooglecom;c5ijior365gj4b9jcgr36b9k6gr3cb9p6csm2b9kcgp3icb36or6aohic4googlecom;vmg9qekl10719qd3vvrfb13tv0googlecom;1n456lenrfi6ug8cvgf73nv92kgooglecom;75i68dpm6cojib9i6tj30b9k6hhmab9o6pi3eb9l74s3ic9lcdhm8chl6cgooglecom;buh30shppobgqs5sllaphahk18googlecom;vqqd6mvf1qkog0rr5csiaiqa20googlecom
     2021-01-29 13:29:00   modeEnded       
     2021-01-29 13:15:03   modeStart       
     2021-01-29 12:28:45   modeStarted     
     2021-01-31 18:18:39   modeUpcoming    j3nveu5s4govmvhqj5gvrj2lssgooglecom;q1q4m9bu7mfbhc6hir53a78kg0googlecom;46dhm891tuuhr5e28n3snrsshcgooglecom;33d7cc65456d4d44afa8c81466b50502;1d82f523eddf458fb891aa0c85ae1f21;emrnklk1goe9imoopr9k4kf9logooglecom;402e19k1dfgf7f3k2nhip6qahcgooglecom;97a42c36c6564e7d85cec6720dd1a107;eiudgt7qfrd25vt86g9aama0ucgooglecom;8h4er7q9u541m36o30se5vmvsogooglecom;jo452s97h1hrpitodlkbobrr2kgooglecom;sme2bjgr12q10ceded4n2qnefogooglecom;6go62dr4cgqj4bb6c5j34b9k64sm2bb164r3ab9g64q62pj369h32d1ickgooglecom;71imcp9k64r3ibb46sr3cb9k75j6abb260sjib9gc4om6cpg74q3ipj560googlecom;2mu0f1btbs5sidjprgc13etnaggooglecom;nlikshococc3o8lriet8esc5togooglecom;couuj9mvs6mj61isb7ovtnpqjogooglecom;5cpt8fu1v1f330s318r66ms50kgooglecom;tsdn0dp9v1pfkbea2ing3vsnqkgooglecom;1vti5k6poecars6khelak25e0ogooglecom;gtlijhgtfhrifqrar7jeabrt98googlecom;u2b9tmpalhb05a63h2e0h94938googlecom;d50f224gg46mp3aff5g2re4l64googlecom;l9u0l8hf7v90dbu0bs8hlhuiusgooglecom;dfd1s4uu92h92rjvtvlmatvorkgooglecom
     2021-01-31 18:18:39   nextUpdate      2021-01-31 19:16:01
     2021-01-31 18:18:39   nextWakeup      2021-01-31 19:16:01
     2021-01-31 18:18:39   state           triggered
Attributes:
   hideLaterThan 7d
   hideOlderThan 1d
   icon       time_calendar
   quirks     ignoreDtStamp
   room       I.Calendar
   verbose    5


Im Anhang das Log.


Dr. Boris Neubert

Zitat von: RatisBow am 31 Januar 2021, 18:29:35
Das geht ja schnell hier erst noch einmal Danke und das am Wochenende.

Wann denn sonst?  ::)

2021.01.31 18:16:28 4: Calendar Cal.GoFrank: merging data
2021.01.31 18:16:29 4: Calendar Cal.GoFrank: 19451 records processed, 0 new, 19451 known, 0 modified, 0 changed.
2021.01.31 18:16:29 4: Calendar Cal.GoFrank: creating calendar events
2021.01.31 18:18:39 5: Starting notify loop for Cal.GoFrank, 3 event(s), first is calname: f.name@name.de


Tja. Vielleicht schaue ich mal in den Code. Aber ich denke, dass das Problem bestehen bleibt, weil es soviele Termine sind, die jedesmal durchgearbeitet werden.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

RatisBow

Wenn er das am Anfang durcharbeiten muss, sollte beim Start ja kein Problem sein und das sind bisher ca 2 Minuten gewesen. Erst später kommt ja die lange CPU Last mit 7 - 10 Minuten warten.
Den Google-Kalender habe ich jetzt ein paar Jahre. Dabei habe ich noch nicht einmal viele Termine in der Woche eingetragen. Was machen da Leute, die jeden Tag mehrere Termine haben?

Ich weiss deine Bemühungen zu schätzen, da ich auch aus der Softwarebranche (C++) komme und Log-Files nicht immer einen alles sagen.

Wäre nett, wenn du dich die Tage deshalb melden könntest. Schönes Restwochenende.

RatisBow

Dr. Boris Neubert

Hallo,

die zwei Minuten Wartezeit beim ersten Holen und Verarbeiten des Kalenders liegt an der großen Anzahl VEVENTs.

Ich habe jetzt die Ursache für die Wartezeit ab dem ersten Update des Kalenders gefunden. Ich beziehe mich auf Zeilen 3085ff in 57_Calender.pm (Step 3 Events).

Grundsätzlich braucht er sich ein VEVENT nur anzuschauen, wenn es seit dem letzten Abruf verändert wurde. Warum also steht in dieser Strophe hier or !$v->numEvents() ?


        if($v->hasChanged() or !$v->numEvents()) {
            #main::Debug "createEvents";
            $v->createEvents($name, $t, $onCreateEvent,
              $cutoffLowerBound, $cutoffUpperBound, %vevents);


Aufgrund der cutoff-Attribute müssen die Termine neu erstellt werden, weil ja seit dem letzten Abruf welche aus dem gleitenden Zeitfenster herausgefallen oder welche hineingekommen sein könnten. Diese Prüfung lässt sich aber nicht daran festmachen, ob aus dem VEVENT beim letzten Generieren keine Termine erzeugt wurden. So wie es da steht, sind die cutoff-Attribute nicht nur kontraproduktiv, wenn wie in Deinem Fall schon ganz viele Termine aus dem Zeitfenster herausgefallen sind, sondern die Abfrage ist schlicht falsch.

Um meine Hypothese zu testen, möchte ich Dich, @RatisBow, um folgendes bitten:

Ersetze bitte im Code die Zeile

        if($v->hasChanged() or !$v->numEvents()) {

durch

        if($v->hasChanged()) {

Danach starte FHEM wieder und warte die initiale Befüllung sowie das erste Update des Kalender ab. Poste dann die jeweiligen Abschnitte aus dem Log (in code-Tags), die von

4: Calendar Cal.GoFrank: asynchronous parsing finished.

bis

4: Calendar Cal.GoFrank: process ended.

gehen. Ich erwarte, dass der zweite Lauf dann sehr viel schneller durch sein wird.

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

RatisBow

Hallo Herr Dr. Boris Neubert,

hier der gewünscht Log-Eintrag.


2021.02.07 13:57:39 4: Calendar Cal.GoFrank: asynchronous parsing finished.
2021.02.07 13:57:39 5: Starting notify loop for Cal.GoFrank, 1 event(s), first is parsed
2021.02.07 13:57:39 5: End notify loop for Cal.GoFrank
2021.02.07 13:57:39 4: Calendar Cal.GoFrank: merging data
2021.02.07 13:57:40 4: Calendar Cal.GoFrank: 19451 records processed, 19451 new, 0 known, 0 modified, 0 changed.
2021.02.07 13:57:40 4: Calendar Cal.GoFrank: creating calendar events
2021.02.07 13:59:30 5: Starting notify loop for Cal.GoFrank, 3 event(s), first is calname: f.name@name.de
2021.02.07 13:59:30 5: End notify loop for Cal.GoFrank
2021.02.07 13:59:30 4: Calendar Cal.GoFrank: Checking times...
2021.02.07 13:59:30 5: Starting notify loop for Cal.GoFrank, 3 event(s), first is modeUpcoming: gtlijhgtfhrifqrar7jeabrt98googlecom;2mu0f1btbs5sidjprgc13etnaggooglecom;5cpt8fu1v1f330s318r66ms50kgooglecom;71imcp9k64r3ibb46sr3cb9k75j6abb260sjib9gc4om6cpg74q3ipj560googlecom;jo452s97h1hrpitodlkbobrr2kgooglecom;46dhm891tuuhr5e28n3snrsshcgooglecom;emrnklk1goe9imoopr9k4kf9logooglecom;l9u0l8hf7v90dbu0bs8hlhuiusgooglecom;tsdn0dp9v1pfkbea2ing3vsnqkgooglecom;33d7cc65456d4d44afa8c81466b50502;j3nveu5s4govmvhqj5gvrj2lssgooglecom;d50f224gg46mp3aff5g2re4l64googlecom;u2b9tmpalhb05a63h2e0h94938googlecom;sme2bjgr12q10ceded4n2qnefogooglecom;402e19k1dfgf7f3k2nhip6qahcgooglecom;q1q4m9bu7mfbhc6hir53a78kg0googlecom;6go62dr4cgqj4bb6c5j34b9k64sm2bb164r3ab9g64q62pj369h32d1ickgooglecom;nlikshococc3o8lriet8esc5togooglecom;97a42c36c6564e7d85cec6720dd1a107;8h4er7q9u541m36o30se5vmvsogooglecom;dfd1s4uu92h92rjvtvlmatvorkgooglecom;eiudgt7qfrd25vt86g9aama0ucgooglecom;couuj9mvs6mj61isb7ovtnpqjogooglecom;1vti5k6poecars6khelak25e0ogooglecom;1d82f523eddf458fb891aa0c85ae1f21
2021.02.07 13:59:30 5: CALVIEW Cal.ViewGoFrank - CALENDAR:Cal.GoFrank triggered, updating CALVIEW Cal.ViewGoFrank (CALVIEW_Notify) ...
2021.02.07 13:59:30 5: CALVIEW Cal.ViewGoFrank - All data:
...
2021.02.07 13:59:30 5: Starting notify loop for Cal.ViewGoFrank, 4 event(s), first is t: 0 td: 0 tm: 0
2021.02.07 13:59:30 5: End notify loop for Cal.ViewGoFrank
2021.02.07 13:59:30 5: CALVIEW Cal.ViewGoFrank - CALENDAR:Cal.GoFrank successfully got all updates for CALVIEW Cal.ViewGoFrank (CALVIEW_Notify). Now process updates...
2021.02.07 13:59:30 5: End notify loop for Cal.GoFrank
2021.02.07 13:59:30 5: Starting notify loop for Cal.GoFrank, 1 event(s), first is nextWakeup: 2021-02-07 14:57:24
2021.02.07 13:59:30 5: End notify loop for Cal.GoFrank
2021.02.07 13:59:30 4: Calendar Cal.GoFrank: process ended.


bis auf die ersten 1- 2 Minuten zum Befüllen liegt die Last immer unter 100%. Im Anhang noch die Log als Zip, die sich üner ca 10 Minuten erstrickt.

RatisBow

Dr. Boris Neubert

Danke für das Log.

Da ist allerdings nur der erste Aufruf um 13:57 drin, Kannst Du bitte mal ein

set Cal.GoFrank update

machen und mir das Log zu diesem Update direkt (im Text in code-Tags) zeigen? Also um den Eintrag mit "creating calendar events" herum?
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

RatisBow

Hallo


Host: tux.server.my:8083
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 63
Origin: http://tux.server.my:8083
Authorization: Basic ZnJhbms6MTIzNA==
Connection: keep-alive
Referer: http://tux.server.my:8083/fhem
Upgrade-Insecure-Requests: 1
2021.02.07 17:30:44 1: frank angemeldet
2021.02.07 17:30:44 4: WEB_192.168.10.71_1431 POST /fhem&fw_id=47&fwcsrf=csrf_513261859055171&cmd=set+Cal.GoFrank+update; BUFLEN:0
2021.02.07 17:30:44 5: Cmd: >set Cal.GoFrank update<
2021.02.07 17:30:44 4: Calendar Cal.GoFrank: Updating...
2021.02.07 17:30:44 5: HttpUtils url=<hidden>
2021.02.07 17:30:44 5: DNS QUERY 7072010000010000000000000863616c656e64617206676f6f676c6503636f6d0000010001
2021.02.07 17:30:44 4: Calendar Cal.GoFrank: Getting data from URL <hidden>
2021.02.07 17:30:44 5: Starting notify loop for Cal.GoFrank, 1 event(s), first is update
2021.02.07 17:30:44 5: createNotifyHash
2021.02.07 17:30:44 5: End notify loop for Cal.GoFrank
2021.02.07 17:30:44 5: GET /fhem?fw_id=47 HTTP/1.1
Host: tux.server.my:8083
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://tux.server.my:8083/fhem
Authorization: Basic ZnJhbms6MTIzNA==
Connection: keep-alive
Upgrade-Insecure-Requests: 1
2021.02.07 17:30:44 4: WEB_192.168.10.71_1431 GET /fhem?fw_id=47; BUFLEN:0
2021.02.07 17:30:44 4: WEB: /fhem?fw_id=47 / RL:1468 / text/html; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate

2021.02.07 17:30:44 5: DNS ANSWER 301:7072818000010001000400080863616c656e64617206676f6f676c6503636f6d0000010001c00c00010001000000e40004acd914eec01500020001000278f70006036e7334c015c01500020001000278f70006036e7333c015c01500020001000278f70006036e7331c015c01500020001000278f70006036e7332c015c0650001000100026db60004d8ef200ac0770001000100026db60004d8ef220ac0530001000100026db60004d8ef240ac0410001000100026db60004d8ef260ac065001c000100026db600102001486048020032000000000000000ac077001c000100026db600102001486048020034000000000000000ac053001c000100026db600102001486048020036000000000000000ac041001c000100026db600102001486048020038000000000000000a
2021.02.07 17:30:44 4: DNS result for calendar.google.com: 172.217.20.238, ttl:228
2021.02.07 17:30:44 4: IP: calendar.google.com -> 172.217.20.238
2021.02.07 17:30:44 5: HttpUtils request header:
GET /calendar/ical/f.name%40name.de/private-e960a9d735af6bd9965ff049543f670b/basic.ics HTTP/1.0
Host: calendar.google.com
User-Agent: fhem
Accept-Encoding: gzip,deflate

2021.02.07 17:30:44 5: GET /fhem/icons/favicon HTTP/1.1


Meinst du das?

RatisBow

Dr. Boris Neubert

Ja, aber noch ein bisschen mehr, der interessante Teil kommt danach.

Bis

4: Calendar Cal.GoFrank: process ended.

bitte.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

RatisBow

Okay, hatte zu früh beendet.


Host: tux.server.my:8083
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 82
Origin: http://tux.server.my:8083
Authorization: Basic ZnJhbms6MTIzNA==
Connection: keep-alive
Referer: http://tux.server.my:8083/fhem?room=I%2eCalendar
Upgrade-Insecure-Requests: 1
2021.02.07 18:19:39 4: WEB_192.168.10.71_1436 POST /fhem&fw_id=47&room=I.Calendar&fwcsrf=csrf_101839287977968e15&cmd=set+Cal.GoFrank+update; BUFLEN:0
2021.02.07 18:19:39 5: Cmd: >set Cal.GoFrank update<
2021.02.07 18:19:39 4: Calendar Cal.GoFrank: Updating...
2021.02.07 18:19:39 5: HttpUtils url=<hidden>
2021.02.07 18:19:39 5: DNS QUERY 7072010000010000000000000863616c656e64617206676f6f676c6503636f6d0000010001
2021.02.07 18:19:39 4: Calendar Cal.GoFrank: Getting data from URL <hidden>
2021.02.07 18:19:39 5: Starting notify loop for Cal.GoFrank, 1 event(s), first is update
2021.02.07 18:19:39 5: createNotifyHash
2021.02.07 18:19:39 5: End notify loop for Cal.GoFrank
2021.02.07 18:19:39 5: GET /fhem?room=I%2eCalendar&fw_id=47 HTTP/1.1
Host: tux.server.my:8083
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://tux.server.my:8083/fhem?room=I%2eCalendar
Authorization: Basic ZnJhbms6MTIzNA==
Connection: keep-alive
Upgrade-Insecure-Requests: 1
2021.02.07 18:19:39 4: WEB_192.168.10.71_1436 GET /fhem?room=I%2eCalendar&fw_id=47; BUFLEN:0
2021.02.07 18:19:39 4: WEB: /fhem?room=I%2eCalendar&fw_id=47 / RL:2825 / text/html; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate

2021.02.07 18:19:39 5: DNS ANSWER 301:7072818000010001000400080863616c656e64617206676f6f676c6503636f6d0000010001c00c00010001000001280004d83acfaec0150002000100026d800006036e7334c015c0150002000100026d800006036e7331c015c0150002000100026d800006036e7333c015c0150002000100026d800006036e7332c015c053000100010002623f0004d8ef200ac077000100010002623f0004d8ef220ac065000100010002623f0004d8ef240ac041000100010002623f0004d8ef260ac053001c00010002623f00102001486048020032000000000000000ac077001c00010002623f00102001486048020034000000000000000ac065001c00010002623f00102001486048020036000000000000000ac041001c00010002623f00102001486048020038000000000000000a
2021.02.07 18:19:39 4: DNS result for calendar.google.com: 216.58.207.174, ttl:296
2021.02.07 18:19:39 4: IP: calendar.google.com -> 216.58.207.174
2021.02.07 18:19:39 5: HttpUtils request header:
GET /calendar/ical/f.name%40name.de/private-e960a9d735af6bd9965ff049543f670b/basic.ics HTTP/1.0
Host: calendar.google.com
User-Agent: fhem
Accept-Encoding: gzip,deflate

2021.02.07 18:19:39 5: GET /fhem?XHR=1&inform=type=status;filter=room=I%2eCalendar;since=1612718378;fmt=JSON&fw_id=47&timestamp=1612718378823 HTTP/1.1
Host: tux.server.my:8083
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0
Accept: */*
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Authorization: Basic ZnJhbms6MTIzNA==
Connection: keep-alive
Referer: http://tux.server.my:8083/fhem?room=I%2eCalendar&fw_id=47
2021.02.07 18:19:39 4: WEB_192.168.10.71_1436 GET /fhem?XHR=1&inform=type=status;filter=room=I%2eCalendar;since=1612718378;fmt=JSON&fw_id=47&timestamp=1612718378823; BUFLEN:0
2021.02.07 18:19:39 4: Connection closed for WEB_192.168.10.71_1439: EOF
2021.02.07 18:19:48 4: <hidden>: HTTP response code 200
2021.02.07 18:19:48 5: HttpUtils <hidden>: Got data, length: 13845959
2021.02.07 18:19:48 5: HttpUtils response header:
HTTP/1.0 200 OK
Content-Type: text/calendar; charset=utf-8
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, 07 Feb 2021 17:19:47 GMT
Content-Encoding: gzip
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
X-XSS-Protection: 1; mode=block
Server: GSE
Alt-Svc: h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
2021.02.07 18:19:48 5: Calendar Cal.GoFrank: HTTP response code 200
2021.02.07 18:19:48 5: Starting notify loop for Cal.GoFrank, 1 event(s), first is retrieved
2021.02.07 18:19:48 5: createNotifyHash
2021.02.07 18:19:48 5: End notify loop for Cal.GoFrank
2021.02.07 18:19:49 5: SubProcess 3689 created.
2021.02.07 18:19:49 4: Calendar Cal.GoFrank: parsing data asynchronously (PID= 3689)
2021.02.07 18:19:49 5: SubProcess 3689 started.
2021.02.07 18:19:49 5: Calendar Cal.GoFrank: control passed back to main loop.
2021.02.07 18:19:50 4: Calendar Cal.GoFrank: still waiting (read: no data).
2021.02.07 18:19:51 4: Calendar Cal.GoFrank: still waiting (read: no data).
2021.02.07 18:19:52 4: Calendar Cal.GoFrank: still waiting (read: no data).
2021.02.07 18:19:53 4: Calendar Cal.GoFrank: still waiting (read: no data).
2021.02.07 18:19:54 4: Calendar Cal.GoFrank: still waiting (read: no data).
2021.02.07 18:19:55 4: Calendar Cal.GoFrank: still waiting (read: no data).
2021.02.07 18:19:56 4: Calendar Cal.GoFrank: still waiting (read: no data).
2021.02.07 18:19:57 4: Calendar Cal.GoFrank: still waiting (read: no data).
2021.02.07 18:19:58 4: Calendar Cal.GoFrank: still waiting (read: no data).
2021.02.07 18:19:59 4: Calendar Cal.GoFrank: still waiting (read: no data).
2021.02.07 18:20:00 4: Calendar Cal.GoFrank: still waiting (read: no data).
2021.02.07 18:20:01 4: Calendar Cal.GoFrank: still waiting (read: no data).
2021.02.07 18:20:02 4: Calendar Cal.GoFrank: got result from asynchronous parsing.
2021.02.07 18:20:02 5: Waiting for SubProcess 3689...
2021.02.07 18:20:02 5: SubProcess 3689 ended.
2021.02.07 18:20:02 5: SubProcess 3689 terminated.
2021.02.07 18:20:02 4: Calendar Cal.GoFrank: asynchronous parsing finished.
2021.02.07 18:20:03 5: Starting notify loop for Cal.GoFrank, 1 event(s), first is parsed
2021.02.07 18:20:03 5: End notify loop for Cal.GoFrank
2021.02.07 18:20:03 4: Calendar Cal.GoFrank: merging data
2021.02.07 18:20:04 4: Calendar Cal.GoFrank: 19451 records processed, 0 new, 19451 known, 0 modified, 0 changed.
2021.02.07 18:20:04 4: Calendar Cal.GoFrank: creating calendar events
2021.02.07 18:20:04 5: Starting notify loop for Cal.GoFrank, 3 event(s), first is calname: f.name@name.de
2021.02.07 18:20:04 5: End notify loop for Cal.GoFrank
2021.02.07 18:20:04 4: Calendar Cal.GoFrank: Checking times...
2021.02.07 18:20:04 5: Starting notify loop for Cal.GoFrank, 3 event(s), first is modeUpcoming: jo452s97h1hrpitodlkbobrr2kgooglecom;u2b9tmpalhb05a63h2e0h94938googlecom;j3nveu5s4govmvhqj5gvrj2lssgooglecom;couuj9mvs6mj61isb7ovtnpqjogooglecom;l9u0l8hf7v90dbu0bs8hlhuiusgooglecom;nlikshococc3o8lriet8esc5togooglecom;1vti5k6poecars6khelak25e0ogooglecom;eiudgt7qfrd25vt86g9aama0ucgooglecom;q1q4m9bu7mfbhc6hir53a78kg0googlecom;d50f224gg46mp3aff5g2re4l64googlecom;gtlijhgtfhrifqrar7jeabrt98googlecom;402e19k1dfgf7f3k2nhip6qahcgooglecom;8h4er7q9u541m36o30se5vmvsogooglecom;emrnklk1goe9imoopr9k4kf9logooglecom;1d82f523eddf458fb891aa0c85ae1f21;tsdn0dp9v1pfkbea2ing3vsnqkgooglecom;97a42c36c6564e7d85cec6720dd1a107;5cpt8fu1v1f330s318r66ms50kgooglecom;33d7cc65456d4d44afa8c81466b50502;2mu0f1btbs5sidjprgc13etnaggooglecom;6go62dr4cgqj4bb6c5j34b9k64sm2bb164r3ab9g64q62pj369h32d1ickgooglecom;46dhm891tuuhr5e28n3snrsshcgooglecom;dfd1s4uu92h92rjvtvlmatvorkgooglecom;sme2bjgr12q10ceded4n2qnefogooglecom;71imcp9k64r3ibb46sr3cb9k75j6abb260sjib9gc4om6cpg74q3ipj560googlecom
2021.02.07 18:20:04 5: CALVIEW Cal.ViewGoFrank - CALENDAR:Cal.GoFrank triggered, updating CALVIEW Cal.ViewGoFrank (CALVIEW_Notify) ...
2021.02.07 18:20:04 5: CALVIEW Cal.ViewGoFrank - All data:
...
2021.02.07 18:20:04 5: Starting notify loop for Cal.ViewGoFrank, 4 event(s), first is t: 0 td: 0 tm: 0
2021.02.07 18:20:04 5: End notify loop for Cal.ViewGoFrank
2021.02.07 18:20:04 5: CALVIEW Cal.ViewGoFrank - CALENDAR:Cal.GoFrank successfully got all updates for CALVIEW Cal.ViewGoFrank (CALVIEW_Notify). Now process updates...
2021.02.07 18:20:04 5: End notify loop for Cal.GoFrank
2021.02.07 18:20:04 5: Starting notify loop for Cal.GoFrank, 1 event(s), first is nextWakeup: 2021-02-07 19:19:39
2021.02.07 18:20:04 5: End notify loop for Cal.GoFrank
2021.02.07 18:20:04 4: Calendar Cal.GoFrank: process ended.
2021.02.07 18:20:17 4: Connection accepted from WEB_192.168.10.71_1442
2021.02.07 18:20:17 5: GET /fhem?cmd=style%20eventMonitor HTTP/1.1
Host: tux.server.my:8083


Dann etwas mehr.

RatisBow

Dr. Boris Neubert

Fein. Es läuft in unter einer Sekunde.

Jetzt muss ich mir noch überlegen, wie es richtig realisiert werden muss.

Du bist erstmal mit einer Lösung versorgt, nicht wahr?
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!


Dr. Boris Neubert

Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

betateilchen

Hallo Boris,

ich habe mir die Ankündigung und den darin enthaltenen Hinweis angeschaut. Es dürfte wahrscheinlich recht unwahrscheinlich (zumindest nicht der Normalfall) sein, dass ein User sein FHEM nicht innerhalb von 400 Tagen einmal neu startet, deshalb betrachte ich das als eher akademisches Problem.

Aber trotzdem stellt sich mir folgende Frage:

Könnte man nicht innerhalb eines Calendar-device intern per timer ein reload einplanen, dessen Zeitpunkt sich entweder am Attributwert cutoffLaterThan bzw. an den 400 Tagen in der Zukunft orientiert und den reload einen Tag vorher durchführt?
-----------------------
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

Zitat von: betateilchen am 17 März 2021, 19:27:11
Könnte man nicht innerhalb eines Calendar-device intern per timer ein reload einplanen, dessen Zeitpunkt sich entweder am Attributwert cutoffLaterThan bzw. an den 400 Tagen in der Zukunft orientiert und den reload einen Tag vorher durchführt?

Ich hatte darüber nachgedacht, das so zu implementieren, und dann verworfen. Der Nutzen ist gering, zumal das Designproblem noch niemanden aufgestoßen ist.

Korrekterweise müsste man eigentlich sehr viel häufiger als min(400d, cutoffLaterThan) nachsehen: nehmen wir mal wöchentliche Termine an. Dann fehlt jede Woche einer mehr am Ende der Terminserie, den man eigentlich in FHEM sehen müsste (auch wenn er noch nichts auslösen kann). Und eigentlich müsste man auch nur diese Serie von Terminen dann neu generieren.

Das war mir dann zu kompliziert bzw. war mein Anspruch, wie ich es realisieren würde, so hoch, dass ich aus Sorge vor der Arbeit die Lust verloren hatte.  :-[ 
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!