Hallo,
ich möchte meinen Dienstplan in FHEM integrieren um darüber weitere Dinge zu managen.
Nun habe ich mittels "define Schichtplan Calendar ical https://www.google.com/calendar/ical/blaaagroup.calendar.google.com/private-blub/basic.ics" den Kalender eingebunden.
Die Termine werden auch brav abgeholt, soweit gut.
Um die Sache anschaulich zu machen, habe ich eine ReadingsGroup aufgesetzt und bin auf folgendes Problem gestoßen:
Beispiel morgen, 03.08., die folgenden Tage sind analog dazu.
Im Google Kalender sehe ich: Urlaub
Importiere ich mit obigen Link in meinen Thunderbird: Urlaub
In FHEM wurde importiert:
Datum
Uhrzeit
Text
Endet am
End um
20.07.2015
00:00:00
EU
10.08.2015
00:00:00
20.07.2015
00:00:00
EU
10.08.2015
00:00:00
03.08.2015
06:30:00
Frühdienst
03.08.2015
14:45:00
03.08.2015
13:45:00
Spätdienst
03.08.2015
22:15:00
03.08.2015
13:45:00
Spätdienst
03.08.2015
22:15:00
Ich habe also 5 Termine für den 03.08. importiert, von denen genau einer real im Kalender steht, nämlich bis 10.08. EU.
Für mich derzeit einzig vorstellbar Möglichkeit, warum dieser Fehler auftritt, woher die andere Einträge stammen:
Ich trage die Termine mit einer Wiederholung im 7-Wochentakt ein (Dienstplan von 7 Wochen)
Anfang des Jahres, quasi in einer Urfassung des Kalenders hat für den morgigen Montag vielleicht(!) auch mal Frühdienst gestanden, vielleicht(!) auch mal Spätdienst.
Letzteres jedoch gewiss nicht doppelt.
Aber spätestens seitdem ich diesen (per Wiederholung eingetragenen) Termin gelöscht habe, müsste er ja auch aus der .ics raus sein.
Im Thunderbird wird es ja auch so umgesetzt.
Die Frage ist nun, wie ich dem am besten gegensteuern kann.
Hat jemand nen Tipp für mich?
Ich werde den Kalender jetzt nochmal löschen und neu definieren. Manchmal sind ja schon verrückte Sachen passiert.
Danke,
vb
Edit: Screen angehangen
Edit2: Löschen und neu anlegen hat leider nichts gebracht.
wenn du ein
get schichtplan full all
machst, werden die termine dann angezeigt?
Hi Chris,
ja, dort stehen die falschen Termine auch drin.
Ich habe gestern Abend noch probiert, den Kalender über ne Datei einzulesen, statt über die URL, aber alles ohne Erfolg.
vb
Hallo,
kannst Du bitte mal die ical-Datei mit
wget https://www.google.com/calendar/ical/blaaagroup.calendar.google.com/private-blub/basic.ics (http://wget%20https://www.google.com/calendar/ical/blaaagroup.calendar.google.com/private-blub/basic.ics)
abholen und hier als Anhang hinterlegen. Ich vermute, dass die Wiederholart des Termins nicht unterstützt wird. Oder alternativ den Kalender zum Lesen freigeben und die URL der Freigabe hier posten. Dann kann ich das untersuchen.
Viele Grüße
Boris
Hallo Boris,
sehr gern.
Wenn du die .ics geladen hast, sag bitte Bescheid, dann kann ich den Anhang wieder löschen.
Muss ja nicht jeder über jede Suchmaschine abrufen können, wie ich zu arbeiten habe ;)
Danke,
vb
Hallo,
habe den Anhang für Dich gelöscht.
Die Kombination WEEKLY, INTERVAL>1 und BYDAY geht schief, ist im Kode auch so dokumentiert.
Muss ich mir in Ruhe ansehen, wie das zu lösen sein könnte.
Grüße
Boris
Danke für deine Zeit.
für mich zum Verständnis:
Wenn ich jeden Termin einzeln eintragen würde, gäbe es diese Probleme nicht?
Hast du, so aus dem Bauch, ne Idee wie ich das Problem Kalenderseitig umschiffen könnte, ohne einzeln einzutragen?
vb
Hallo,
probiere bitte mal die beigefügte Version - ich habe nur eine Zeile einfügen müssen.
Viele Grüße
Boris
EDIT: Anhang entfernt
Darf man hier "Alter!!" sagen, um seinen Respekt zum Ausdruck zu bringen?? ;)
Was ich auf die schnelle sehe, funktioniert.
Ich lasse mir inzwischen den nächsten zehn Termine anzeigen, und diese sind alle korrekt.
Auch Beginn und Ende stimmen, keine Dopplungen mehr drin.
Ganz großes Danke!!
Kann ich noch irgendwas testen, um deinen Erfolg zu verifizieren??
vb
edit:
sehe grade, zwei Termine fehlen.
Wenn du die ics noch hast, die Einträge vom 15. und 18. sind nicht dabei.
FHEM ist neu gestartet, Kalender geupdatet und reloadet.
edit2:
Ich lege den Kalender mal komplett neu an
edit: Es bleibt dabei. Die beiden Besagten Termine fehlen.
nochn Edit:
Habe als Test einen neuen Termin eingefügt, der wurde nach update/reload gleich angezeigt
Krass, der Termin mit der UID vup1jet6q16el6cutkqlrc2o8c@google.com steht zweimal in der iCal-Datei. Einmal als Einzeltermin am 15.08. und einmal als sich alle 7 Wochen wiederholender Termin (nächstes Auftreten: 22.08.). Der zweite Eintrag überschreibt den ersten.
Wie kann das passieren?
Kannst Du bitte mal in den Google-Kalender schauen und sehen, ob es eine Erklärung dafür gibt?
Viele Grüße
Boris
Die Erklärung gibt es.
Kurzfassung: Diensttausch
Langfassung: Originaltermin liegt auf dem 22., ist eine Standartwiederholung, des Originals von irgendwann. Wiederholung alle 7 Wochen.
In diesem speziellen Fall habe ich jedoch mit einem Kollegen den Dienst getauscht, so dass ich den Termin einfach vom 22. auf den 15. verschoben habe.
Nur diesen einen.
Ich vermute das, quasi intern, der 22. noch gebucht ist eben wegen der Wiederholung.
vb
So, heute wieder ein großer Fortschritt im Kalendermodul zu verzeichnen!
Gemäß RFC 2445 dürfen mehrere Ereignisse die selbe UID haben. Sie unterscheiden sich dann in der SEQUENCE-Nummer. Ich habe die modulinterne UID durch Konkatenation der (gesäuberten) UID aus dem Kalender und der SEQUENCE gebaut.
Damit sollte es jetzt bei Dir funktionieren. Ich habe die Version eingecheckt.
Viele Grüße
Boris
Mahlzeit Boris,
Danke für deine Arbeit und die neue Version.
Ich habe FHEM geupdatet und neu gestartet, den Kalender mit allem Zubehör gelöscht und neu angelegt, wiederum gestartet.
Leider habe ich jetzt den Effekt aus meinem Eröffnungspost.
Für morgen habe ich Früh, Spät- und Nachtdienst, jeweils doppelt eingetragen.
Da fand ich die Version von gestern besser ;)
Ich muss mal heute nix machen und die Tage mich nochmal frisch ans Werk machen...
Ich kann und will nicht ausschliessen, das der Fehler auf meiner Seite liegt, will aber verhindern das durch meine Unfähigkeit bei dir Mehrarbeit ankommt.
Ich hänge mal den Auszug meiner .cfg dran, vielleicht habe ich da ja auch nen groben Fehler drin.
define Schichtplan Calendar ical url https://www.google.com/calendar/ical/kenneichauch.calendar.google.com/private-isbekannt/basic.ics 3600
attr Schichtplan room Kalender
define Kal_Schicht CALVIEW Schichtplan 2
attr Kal_Schicht modes all
attr Kal_Schicht room Kalender
define rg_Kal_Schicht readingsGroup <Datum>,<Uhrzeit>,<Text>,<Endet am>,<End um> Kal_Schicht:t_001_bdate,t_001_btime,t_001_summary,t_001_edate,t_001_etime Kal_Schicht:t_002_bdate,t_002_btime,t_002_summary,t_002_edate,t_002_etime Kal_Schicht:t_003_bdate,t_003_btime,t_003_summary,t_003_edate,t_003_etime Kal_Schicht:t_004_bdate,t_004_btime,t_004_summary,t_004_edate,t_004_etime Kal_Schicht:t_005_bdate,t_005_btime,t_005_summary,t_005_edate,t_005_etime Kal_Schicht:t_004_bdate,t_004_btime,t_004_summary,t_004_edate,t_004_etime Kal_Schicht:t_005_bdate,t_005_btime,t_005_summary,t_005_edate,t_005_etime Kal_Schicht:t_006_bdate,t_006_btime,t_006_summary,t_006_edate,t_006_etime Kal_Schicht:t_007_bdate,t_007_btime,t_007_summary,t_007_edate,t_007_etime Kal_Schicht:t_008_bdate,t_008_btime,t_008_summary,t_008_edate,t_008_etime Kal_Schicht:t_009_bdate,t_009_btime,t_009_summary,t_009_edate,t_009_etime Kal_Schicht:t_010_bdate,t_010_btime,t_010_summary,t_010_edate,t_010_etime
attr rg_Kal_Schicht room Kalender
define at_rg_Kal_Schicht at +*02:00 {\ my $i;; \ my $modtext = "<Datum>,<Uhrzeit>,<Text>,<Endet am>,<End um> ";;\ for($i= 1;;$i<= ReadingsVal("Kal_Schicht","c-tomorrow", 0);;$i++){\ $modtext .= "Kal_Schicht:<Morgen>,tomorrow_".sprintf('%03d',$i)."_btime,tomorrow_".sprintf('%03d',$i)."_summary,tomorrow_".sprintf('%03d',$i)."_edate,tomorrow_".sprintf('%03d',$i)."_etime ";;}\ for($i= 1;;$i<= ReadingsVal("Kal_Schicht","c-today", 0);;$i++){\ $modtext .= "Kal_Schicht:<Heute>,today_".sprintf('%03d',$i)."_btime,today_".sprintf('%03d',$i)."_summary,today_".sprintf('%03d',$i)."_edate,today_".sprintf('%03d',$i)."_etime ";;}\ for($i= 1;;$i<= ReadingsVal("Kal_Schicht","c-term", 0);;$i++){\ $modtext .= "Kal_Schicht:t_".sprintf('%03d',$i)."_bdate,t_".sprintf('%03d',$i)."_btime,t_".sprintf('%03d',$i)."_summary,t_".sprintf('%03d',$i)."_edate,t_".sprintf('%03d',$i)."_etime ";;}\ fhem("modify rg_Kal_Schicht $modtext");;\ }
Nu geh ich erstmal in Familie das Wetter nutzen.
Bis später.
vb
Die neue Version gibt es erst morgen per Update. Du musst sie aus dem SVN Repo laden. Das Update hat Dir wieder die Version vom Freitag beschert.
Viele Grüße
Boris
Ah... Das erklärt natürlich alles.
Begreife ich auch irgendwann, das es erst am nächsten Morgen nach acht per update funktioniert.
Werde die Version aus dem svn heute abend noch testen.
sooo Boris,
ich habe mir die Datei nun aus dem svn geladen und "eingebaut".
Einzig der 14tägige Termin Dienstags machte Probleme.
Nachdem ich den aber kurzerhand im Kalender gelöscht und neu angelegt habe, wird er nun auch im Modul angezeigt.
Bis hierhin also alles bestens.
Nun mal sehen, wie ich meine Planungen damit umsetzen kann.
Vielen Dank für deine Arbeit!!
vb
hmm, irgendwie habe ich Probleme mit der neuen Version.
Der Abruf per url funktioniert, der Abruf per file nicht mehr (gleicher Kalender).
Fehlermeldung: Can't call method "updateFromCalendar" on an undefined value at ./FHEM/57_Calendar.pm line 1026.
hab' ich schon gefixt. Kommt morgen früh im update. Oder jetzt im SVN Repo.
Boris
Guten Abend,
eigentlich wollte ich vor dieses Thema ein [gelöst] setzen, aber das kann ich noch nicht.
Wobei in mir wieder der Gedanke keimt, es könnte (m)ein Konfigurationsproblem sein.
Zum Startproblem dieses Threads...
Ich hatte hier wieder Dopplungen von Terminen drin. Auch Ungereimtheiten, bzgl. verschobener Termine.
Letztere bestehen auch noch teilweise. Stichwort "Diensttausch" 22.08. <-> 15.08.
Viel "schwerer" liegt mir aber das folgende im Magen:
Zur Erklärung...
Schon seit einigen Monaten nutze ich dieses Modul, um einen sog. Müllkalender auszulesen.
Anfangs des Jahres trage ich die betreffenden Termine in einen Googlekalender ein, auf den mehrere Personen Zugriff haben.
Die Termine für die Abholung wiederholen sich zwei- oder auch vierwöchentlich, wie man das so kennt.
In Zusammenhang mit dem Yowsup-Modul bekommen alle Interessierten am Tage zuvor eine Whatsapp-Nachricht, welche Tonne bereit gestellt werden soll.
In den letzten Monaten funktionierte das auch Reibungslos und Termingerecht.
Nach dem Update von oben, um Wiederholungen noch besser nutzen zu können, habe ich jedoch Probleme.
1. mir wird als erstes ein Termin in der Vergangenheit angezeigt. Nur ein einziger, immer der gleiche.
Hier kann ich CALVIEW überreden, mir den auszublenden. Habe ich im Moment bewusst nicht getan. Zuvor war es auch nicht nötig.
2. Termine in der Zukunft, sind um ein/zwei Woche(n) verschoben.
Bsp:
Im Kalender steht: 21.08. Gelber Sack
FHEM/CALVIEW: 28.08. Gelber Sack
Im Kalender: 31.08. schwarze Tonne
FHEM : 14.09. schwarze Tonne
Nun sind das Calendar- und CALVIEW Modul zwei paar Schuhe. Das ist mir bewusst.
Da aber nach meinem dafürhalten CALVIEW nur anzeigt, was CALENDAR ausliest, würde ich hier gern die Spurensuche beginnen.
Auch und vorallem, weil es diese Verschiebungen erst seit dem Update für CALENDAR gibt. Zumindetens, soweit mir das aufgefallen ist.
Ich lasse mich jedoch auch gern belehren, und erstelle für das CALVIEW-Modul ein passendes Thema.
Da ich mir in diesem speziellen Kalender lediglich die nächsten drei Termine anzeigen lasse, könnte es theoretisch natürlich auch sein, das es diese Verschhiebung schon vor dem Update gab.
Ich habe den Kalender nun schon x-mal gekillt und neu angelegt. Sollt ich jedesmal den gleichen Fehler machen.
Aktuell sieht meine Konfig dazu so aus:
define Kalender_Muell Calendar ical url https://www.google.com/calendar/ical/c8q9m156n59vv6cflfralf0ul8%40group.calendar.google.com/public/basic.ics
attr Kalender_Muell room Kalender
define Kal_Muell CALVIEW Kalender_Muell 1
attr Kal_Muell modes modeAlarm,modeStart,modeStarted,modeUpcoming
attr Kal_Muell room Kalender
define rg_Kal_Muell readingsGroup <Datum>,<Uhrzeit>,<Text>,<Endet am>,<End um> Kal_Muell:t_001_bdate,t_001_btime,t_001_summary,t_001_edate,t_001_etime Kal_Muell:t_002_bdate,t_002_btime,t_002_summary,t_002_edate,t_002_etime Kal_Muell:t_003_bdate,t_003_btime,t_003_summary,t_003_edate,t_003_etime
attr rg_Kal_Muell room Kalender
define at_rg_Kal_Muell at +*23:55 {\ my $i;; \ my $modtext = "<Datum>,<Uhrzeit>,<Text>,<Endet am>,<End um> ";;\ for($i= 1;;$i<= ReadingsVal("Kal_Muell","c-tomorrow", 0);;$i++){\ $modtext .= "Kal_Muell:<Morgen>,tomorrow_".sprintf('%03d',$i)."_btime,tomorrow_".sprintf('%03d',$i)."_summary,tomorrow_".sprintf('%03d',$i)."_edate,tomorrow_".sprintf('%03d',$i)."_etime ";;}\ for($i= 1;;$i<= ReadingsVal("Kal_Muell","c-today", 0);;$i++){\ $modtext .= "Kal_Muell:<Heute>,today_".sprintf('%03d',$i)."_btime,today_".sprintf('%03d',$i)."_summary,today_".sprintf('%03d',$i)."_edate,today_".sprintf('%03d',$i)."_etime ";;}\ for($i= 1;;$i<= ReadingsVal("Kal_Muell","c-term", 0);;$i++){\ $modtext .= "Kal_Muell:t_".sprintf('%03d',$i)."_bdate,t_".sprintf('%03d',$i)."_btime,t_".sprintf('%03d',$i)."_summary,t_".sprintf('%03d',$i)."_edate,t_".sprintf('%03d',$i)."_etime ";;}\ fhem("modify rg_Kal_Muell $modtext");;\ }
attr at_rg_Kal_Muell room Kalender
Zur optischen Aufbereitung noch ein Anhang...
@Boris
Könntest du dir das mal bitte nochmal anschauen und ne Einschätzung abgeben?
Hat jemand der anderen User vielleicht noch eine Lösungsidee?
Herzlichen Dank.
vb
Hallo vb,
bitte sende mir die ical-Datei zu dem Müllkalender per PM.
Danke
Boria
ich denke der grund ist bei calendar zu suchen da ich im calview wirklich nur die daten aus diesem hole. es wird zur sortierung einmal das datum aus calendar per str2time konvertier.
die anzeige-daten allerdings nicht. im schlimmsten fall wäre also die sortierung nur nicht i.O.
ich habe wie es der zufall will auch einen muell-kalender und wie du.
termin ist auch
wiederholend, Wöchentlich am Freitag
wiederholend, Alle 2 Wochen am Freitag
wiederholend, Alle 2 Wochen am Montag
ich habe aktuell keine probleme und vor der neuen version auch keine
nebenbei: ein
attr rg_Kal_Muell nonames 1
attr rg_Kal_Schicht nonames 1
macht die rg hübscher ;-)
ich habe testweise mal einen termin gelöscht und ihn neu angelegt, genau wie vorher. nun hab ich eine 1-wöchige verschiebung im calendar
bioabfall ist am 24.08. calendar führt ihn am 31.08.
EDIT: gerade noch einen neuen Termin eingefügt -> auch hier eine verschiebung um genau 7 tage über die serie
per pm kann man keine anhänge machen. willst di sie als text in der pm?
Guten Morgen,
@Boris
ich hänge die Datei hier mit an, beim Müll sehe ich das nicht so angespannt, wie bei meinem Dienstplan.
Wird mir ja hoffentlich niemand meine volle Mülltonne aus der Einfahrt mausen :D
@Chris
Ich sehe das auch so, deswegen habe ich es hier mit eingehangen.
Lasse mich wie gesagt, aber auch gern eines besseren belehren, bin da im Ganzen noch immer nicht so firm wie ich es gern hätte.
Danke für den Tipp "nonames", du hast recht ;)
vb
ich habe wieder die
Zitat# $Id: 57_Calendar.pm 7701 2015-01-24 20:16:37Z borisneubert $
eingespielt. diese zeigt die serientermine wieder richtig an
Chris, kannst Du mir bitte auch Deinen Kalender zum Testen zur Verfügung stellen und die Problemtermine benennen? Heute ist auf zwei Wochen das letzte Mal, dass ich FHEMmen kann.
Viele Grüße
Boris
gerne
Hallo,
es gab einen Fehler bei der Berechnung der wöchentlich wiederkehrenden Ereignisse. Diesen habe ich beseitigt und eine neue Version eingecheckt. Es sollte außerdem jetzt auch funktionieren, dass ein Ereignis alle x Wochen Montag, Mittwoch und Freitag stattfindet - das habe ich aber nicht getestet.
Im Kalender von vb90 ist noch eine Merkwürdigkeit: es gibt ein Ereignis UID:bgk1ph6nc5bj8q4jdoiv0aqrq8@google.com mit zweimal derselben SEQUENCE:2 Das führt zu Problemen, die ich aber heute nicht mehr löse.
Außerdem habe ich es noch nicht geschafft, Serien, die beendet sind, gar nicht erst zu laden.
Viele Grüße
Boris
Kann mir jemand sagen, wo ich halbwegs übersichtlich nach diesem doppelten Event suchen kann, um eventuell herauszufinden, wo die Ursache dafür liegt?
Hilfreich wäre, wenn ich irgendwo sehen könnte, wie das Event in meinem Kalender heisst.
@Boris
Danke!
Werde morgen ein Update machen und berichten.
vb
Hallo,
du könntest in einer Shell mit
sort Kalender.ics | grep UID: | uniq -d
eine halbwegs übersichtliche Darstellung doppelter Einträge finden.
Gruß
Hans
Edit:
Und mit
grep -A 10 'UID:bgk1ph6nc5bj8q4jdoiv0aqrq8@google.com' Kalender.ics
den von Boris gefundenen doppelten Eintrag plus 10 Zeilen anzeigen lassen.
Edit2:
Einen hab' ich noch ;)
for i in `sort Kalender.ics | grep UID: | uniq -d`;do grep -A 10 $i Kalender.ics | grep -E 'UID|SEQUENCE';echo '---'; done
Zitat von: VB90 am 13 August 2015, 00:42:01
Kann mir jemand sagen, wo ich halbwegs übersichtlich nach diesem doppelten Event suchen kann, um eventuell herauszufinden, wo die Ursache dafür liegt?
Hilfreich wäre, wenn ich irgendwo sehen könnte, wie das Event in meinem Kalender heisst
so habe ich das gemacht : ical-Datei von Dir im Editor geöffnet, nach dem Anfang der oben genannten uid gesucht (gibt es mindestens dreimal), Events sind von BEGIN VEVENT und END VEVENT eingerahmt. Ein Eintrag ist entweder eine Serie (RRULE WEEKLY) oder ein außer-der-Reihe-Termin.
Ich muss den RFC lesen, ob die Beobachtung ein zulässiges VEVENT oder ein Bug im Google -Kalender ist.
Grüße
Boris
passt, termine sind so wie sie sein sollen. wennihc das richtig sehe zeigt der kalender immer nur das nächste event einer serie (beispiel bioabfall ist am 24.8. und dann wieder am 10.09.)
kann man im modul mit einbauen das auch x events einer serie gezeigt werden, evtl per attribut gesteuert?
kann ich so für mich leider nicht bestätigen.
trotz Update von FHEM bestehen die letztgenannten Fehler weiter.
vb
VB, bist Du sicher, die Version von gestern Abend zu verwenden und ein Reload gemacht zu haben? Hatte es mit Deiner Datei umfassend getestet.
Grüße
Boris
Hallo Boris,
ich habe heute, extra am nachmittag, ein Update vom FHEM gefahren.
Dabei wurde auch die calendar.pm geupdatet. Zumindest stand es so im EventLog, habe extra drauf geachtet.
Per WinSCP auf den Odroiden geschaut, die aktuelle Datei aufgemacht, steht in der 1. Zeile:
Zitat# $Id: 57_Calendar.pm 9063 2015-08-12 20:41:53Z borisneubert $
Also, ich sage: ja, ich nutze die Version von gestern Abend.
Ich werde jetzt probehalber den Müllkalender nochmals killen und nach Neustart vom FHEM neu anlegen.
Ich werde berichten.
vb
Muss mich korrigieren bzw. mein Statement erläutern.
Der um eine Woche verschobene Termin (gelber Sack im Kalender 21.08. vs. FHEM 28.0.) ist korrigiert.
Dieser wird nun richtig angezeigt.
Was immernoch falsch angezeigt wird:
vergangener Termin vom 04.05. im Müllkalender
Termin Spätdienst original am 22.08, verschoben auf 15.08., wird an beiden Tagen gelistet.
Das war mir auch auf den ersten Blick aufgefallen, daher meine Einlassung oben.
Sorry, das ich vorhin so kurz dran war, und dadurch Verwirrung gestiftet habe.
vb
# $Id: 57_Calendar.pm 9063 2015-08-12 20:41:53Z borisneubert $
Aktuell scheint es noch ein Problem mit wöchentlich wiederkehrenden Terminen zu geben, im Speziellen habe ich Probleme mit solchen Terminen, bei denen der Ende-Zeitpunkt nicht am gleichen Tag auftritt wie der Start-Zeitpunkt. Bestimmte Geräte schalte ich abends ein und am nächsten Morgen wieder aus. Das Einschalten funktioniert problemlos, aber die Geräte werden nicht wieder ausgeschaltet.
Nachtrag:
Das Fehlerverhalten ist neu. Die wöchentlich wiederkehrenden Termine hatten seit Monaten problemlos funktioniert. Das Problem habe ich erst seit einem am vergangenen Wochenende nach langer Zeit durchgeführten fhem Update.
ich trag mich hier kurz ein um mitzulesen (57_Calendar ist immer wieder mal ein Thema)
Glaube Boris ist derzeit im Urlaub ?
kvo1
Der Urlaub sei ihm gegönnt 8) und ich erwarte ja auch nicht sofort eine Lösung. Ich werde Version für Version zurückgehen, bis ich eine Modulversion finde, in der diese Kalendereinträge wieder korrekt funktionieren. Bis dahin behelfe ich mir mit einem at, das die betreffenden Geräte jeden Morgen explizit ausschaltet. Nicht schön, aber funktioniert.
Es wird zum End-Zeitpunkt einfach kein Event mehr ausgelöst, der ein notify triggern könnte.
Ein Test in der letzten Nacht hat gezeigt, dass ein einzelner, sich nicht wiederholender Termin über den Tageswechsel sowohl zum Start als auch zum Ende einen Event erzeugt und somit korrekt geschaltet wird.
Das Problem scheint also tatsächlich mit den Wiederholungen zusammenzuhängen.
Hallo,
der Einbau des asynchronen Herunterladens von iCal-Dateien mittels HttpUtils_NonblockingGet() zog doch noch einige Probleme und Race Conditions mit sich, die ich jetzt hoffentlich alle beseitigt habe.
Udo, ich kann nicht erkennen, warum Serientermine, die über Mitternacht laufen, kein Ende-Event (changed: uid end) senden sollten. Kannst Du bitte die beigefügte Version einmal bei Dir testen? Bitte berücksichtigen, dass die UID im Modul seit neuestem auch noch die SEQUENCE enthält.
In dieser Version habe ich die Funktion ausgebaut, die abgelaufene Termine aus der modulinternen Datenhaltung rauswirft. Grund hierfür ist, dass ich nach inniger Meditation über dem Kode zu dem Ergebnis gekommen bin, dass das so für Serientermine nicht funktioniert. Aus demselben Grunde bleiben auch Termine, die abgelaufen sind, mit dieser Version wieder in der modulinternen Datenhaltung. Ich lasse mir bezüglich des Status "expired" etwas anderes einfallen.
Was ich auch nicht lösen kann, sind die außer-der-Reihe-Termine, die sich bei gleicher UID und SEQUENCE nur durch die RECURRENCE-ID unterscheiden. Hier gewinnt immer der letzte Termin in der Datei aus allen mit gleicher UID und SEQUENCE. Das ruft nach einem substanziell neuen Konzept für die Verwaltung der Termine.
Für heute erstmal Schluss.
Viele Grüße
Boris
Hallo Boris,
ich habe die Moduldatei eben eingespielt und werde beobachten, was heute nacht passiert.
Sollte das Problem wieder auftreten, werde ich Dir die Kalenderdatei per email zuschicken, vielleicht hilft Dir das ja weiter.
Viele Grüße
Udo
Hallo Boris,
das Abschalten hat heute morgen mit Deiner Testversion funktioniert.
Allerdings verhält sich nun das Ganze sehr eigenartig:
2015.08.26 00:05:03 3: get oc_Schalter summary 069EDE597FAA42C5B3A22295DC95F3866 : sz_Bett_rechts
2015.08.26 00:05:03 3: get oc_Schalter summary 178C817DF4DF4FD0BE6401A97F88672F8 : sz_Bett_links
2015.08.26 00:05:03 3: get oc_Schalter summary 299295b8e90 : sz_Bett_rechts
2015.08.26 00:05:03 3: get oc_Schalter summary 2aa2504272968b45a9b67444105bb42b1 : sz_Bett_links
2015.08.26 00:05:03 3: get oc_Schalter summary 2d048395f0cd9a43816130f90d16b9010 : sz_Bett_links
2015.08.26 00:05:03 3: get oc_Schalter summary 2ea0060057f0584e8ea8ccbe0eb5545e0 : sz_Bett_rechts
2015.08.26 00:05:03 3: get oc_Schalter summary 3209f52d7a61744ab4136ca1f44cf1220 : sz_Bett_rechts
2015.08.26 00:05:03 3: get oc_Schalter summary 36a9c91e8240d74ea356fe644f251cfd1 : sz_Bett_links
2015.08.26 00:05:03 3: get oc_Schalter summary 3E48D93ED5BD4A7A8DCDAC835B3DFB6B5 : sz_Bett_rechts
2015.08.26 00:05:03 3: get oc_Schalter summary 431F217050BD46709BCCB867289B7CCB8 : sz_Bett_links
2015.08.26 00:05:03 3: get oc_Schalter summary 435d58b1060 : wz_Ventilator
2015.08.26 00:05:03 3: get oc_Schalter summary 49755CF095E645548CE6A77E91548CA30 : sz_Bett_rechts
2015.08.26 00:05:03 3: get oc_Schalter summary 4d16cadb4a0 : sz_Bett_rechts
2015.08.26 00:05:03 3: get oc_Schalter summary 615d578b54a6024088d3434bf85614350 : sz_Bett_rechts
2015.08.26 00:05:03 3: get oc_Schalter summary 7029FC1CB06E4C69B5544AC6111D9FB97 : sz_Bett_links
2015.08.26 00:05:04 3: get oc_Schalter summary 71D9538A84CD4E72A94B481FBAF9F01B6 : sz_Bett_rechts
2015.08.26 00:05:04 3: get oc_Schalter summary 84DD7A0AA6A34E6591DE51855CEC237D5 : sz_Bett_rechts
2015.08.26 00:05:04 3: get oc_Schalter summary 86752848B98C4B87A6E8BEC4DF5B890E6 : sz_Bett_rechts
2015.08.26 00:05:04 3: get oc_Schalter summary 8F7C870CF7FE4ADE8A7B13BEBBC2D6D80 : sz_Bett_links
2015.08.26 00:05:04 3: get oc_Schalter summary 8f3c37f9fe0 : sz_Bett_links
2015.08.26 00:05:04 3: get oc_Schalter summary 9003ab0900db8349b1c581d035419a290 : sz_Bett_rechts
2015.08.26 00:05:04 3: get oc_Schalter summary 952b47b92c0c014fa56ed0482a55fd050 : sz_Bett_rechts
2015.08.26 00:05:04 3: get oc_Schalter summary 95FA293E1C6A4B1C9469A09EC8BF04CB0 : sz_Bett_rechts
2015.08.26 00:05:04 3: get oc_Schalter summary 96d9c4c4530 : sz_Bett_rechts
2015.08.26 00:05:04 3: get oc_Schalter summary D564B2CD6BBF4D2AAAEAAB94CA429C805 : sz_Bett_rechts
2015.08.26 00:05:04 3: get oc_Schalter summary a0fe0f37ea0 : sz_Bett_links
2015.08.26 00:05:04 3: get oc_Schalter summary c7efa85c290d60448cdf1ed565f66ff70 : sz_Bett_links
2015.08.26 00:05:04 3: get oc_Schalter summary e002694a7e0 : sz_Bett_links
2015.08.26 00:05:04 3: get oc_Schalter summary e8332e5d540 : sz_Bett_links
2015.08.26 00:05:04 3: get oc_Schalter summary ec6254ed310 : sz_Bett_links
2015.08.26 00:05:04 3: get oc_Schalter summary f07d4a83c60 : sz_Bett_rechts
2015.08.26 00:05:04 3: get oc_Schalter summary f571dd9a940b85439eb3568e3702b3750 : sz_Bett_links
Der einzige Termin, der im Kalender wirklich für 00:05 Uhr eingeplant war, war das Abschalten von wz_Ventilator. Warum die ganze Menge von Events mein notify
oc_Schalter:modeEnded.* { oc_SchalterEnde("$EVENT") }
triggern, ist mir unklar.
Zitat von: betateilchen am 26 August 2015, 06:51:55
Warum die ganze Menge von Events mein notify ... triggern, ist mir unklar.
ich habe gerade mal ein bisschen weitergesucht. Ein "get ... full all" liefert mir
84DD7A0AA6A34E6591DE51855CEC237D5 expired end 13.11.2014 21:00:00-14.11.2014 05:00:00 sz_Bett_rechts
069EDE597FAA42C5B3A22295DC95F3866 expired end 14.11.2014 21:00:00-15.11.2014 05:00:00 sz_Bett_rechts
86752848B98C4B87A6E8BEC4DF5B890E6 expired end 15.11.2014 21:00:00-16.11.2014 05:00:00 sz_Bett_rechts
178C817DF4DF4FD0BE6401A97F88672F8 expired end 27.11.2014 08:00:00-28.11.2014 08:00:00 sz_Bett_links
3E48D93ED5BD4A7A8DCDAC835B3DFB6B5 expired end 27.11.2014 21:00:00-28.11.2014 05:00:00 sz_Bett_rechts
431F217050BD46709BCCB867289B7CCB8 expired end 28.11.2014 21:00:00-29.11.2014 08:00:00 sz_Bett_links
D564B2CD6BBF4D2AAAEAAB94CA429C805 expired end 28.11.2014 21:00:00-29.11.2014 05:00:00 sz_Bett_rechts
7029FC1CB06E4C69B5544AC6111D9FB97 expired end 29.11.2014 21:00:00-30.11.2014 08:00:00 sz_Bett_links
71D9538A84CD4E72A94B481FBAF9F01B6 expired end 29.11.2014 21:00:00-30.11.2014 05:00:00 sz_Bett_rechts
a0fe0f37ea0 expired end 23.12.2014 05:00:00-24.12.2014 08:00:00 sz_Bett_links
ec6254ed310 expired end 24.12.2014 20:00:00-25.12.2014 08:00:00 sz_Bett_links
8f3c37f9fe0 expired end 25.12.2014 20:00:00-26.12.2014 08:00:00 sz_Bett_links
96d9c4c4530 expired end 25.12.2014 21:00:00-26.12.2014 05:00:00 sz_Bett_rechts
e002694a7e0 expired end 26.12.2014 20:00:00-27.12.2014 08:00:00 sz_Bett_links
f07d4a83c60 expired end 26.12.2014 21:00:00-27.12.2014 05:00:00 sz_Bett_rechts
e8332e5d540 expired end 27.12.2014 20:00:00-28.12.2014 08:00:00 sz_Bett_links
299295b8e90 expired end 27.12.2014 21:00:00-28.12.2014 05:00:00 sz_Bett_rechts
4d16cadb4a0 expired end 03.01.2015 01:00:00-04.01.2015 05:00:00 sz_Bett_rechts
435d58b1060 expired end 14.01.2015 13:30:00-14.01.2015 15:00:00 wz_Ventilator
2aa2504272968b45a9b67444105bb42b1 expired end 18.03.2015 21:00:00-19.03.2015 08:00:00 sz_Bett_links
36a9c91e8240d74ea356fe644f251cfd1 expired end 19.03.2015 21:00:00-20.03.2015 08:00:00 sz_Bett_links
615d578b54a6024088d3434bf85614350 expired end 19.03.2015 21:00:00-20.03.2015 05:00:00 sz_Bett_rechts
952b47b92c0c014fa56ed0482a55fd050 expired end 20.03.2015 21:00:00-21.03.2015 05:00:00 sz_Bett_rechts
c7efa85c290d60448cdf1ed565f66ff70 expired end 20.03.2015 21:00:00-21.03.2015 08:00:00 sz_Bett_links
2d048395f0cd9a43816130f90d16b9010 expired end 21.03.2015 21:00:00-22.03.2015 08:00:00 sz_Bett_links
3209f52d7a61744ab4136ca1f44cf1220 expired end 21.03.2015 21:00:00-22.03.2015 05:00:00 sz_Bett_rechts
2ea0060057f0584e8ea8ccbe0eb5545e0 expired end 07.05.2015 09:00:00-07.05.2015 20:55:00 sz_Bett_rechts
9003ab0900db8349b1c581d035419a290 expired end 20.06.2015 08:00:00-21.06.2015 06:00:00 sz_Bett_rechts
f571dd9a940b85439eb3568e3702b3750 expired end 04.07.2015 08:00:00-05.07.2015 05:00:00 sz_Bett_links
8F7C870CF7FE4ADE8A7B13BEBBC2D6D80 expired end 15.07.2015 08:00:00-16.07.2015 06:00:00 sz_Bett_links
49755CF095E645548CE6A77E91548CA30 expired end 15.07.2015 08:00:00-16.07.2015 06:00:00 sz_Bett_rechts
95FA293E1C6A4B1C9469A09EC8BF04CB0 expired end 02.08.2015 12:00:00-02.08.2015 20:50:00 sz_Bett_rechts
418f7ec6ba8 known upcoming 26.08.2015 21:00:00-27.08.2015 05:00:00 sz_Bett_rechts
1bf61f34c82 known upcoming 27.08.2015 21:00:00-28.08.2015 05:00:00 sz_Bett_rechts
11d7c438a12 known upcoming 28.08.2015 21:00:00-29.08.2015 05:00:00 sz_Bett_rechts
c129db17443 known upcoming 29.08.2015 21:00:00-30.08.2015 05:00:00 sz_Bett_rechts
c9a1ea64e61 known upcoming 30.08.2015 21:00:00-31.08.2015 05:00:00 sz_Bett_rechts
dcac449f426 known upcoming 31.08.2015 21:00:00-01.09.2015 05:00:00 sz_Bett_rechts
8c3b3c14e07 known upcoming 01.09.2015 21:00:00-02.09.2015 05:00:00 sz_Bett_rechts
0443ffc7085 known upcoming 06.09.2015 12:00:00-07.09.2015 05:00:00 sz_Bett_rechts
3e8f7c181f0 known upcoming 08.09.2015 23:55:00-09.09.2015 00:05:00 wz_Ventilator
das heißt, es werden auch alle "expired" Einträge verarbeitet - und die triggern mir auch ein "modeEnded"
Da das expired-Handling bei Dir ja noch auf der ToDo-Liste steht, werde ich einfach mal warten. Aber offenbar funktioniert das von Dir beschriebene Rausschmeißen aller abgelaufenen Termine aus der globalen Datenhaltung auch in der Testversion nicht wie vorgesehen.
Danke, Udo, für die Beobachtungen. Damit sollte ich der Ursache der überzähligen Events auf die Schliche kommen.
Expired Termine sind erst in der Testversion wieder reingekommen, weil ich festgestellt habe, dass ich beim Parsen des Kalenders expired und entfernte Serientermine wieder als neu entdecke und dass zu komischen Effekten führt. Allerdings sind diese Termine statisch und sollten keine ended-Events triggern.
Melde mich mit neuer Version zurück.
Viele Grüße
Boris
Hallo Boris,
vielleicht noch eine (wichtige?) Info die ich gerade rausgefunden habe: Die oben aufgeführten "expired" Termine sind offenbar alles Einmal-Termine ohne Wiederholung.
Hallo Boris,
noch ein Hinweis (aufgetreten in Deiner Testversion)
2015.08.29 10:26:31 1: PERL WARNING: Use of uninitialized value in numeric ge (>=) at ./FHEM/57_Calendar.pm line 868.
Hallo,
wegen einer Reihe von Problemen mit den jüngsten Änderungen habe ich das Kalendermodul auf den Stand vom 04.06.2015 zurückgesetzt.
Damit entfallen zunächst die folgenden Funktionen wieder:
- Entfernen beendeter Kalenderereignisse
- Nicht-blockierendes Abholen von Daten per HTTP
Diese alte Version wird ab morgen per Update wieder eingespielt.
Diese alte Version hat Schwierigkeiten, Serientermine mit Terminen außer der Reihe korrekt zu verarbeiten.
Ich werde einige substanzielle Veränderungen am Modul vornehmen, damit Serientermine mit Terminen außer der Reihe funktionieren, abgelaufene Termine und Serien nicht angezeigt werden, und Daten nicht-blockierend abgeholt werden.
Ich werde dazu erst Testversionen zur Verfügung stellen, bevor eine grundsätzlich neue die Version wieder per Update bereit gestellt wird.
Ich schließe daher dieses Thema.
Viele Grüße
Boris