Hallo,
ich habe das Calendar-Modul fast vollkommen neu geschrieben (anbei). Das war notwendig, weil die Konzeption des bisherigen Moduls nicht geeignet war, ausreichend gut mit Serienterminen umzugehen.
Heute beginnt der alpha-Test. Er ist beschränkt auf Developer und Tester. Nur diese können in diesem Thema Antworten schreiben.
Das Modul ist weitestgehend abwärtskompatibel. Funktionale Ergänzungen erfolgen erst, wenn die neue Version etabliert ist. Interessierte finden am Anfang des Moduls ca. 300 Zeilen Dokumentation.
What's new?
-----------
This module version replaces the 2015 version that has been widely. Noteworthy
changes
- No more state... readings; "all" reading has been removed as well.
- The mode... readings (modeAlarm, modeAlarmOrStart, etc.) are deprecated
and will be removed in a future version. Use the mode=<regex> filter instead.
- Handles recurring calendar events with out-of-order events and exceptions
(EXDATE).
- Keeps ALL calendar events within plus/minus 400 days from the date of the
in FHEM: this means that you can have more than one calendar event with the
same UID.
- You can restrict visible calendar events with attributes hideLaterThan,
hideOlderThan.
- Nonblocking retrieval of calendar from URL.
- New get commands:
get <name> vevents
get <name> vcalendar
get <name> <format> <mode>
get <name> <format> mode=<regex>
get <name> <format> uid=<regex>
- The get commands
get <name> <format> ...
may not work as before since several calendar events may exist for a
single UID, particularly the get command
get <name> <format> all
show all calendar events from a series (past, current, and future); you
probably want to replace "all" by "next":
get <name> <format> next
to get only the first (not past but current or future) calendar event from
each series.
- Migration hints:
Replace
get <name> <format> all
by
get <name> <format> next
Replace
get <name> <format> <uid>
by
get <name> <format> uid=<uid> 1
Replace
get <name> <format> modeAlarmOrStart
by
get <name> <format> mode=alarm|start
- The FHEM events created for mode changes of single calendar events have been
amended:
changed: UID <mode>
<mode>: UID (this is new)
<mode> is the current mode of the calendar event after the change. It is
highly advisable to trigger actions based on these FHEM events instead of
notifications for changes of the mode... readings.
Viele Grüße
Boris
2016-01-02 19:51
- Perl-Syntaxfehler beseitigt %->$
2016-01-02 20:53
- Ein Reload ohne Neustart von FHEM erzeugt Warnungen. Das ist normal. Besser vor Verwendung FHEM neu starten.
2016-01-03 16:00
- Interne Readings (fhem) unsichtbar gemacht.
- Neue Defaults für Attribute: hideLaterThan inaktiv, hideOlderThan= 0. Damit werden alle Termine außer den beendeten angezeigt.
- get <name> full|debug|text|summary|location|alarm|start|end <reading> wiederbelebt.
2016-01-01 18:40
- Calendar_GetEvents() überall mit 4 Parametern aufrufen
2016-01-08 19:14
- Erkennt nun auch veränderte Elemente an verändertem DTSTAMP
- Ein define löst eine Aktualisierung des Kalenders aus, wenn das define nach Initialisierung von FHEM erfolgt.
2016-01-09 15:30
- reload tut nun was es soll und nicht nur update
- Verzögerung bis zur Aktualisierung nach Start von FHEM auf fix 2 Sekunden gesetzt.
- Neuer Default: hideOlderThan inaktiv
- Neuer Filter: next
- onCreateEvent plugin
- Doku überarbeitet
- What's new? überarbeitet
2016-01-09 19:52
- Sicherung, damit Kalender nur in der Zukunft aufwacht
- Vor der Verarbeitung in der ical-Datei [\r\n\]+ durch \n ersetzen
2016-01-10 15:32
- Absturz bei define beseitigt
2016-01-16 19:09
- Hirntote Kalender mit VEVENTs ohne UID bekommen eine synthetische UID verpasst
2016-01-17 11:17
- Neue Filter mode= und uid=
2016-01-23 19:25
- Änderung vom 8.1. rückgängig gemacht: DTSTAMP ist kein Kennzeichen für eine Änderung am Termin
- Versuch einer Beschleunigung von Merge und Crossreferencing mittels Perl-Gymnastik
- CalendarAsHtml()
- nach Aktualisierung der Termin (wegen reload, update oder weil eine Alarm-, Start- oder Ende-Zeit erreicht wurde) wird das FHEM-Event triggered gefeuert.
- Doku DE eingebaut (Dank an JoWiemann) und Doku komplett qualitätsgesichert
- Das ist der Release-Kandidat 1
2016-01-29 20:42
- Fehler im Programmfluss beseitigt, dass nach einem fehlgeschlagenen Update der Wecker nicht mehr gestellt wird
Hallo Boris,
vorweg: Vielen Dank für deine Arbeit das Modul neu zu schreiben.
Gern beteilige ich mich an den Test zur neuen Version. Meine FHEM Installation ist FeatureLevel 5.7 und gestern zuletzt geupdatet.
Ich habe es neu geladen, Nach reload des Moduls bekomme ich folgenden Eintrag im Logfile:
2016.01.02 19:29:24.705 0: syntax error at ./FHEM/57_Calendar.pm line 1175, near "%vevents{"
Global symbol "$vevent" requires explicit package name at ./FHEM/57_Calendar.pm line 1176, <$fh> line 863.
Global symbol "$vevent" requires explicit package name at ./FHEM/57_Calendar.pm line 1177, <$fh> line 863.
Global symbol "$skip" requires explicit package name at ./FHEM/57_Calendar.pm line 1193, <$fh> line 863.
Global symbol "$skip" requires explicit package name at ./FHEM/57_Calendar.pm line 1201, <$fh> line 863.
syntax error at ./FHEM/57_Calendar.pm line 1258, near "} else"
syntax error at ./FHEM/57_Calendar.pm line 1264, near "}"
Can't use global @_ in "my" at ./FHEM/57_Calendar.pm line 1273, near "= @_"
Global symbol "$level" requires explicit package name at ./FHEM/57_Calendar.pm line 1274, <$fh> line 863.
Global symbol "$level" requires explicit package name at ./FHEM/57_Calendar.pm line 1274, <$fh> line 863.
syntax error at ./FHEM/57_Calendar.pm line 1315, near "}"
./FHEM/57_Calendar.pm has too many errors.
Der Versuch das Kalender Device in FHEM zu löschen und neu anzulegen endete in einem sofortigem Chrash von FHEM.
vb
Danke, vb, dass Du testest.
Definitiv ein Fehler. Mein Perl steckts klaglos weg. Habe es gefixt. Version im ersten Post aktualisiert.
Hallo Boris,
ich möchte auch für Weiterentwicklung bedanken, auch wenn ich den Kalendar-Modul nicht produktiv einsetze, will ich gerne ein oder anderes Test durchführen. :)
Bei mir wollte das neue Modul leider noch nicht mitspielen...
FHEM ist aktuell (gestern upgedated).
2016.01.02 20:03:16 1: PERL WARNING: Subroutine new redefined at ./FHEM/57_Calendar.pm line 359.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine uid redefined at ./FHEM/57_Calendar.pm line 368.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine start redefined at ./FHEM/57_Calendar.pm line 373.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine setMode redefined at ./FHEM/57_Calendar.pm line 400.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine lastModified redefined at ./FHEM/57_Calendar.pm line 418.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine modeChanged redefined at ./FHEM/57_Calendar.pm line 423.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine summary redefined at ./FHEM/57_Calendar.pm line 430.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine location redefined at ./FHEM/57_Calendar.pm line 435.
2016.01.02 20:03:16 1: PERL WARNING: Prototype mismatch: sub Calendar::Event::ts: none vs ($$) at ./FHEM/57_Calendar.pm line 445.
2016.01.02 20:03:16 3: stacktrace:
2016.01.02 20:03:16 3: main::__ANON__ called by ./FHEM/57_Calendar.pm (445)
2016.01.02 20:03:16 3: (eval) called by fhem.pl (2206)
2016.01.02 20:03:16 3: (eval) called by fhem.pl (2205)
2016.01.02 20:03:16 3: main::CommandReload called by fhem.pl (1070)
2016.01.02 20:03:16 3: main::AnalyzeCommand called by fhem.pl (940)
2016.01.02 20:03:16 3: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (265)
2016.01.02 20:03:16 3: main::telnet_Read called by ./FHEM/98_apptime.pm (104)
2016.01.02 20:03:16 3: main::apptime_getTiming called by ./FHEM/98_apptime.pm (74)
2016.01.02 20:03:16 3: main::CallFn called by fhem.pl (661)
2016.01.02 20:03:16 1: PERL WARNING: Subroutine ts redefined at ./FHEM/57_Calendar.pm line 440.
2016.01.02 20:03:16 1: PERL WARNING: Prototype mismatch: sub Calendar::Event::ts0: none vs ($$) at ./FHEM/57_Calendar.pm line 452.
2016.01.02 20:03:16 3: stacktrace:
2016.01.02 20:03:16 3: main::__ANON__ called by ./FHEM/57_Calendar.pm (452)
2016.01.02 20:03:16 3: (eval) called by fhem.pl (2206)
2016.01.02 20:03:16 3: (eval) called by fhem.pl (2205)
2016.01.02 20:03:16 3: main::CommandReload called by fhem.pl (1070)
2016.01.02 20:03:16 3: main::AnalyzeCommand called by fhem.pl (940)
2016.01.02 20:03:16 3: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (265)
2016.01.02 20:03:16 3: main::telnet_Read called by ./FHEM/98_apptime.pm (104)
2016.01.02 20:03:16 3: main::apptime_getTiming called by ./FHEM/98_apptime.pm (74)
2016.01.02 20:03:16 3: main::CallFn called by fhem.pl (661)
2016.01.02 20:03:16 1: PERL WARNING: Subroutine ts0 redefined at ./FHEM/57_Calendar.pm line 447.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine asText redefined at ./FHEM/57_Calendar.pm line 454.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine asFull redefined at ./FHEM/57_Calendar.pm line 462.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine alarmTime redefined at ./FHEM/57_Calendar.pm line 491.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine startTime redefined at ./FHEM/57_Calendar.pm line 496.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine endTime redefined at ./FHEM/57_Calendar.pm line 501.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine isUpcoming redefined at ./FHEM/57_Calendar.pm line 508.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine isAlarmed redefined at ./FHEM/57_Calendar.pm line 518.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine isStarted redefined at ./FHEM/57_Calendar.pm line 525.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine isEnded redefined at ./FHEM/57_Calendar.pm line 551.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine nextTime redefined at ./FHEM/57_Calendar.pm line 561.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine new redefined at ./FHEM/57_Calendar.pm line 592.
2016.01.02 20:03:16 1: PERL WARNING: Prototype mismatch: sub ICal::Entry::new: none vs ($$) at ./FHEM/57_Calendar.pm line 632.
2016.01.02 20:03:16 3: stacktrace:
2016.01.02 20:03:16 3: main::__ANON__ called by ./FHEM/57_Calendar.pm (632)
2016.01.02 20:03:16 3: (eval) called by fhem.pl (2206)
2016.01.02 20:03:16 3: (eval) called by fhem.pl (2205)
2016.01.02 20:03:16 3: main::CommandReload called by fhem.pl (1070)
2016.01.02 20:03:16 3: main::AnalyzeCommand called by fhem.pl (940)
2016.01.02 20:03:16 3: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (265)
2016.01.02 20:03:16 3: main::telnet_Read called by ./FHEM/98_apptime.pm (104)
2016.01.02 20:03:16 3: main::apptime_getTiming called by ./FHEM/98_apptime.pm (74)
2016.01.02 20:03:16 3: main::CallFn called by fhem.pl (661)
2016.01.02 20:03:16 1: PERL WARNING: Subroutine new redefined at ./FHEM/57_Calendar.pm line 618.
2016.01.02 20:03:16 1: PERL WARNING: Prototype mismatch: sub ICal::Entry::value: none vs ($$) at ./FHEM/57_Calendar.pm line 655.
2016.01.02 20:03:16 3: stacktrace:
2016.01.02 20:03:16 3: main::__ANON__ called by ./FHEM/57_Calendar.pm (655)
2016.01.02 20:03:16 3: (eval) called by fhem.pl (2206)
2016.01.02 20:03:16 3: (eval) called by fhem.pl (2205)
2016.01.02 20:03:16 3: main::CommandReload called by fhem.pl (1070)
2016.01.02 20:03:16 3: main::AnalyzeCommand called by fhem.pl (940)
2016.01.02 20:03:16 3: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (265)
2016.01.02 20:03:16 3: main::telnet_Read called by ./FHEM/98_apptime.pm (104)
2016.01.02 20:03:16 3: main::apptime_getTiming called by ./FHEM/98_apptime.pm (74)
2016.01.02 20:03:16 3: main::CallFn called by fhem.pl (661)
2016.01.02 20:03:16 1: PERL WARNING: Subroutine value redefined at ./FHEM/57_Calendar.pm line 651.
2016.01.02 20:03:16 1: PERL WARNING: Prototype mismatch: sub ICal::Entry::parts: none vs ($$) at ./FHEM/57_Calendar.pm line 682.
2016.01.02 20:03:16 3: stacktrace:
2016.01.02 20:03:16 3: main::__ANON__ called by ./FHEM/57_Calendar.pm (682)
2016.01.02 20:03:16 3: (eval) called by fhem.pl (2206)
2016.01.02 20:03:16 3: (eval) called by fhem.pl (2205)
2016.01.02 20:03:16 3: main::CommandReload called by fhem.pl (1070)
2016.01.02 20:03:16 3: main::AnalyzeCommand called by fhem.pl (940)
2016.01.02 20:03:16 3: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (265)
2016.01.02 20:03:16 3: main::telnet_Read called by ./FHEM/98_apptime.pm (104)
2016.01.02 20:03:16 3: main::apptime_getTiming called by ./FHEM/98_apptime.pm (74)
2016.01.02 20:03:16 3: main::CallFn called by fhem.pl (661)
2016.01.02 20:03:16 1: PERL WARNING: Subroutine parts redefined at ./FHEM/57_Calendar.pm line 679.
2016.01.02 20:03:16 1: PERL WARNING: Prototype mismatch: sub ICal::Entry::addproperty: none vs ($$) at ./FHEM/57_Calendar.pm line 859.
2016.01.02 20:03:16 3: stacktrace:
2016.01.02 20:03:16 3: main::__ANON__ called by ./FHEM/57_Calendar.pm (859)
2016.01.02 20:03:16 3: (eval) called by fhem.pl (2206)
2016.01.02 20:03:16 3: (eval) called by fhem.pl (2205)
2016.01.02 20:03:16 3: main::CommandReload called by fhem.pl (1070)
2016.01.02 20:03:16 3: main::AnalyzeCommand called by fhem.pl (940)
2016.01.02 20:03:16 3: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (265)
2016.01.02 20:03:16 3: main::telnet_Read called by ./FHEM/98_apptime.pm (104)
2016.01.02 20:03:16 3: main::apptime_getTiming called by ./FHEM/98_apptime.pm (74)
2016.01.02 20:03:16 3: main::CallFn called by fhem.pl (661)
2016.01.02 20:03:16 1: PERL WARNING: Subroutine addproperty redefined at ./FHEM/57_Calendar.pm line 817.
2016.01.02 20:03:16 1: PERL WARNING: Prototype mismatch: sub ICal::Entry::parse: none vs ($$) at ./FHEM/57_Calendar.pm line 864.
2016.01.02 20:03:16 3: stacktrace:
2016.01.02 20:03:16 3: main::__ANON__ called by ./FHEM/57_Calendar.pm (864)
2016.01.02 20:03:16 3: (eval) called by fhem.pl (2206)
2016.01.02 20:03:16 3: (eval) called by fhem.pl (2205)
2016.01.02 20:03:16 3: main::CommandReload called by fhem.pl (1070)
2016.01.02 20:03:16 3: main::AnalyzeCommand called by fhem.pl (940)
2016.01.02 20:03:16 3: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (265)
2016.01.02 20:03:16 3: main::telnet_Read called by ./FHEM/98_apptime.pm (104)
2016.01.02 20:03:16 3: main::apptime_getTiming called by ./FHEM/98_apptime.pm (74)
2016.01.02 20:03:16 3: main::CallFn called by fhem.pl (661)
2016.01.02 20:03:16 1: PERL WARNING: Subroutine parse redefined at ./FHEM/57_Calendar.pm line 861.
2016.01.02 20:03:16 1: PERL WARNING: Prototype mismatch: sub ICal::Entry::parseSub: none vs ($$$) at ./FHEM/57_Calendar.pm line 896.
2016.01.02 20:03:16 3: stacktrace:
2016.01.02 20:03:16 3: main::__ANON__ called by ./FHEM/57_Calendar.pm (896)
2016.01.02 20:03:16 3: (eval) called by fhem.pl (2206)
2016.01.02 20:03:16 3: (eval) called by fhem.pl (2205)
2016.01.02 20:03:16 3: main::CommandReload called by fhem.pl (1070)
2016.01.02 20:03:16 3: main::AnalyzeCommand called by fhem.pl (940)
2016.01.02 20:03:16 3: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (265)
2016.01.02 20:03:16 3: main::telnet_Read called by ./FHEM/98_apptime.pm (104)
2016.01.02 20:03:16 3: main::apptime_getTiming called by ./FHEM/98_apptime.pm (74)
2016.01.02 20:03:16 3: main::CallFn called by fhem.pl (661)
2016.01.02 20:03:16 1: PERL WARNING: Subroutine parseSub redefined at ./FHEM/57_Calendar.pm line 866.
2016.01.02 20:03:16 1: PERL WARNING: Prototype mismatch: sub ICal::Entry::asString () vs ($$) at ./FHEM/57_Calendar.pm line 1316.
2016.01.02 20:03:16 3: stacktrace:
2016.01.02 20:03:16 3: main::__ANON__ called by ./FHEM/57_Calendar.pm (1316)
2016.01.02 20:03:16 3: (eval) called by fhem.pl (2206)
2016.01.02 20:03:16 3: (eval) called by fhem.pl (2205)
2016.01.02 20:03:16 3: main::CommandReload called by fhem.pl (1070)
2016.01.02 20:03:16 3: main::AnalyzeCommand called by fhem.pl (940)
2016.01.02 20:03:16 3: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (265)
2016.01.02 20:03:16 3: main::telnet_Read called by ./FHEM/98_apptime.pm (104)
2016.01.02 20:03:16 3: main::apptime_getTiming called by ./FHEM/98_apptime.pm (74)
2016.01.02 20:03:16 3: main::CallFn called by fhem.pl (661)
2016.01.02 20:03:16 1: PERL WARNING: Subroutine asString redefined at ./FHEM/57_Calendar.pm line 1273.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine Calendar_Initialize redefined at ./FHEM/57_Calendar.pm line 1327.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine Calendar_Define redefined at ./FHEM/57_Calendar.pm line 1341.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine Calendar_Undef redefined at ./FHEM/57_Calendar.pm line 1377.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine Calendar_Set redefined at ./FHEM/57_Calendar.pm line 1411.
2016.01.02 20:03:16 1: PERL WARNING: Subroutine Calendar_Get redefined at ./FHEM/57_Calendar.pm line 1434.
Danke auch an Dich, dass Du testest.
Hast Du das Modul nur mit reload angezogen? Dann kommen üblicherweise diese Meldungen. Aber laufen tut es doch dennoch, oder?
Hallo Boris,
wird ein nicht freigegebener Google-Kalender hinterlegt, wird folgendes Log geschrieben:
2016.01.02 20:24:06 1: Calendar MeinKalender: data not in ICal format
2016.01.02 20:24:06 1: Calendar MeinKalender: maybe gzip data, but cannot load Compress::Zlib
Grüße Jörg
Danke, Jörg, fürs Testen.
Das Ergebnis ist normal.
Das Modul enthält etwas zurück, was nicht wie ein iCalendar aussieht. Es denkt, es könnte komprimiert sein, und versucht zu dekomprimieren. Bei Dir schlägt das fehl, weil Compress::Zlib fehlt. Wenn die Dekompression laufen und auch fehlschlagen würde, käme dann die endgültige Meldung, dass der Kalender kein iCalendar ist.
Bei Dir müsste aber get MeinKalender vcalendar die heruntergeladenen Daten (Fehlermeldung im HTML-Format?) zeigen.
Grüße
Boris
Zitat von: Dr. Boris Neubert am 02 Januar 2016, 20:11:47
Hast Du das Modul nur mit reload angezogen? Dann kommen üblicherweise diese Meldungen. Aber laufen tut es doch dennoch, oder?
Hast Recht :)
Bei Neustart sah das besser aus. Das Modul läuft, habe noch keine Unstimmigkeiten gemerkt. Positiv: Das Modul ist aus der apptime-Auflistung verschwunden :)
Hallo Boris,
ich habe mir das neue Modul auch mal heruntergeladen und in meinem Testsystem eingespielt.
Der Kalender konnte auch erfolgreich abgerufen werden, allerdings erhalte ich bei get keine Ergebnisse (s. Screenshot), obwohl entsprechende Termine vorhanden sind.
Auf meinem Produktivsystem, auf dem noch das reguläre Modul arbeitet erhalte ich dagegen korrekte Ergebnisse. Beide Systeme verwenden den selben google-Kalender.
Mein Testsystem ist tagesaktuell (FHEM + Wheezy)
Gruß Benni.
Zitat von: Dr. Boris Neubert am 02 Januar 2016, 20:29:36
Das Modul enthält etwas zurück, was nicht wie ein iCalendar aussieht. Es denkt, es könnte komprimiert sein, und versucht zu dekomprimieren. Bei Dir schlägt das fehl, weil Compress::Zlib fehlt. Wenn die Dekompression laufen und auch fehlschlagen würde, käme dann die endgültige Meldung, dass der Kalender kein iCalendar ist.
Hallo Boris,
habe seit langem libio-compress-zlib-perl installiert, oder brauche ich Bundle::Compress::Zlib - search.cpan.org?
Grüße Jörg
Zitat von: JoWiemann am 02 Januar 2016, 21:02:41
habe seit langem libio-compress-zlib-perl installiert, oder brauche ich Bundle::Compress::Zlib - search.cpan.org?
Hmm, habe das nie benutzt und auch nicht getestet - Code war eine Spende eines Dritten.
Das Package heisst
libio-compress-perl auf neueren Systemen.
Danke, Benni, für Deinen Test.
Zitat von: Benni am 02 Januar 2016, 20:57:03
Der Kalender konnte auch erfolgreich abgerufen werden, allerdings erhalte ich bei get keine Ergebnisse (s. Screenshot), obwohl entsprechende Termine vorhanden sind.
Mit
get cal vevents erhältst Du ausführliche Informationen, wie sich aus den VEVENTS im iCalendar die Kalenderereignisse ergeben.
Sofern nicht vertraulich, kannst Du das gerne hier posten, und ich schaue es mir an.
Grüße
Boris
Hallo Boris,
die Informationen sind leider teilweise zu heikel, da auch einige geschäftliche Termine dabei sind.
Ich werde mir morgen mal noch einen separaten Testaccount einrichten, brauche ich sowieso ;)
Gruß Benni.
OK, verstehe ich. Hinweis: ab dem zweiten Google-Calendar werden die Alarme nicht übertragen, d.h. sie kommen schon gar nicht beim Download des iCalenders an. Das soll Dich bitte nicht wundern und es ist kein Fehler des Moduls.
Hast Du Dir die Ausgabe angesehen?
Bei meinem Testaccount sieht sie beispielsweise so aus:
get T vevents
1: VEVENT [new]
CREATED: 20160102T141354Z
DESCRIPTION:
DTEND: 20160102T145400Z
DTSTAMP: 20160102T203259Z
DTSTART: 20160102T145300Z
LAST-MODIFIED: 20160102T145100Z
LOCATION:
SEQUENCE: 2
SUMMARY: Bald\, bald\, mein Schatz
UID: 08dciotv1763hi5ls2tqi4fjrc@google.com
>>> Events:
08dciotv1763hi5ls2tqi4fjrcgooglecom end 02.01.2016 15:53:00-02.01.2016 15:54:00 Bald\, bald\, mein Schatz
>>> Skipped events:
2: VEVENT [new, in a series with 3,4]
CREATED: 20151122T132130Z
DESCRIPTION: 11.01.2016 verschoben auf 13.01.2016 13-14 Uhr
DTEND: 20160113T140000
DTSTAMP: 20160102T203259Z
DTSTART: 20160113T130000
LAST-MODIFIED: 20160102T133836Z
LOCATION: Ort
RECURRENCE-ID: 20160111T170000
SEQUENCE: 1
SUMMARY: Montags 17-18 ab 07.09.2015
UID: i6uhqrgv5gjm9j5ep59sh4ub78@google.com
>>> is an exception
>>> Events:
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 13.01.2016 13:00:00-13.01.2016 14:00:00 Montags 17-18 ab 07.09.2015 Ort
>>> Skipped events:
3: VEVENT [new, in a series with 2,4]
CREATED: 20151122T132130Z
DESCRIPTION: 25.01.2016 verschoben auf 27.01.2016 7-8 Uhr
DTEND: 20160127T080000
DTSTAMP: 20160102T203259Z
DTSTART: 20160127T070000
LAST-MODIFIED: 20160102T115651Z
LOCATION: Ort
RECURRENCE-ID: 20160125T170000
SEQUENCE: 1
SUMMARY: Montags 17-18 ab 07.09.2015
UID: i6uhqrgv5gjm9j5ep59sh4ub78@google.com
>>> is an exception
>>> Events:
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 27.01.2016 07:00:00-27.01.2016 08:00:00 Montags 17-18 ab 07.09.2015 Ort
>>> Skipped events:
4: VEVENT [new, in a series with 2,3]
CREATED: 20151122T132130Z
DESCRIPTION: Beschreibung
DTEND: 20150907T180000
DTSTAMP: 20160102T203259Z
DTSTART: 20150907T170000
EXDATE: (20160425T170000 20160222T170000)
LAST-MODIFIED: 20160102T094155Z
LOCATION: Ort
RRULE: FREQ=WEEKLY;BYDAY=MO
SEQUENCE: 0
SUMMARY: Montags 17-18 ab 07.09.2015
UID: i6uhqrgv5gjm9j5ep59sh4ub78@google.com
>>> is a series
>>> Events:
i6uhqrgv5gjm9j5ep59sh4ub78googlecom end 07.09.2015 17:00:00-07.09.2015 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom end 14.09.2015 17:00:00-14.09.2015 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom end 21.09.2015 17:00:00-21.09.2015 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom end 28.09.2015 17:00:00-28.09.2015 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom end 05.10.2015 17:00:00-05.10.2015 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom end 12.10.2015 17:00:00-12.10.2015 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom end 19.10.2015 17:00:00-19.10.2015 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom end 26.10.2015 17:00:00-26.10.2015 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom end 02.11.2015 17:00:00-02.11.2015 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom end 09.11.2015 17:00:00-09.11.2015 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom end 16.11.2015 17:00:00-16.11.2015 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom end 23.11.2015 17:00:00-23.11.2015 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom end 30.11.2015 17:00:00-30.11.2015 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom end 07.12.2015 17:00:00-07.12.2015 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom end 14.12.2015 17:00:00-14.12.2015 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom end 21.12.2015 17:00:00-21.12.2015 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom end 28.12.2015 17:00:00-28.12.2015 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 04.01.2016 17:00:00-04.01.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 18.01.2016 17:00:00-18.01.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 01.02.2016 17:00:00-01.02.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 08.02.2016 17:00:00-08.02.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 15.02.2016 17:00:00-15.02.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 29.02.2016 17:00:00-29.02.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 07.03.2016 17:00:00-07.03.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 14.03.2016 17:00:00-14.03.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 21.03.2016 17:00:00-21.03.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 28.03.2016 17:00:00-28.03.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 04.04.2016 17:00:00-04.04.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 11.04.2016 17:00:00-11.04.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 18.04.2016 17:00:00-18.04.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 02.05.2016 17:00:00-02.05.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 09.05.2016 17:00:00-09.05.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 16.05.2016 17:00:00-16.05.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 23.05.2016 17:00:00-23.05.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 30.05.2016 17:00:00-30.05.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 06.06.2016 17:00:00-06.06.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 13.06.2016 17:00:00-13.06.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 20.06.2016 17:00:00-20.06.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 27.06.2016 17:00:00-27.06.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 04.07.2016 17:00:00-04.07.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 11.07.2016 17:00:00-11.07.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 18.07.2016 17:00:00-18.07.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 25.07.2016 17:00:00-25.07.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 01.08.2016 17:00:00-01.08.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 08.08.2016 17:00:00-08.08.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 15.08.2016 17:00:00-15.08.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 22.08.2016 17:00:00-22.08.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 29.08.2016 17:00:00-29.08.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 05.09.2016 17:00:00-05.09.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 12.09.2016 17:00:00-12.09.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 19.09.2016 17:00:00-19.09.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 26.09.2016 17:00:00-26.09.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 03.10.2016 17:00:00-03.10.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 10.10.2016 17:00:00-10.10.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 17.10.2016 17:00:00-17.10.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 24.10.2016 17:00:00-24.10.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 31.10.2016 17:00:00-31.10.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 07.11.2016 17:00:00-07.11.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 14.11.2016 17:00:00-14.11.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 21.11.2016 17:00:00-21.11.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 28.11.2016 17:00:00-28.11.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 05.12.2016 17:00:00-05.12.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 12.12.2016 17:00:00-12.12.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 19.12.2016 17:00:00-19.12.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 26.12.2016 17:00:00-26.12.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 02.01.2017 17:00:00-02.01.2017 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 09.01.2017 17:00:00-09.01.2017 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 16.01.2017 17:00:00-16.01.2017 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 23.01.2017 17:00:00-23.01.2017 18:00:00 Montags 17-18 ab 07.09.2015 Ort
i6uhqrgv5gjm9j5ep59sh4ub78googlecom upcoming 30.01.2017 17:00:00-30.01.2017 18:00:00 Montags 17-18 ab 07.09.2015 Ort
>>> Skipped events:
i6uhqrgv5gjm9j5ep59sh4ub78googlecom undefined 11.01.2016 17:00:00-11.01.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort RECURRENCE-ID: 20160111T170000
i6uhqrgv5gjm9j5ep59sh4ub78googlecom undefined 25.01.2016 17:00:00-25.01.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort RECURRENCE-ID: 20160125T170000
i6uhqrgv5gjm9j5ep59sh4ub78googlecom undefined 22.02.2016 17:00:00-22.02.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort EXDATE: 20160222T170000
i6uhqrgv5gjm9j5ep59sh4ub78googlecom undefined 25.04.2016 17:00:00-25.04.2016 18:00:00 Montags 17-18 ab 07.09.2015 Ort EXDATE: 20160425T170000
Aus dem new in eckigen Klammern wird dann nach dem ersten Update ein known, wenn sich nichts ändert.
Viele Grüße
Boris
Ja, das sieht bei mir grundsätzlich genau so aus.
Auch der Wechsel von [new] auf [known] nach einem update hat funktioniert.
Und es werden Dir auch unter >>> Events: die Events angezeigt? Und es liegen welche im Intervall [heute-1d, heute+30d]?
Übrigens: es heißt nun get CalBB full alarm (statt modeAlarm).
Siehe bitte Doku und What's new? im ersten Post.
Zitat von: Dr. Boris Neubert am 02 Januar 2016, 21:11:40
Hmm, habe das nie benutzt und auch nicht getestet - Code war eine Spende eines Dritten.
Das Package heisst libio-compress-perl auf neueren Systemen.
Mit libio-compress-perl funktioniert es bei mir nicht, aber mit dem CPAN-Modul läuft es.
Grüße Jörg
Hallo Boris,
mit vevent bekomme ich folgende Infos:
1: VEVENT [known]
CREATED: 20160102T200805Z
DESCRIPTION:
DTEND: 20160103T200000Z
DTSTAMP: 20160102T213149Z
DTSTART: 20160103T190000Z
LAST-MODIFIED: 20160102T200805Z
LOCATION:
SEQUENCE: 0
SUMMARY: Testeintrag
UID: ovorq4p1igeja1obd2dnfhda1g@google.com
>>> Events:
ovorq4p1igeja1obd2dnfhda1ggooglecom upcoming 03.01.2016 20:00:00-03.01.2016 21:00:00 Testeintrag
>>> Skipped events:
als List sehe ich folgendes:
NAME MeinKalender
NR 384
NTFY_ORDER 50-MeinKalender
STATE updated
TYPE Calendar
Readings:
2016-01-02 22:35:57 calname jowiemann@debitel.net
2016-01-02 22:35:57 lastUpdate 2016-01-02 22:35:51
2016-01-02 20:17:55 modeAlarm
2016-01-02 20:17:55 modeAlarmOrStart
2016-01-02 20:17:55 modeAlarmed
2016-01-02 20:17:55 modeChanged
2016-01-02 21:07:07 modeEnd 6525gcvtf11q2p3cedj78db3ctr6juau01googlecom;6525gcvtf11q2p3cedj78db3ctr6juau02googlecom
2016-01-02 20:17:55 modeEnded
2016-01-02 20:17:55 modeStart
2016-01-02 20:17:55 modeStarted
2016-01-02 21:08:20 modeUpcoming ovorq4p1igeja1obd2dnfhda1ggooglecom
2016-01-02 22:35:57 nextUpdate 2016-01-02 23:35:51
2016-01-02 22:35:57 nextWakeup 2016-01-02 23:35:51
2016-01-02 22:35:57 state updated
Fhem:
iCalendar BEGIN:VCALENDAR
Müsste nicht irgendwie ModeStart gefüllt werden?
Grüße Jörg
Nein, der 03.01. ist erst morgen ;)
Guten Morgen Boris,
ich habe inzwischen einen Testkalender eingerichtet, mit dem es korrekt funktioniert.
Damit erhalte ich auch die >>>Events unter vevents angezeigt und auch mit get bekomme ich die korrekten Werte :)
Es war tatsächlich so, dass in meinem bisher verbundenen Kalender keine Ereignisse im Intervall [heute-1d, heute+30d] lagen :-[
Nach Erweiterung des Intervalls mittels hideLaterThan zeigt mir auch der ursprüngliche Kalender die korrekten Daten an.
Sieht also erst mal gut aus.
Werde weiter testen.
Gruß Benni.
hi boris,
soweit lässt es sich einbinden und läuft auch stabil
schade das get full <id> nicht mehr geht....
so konnte man sich einzelne id's auslesen, was ich mir auch für das neue modul wieder wünschen würde (CALVIEW nutzt diese funktion ,sowie die meisten code-schnipsel für die myUtils zum auswerten des calendar ).
get full all funktioniert
get full modeUpcoming / modeEnd / andere modes geht noch nicht (es pasiert nichts)
Zitat von: chris1284 am 03 Januar 2016, 09:19:18
schade das get full <id> nicht mehr geht....
so konnte man sich einzelne id's auslesen, was ich mir auch für das neue modul wieder wünschen würde (CALVIEW nutzt diese funktion ,sowie die meisten code-schnipsel für die myUtils zum auswerten des calendar ).
soweit ich anfangs gelesen habe, soll das "get" ohnehin umgebaut/erweitert werden. Warten wir mal ab, was da noch kommt. In einer alpha-Phase ist ein Modul meistens in seinem Funktionsumfang noch nicht vollständig im Funktionsumfang.
Zitat von: Dr. Boris Neubert am 02 Januar 2016, 21:35:40
Hinweis: ab dem zweiten Google-Calendar werden die Alarme nicht übertragen, d.h. sie kommen schon gar nicht beim Download des iCalenders an.
@Boris: was heißt das konkret? Das Modul selbst kann aber schon mit mehreren Kalendern umgehen, oder? Ich werde im Laufe der nächsten Tage in den Test mit einsteigen.
Hallo Chris,
Zitat von: chris1284 am 03 Januar 2016, 09:19:18
schade das get full <id> nicht mehr geht....
doch, geht schon, aber die Events müssen aber innerhalb des definierten Intervalls sein (Default [heute-1d, heute+30d])
-> siehe ein paar Posts weiter oben (http://forum.fhem.de/index.php/topic,46608.msg383513.html#msg383513)
Hallo Udo,
Zitat von: betateilchen am 03 Januar 2016, 10:04:05
@Boris: was heißt das konkret? Das Modul selbst kann aber schon mit mehreren Kalendern umgehen, oder? Ich werde im Laufe der nächsten Tage in den Test mit einsteigen.
für meine Tests habe ich zusätzlich zu meinem ersten privaten Produktivkalender einen zweiten Kalender bei Google angelegt. Während die ics-Datei, die ich vom meinem privaten Kalender herunterlade, die VALARMS am VEVENT enthält, finde ich bei dem Testkalender keine VALARMS in der ics-Datei, obwohl die Termine mit Benachrichtigungen versehen sind.
Das Modul kann mit beliebig vielen Kalendern umgehen und behandelt alle gleich.
Viele Grüße
Boris
Zitat von: Benni am 03 Januar 2016, 10:18:57
Hallo Chris,
doch, geht schon, aber die Events müssen aber innerhalb des definierten Intervalls sein (Default [heute-1d, heute+30d])
-> siehe ein paar Posts weiter oben (http://forum.fhem.de/index.php/topic,46608.msg383513.html#msg383513)
das sind sie. alle in kw1 und 2, also max heute+14d
ZitatÜbrigens: es heißt nun get CalBB full alarm (statt modeAlarm).
das die get's nicht zu den readings passen finde ich nicht optimal (reading modeXXX -> get XXX), sollte einheitlich sein
Hallo Chris, hallo Benni,
Zitat von: Benni am 03 Januar 2016, 10:18:57
doch, geht schon, aber die Events müssen aber innerhalb des definierten Intervalls sein (Default [heute-1d, heute+30d])
-> siehe ein paar Posts weiter oben (http://forum.fhem.de/index.php/topic,46608.msg383513.html#msg383513)
die Beschränkung der sichtbaren Termine per Default scheint ein überraschendes Feature zu sein. Was denkt Ihr, wie das geändert werden könnte, damit niemand in diese Falle tappt?
Es ist aber schon klar, dass grundsätzlich Termine nur zwischen [t-400d, t+400d] erzeugt werden? Dabei ist t der letzte Zeitpunkt, an dem ein Termin als new, modified oder changed erkannt wurde. Das soll verhindern, dass Speicher- und Laufzeitgrenzen überschritten werden - besonders bei Terminserien ohne Ende ;) und gleichzeitig möglichst alle Termin in den vergangenen und nächsten 12 Monaten erfasst werden.
Viele Grüße
Boris
Zitat von: chris1284 am 03 Januar 2016, 09:19:18
schade das get full <id> nicht mehr geht....
Also bei mir funktioniert das ???
get calFHEM full eve7rtanico82903lmrctsfof8googlecom
eve7rtanico82903lmrctsfof8googlecom end 03.01.2016 08:35:00-03.01.2016 08:45:00 dmFHEM switch dmFHEM
mittlerweile geht das bei mir auch, ich hatte vorhind id's mit 2016...._davor , warum auch immer.
Zitat von: Dr. Boris Neubert am 03 Januar 2016, 10:50:41
die Beschränkung der sichtbaren Termine per Default scheint ein überraschendes Feature zu sein. Was denkt Ihr, wie das geändert werden könnte, damit niemand in diese Falle tappt?
Ich weiß ja nicht, wie das modulintern mit der Sichtbarkeit und den tatsächlich verfügbaren events (t-400 bis t+400) verwaltet wird. Aber ich finde, dass zumindest ein explizites get mit uid eines termins aus dem tatsächlich verfügbaren Event-Bereich auch ein Ergebnis liefern sollte, zumal die uids in den Readings ja auch angezeigt werden (so war es zumindest bei meinen Tests von gestern Abend).
Eventuell reicht es ja den default für den sichtbaren Bereich zu erhöhen, evtl. sogar auf max.
Ich schätze mal, dass die Menge der Kalender, bei denen das speicherkritisch sein könnte geringer ist, als die Anzahl derer, die in die Sichtbarkeitsfalle stolpern ;)
Gruß Benni.
Zitat von: chris1284 am 03 Januar 2016, 10:48:52
das die get's nicht zu den readings passen finde ich nicht optimal (reading modeXXX -> get XXX), sollte einheitlich sein
Die gets scheinen auch eine Falle zu sein. Ich hoffe, dass es nicht zu schmerzhaft wird, wenn ich
get <name> full|text|summary|location|alarm|start|end <reading>|<uid> [max]abschaffe. Durch den Fehler beim Aufruf wird der Anwender auf die Doku gestoßen.
Ich würde gerne folgendes einführen:
get <name> events [format:<formatspec>] [filter:<filterspec>] [limit:<limitspec>]mit
<formatspec>:= full|text|summary|location|alarm|start|end|{ <perlcode> }
<filterspec> := uid =<uid> | mode=<mode> | { <perlcode> }
<limitspec> := max=<max> | window=timespec1,timespec2
Beispiele:
get MyCalendar events format:full filter:uid=543567e3d2
get MyCalendar events format:{ strftime("%Y-%m-%d", $tstart) . " " . $summary } limit:windows=1d,30d
get MyCalendar events format:text limit:max=3
für mich persönlich kein Problem. :)
Ich hatte das Calendar-Modul bisher nur ganz rudimentär im Einsatz und für mich ist das Testen mit dem neuen Modul der perfekte Einstieg mich endlich mal näher damit zu beschäftigen.
Allerdings setzt, wie Chris weiter oben schon bemerkt hatte, zumindest das CALVIEW-Modul direkt auf das Calendar-Modul auf, was dazu wohl entsprechende get-Funktionalitäten benötigt. Ich schätze mal, dass das CALVIEW-Modul ein häufiger Anwendungsfall ist.
Ich könnte mir aber vorstellen, dass von dem Plus an Flexibilität, das durch diese Abfragemöglichkeiten entsteht letztendlich auch das CALVIEW-Modul profitieren würde.
Es ist halt immer schwierig wenn alte Zöpfe abgeschnitten werden sollen aber grundsätzlich bin ich eher dafür ;D
Hallo Chris,
Zitat von: Benni am 03 Januar 2016, 11:46:46
Allerdings setzt, wie Chris weiter oben schon bemerkt hatte, zumindest das CALVIEW-Modul direkt auf das Calendar-Modul auf, was dazu wohl entsprechende get-Funktionalitäten benötigt. Ich schätze mal, dass das CALVIEW-Modul ein häufiger Anwendungsfall ist.
Ich könnte mir aber vorstellen, dass von dem Plus an Flexibilität, das durch diese Abfragemöglichkeiten entsteht letztendlich auch das CALVIEW-Modul profitieren würde.
brauchst Du ein API für CALVIEW? Was sollte das leisten - wenn Du mir eine Spezifikation zukommen lässt, kann ich das einbauen.
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert am 03 Januar 2016, 11:26:36
Ich hoffe, dass es nicht zu schmerzhaft wird, wenn ich
get <name> full|text|summary|location|alarm|start|end <reading>|<uid> [max]
abschaffe.
Das gibt allerdings - vorhersehbar - massiven Ärger.
Hattest Du nicht irgendwann geschrieben, Du willst abwärtskompatibel bleiben?
Erster Test hier: Modul funktioniert offenbar auch mit ownCloud Kalendern.
Zitat von: betateilchen am 03 Januar 2016, 12:24:50
Das gibt allerdings - vorhersehbar - massiven Ärger.
Ich befürchte, dass Du Recht behalten wirst :-(
Fazit: ich mache es VOLLSTÄNDIG abwärtskompatibel (bis auf die Tatsache, dass man auf einmal ganz viele Termine sehen wird) und get ... events wird es zusätzlich geben.
Zitat von: Dr. Boris Neubert am 03 Januar 2016, 12:14:22
Hallo Chris,
brauchst Du ein API für CALVIEW? Was sollte das leisten - wenn Du mir eine Spezifikation zukommen lässt, kann ich das einbauen.
Viele Grüße
Boris
solange man die get-funktion aufrufen kann ist das denke ich kein problem mit neuen get-befehlen. das kernstück aktuell nur die abfrage der bestandteile eines termines über die uid.
ich hole erst pro mode die uid's, teile sie auf und hole die daten:
foreach my $calendername (@calendernamen){
foreach my $mode (@modes){
my $all = ReadingsVal($calendername, $mode, "");
my @uids=split(/;/,$all);
foreach my $uid (@uids){
my $terminstart = CallFn($calendername, "GetFn", $defs{$calendername},(" ","start", $uid));
my $termintext = CallFn($calendername, "GetFn", $defs{$calendername}, (" ","summary", $uid));
my $terminend = CallFn($calendername, "GetFn", $defs{$calendername}, (" ","end", $uid));
my $terminort = CallFn($calendername, "GetFn", $defs{$calendername}, (" ","location", $uid));
push(@terminliste, [$terminstart, $termintext, $terminend, $calendername, $terminort, $mode]);
};
};
};
return @terminliste;also auch wenn du die mode-bezeichnung änderst sollte es kein problem sein.
Hallo,
ich habe mir die Ergebnisse der letzten 20 Stunden zu Herzen genommen und ein paar Anpassungen vorgenommen. Die Änderungen sind im ersten Beitrag in diesem Thema dokumentiert, wo auch die neue Version hängt.
Folgende Gedanken dazu:
- die Einstellung (hideOlderThan= 0, hideLaterThan inaktiv) führt dazu, dass nur nicht beendete Termine gezeigt werden. Früher wurde ein beendeter Termin noch gezeigt, bevor er beim nächsten Kalender-Update rausgeworfen wurde.
- get <name> <format> <reading> mit <reading>:= modeAlarm|modeAlarmed|... funktioniert wieder. Da aber über die UID ausgewertet wird, werden alle Termine mit der entsprechenden UID angezeigt und das auch egal in welchem Zustand sie sind. Das ist wahrscheinlich nicht das, was der Benutzer erwartet. Aufgrund der Neuerung, dass es zu einer UID mehrere Termine geben kann, weiß ich aber nicht, wie ich das noch viel besser machen kann. Echt abwärtskompatibel wird es vermutlich nur, wenn ich ein Attribut einbaue, mit dem aus einer Serie jeweils nur der interessanteste Termin behalten wird.
Was meint Ihr?
Bis zum kommenden Wochenende keine Updates mehr, außer bei gravierenden Fehlern.
Grüße
Boris
Halloo Boris,
bei der neuen Version fehlt der letzte Parameter im Aufruf von Calendar_GetEvents
Not enough arguments for main::Calendar_GetEvents at ./FHEM/57_Calendar.pm line 1471, near "undef)"
BEGIN not safe after errors--compilation aborted at ./FHEM/57_Calendar.pm line 1635.
Grüße,
Alexander
Danke, Alexander, für den Hinweis. Hab's gefixt und im ersten Beitrag hinterlegt.
Bei mir meckert Perl nicht, wenn ich weniger Argumente übergebe als im Prototyp angegeben ($$$$). Ich bin explizit davon ausgegangen, dass der Rest dann undef ist.
Warum ist Dein perl pingeliger als meins?
This is perl 5, version 20, subversion 2 (v5.20.2) built for x86_64-linux-gnu-thread-multi
(with 51 registered patches, see perl -V for more detail)
auf KUbuntu 15.10.
Grüße
Boris
Zitat von: Dr. Boris Neubert am 03 Januar 2016, 17:36:30
Früher wurde ein beendeter Termin noch gezeigt, bevor er beim nächsten Kalender-Update rausgeworfen wurde.
Das Rauswerfen hat "früher" noch nie zuverlässig funktioniert 8)
Zitat von: Dr. Boris Neubert am 03 Januar 2016, 18:43:53
Bei mir meckert Perl nicht, wenn ich weniger Argumente übergebe als im Prototyp angegeben ($$$$). Ich bin explizit davon ausgegangen, dass der Rest dann undef ist.
Gib doch einfach in den Funktionsdefinitionen gar keine Argumente an, auch nicht im Prototyp.
Es gibt einfach zuviele verschiedene perl-Versionen.
Warum wird ein neu definiertes Calendar-device (noch?) nicht automatisch beim define aktualisiert sondern erst nach einem "set ... reload"?
Hallo,
nach einem global:initialized oder rereadcfg Event wird der Kalender nach einer zufälligen Verzögerung von 10 bis 20 Sekunden automatisch aktualisiert. Das verhindert, dass die Leitung verstopft, wenn nach dem Start alle Devices Daten aus dem Web holen.
Grüße
Boris
Nachtrag:
ich könnte natürlich die Aktualisierung sofort beim define auslösen, wenn FHEM bereits initialisiert ist. Wie kann ich das feststellen?
Variante 1: if ($init_done == 1)
Variante 2: $fhem_started auswerten, damit kannst Du die Zeit seit dem letzten fhem Start ermitteln
gibt es eigentlich keinen event "modeEnded" mehr?
Edit: Ich ziehe die Frage zurück. Es scheint den event doch noch zu geben - aber warum der vorhin nicht auftrat, keine Ahnung.
Zitat von: Dr. Boris Neubert am 03 Januar 2016, 18:43:53
Warum ist Dein perl pingeliger als meins?
This is perl 5, version 20, subversion 2 (v5.20.2) built for x86_64-linux-gnu-thread-multi
(with 51 registered patches, see perl -V for more detail)
auf KUbuntu 15.10.
Eine sehr gute Frage...
This is perl 5, version 14, subversion 2 (v5.14.2) built for arm-linux-gnueabihf-thread-multi-64int
(with 89 registered patches, see perl -V for more detail)
auf CubieTruck mit Igors-Image
Linux cubie 3.4.109-sunxi #4 SMP PREEMPT Wed Sep 30 13:44:47 CEST 2015 armv7l GNU/Linux
Die neue Version teste ich gleich.
Edit: Keine Warnings ;)
Nochmal zum Thema modeEnded:
Ereignis 1: modeEnded vorhanden:
2016-01-03_22:25:00 oc_Schalter changed: 636696728b end
2016-01-03_22:25:00 oc_Schalter end: 636696728b
2016-01-03_22:25:00 oc_Schalter modeUpcoming: 1bf61f34c8;c129db1744;418f7ec6ba;8c3b3c14e0;11d7c438a1;dcac449f42;0443ffc708
2016-01-03_22:25:00 oc_Schalter modeAlarmOrStart: c9a1ea64e6
2016-01-03_22:25:00 oc_Schalter modeStart: c9a1ea64e6
2016-01-03_22:25:00 oc_Schalter modeStarted:
2016-01-03_22:25:00 oc_Schalter modeEnd: 636696728b;db533f4977;698ffc0dd1;a41abb4589;AAFEBBFF8F4341788099671939BCDABF;a9c6be8b5a;9B2DD77E13DD462CACBA83ED30672B1E;c531b570e9;60e81c691d;85c66f6494;0FE7395834524DC884C8903978F77996;7020276aa4;C0579E685DB44A0D9349DF524611BD8D;FDFC8E01969A4BBFBF1BF81D67F699BC;C5F7FE902B894CF9AEB828DECBB80C34;a8f59d8d90;F5E71E148E0B48D68F1482C041D7DF2C;9FB130A0ACCB43CA931D00881D911475;FF7F7CEA049A4639BFD5759EDA4ABCEF;c85d45a0ef;91573703a9;297D5D2A7BD44354A216812108A7C368;e31a5b34fd;FBC398E8869544C68A647868D3692C1E;1CEE724FD55D4D20B2253CFE8968A003
2016-01-03_22:25:00 oc_Schalter modeEnded: 636696728b
2016-01-03_22:25:00 oc_Schalter nextWakeup: 2016-01-03 23:18:24
Ereignis 2: modeEnded fehlt:
2016-01-04_05:00:00 oc_Schalter changed: c9a1ea64e6 end
2016-01-04_05:00:00 oc_Schalter end: c9a1ea64e6
2016-01-04_05:00:00 oc_Schalter modeUpcoming: 1bf61f34c8;c129db1744;11d7c438a1;8c3b3c14e0;418f7ec6ba;0443ffc708;dcac449f42;c9a1ea64e6
2016-01-04_05:00:00 oc_Schalter modeAlarmOrStart:
2016-01-04_05:00:00 oc_Schalter modeChanged: c9a1ea64e6
2016-01-04_05:00:00 oc_Schalter modeStart:
2016-01-04_05:00:00 oc_Schalter modeEnd: a41abb4589;698ffc0dd1;AAFEBBFF8F4341788099671939BCDABF;a9c6be8b5a;9B2DD77E13DD462CACBA83ED30672B1E;636696728b;db533f4977;C0579E685DB44A0D9349DF524611BD8D;FDFC8E01969A4BBFBF1BF81D67F699BC;C5F7FE902B894CF9AEB828DECBB80C34;c531b570e9;60e81c691d;85c66f6494;0FE7395834524DC884C8903978F77996;7020276aa4;c85d45a0ef;91573703a9;a8f59d8d90;F5E71E148E0B48D68F1482C041D7DF2C;9FB130A0ACCB43CA931D00881D911475;FF7F7CEA049A4639BFD5759EDA4ABCEF;FBC398E8869544C68A647868D3692C1E;1CEE724FD55D4D20B2253CFE8968A003;e31a5b34fd;297D5D2A7BD44354A216812108A7C368
2016-01-04_05:00:00 oc_Schalter nextWakeup: 2016-01-04 05:18:24
Unterschied zwischen Kalenderereignis 1 + 2:
- Ereignis 1 wurde gestern angelegt und ist ein einmaliges Ereignis.
- Ereignis 2 ist ein Serienelement, das schon sehr lange im Kalender vorhanden ist.
Als workaround auf dem Testsystem habe ich die notify nun umgestellt, dass auf "end" anstatt "modeEnded" getriggert wird.
Im Logfile heute morgen um 05:00:00 Uhr sieht es übrigens verheerend aus:
2016.01.04 05:00:00 3: get oc_Schalter summary c9a1ea64e6 : sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
2016.01.04 05:00:00 3: set sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts off : Please define sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts first
Mir ist noch ein eigenartiges Verhalten aufgefallen:
Gestern abend habe ich zu Testzwecken einen einmaligen Termin von 22:20 bis 22:25 Uhr angelegt, danach ein set ... reload gemacht.
Dann habe ich per get ... vevents festgestellt, dass ich versehentlich den Termin auf den 04.01. anstatt den 03.01. geplant hatte. Das Datum habe ich dann im Termin korrigiert.
Ein neues set ... reload in fhem hat aber nicht dazu geführt, dass im Calendar-device der Termin vom 04. auf den 03. gewandert wäre. fhem behauptet per get ... vevents stur, dass der Termin am 04.01. ansteht.
Erst ein Löschen des Termins mit anschließender Neuanlage mit korrektem Datum löste das Problem.
Hallo Udo,
Danke für Deine Tests. Habe die Ergebnisse registriert und werde sie am Wochenende abarbeiten.
Zu der Änderung von Terminen. Das hatte ich bei mir exzessiv getestet. Falls Du das nachstellen kannst, wäre mir geholfen, den entsprechenden Auszug von get ... vevents zu sehen.
Ein geändertes VEVENT gibt es nach dem ersten get ... reload zweimal, einmal als modified-new (oder changed-new) und einmal als modified-old (oder changed-old), wobei die beiden VEVENTS wechselseitig auf die interne ID (kleine Ganzzahl) ihres Gegenstücks verweisen. Ist das VEVENT einfach nur known, hat das Modul die Änderung nicht mitbekommen. Auch in diesem Fall wäre es interessant, es zu sehen, wobei ich dann auch noch die genaue Zeit der Änderung im Google-Kalender wissen müsste, um zu sehen, wie das im VEVENT reflektiert ist.
Viele Grüße
Boris
Edit: wir reden nicht von einem Google-Kalender, sondern von einem Kalender in ownCloud, in dem Einträge per Apple OSX Kalender verwaltet werden.
Termin angelegt:
38: VEVENT [new]
CREATED: 20160104T212702Z
DTEND: 20160105T231500
DTSTAMP: 20160104T212800Z
DTSTART: 20160105T230000
SEQUENCE: 0
SUMMARY: testEintrag
UID: 54B48541-01B0-4114-8B18-1CEE487BC6E7
X-APPLE-TRAVEL-ADVISORY-BEHAVIOR: AUTOMATIC
>>> Events:
54B4854101B041148B181CEE487BC6E7 upcoming 05.01.2016 23:00:00-05.01.2016 23:15:00 testEintrag
>>> Skipped events:
Termin geändert von 05.01. auf 04.01., danach ein get ... reload
38: VEVENT [known]
CREATED: 20160104T212702Z
DTEND: 20160105T231500
DTSTAMP: 20160104T212800Z
DTSTART: 20160105T230000
SEQUENCE: 0
SUMMARY: testEintrag
UID: 54B48541-01B0-4114-8B18-1CEE487BC6E7
X-APPLE-TRAVEL-ADVISORY-BEHAVIOR: AUTOMATIC
>>> Events:
54B4854101B041148B181CEE487BC6E7 upcoming 05.01.2016 23:00:00-05.01.2016 23:15:00 testEintrag
>>> Skipped events:
Es gibt keine zwei vevents, soweit ich das sehe.
Nachtrag:
Das Löschen des Kalendereintrags wird erkannt:
38: VEVENT [obsolete, deleted]
CREATED: 20160104T212702Z
DTEND: 20160105T231500
DTSTAMP: 20160104T212800Z
DTSTART: 20160105T230000
SEQUENCE: 0
SUMMARY: testEintrag
UID: 54B48541-01B0-4114-8B18-1CEE487BC6E7
X-APPLE-TRAVEL-ADVISORY-BEHAVIOR: AUTOMATIC
>>> Events:
>>> Skipped events:
Zitat von: betateilchen am 04 Januar 2016, 22:33:08
Edit: wir reden nicht von einem Google-Kalender, sondern von einem Kalender in ownCloud, in dem Einträge per Apple OSX Kalender verwaltet werden.
Ahaaa, möglicherweise verhält sich das nicht RFC-konform. Kannst Du mir bitte mal das VEVENT aus dem icalendar schicken, vor und nach Änderung? get ... vcalendar
Will sehen, woran man die Änderung überhaupt erkennen kann.
Angelegt:
BEGIN:VEVENT
CREATED:20160104T230906Z
UID:E59607CA-154A-4B8A-8D5D-6DF446F65AB5
DTEND;TZID=Europe/Berlin:20160106T071500
TRANSP:OPAQUE
X-APPLE-TRAVEL-ADVISORY-BEHAVIOR:AUTOMATIC
SUMMARY:Neues Ereignis
DTSTART;TZID=Europe/Berlin:20160106T061500
DTSTAMP:20160104T230910Z
SEQUENCE:0
END:VEVENT
Geändert:
BEGIN:VEVENT
CREATED:20160104T230906Z
UID:E59607CA-154A-4B8A-8D5D-6DF446F65AB5
DTEND;TZID=Europe/Berlin:20160105T071500
TRANSP:OPAQUE
X-APPLE-TRAVEL-ADVISORY-BEHAVIOR:AUTOMATIC
SUMMARY:Neues Ereignis
DTSTART;TZID=Europe/Berlin:20160105T061500
DTSTAMP:20160104T231009Z
SEQUENCE:0
END:VEVENT
Zitat von: Dr. Boris Neubert am 04 Januar 2016, 22:55:14
Will sehen, woran man die Änderung überhaupt erkennen kann.
an DTEND, DTSTART und DTSTAMP würde ich vermuten :)
Hallo Boris,
hatte die alte Modulversion eigentlich ein (bekanntes?) Problem mit Terminen über den Jahreswechsel?
http://forum.fhem.de/index.php/topic,46853.0.html
Falls ja, sollte man mal prüfen, wie sich die neue Modulversion dabei verhält.
Zitat von: betateilchen am 06 Januar 2016, 18:07:42
hatte die alte Modulversion eigentlich ein (bekanntes?) Problem mit Terminen über den Jahreswechsel?
http://forum.fhem.de/index.php/topic,46853.0.html
Nein, und siehe dort.
Viele Grüße
Boris
kurze Rückmeldung meinerseits...
bei mir läuft alles wie es soll. zumindest soweit ich das beurteilen vermag.
Ich habe lediglich Anzeigefehler in der Readingsgroup vom CALVIEW.
Dort werden die Serientermine sehr häufig angezeigt. siehe Screenshot.
Ich sehe die Probleme aber eher beim CALVIEW Modul, das aufgrund der hiesigen Neuentwicklung eben nicht 100% kompatibel zu sein scheint. Setze ich im CALENDAR Device ein "get Device full all" wird alles korrekt angezeigt.
vb
Zitat von: VB90 am 07 Januar 2016, 22:16:28
Ich habe lediglich Anzeigefehler in der Readingsgroup vom CALVIEW.
...
Ich sehe die Probleme aber eher beim CALVIEW Modul
nein, das kommt aus dem neuen Kalendermodul. Ich habe ähnliche Probleme (siehe weiter oben hier im Thread)
Bei mir hat die Begrenzung auf 1 bei "get ... summary $uid 1" den Effekt behoben. Wobei ein einzelner event ja von Haus aus nur eine summary hat und nicht die ganze Liste aus der eigenen Serie :)
Hallo,
habe zwei Änderungen durchgeführt (siehe bitte Eröffnungsbeitrag).
Ich bestätige ferner, dass bei einem Serientermin modeEnded nicht kommt - der Grund ist, dass der Termin wieder in den Modus Upcoming geht. In modeEnded sind die Ereignisse, die gerade nach modeEnd gekommen sind.
Womit ich mich noch befassen werde ist die Frage, ob ein beendeter Termin nicht noch durch modeEnd und modeEnded gezogen werden sollte und ob das überhaupt realisierbar ist.
Das ist alles schon sehr subtil...
Die empfohlene Vorgehensweise ist sowieso auf das Event end: <uid> zu reagieren. Das muss ich noch dokumentieren.
Interaktion mit CALVIEW sehe ich mir auch noch näher an.
Grüße
Boris
Bevor Du jetzt noch mehr solche Krücken vorschlägst, solltest Du besser auf die angedachte Abwärtskompatibilität komplett verzichten und lieber ein logisch und leicht verständliches, stabiles Modul bauen.
Mir wäre das jedenfalls als Anwender viel lieber.
Hallo,
so, das Ende des alpha-Tests naht.
An den FHEM-Events für die mode...-Readings habe ich nicht gedreht.
Ich habe einen neuen Filter namens "new" eingebaut. Er funktioniert praktisch so wie "all" in der Vorversion, indem aus jeder Menge von Terminen mit derselben UID der erste nicht abgelaufene Termin angezeigt wird. Dafür ist jetzt das Attribut hideOlderThan per Default nicht mehr gesetzt. Migrationshinweise in What's new? im ersten Beitrag.
Die von Udo gemeldeten Auffälligkeiten sollten entweder beseitigt oder erklärt sein.
Weiterhin gibt es jetzt das Plug-In onCreateEvent. Damit kann man sich z.B. einen Alarm an die Termine zur Abholung der Mülltonne zaubern. Das tut hoffentlich die ganzen Frickeleien mit den Müllkalendern vereinfachen.
Wenn nichts gravierendes mehr an Meldungen kommt, geht das Teil morgen in den beta-Test für alle.
Viele Grüße
Boris
An Chris wegen CALVIEW.
Ich habe CALVIEW gar nicht richtig zum Laufen gebracht. Konnte mir daher auch nicht ansehen, was man gegen die von VB90 geschilderte Beobachtung tun kann.
Ich habe folgendes erstellt (T ist mein Testkalender):
define CV CALVIEW T 2
define kalenderTermine readingsGroup <%time_calendar>,<Text>,<Zuletzt erfasst> CV
attr kalenderTermine alias Termine
attr kalenderTermine group _KalenderView_
attr kalenderTermine mapping %READING
CV zeigt jedoch nur
Internals:
DEF T 2
INTERVAL 43200
KALENDER T
NAME CV
NR 23
STATE t: 0 td: 0 tm: 0 ts: 0
TYPE CALVIEW
Readings:
2016-01-09 15:41:45 c-started 0
2016-01-09 15:41:45 c-term 0
2016-01-09 15:41:45 c-today 0
2016-01-09 15:41:45 c-tomorrow 0
2016-01-09 15:41:45 state t: 0 td: 0 tm: 0 ts: 0
Attributes:
modes all
Kannst Du mir bitte ein funktionierendes Beispiel geben?
Viele Grüße
Boris
Hallo Boris,
ich habe gerade die neueste Version vom ersten Post (http://forum.fhem.de/index.php/topic,46608.msg383378.html#msg383378) in mein Testsystem geladen.
Beim Versuch einen neuen Calendar per define im webif anzulegen ist mir direkt FHEM abgeschmiert.
Log-Auszug:
Zitat
2016.01.10 13:35:51 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/57_Calendar.pm line 1710.
2016.01.10 13:35:51 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/57_Calendar.pm line 1715.
2016.01.10 13:35:51 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/57_Calendar.pm line 1854.
2016.01.10 13:35:51 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/57_Calendar.pm line 1861.
2016.01.10 13:35:51 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/57_Calendar.pm line 1868.
2016.01.10 13:35:51 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/57_Calendar.pm line 1883.
Software Error at ./FHEM/57_Calendar.pm line 1907.
define des Calendar:
define calTest Calendar ical url https://calendar.google.com/calendar/ical/8bugtd3u7c7rhf4fgaodac7ufo%40group.calendar.google.com/public/basic.ics
Das ganze passiert auch, wenn ich einen bereits bestehenden Calendar mit o.a. url modifiziere.
Beim Starten von FHEM werden aber bereits zuvor definierte Calendar ohne Probleme wieder angelegt.
Wenn ich nun auch den Kalender mit o.a. url direkt in der fhem.cfg definiere und dann FHEM starte, wird auch das neue Calendar-Device problemlos angelegt und funktioniert (s.Screenshot).
Auszug aus fhem.cfg:
define calTest Calendar ical url https://calendar.google.com/calendar/ical/8bugtd3u7c7rhf4fgaodac7ufo%40group.calendar.google.com/public/basic.ics
attr calTest alias Test-Kalender
attr calTest hideLaterThan 1
attr calTest hideOlderThan 0
attr calTest room caltest
Gruß Benni.
Hallo Benni,
Danke fürs Testen und die aussagekräftigen Meldungen. Konnte das Problem damit sofort nachstellen und beseitigen.
Neue Version im Eingangsbeitrag.
Viele Grüße
Boris
Wenn ich mich auf modeEnded, modeStarted usw ohnehin nicht mehr verlassen kann, hätte ich gerne ein Attribut, mit dem ich die Generierung dieser mode.* readings samt ihrer events komplett abschalten kann. Mir reicht end: und start:
Kannst Du Gedanken lesen, Udo?
Ich will nämlich ein Attribut einbauen, mit dem man diese Readings anschalten kann. Es würde dann per Default gesetzt sein, bis irgendwann der Default wechselt.
--> sobald der beta-Test durch ist, werden solche Neuerungen geliefert. Insbesondere aber erstmal die flexible Ausgabe, die ich hier beschrieben habe: http://forum.fhem.de/index.php/topic,46608.msg383729.html#msg383729 (http://forum.fhem.de/index.php/topic,46608.msg383729.html#msg383729)
(Natürlich kann man sich auf mode... verlassen - man muss nur wissen, was es leistet und was nicht.)
Die mode.* leisten in meinen Tests einfach nicht mehr das, was bisher möglich war. Insofern sind sie für mich leider unzuverlässig geworden.
Hat zufällig jemand schon ganztägige, periodische Termine getestet? Bin noch nicht dazu gekommen, aber mit diesen Terminen hatte ich im alten Modul massive Probleme.
Ausserdem wäre es schön, wenn Du die jeweils aktuelle betaversion in ./contrib bereitstellen könntest, da macht das Testen auf entfernten Systemen, die man per ssh erreicht, viel einfacher, da man die Datei dann per avn bereits auf dem Zielsystem hat. Das ist viel einfacher, als sie erst aus dem Forum runterladen und dann aufs Zielsystem kopieren zu müssen.
Viele Grüsse aus dem IC im Mittelrheintal
Hallo Boris,
danke! Die neue Version führt nicht mehr zum Absturz, aber....
...hat sich zwischenzeitlich noch was bei der Sichtbarkeit der Termine geändert?
Sobald ich das Attribut hideLaterThan auf einen beliebigen Wert setze bekomme ich mit einem get leider gar nichts mehr zurück. Sobald ich das Attribut wieder lösche, bekomme ich wieder alles zurück.
Getestet mit meinem (öffentlich verfügbaren) Test-Kalendar von ein paar Posts weiter oben (http://forum.fhem.de/index.php/topic,46608.msg388779.html#msg388779).
In wie weit ist denn bereits die angedeutete neue get-Syntax,
get events ...
die mir übrigens sehr gut gefällt, implementiert?
limit scheint jedenfalls noch nicht zu funktionieren ;D
(bekomme derzeit immer alles zurück)
Hallo Benni,
Danke fürs Weitertesten.
Kann Deine Meldung nicht nachvollziehen. Habe Deinen Kalender definiert und dann
attr calTest hideLaterThan 30d
gesetzt und es funktioniert. Bitte beachten, dass bei Angabe einer nackten Ganzzahl die Zeitangabe in Sekunden ist (siehe commandref für die erlaubten Formate).
Weitere Neuerungen kommen, wenn die neue Version durch den Betatest ist (siehe meine Antwort wenige Beiträge zurück an betateilchen).
Grüße
Boris
Die Funktionsweise der hideDingenskirchen ist mir ohnehin suspekt. Da habe ich noch NIE das Ergebnis bekommen, mit dem ich eigentlich gerechnet hätte.
Zitat von: Dr. Boris Neubert am 10 Januar 2016, 17:39:50
Bitte beachten, dass bei Angabe einer nackten Ganzzahl die Zeitangabe in Sekunden ist (siehe commandref für die erlaubten Formate).
Ah! Das ist mir leider entgangen. :-[
Jetzt klappt's! Danke!
Hallo,
habe noch eine funktionale Erweiterung eingebaut:
Neue Filter mode=<regex> und uid=<regex> bei get <name> <format> <filter> [max]
Grüße
Boris
Hallo Boris,
ich habe bei mir doch noch eine Kleinigkeit festgestellt.
Ich habe ein Notify auf dem '
updated' Event es Kalenders gesetzt, in dem ich dann u.a. per
get Termine anhand deren Status abfrage:
get calTest summary upcoming
get calTest summary start
(die werde ich dann noch auf die neue
filter-Funktionalität umstellen)
anscheinend ist aber zum Zeitpunkt, an dem das
updated Event kommt, der Kalender noch nicht vollständig verarbeitet, denn ich bekomme mit den
get keine Ergebnisse. Wenn ich allerdings nach einer Verzögerung (aktuell habe ich mal 30 Sekunden genommen) die
get-Abfrage mache, erhalte ich die erwarteten Ergebnisse.
So wie's aussieht, verwende ich da wahrscheinlich noch "zukünftige" Funktionalität, zumindest konnte ich in der Doku nichts zum
updated-Event finden, den habe ich mir aus dem Eventmonitor geholt.
Zitat
2016-01-17 12:43:59 Calendar calTest update
2016-01-17 12:43:59 Calendar calTest retrieved
2016-01-17 12:43:59 Calendar calTest calname: Testkalender
2016-01-17 12:43:59 Calendar calTest lastUpdate: 2016-01-17 12:43:59
2016-01-17 12:43:59 Calendar calTest nextUpdate: 2016-01-17 16:43:59
2016-01-17 12:43:59 Calendar calTest updated
2016-01-17 12:43:59 Calendar calTest nextWakeup: 2016-01-17 16:43:59
Wie auch immer, mit der verzögerten Abfrage funktioniert es jetzt erst mal so, wie ich wollte, daher das nur als Hinweis.
Gruß Benni.
Hallo Benni,
Zitat von: Benni am 17 Januar 2016, 12:54:28
ich habe bei mir doch noch eine Kleinigkeit festgestellt.
Danke für die Meldung. Ohne Deinen Use Case und die genaue Beschreibung wäre das sicher erst irgendeinem User aufgefallen und dann hätte ich mir Ewigkeiten das Hirn zermartert, was das Problem ist.
Es ist KEINE Kleinigkeit.
Das updated-Event kommt in der von Dir getesteten Version, nachdem die Termine (calendar events am VEVENT) erzeugt sind und bevor die Modi aktualisiert sind. Damit stehen die Modi alle auf "undefined" und Du erhältst keine Termine, die im Modus "upcoming" oder "start" stehen.
Wie lässt sich das beheben? Dazu vorab eine Erklärung. Die zwei zentralen Routinen sind Calendar_Update und Calendar_CheckTimes. Calendar_Update holt den Kalender von der Quelle und aktualisiert Termine, sofern diese an der Quelle geändert wurden. Calender_CheckTimes wird zu jedem Zeitpunkt aufgerufen, an dem ein Termin beginnt, endet, oder alarmiert wird, sowie nach einem Update. Erst dabei werden auch die Modi aller Termine aktualisiert.
Ereignis "update" feuern nach Calendar_Update führt dazu, dass in diesem Augenblick die Modi noch nicht korrekt sind. Ereignis "update" feuern nach Calendar_CheckTimes führt dazu, dass Dein Notify nach jeder Modusänderung jedes Termins gefeuert wird.
Die sauberste Lösung ist m.E. die folgende:
- Ereignis "triggered" wird gefeuert, immer nachdem CheckTimes die Modi aktualisiert hat.
- Ereignis "update" wird gefeuert, immer nachdem CheckTimes die Modi aktualisiert hat und zuvor der Kalender aktualisiert wurde (per update oder reload).
Das setze ich noch um, aber nicht mehr heute.
Viele Grüße
Boris
Hallo Benni,
habe die Änderung am Calendar-Modul durchgeführt. Nachdem der Kalender aktualisiert wurde und alle Zeiten gesetzt sind, wird das FHEM-Event triggered gefeuert. Auf das Event updated aus meinem vorigen Beitrag habe ich verzichtet. Mir leuchtet nicht ein, wozu man das braucht.
Viele Grüße
Boris
Hallo,
ich habe an einer zentralen Stelle im Modul noch herumgebastelt. Die Laufzeit für das Merging und Crossreferencing der Termine geht quadratisch mit der Anzahl der VEVENTs. Das habe ich durch Perl-Gymnastik mit Lookup-Hashes versucht zu beschleunigen. Meine Tests mit mehreren Kalendern haben danach immer noch die richtigen Ergebnisse erbracht. Es wäre aber gut, wenn jeder seinen Anwendungsfall noch mal testet.
Die Version im ersten Beitrag ist der Release-Kandidat. Wenn nichts mehr gefunden wird, geht das Modul nächstes Wochenende ins Update.
Grüße
Boris
Hallo Boris,
ich habe die neue Version gestern Abend noch auf mein Testsystem eingespielt und heute Morgen, nachdem es dort problemlos und in Funktionalität wie erwartet durchlief, auf mein Produktiv-System übernommen.
Auch hier läuft im Moment alles wie erwartet. Mit dem triggered-Event liefert nun auch mein notify die korrekten Ergebnisse aus den Readings.
Ich hätte da übrigens noch eine Idee für den max-Parameter beim get-Command. Könnte man den eventuell auch eventuell mit max-days (bspw. 10d) angeben, denn u.U. interessieren ja nicht die nächsten 10 Termine, sondern die der nächsten 10 Tage, schließlich kann es an einem Tag ja auch mehrere Ereignisse geben.
Natürlich könnte man hier auch über hideLaterThan einschränken, was sich ja aber wieder generell auf die Sichtbarkeit auswirken würde. Mit max-days könnte einzelne Abfragen flexibel einschränken (Noch flexibler wäre natürlich eine Range-Angabe ;) )
Auf jeden Fall scheint bei mir alles soweit korrekt zu funktionieren, so dass einem Release von meiner Seite her nichts entgegen steht.
Gruß und vielen Dank!
Benni.
Danke, Benni, für Deinen Test!
Auch Danke für den Vorschlag. Ich gehe jetzt in den Feature Freeze und mache dann erstmal Calendar-Pause. Habe noch Themen auf der ECMD-Schiene.
Wenn ich mit Calendar wieder anfange, werde ich als erstes
get myCalendar events filter:mode=alarm|start|upcoming format=custom:{ sprintf("...") } select:series=next,max=8,from=-3d,to=10d
entwickeln. Wird aufwändig, aber lieber einmal richtig ran. Ich habe gestern den Bedarf gut gesehen, als ich versucht habe, CALVIEW für Arme aka CalendarAsHtml() zu entwickeln.
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert am 24 Januar 2016, 11:29:36
get myCalendar events filter:mode=alarm|start|upcoming format=custom:{ sprintf("...") } select:series=next,max=8,from=-3d,to=10d
gefällt mir! ;D
Hallo Boris,
was wurde eigentlich aus diesem von Dir am 29.09.2013 (http://forum.fhem.de/index.php/topic,14834.msg96780.html#msg96780) gemachten Vorschlag?
Zitat von: Dr. Boris Neubert
Was hältst Du von einer superduperselbstkonfigurierbaren Lösung?
attr myCalendar customFormat uid,summary,location
get myCalendar all custom
Viele Grüße
Boris
(ich gebe zu, ich habe noch nicht die gesamte commandref der aktuellen Neuentwicklung durchforstet)
Viele Grüße
Udo
---
Zitat von: betateilchen am 24 Januar 2016, 20:03:13
was wurde eigentlich aus diesem von Dir am 29.09.2013 (http://forum.fhem.de/index.php/topic,14834.msg96780.html#msg96780) gemachten Vorschlag?
(ich gebe zu, ich habe noch nicht die gesamte commandref der aktuellen Neuentwicklung durchforstet)
Steht wieder auf der Agenda.
Den Vorschlag von damals habe ich als ungenügend verworfen. Wer nämlich am selben Kalender verschiedene custom-Formate anwenden möchte, muss diese immer erst als Attribut setzen, bevor es benutzen kann. Die Form
get myCalendar events format:custom=<irgendwas> ...ist meine präferierte Variante. <irgendwas> wird so ähnlich wie stateFormat funktionieren, mit vorgefertigten Variablen $SUMMARY, $STARTDATE, ... und vollem Zugriff $e->... auf das Event (wie in onCreate).
Aber ich will erstmal die Version freilassen und mich ausruhen, bevor ich das angehe.
Viele Grüße
Boris
Schade. :(
Ich fand den angedachten Ansatz sehr praktisch, in vielen Fällen völlig ausreichend und sehr viel inuitiver (und damit vor allem Anfängern leichter erklärbar) als die jetzt favorisierte Lösung.
get oc_Schalter text all 2
Sollte eigentlich immer - wie im alten Modul, zwecks Abwärtskompatibilität - vom aktuellen Zeitpunkt ausgehend die nächsten zwei events zeigen und nicht die ersten zwei events der Serie. In meiner Anwendung kommen da Werte aus 2014 im InfoPanel zur Anzeige.
Hallo,
all durch next ersetzen.
Viele Grüße
Boris
ja ja... ich hab bereits erkannt, dass ich für das neue Calendar-Modul einfach zu doof bin :(
Kann es sein, dass bei einem erfolglosen update-Versuch eines bestehenden Kalenders (beispielsweise weil der Server auf dem der Kalender liegt, nicht erreichbar ist) sämtliche in fhem vorhandenen events verlorengehen?
Zumindest hatte ich heute den Effekt, dass mir in fhem plötzlich keine events mehr angezeigt wurden, weil der Server bei Strato nicht erreichbar war und das regluäre update (3600 Sekunden) gescheitert war. In state des device war die Fehlermeldung, dass der Server nicht erreicht werden konnte, enthalten.
Ernstzunehmende Frage. Muss mir zuhause den Flow ansehen. Gibt es ein verwertbares Log von dem Incident?
Viele Grüße
Boris
Erstmal nicht. Prinzipiell kann ich die Situation jederzeit reproduzieren, weil der Kalenderserver mir selbst gehört - ich brauche ihn nur runterzufahren. Aber heute nicht mehr.
ok ok... aber wirklich aussagekräftig ist selbst verbose=5 nicht.
2016.01.27 21:18:42 4: Calendar oc_Heizung: Updating...
2016.01.27 21:18:42 4: Calendar oc_Heizung: Getting data from URL <hidden>
2016.01.27 21:18:42 1: Calendar oc_Heizung: retrieval failed with error message cloud.betateilchen.de: Verbindungsaufbau abgelehnt
2016.01.27 21:20:34 4: Calendar oc_Schalter: Updating...
2016.01.27 21:20:34 4: Calendar oc_Schalter: Getting data from URL <hidden>
2016.01.27 21:20:34 1: Calendar oc_Schalter: retrieval failed with error message cloud.betateilchen.de: Verbindungsaufbau
Das richtig schlimme an der Sache: Nach einem fehlgeschlagenen Update wird offenbar die regelmäßige Aktualisierung komplett verworfen, denn seit halb fünf heute abend gab es keine Aktualisierungen mehr, obwohl der Server längst wieder läuft und die Calendar-devices nach einem manuellen set ... reload wieder korrekt arbeiten.
(http://up.picr.de/24413691hz.jpg)
Okay, die fehlende Aktualisierung kann auch ein Problem im Programmfluss sein. Die Angaben reichen erstmal. Schaue mir den Code an und komme dann zurück.
Grüße
Boris
Zitat von: betateilchen am 25 Januar 2016, 08:56:02
Schade. :(
Ich fand den angedachten Ansatz sehr praktisch, in vielen Fällen völlig ausreichend und sehr viel inuitiver (und damit vor allem Anfängern leichter erklärbar) als die jetzt favorisierte Lösung.
Habe mir überlegt, ein Attribut
attr myCalendar defaultFormat <format>einzuführen. Nach dem Release, wenn die Hitze abgeklungen ist.
Zitat von: Dr. Boris Neubert am 27 Januar 2016, 21:50:48
Okay, die fehlende Aktualisierung kann auch ein Problem im Programmfluss sein. Die Angaben reichen erstmal. Schaue mir den Code an und komme dann zurück.
Es war ein Fehler im Programmfluss. Nach einem fehlgeschlagenen NonblockingGet wurde der Wecker nicht gestellt und der ewige Zyklus von update und trigger kam zum Erliegen.
Gefixt in der Version im Eingangsbeitrag.
Irgendwie habe ich aktuell ein Problem mit einmaligen Terminen, die über Mitternacht hinausgehen, wenn ich hideOlderThan auf 0d setze. Muss die Sache aber noch genauer untersuchen. Effekt ist, dass am Ende des Termins zwar der event für end: getriggert wird, der Termin aber nicht mehr gefunden wird, um die summary auszulesen.
Ich verstehe das Problem.
Gut lösen lässt es sich wohl nur mit der angekündigten Superduper-Funktion get ... events flexibleFilterregel
Für den Augenblick kannst Du Dir vielleicht damit behelfen, hideOlderThan auf 10 zu setzen. Das steht für 10 Sekunden. Das müsste reichen, im Notify noch das Summary auszulesen.
Den Vorschlag mit 10 Sekunden werde ich mal testen, danke.
Verständnisfrage...
Warum werden mir trotz hideOlderThan = 10 folgende vEvents von get ... vEvents zurückgeliefert?
93: VEVENT @580 [known]
CREATED: 20160128T161756Z
DTEND: 20160207T070000
DTSTAMP: 20160128T161813Z
DTSTART: 20160206T210000
SEQUENCE: 0
SUMMARY: sz_Bett_.*
UID: B68BC8BB-BFA9-4EAC-AF9B-418925813C5C
>>> Events:
B68BC8BBBFA94EACAF9B418925813C5C end 06.02.2016 21:00:00-07.02.2016 07:00:00 sz_Bett_.*
>>> Skipped events:
94: VEVENT @591 [known]
CREATED: 20160202T194059Z
DTEND: 20160204T205500
DTSTAMP: 20160202T194150Z
DTSTART: 20160203T203000
SEQUENCE: 0
SUMMARY: sz_Bett_links
UID: 12D5E197-C121-40B9-83DF-A9737034BDD1
>>> Events:
12D5E197C12140B983DFA9737034BDD1 end 03.02.2016 20:30:00-04.02.2016 20:55:00 sz_Bett_links
>>> Skipped events:
95: VEVENT @603 [known]
CREATED: 20160207T150322Z
DTEND: 20160208T070000
DTSTAMP: 20160207T150344Z
DTSTART: 20160207T210000
SEQUENCE: 0
SUMMARY: sz_Bett_rechts
UID: 4536E59A-2C7B-435F-BFB0-58F72FC79205
>>> Events:
4536E59A2C7B435FBFB058F72FC79205 start 07.02.2016 21:00:00-08.02.2016 07:00:00 sz_Bett_rechts
>>> Skipped events:
Zumindest die events 93 und 94 hätte ich nicht als Rückgabe erwartet.
get ... vevents gibt immer alle VEVENTs. hide... bezieht sich auf Termine und findet nur bei get ... full ... und Konsorten Anwendung.
ok, danke.
Zitat von: Dr. Boris Neubert am 07 Februar 2016, 10:44:06
Für den Augenblick kannst Du Dir vielleicht damit behelfen, hideOlderThan auf 10 zu setzen. Das steht für 10 Sekunden. Das müsste reichen, im Notify noch das Summary auszulesen.
Die Angabe von 10 Sekunden haben das beschriebene Problem tatsächlich gelöst. Das Problem hatte nichts damit zu tun, ob der Event über Mitternacht geht oder nicht, es war mir nur zuerst bei solchen Terminen aufgefallen.
Sollte nicht seitens des Moduls automatisch eine solche "Löschfrist" eingehalten werden?
Oder ein Wert 0 für hideOlderThan generell abgelehnt werden? Ob man 0d oder 0 angibt, läuft ja am Ende auf die gleiche Frist raus.
Zitat von: betateilchen am 08 Februar 2016, 09:40:34
Oder ein Wert 0 für hideOlderThan generell abgelehnt werden? Ob man 0d oder 0 angibt, läuft ja am Ende auf die gleiche Frist raus.
Ich habe in der Doku darauf hingewiesen:
Please note that an action triggered by a change to mode "end" cannot access the calendar event
if you set hideOlderThan to 0 because the calendar event will already be hidden at that time. Better set
hideOlderThan to 10.
Wird demnächst eingecheckt.
Grüße
Boris
naja, besser als nix 8)
Wobei das Problem nur bei nicht-wiederholenden Events auftritt. Bei wiederholenden Ereignissen wird zwar eine summary zurückgeliefert, das ist aber nicht zwingend die summary des Ereignisses, das gerade den event getriggert hat. Da kommen manchmal ganz lustige Dinge raus...
Nach nunmehr zwei Jahren fertiggestellt:
https://forum.fhem.de/index.php?topic=86148.new#new (https://forum.fhem.de/index.php?topic=86148.new#new)
Bitte dort weiterdiskutieren. Ich mache hier endgültig dicht.