Hallo zusammen,
habe im Google Calendar folgenden Serientermin angelegt:
Start Di 15:12 Ende Di 15:14. Immer Dienstags, keine Begrenzung nach hinten.
Erwartetes Verhalten: um 15:12 ein "start"-Event. Kommt auch.
Problem Statement: um 15:14 erhalte ich kein "end"-Event.
Komplikation: In den einschlägigen Beiträgen hier im Forum wird darauf verwiesen, dass ggfls. über die Plug-In Lösung Ende-Zeiten gesetzt werden sollen. Verstehe ich aber in meinem Fall nicht, da zwar die Serie an sich kein Ende hat, aber jeder einzelne Termin.
Was muss ich tun, um um 15:14 ein Ende-Event zu erhalten?
Vorab führe ich ein deletereading calendar_julia .* durch, danach um 15:11 ein update.
Ich sehe folgende Readings:
READINGS:
2020-11-03 15:11:01 calname Julia
2020-11-03 15:11:01 lastUpdate 2020-11-03 15:11:00
2020-11-03 15:11:01 modeAlarm
2020-11-03 15:11:01 modeAlarmOrStart
2020-11-03 15:11:01 modeAlarmed
2020-11-03 15:10:22 modeChanged
2020-11-03 15:11:01 modeEnd
2020-11-03 15:11:01 modeEnded
2020-11-03 15:11:01 modeStart
2020-11-03 15:11:01 modeStarted
2020-11-03 15:10:22 modeUpcoming n1tvrj39529g0e1lbmd63qrkjggooglecom;2772dnlrlpunn2uavcec83rkhggooglecom
2020-11-03 15:11:01 nextUpdate 2020-11-03 17:11:00
2020-11-03 15:11:01 nextWakeup 2020-11-03 15:12:00
2020-11-03 15:11:01 state triggered
nach Start, also ein paar Sekunden nach 15:12. Der Termin hat wie erwartet und gewünscht begonnen.
READINGS:
2020-11-03 15:11:01 calname Julia
2020-11-03 15:11:01 lastUpdate 2020-11-03 15:11:00
2020-11-03 15:11:01 modeAlarm
2020-11-03 15:12:00 modeAlarmOrStart 2772dnlrlpunn2uavcec83rkhggooglecom
2020-11-03 15:11:01 modeAlarmed
2020-11-03 15:12:00 modeChanged 2772dnlrlpunn2uavcec83rkhggooglecom
2020-11-03 15:11:01 modeEnd
2020-11-03 15:11:01 modeEnded
2020-11-03 15:12:00 modeStart 2772dnlrlpunn2uavcec83rkhggooglecom
2020-11-03 15:12:00 modeStarted 2772dnlrlpunn2uavcec83rkhggooglecom
2020-11-03 15:12:00 modeUpcoming n1tvrj39529g0e1lbmd63qrkjggooglecom
2020-11-03 15:11:01 nextUpdate 2020-11-03 17:11:00
2020-11-03 15:12:00 nextWakeup 2020-11-03 15:14:00
2020-11-03 15:12:00 state triggered
nach Ende, also ein paar Sekunden nach 15:14. Der Termin taucht nicht in modeEnd(ed) auf.
READINGS:
2020-11-03 15:11:01 calname Julia
2020-11-03 15:11:01 lastUpdate 2020-11-03 15:11:00
2020-11-03 15:11:01 modeAlarm
2020-11-03 15:14:00 modeAlarmOrStart
2020-11-03 15:11:01 modeAlarmed
2020-11-03 15:14:00 modeChanged 2772dnlrlpunn2uavcec83rkhggooglecom
2020-11-03 15:11:01 modeEnd
2020-11-03 15:11:01 modeEnded
2020-11-03 15:14:00 modeStart
2020-11-03 15:14:00 modeStarted
2020-11-03 15:14:00 modeUpcoming 2772dnlrlpunn2uavcec83rkhggooglecom;n1tvrj39529g0e1lbmd63qrkjggooglecom
2020-11-03 15:11:01 nextUpdate 2020-11-03 17:11:00
2020-11-03 15:14:01 nextWakeup 2020-11-03 17:11:00
2020-11-03 15:14:00 state triggered
Und noch der Calview-Eintrag dazu:
2020-11-03 15:14:00 t_002_bdate 03.11.2020
2020-11-03 15:14:00 t_002_btime 15:12
2020-11-03 15:14:00 t_002_categories
2020-11-03 15:14:00 t_002_daysleft 0
2020-11-03 15:14:00 t_002_daysleftLong heute
2020-11-03 15:14:00 t_002_description
2020-11-03 15:14:00 t_002_duration 120
2020-11-03 15:14:00 t_002_edate 03.11.2020
2020-11-03 15:14:00 t_002_etime 15:14
2020-11-03 15:14:00 t_002_location
2020-11-03 15:14:00 t_002_mode next
2020-11-03 15:14:00 t_002_source calendar_julia
2020-11-03 15:14:00 t_002_sourcecolor white
2020-11-03 15:14:00 t_002_summary Schule
2020-11-03 15:14:00 t_002_timeshort 15:12 - 15:14
2020-11-03 15:14:00 t_002_weekday 2
2020-11-03 15:14:00 t_002_weekdayname Dienstag
Zeige mal bitte die Definition des Kalenders (list calendar_julia).
voila
Internals:
DEF ical url https://calendar.google.com/calendar/ical/***removed***/basic.ics 7200
FUUID 5f8d97aa-f33f-e3ae-85dc-837e66b03ab69c7f
FVERSION 57_Calendar.pm:0.219100/2020-05-10
NAME calendar_julia
NOTIFYDEV global
NR 101
NTFY_ORDER 50-calendar_julia
STATE triggered
TYPE Calendar
OLDREADINGS:
READINGS:
2020-11-03 17:10:23 calname Julia
2020-11-03 17:10:23 lastUpdate 2020-11-03 17:10:15
2020-11-03 15:11:01 modeAlarm
2020-11-03 15:41:00 modeAlarmOrStart
2020-11-03 15:11:01 modeAlarmed
2020-11-03 15:39:00 modeChanged 2772dnlrlpunn2uavcec83rkhggooglecom
2020-11-03 15:11:01 modeEnd
2020-11-03 15:11:01 modeEnded
2020-11-03 15:41:00 modeStart
2020-11-03 15:41:00 modeStarted
2020-11-03 17:10:23 modeUpcoming 2772dnlrlpunn2uavcec83rkhggooglecom;n1tvrj39529g0e1lbmd63qrkjggooglecom
2020-11-03 17:10:23 nextUpdate 2020-11-03 19:10:15
2020-11-03 17:10:23 nextWakeup 2020-11-03 19:10:15
2020-11-03 17:10:23 state triggered
Attributes:
alias Google Calendar Julia
cutoffOlderThan 1d
group KalenderSystem
hideOlderThan 1d
room Vorhersagen
Danke. Sehe keinen Grund.
Kannst Du mal bitte mit
get calendar_julia vevents
die VEVENTS auflisten und dann das mit der UID 2772dnlrlpunn2uavcec83rkhggooglecom raussuchen (leider von Hand) und hier posten?
Ist nicht wirklich Arbeit, in diesem Kalender soll sich nur FHEM-relvantes befinden, d.h. sehr überschaubares Termin-Aufkommen. Habe #38 dringelassen wegen der Referenz auf #40, was der gesuchte Serientermin ist. Falls Du Dich wunderst warum der Serientermin nun ein Ende hat obwohl ich in Post #1 geschrieben habe, dass er nicht endet. Ich hatte nach meinem Post den Serien-Endtermin in Google gesetzt auf 2021-02-02 und nochmal neu ausprobiert, das hat allerdings keine Änderungen gegenüber dem ursprünglichen Symptom gezeigt. Daher jetzt auch die Uhrzeiten 15:39-15:41. Also scheint das Phänomen unabhängig zu sein von der Frage, ob die Serie einen Endtermin hat oder nicht.
38: VEVENT @27 [obsolete, modified-old, refers to 40]
CREATED: 20201103T131114Z
DESCRIPTION:
DTEND: 20201103T154100
DTSTAMP: 20201103T143704Z
DTSTART: 20201103T153900
LAST-MODIFIED: 20201103T143658Z
LOCATION:
RRULE: FREQ=WEEKLY;WKST=MO;UNTIL=20210202T225959Z;BYDAY=TU
SEQUENCE: 4
STATUS: CONFIRMED
SUMMARY: Schule
TRANSP: OPAQUE
UID: 2772dnlrlpunn2uavcec83rkhg@google.com
>>> is a series
>>> Events:
>>> Skipped events:
### deleted nr 39 ###
40: VEVENT @27 [modified-new, refers to 38]
CREATED: 20201103T131114Z
DESCRIPTION:
DTEND: 20201103T154100
DTSTAMP: 20201103T163702Z
DTSTART: 20201103T153900
LAST-MODIFIED: 20201103T143658Z
LOCATION:
RRULE: FREQ=WEEKLY;WKST=MO;UNTIL=20210202T225959Z;BYDAY=TU
SEQUENCE: 4
STATUS: CONFIRMED
SUMMARY: Schule
TRANSP: OPAQUE
UID: 2772dnlrlpunn2uavcec83rkhg@google.com
>>> is a series
>>> Events:
2772dnlrlpunn2uavcec83rkhggooglecom end 03.11.2020 15:39-03.11.2020 15:41 Schule
2772dnlrlpunn2uavcec83rkhggooglecom upcoming 10.11.2020 15:39-10.11.2020 15:41 Schule
2772dnlrlpunn2uavcec83rkhggooglecom upcoming 17.11.2020 15:39-17.11.2020 15:41 Schule
2772dnlrlpunn2uavcec83rkhggooglecom upcoming 24.11.2020 15:39-24.11.2020 15:41 Schule
2772dnlrlpunn2uavcec83rkhggooglecom upcoming 01.12.2020 15:39-01.12.2020 15:41 Schule
2772dnlrlpunn2uavcec83rkhggooglecom upcoming 08.12.2020 15:39-08.12.2020 15:41 Schule
2772dnlrlpunn2uavcec83rkhggooglecom upcoming 15.12.2020 15:39-15.12.2020 15:41 Schule
2772dnlrlpunn2uavcec83rkhggooglecom upcoming 22.12.2020 15:39-22.12.2020 15:41 Schule
2772dnlrlpunn2uavcec83rkhggooglecom upcoming 29.12.2020 15:39-29.12.2020 15:41 Schule
2772dnlrlpunn2uavcec83rkhggooglecom upcoming 05.01.2021 15:39-05.01.2021 15:41 Schule
2772dnlrlpunn2uavcec83rkhggooglecom upcoming 12.01.2021 15:39-12.01.2021 15:41 Schule
2772dnlrlpunn2uavcec83rkhggooglecom upcoming 19.01.2021 15:39-19.01.2021 15:41 Schule
2772dnlrlpunn2uavcec83rkhggooglecom upcoming 26.01.2021 15:39-26.01.2021 15:41 Schule
2772dnlrlpunn2uavcec83rkhggooglecom upcoming 02.02.2021 15:39-02.02.2021 15:41 Schule
>>> Skipped events:
Die Lösung steht in der Doku im Code. Die musste ich erst nachlesen:
Zitat
In case of a series of calendar events, several calendar events may exist for
the same uid which may be in different modes. Therefore only the most
interesting mode is chosen over any other mode of any calendar event with
the same uid. The most interesting mode is the first applicable from the
following list:
- start
- alarm
- upcoming
- end
Weil der Termin schon wieder kommt, wird er in modeUpcoming geführt.
Ok verstehe. Aber was ist denn der Algorithmus der ,,most interesting" bestimmt. Mein Problem Statement ist ja, dass ich kein Ende Event bekomme. Die nächste Occurence des Termins liegt eine Woche in der Zukunft. Meine Erwartungshaltung wäre, dass das Ende Event kommt, der Kalendereintrag für sagen wir die Hälfte oder ein Drittel der Zeit zur nächsten Occurence, notfalls auch nur wenige Sekunden in modeStart(ed) steht. Aber als absolutes Minimum müsste doch der Event ausgelöst werden, dann könnte ich notfalls ja started auslesen, tut es aber auch nicht.
Sonst wären ja Serientermine zur Steuerung von FHEM Devices völlig ungeeignet, da man nie ein Ende sehen würde. Gibt es denn zumindest einen Workaround? Im schlimmsten Fall könnte ich changed auslesen (darauf gibts einen Event) und checken ob diese UID nicht mehr im started ist, fände ich aber weniger elegant als ein Ende Event zu bekommen.
Ich denke auch, dass ein Event end kommen müsste. Ich muss es an einem Beispiel mal selbst testen.
Zitat von: eddy242 am 03 November 2020, 19:47:45
Gibt es denn zumindest einen Workaround? Im schlimmsten Fall könnte ich changed auslesen (darauf gibts einen Event) und checken ob diese UID nicht mehr im started ist
Interessant fände ich einen Auszug aus dem Event Monitor, wenn der changed Event kommt. Eigentlich steht dort ja auch "start" oder "end" drin, wenn alles korrekt läuft.
Irgendwas muss FHEM ja dazu bringen, den changed Event zu erzeugen.
Ok der Versuch macht klug. Ich nehme die Aussage das ,,end"-Event-kommt-nicht zurück. Ich könnte also aus dem end-Event die UID rausholen. Soweit so gut, bleibt aber das Problem, das modeEnd(ed) reading leer bleibt. Um also mit get calender_julia events von der UID aus dem Event auf den Inhalt zu kommen, müsste ich in Zukunft eine Fallunterscheidung machen.Wenn der Event KEIN Serientermin, hole die UID für die Event-Inhalte aus ModeEnd(ed). Wenn der Event ein Serientermin, dann hole die UID aus upcoming. Das fände ich nicht elegant, würde aber gehen, solange es noch einen nächsten Termin gäbe. Wenn der gerade abgelaufene der Letzte der Serie ist und es keinen Upcoming gibt, würde das ins Leere laufen. Wäre es nicht möglich, einfacher und eleganter wenn auch bei einem abgelaufenen Serientermin-Event die üblichen Readings modeEnd und modeEnded befüllt werden könnten?
2020-11-03 21:04:00.554 Calendar calendar_julia changed: 2772dnlrlpunn2uavcec83rkhggooglecom start
2020-11-03 21:04:00.554 Calendar calendar_julia start: 2772dnlrlpunn2uavcec83rkhggooglecom
2020-11-03 21:04:00.554 Calendar calendar_julia modeUpcoming: n1tvrj39529g0e1lbmd63qrkjggooglecom
2020-11-03 21:04:00.554 Calendar calendar_julia modeAlarmOrStart: 2772dnlrlpunn2uavcec83rkhggooglecom
2020-11-03 21:04:00.554 Calendar calendar_julia modeChanged: 2772dnlrlpunn2uavcec83rkhggooglecom
2020-11-03 21:04:00.554 Calendar calendar_julia modeStart: 2772dnlrlpunn2uavcec83rkhggooglecom
2020-11-03 21:04:00.554 Calendar calendar_julia modeStarted: 2772dnlrlpunn2uavcec83rkhggooglecom
2020-11-03 21:04:00.554 Calendar calendar_julia triggered
2020-11-03 21:04:00.559 Calendar calendar_julia nextWakeup: 2020-11-03 21:06:00
...
2020-11-03 21:06:00.519 Calendar calendar_julia changed: 2772dnlrlpunn2uavcec83rkhggooglecom end
2020-11-03 21:06:00.519 Calendar calendar_julia end: 2772dnlrlpunn2uavcec83rkhggooglecom
2020-11-03 21:06:00.519 Calendar calendar_julia modeUpcoming: 2772dnlrlpunn2uavcec83rkhggooglecom;n1tvrj39529g0e1lbmd63qrkjggooglecom
2020-11-03 21:06:00.519 Calendar calendar_julia modeAlarmOrStart:
2020-11-03 21:06:00.519 Calendar calendar_julia modeStart:
2020-11-03 21:06:00.519 Calendar calendar_julia modeStarted:
2020-11-03 21:06:00.519 Calendar calendar_julia triggered
2020-11-03 21:06:00.523 Calendar calendar_julia nextWakeup: 2020-11-03 23:00:58
ich versteh das Problem gar nicht, die UID für den auslösenden Termin steht doch immer im Event ($EVTPARTx)? Die musst Du doch nirgends extra rauslesen?
Beispiel:
define n_TestKalender notify TestKalender:changed:.*start {\
fhem("set Server on") if defined fhem('get '.$NAME.' events filter:uid=="'.$EVTPART1.'",field(summary)=~"(?i)sprechstunde" limit:count=1,from=0',1)\
}
Vielen Dank an alle Antworten- nun ist der Groschen bei mir Gefallen wie ich meine Abfrage-Logik ändere. Bisher habe ich auf die Inhalte der Readings modeEnd(Ed) bzw. modeStarted verlassen. Das ist nach den Erkenntnissen des heutigen Tages der Holzweg zumindest bei ended. Ich muss einzig die Inhalte des change-Events auswerten und dort prüfen, ob es ein Start-oder Ende Event ist, die UID habe ich ja dann auch. Also damit ist mein Problem gelöst, nochmals danke für den Anschub. Ich würde allerdings bei meiner Aussage aus dem vorigen Post bleiben, wäre es nicht nachdenkenswert, modeEnd(ed) auch zu befüllen?
Grüße eddy242
Zitat von: eddy242 am 03 November 2020, 21:41:19
Bisher habe ich auf die Inhalte der Readings modeEnd(Ed) bzw. modeStarted verlassen. Das ist nach den Erkenntnissen des heutigen Tages der Holzweg zumindest bei ended. Ich muss einzig die Inhalte des change-Events auswerten und dort prüfen, ob es ein Start-oder Ende Event ist, die UID habe ich ja dann auch. Also damit ist mein Problem gelöst, nochmals danke für den Anschub. Ich würde allerdings bei meiner Aussage aus dem vorigen Post bleiben, wäre es nicht nachdenkenswert, modeEnd(ed) auch zu befüllen?
Hast Du eigentlich mal in die Dokumentation geschaut und diese auch gelesen? Da steht doch ausdrücklich
ZitatIn particular, you will never see the UID of a series in modeEnd or modeEnded as long as the series has not yet ended - the UID will be in one of the other mode... readings. This means that you better do not trigger FHEM events for series based on mode... readings. See below for a recommendation.
Und alternative Lösungsbeispiele finden sich dort auch.
Works as designed.
@Boris: hattest Du nicht schon vor längerem den Plan, die mode... readings insgesamt abzuschaffen, weil Du beim redesign des Calendar-Moduls das Verhalten und die event-Steuerung komplett umgebaut hattest?
Du hast mMn sogar die gute Wahl ob Du exakt auf TestKalender:start:.* TestKalender:end:.* oder eben auf TestKalender:changed:.* triggerst - bei den ersten beiden weißt Du wo Du bist und hast getrennte Routinen dahinter, beim dritten könntest Du in EINER Routine auswerten "wo bin ich". Es gibt da aber noch viele Möglichkeiten.
In die mode Readings selbst schau ich eigentlich nie. ;)
Zitat von: Otto123 am 03 November 2020, 22:00:26
beim dritten könntest Du in EINER Routine auswerten "wo bin ich".
Zwei Anwendungsbeispiele habe ich vor einiger Zeit im angepinnten Beitrag ganz oben in diesem Unterforum beschrieben.
Zitat von: betateilchen am 03 November 2020, 21:50:06
@Boris: hattest Du nicht schon vor längerem den Plan, die mode... readings insgesamt abzuschaffen, weil Du beim redesign des Calendar-Moduls das Verhalten und die event-Steuerung komplett umgebaut hattest?
Ja, hattest Du, vor ziemlich genau fünf Jahren:
https://forum.fhem.de/index.php/topic,44731.msg365484.html#msg365484
Zitat von: Dr. Boris Neubert
Ich denke sogar darüber nach, die mode...-Readings zu eliminieren.
Die damalige Diskussion zum Thema Calview muss man nun nicht noch einmal führen. Es wären fünf Jahre Zeit gewesen, das Modul entsprechend umzubauen.
Und seit Mitte 2017 gibt es sogar noch ein zweites Calview Modul speziell für Google Kalender.
Aus meiner Sicht sind die mode...-readings als Altlast entbehrlich, weil man mit den vor 5 Jahren neu bereitgestellten Mechanismen viel flexibler arbeiten kann.
Zitat von: betateilchen am 03 November 2020, 22:16:16
Ja, hattest Du, vor ziemlich genau fünf Jahren:
https://forum.fhem.de/index.php/topic,44731.msg365484.html#msg365484
Die damalige Diskussion zum Thema Calview muss man nun nicht noch einmal führen. Es wären fünf Jahre Zeit gewesen, das Modul entsprechend umzubauen.
Und seit Mitte 2017 gibt es sogar noch ein zweites Calview Modul speziell für Google Kalender.
Aus meiner Sicht sind die mode...-readings als Altlast entbehrlich, weil man mit den vor 5 Jahren neu bereitgestellten Mechanismen viel flexibler arbeiten kann.
Auf meinem Entwicklungsrechner befindet sich nun eine Version vom Calendar-Modul, bei dem die mode-Readings nicht nur standardmäßig nicht mehr gesetzt werden sondern auch gelöscht werden, sofern es welche gibt. :-*
Wer die mode-Readings unbedingt braucht, bekommt sie per Attribut wieder.
Es gibt dann noch der Fairness halber eine Ankündigung dazu, bevor das Modul verteilt wird.