Dann sind sind meine Suchtexte vermutlich nicht korrekt. Ich probiere es dann nochmal mit der Testversion. Muss also der ganze Text für die Terminbezeichnung übereinstimmen und nicht nur ein Wort davon eindeutig sein? Dann macht das mit den RegEx natürlich deutlich mehr Sinn!
Beim Suchtext gibst du einen Teilstring (z.B. „Papier“) mit.
Beim Suchmuster ist es eine Regular Expression.
Ich habe ein Problem mit Wiederholenden Ereignissen. Hier wird im FROM Feld immer die ENDuhrzeit angezeigt. Das Datum stimmt allerdings. Im KONKRETEN ist der Termin auch noch über die Nachtgrenze, das hatte ich ursprünglich in Verdacht. Habe aber während des Schreibens auch Termine gefunden die den Tag nicht wechseln, mit dem selben Problem.
Zudem - auch auf die Gefahr dass ich das vor paar Wochen schonmal geschrieben hatte: Wenn die SSL Validierung fehlschlägt, bitte die Instanz nicht dauerhaft sperren sondern regelmäßig erneut prüfen, ob das Zertifikat wieder gültig ist. Mir ist vor paar Wochen das Zertifikat abgelaufen und die Kalender standen. Auch nach Zertifikatsaustausch.
BEGIN:VEVENT
UID:5ddd32e9-1981-4444-95ff-b3abd18ea48e
DTSTART;TZID=W. Europe Standard Time:20250129T223000
DTEND;TZID=W. Europe Standard Time:20250130T070000
TRANSP:OPAQUE
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
LAST-MODIFIED:20250124T181224Z
DTSTAMP:20250124T181224Z
CREATED:20250124T181224Z
SUMMARY:Arbeiten
CLASS:PUBLIC
RRULE:FREQ=DAILY;COUNT=4
END:VEVENT
Array
(
[0] => Array
(
[UID] => 5ddd32e9-1981-4444-95ff-b3abd18ea48e
[Name] => Arbeiten
[Status] =>
[Location] =>
[Description] =>
[Categories] =>
[From] => 1738359000
[To] => 1738389600
[FromS] => 2025-01-31T22:30:00+01:00
[ToS] => 2025-02-01T07:00:00+01:00
[allDay] =>
[Alarms] => Array
(
)
)
[1] => Array
(
[UID] => 5ddd32e9-1981-4444-95ff-b3abd18ea48e
[Name] => Arbeiten
[Status] =>
[Location] =>
[Description] =>
[Categories] =>
[From] => 1738445400
[To] => 1738476000
[FromS] => 2025-02-01T22:30:00+01:00
[ToS] => 2025-02-02T07:00:00+01:00
[allDay] =>
[Alarms] => Array
(
)
)
[2] => Array
(
[UID] => b6a62d5b-374d-42df-8b54-888bce837c77
[Name] => Arbeiten
[Status] =>
[Location] =>
[Description] =>
[Categories] =>
[From] => 1738648800
[To] => 1738648800
[FromS] => 2025-02-04T07:00:00+01:00
[ToS] => 2025-02-04T07:00:00+01:00
[allDay] =>
[Alarms] => Array
(
)
)
Moin,
Im Kalender steht doch von 22:30 bis 7:00 am Folgetag genau wie bei iCal nur beim letzten Eintrag nicht.
Die Termine sind vom:
-
- auf 30.
-
- auf 31.
-
- auf 1.
-
- auf 2.
Also 4mal von 22:30 bis 7:00 und bis zum 2.2 steht es ja auch drin.
Ralf
Ja. Aber die Uhrzeit im From (nicht FromS) Arrayfeld ist fälschlicherweise 7 Uhr statt 22:30 Uhr.
Aber es ist der letzte (4.) Tag. Könnte ein < bzw. <= Fall sein.
Ralf
Also das letzte Arrayelement ist falsch, die anderen sind richtig. Sind wir uns da einig.
Das schaue ich mir mal an.
Da habe ich eigentlich nicht vor zu investieren.
Wenn du dich expliziter informieren lassen möchtest, könntest du das Event Control dazu benutzen.
Zum Reaktivieren sollte ein ApplyChanges oder einfach ein Symcon Neustart.
In meiner html Ausgabe stimmt die From Zeit bei keinem der vier Termine. Es wird immer 7 Uhr angezeigt. In dem o.s. Beispiel hingegen scheint nur der letzte Tag falsch zu sein.
Symcon startet bei mir ca. 3x im Jahr neu. Das ist schonmal keine Option. Informieren bedeutet manueller Eingriff.
Ich vermute dass diese Zeile
if (!in_array($this->GetStatus(), [
IS_ACTIVE,
self::STATUS_INST_OPERATION_TIMED_OUT,
self::STATUS_INST_CONNECTION_ERROR,
self::STATUS_INST_INVALID_MEDIA_CONTENT],
true)) {
halt auch beim Instanzstatus ’ STATUS_INST_SSL_ERROR’ für meine Fälle erneut prüfen sollte.
Ich werde jetzt ein Ereignis bauen, dass den Instanzstatus (vmtl. mit Apply-Changes) nach ~n*Updatetime zurücksetzt.
Das kann ich gerne anpassen.
Burkhard
Jetzt bei genauerer Betrachtung scheint da bei dir noch mehr falsch zu sein. Du hast einen 4x täglich wiederkehrenden Termin
DTSTART;TZID=W. Europe Standard Time:20250129T223000
DTEND;TZID=W. Europe Standard Time:20250130T070000
RRULE:FREQ=DAILY;COUNT=4
beginnend am 29.1.
Also sollten das der
29.1./30.1.
30.1./31.1.
31.1./1.2.
1.2./2.2. sein.
Du erhältst aber den
31.1./1.2.
1.2./2.2.
4.2.
Bei mir kommt es richtig raus:
Die folgenden Einträge wurden gelesen:
Array
(
[0] => Array
(
[UID] => 5ddd32e9-1981-4444-95ff-b3abd18ea48e
[Name] => Arbeiten
[Status] =>
[Location] =>
[Description] =>
[Categories] =>
[From] => 1738186200
[To] => 1738216800
[FromS] => 2025-01-29T22:30:00+01:00
[ToS] => 2025-01-30T07:00:00+01:00
[allDay] =>
[Alarms] => Array
(
)
)
[1] => Array
(
[UID] => 5ddd32e9-1981-4444-95ff-b3abd18ea48e
[Name] => Arbeiten
[Status] =>
[Location] =>
[Description] =>
[Categories] =>
[From] => 1738272600
[To] => 1738303200
[FromS] => 2025-01-30T22:30:00+01:00
[ToS] => 2025-01-31T07:00:00+01:00
[allDay] =>
[Alarms] => Array
(
)
)
[2] => Array
(
[UID] => 5ddd32e9-1981-4444-95ff-b3abd18ea48e
[Name] => Arbeiten
[Status] =>
[Location] =>
[Description] =>
[Categories] =>
[From] => 1738359000
[To] => 1738389600
[FromS] => 2025-01-31T22:30:00+01:00
[ToS] => 2025-02-01T07:00:00+01:00
[allDay] =>
[Alarms] => Array
(
)
)
[3] => Array
(
[UID] => 5ddd32e9-1981-4444-95ff-b3abd18ea48e
[Name] => Arbeiten
[Status] =>
[Location] =>
[Description] =>
[Categories] =>
[From] => 1738445400
[To] => 1738476000
[FromS] => 2025-02-01T22:30:00+01:00
[ToS] => 2025-02-02T07:00:00+01:00
[allDay] =>
[Alarms] => Array
(
)
)
)
Seltsam. Welche Version des iCal Moduls nutzt du?
Ich nutze die letzte Beta von vor ~1 Woche? Der Fehler ist aber schon mindestens 4 Wochen da. Dass das Array falsch ist, könnte auch einfach ein doofer Kopierfehler sein.
Dann probiere mal bitte die Testversion 2.1 build 112 aus.
Irgendwas hat sich geändert, aber der letzte Termin zum Beispiel ist noch immer falsch.
Achtung: Diese Termine werden mit zwei unterschiedlichen Clients angelegt, ggf. macht einer hier das eine falsch, der andere was anderes.
Der 15:15 - 15:15 Uhr Termin ist auch falsch.
[7] => Array
(
[UID] => b6a62d5b-374d-42df-8b54-888bce837c77
[Name] => Arbeiten
[Status] =>
[Location] =>
[Description] =>
[Categories] =>
[From] => 1738648800
[To] => 1738648800
[FromS] => 2025-02-04T07:00:00+01:00
[ToS] => 2025-02-04T07:00:00+01:00
[allDay] =>
[Alarms] => Array
(
)
)
[8] => Array
(
[UID] => b6a62d5b-374d-42df-8b54-888bce837c77
[Name] => Arbeiten
[Status] =>
[Location] =>
[Description] =>
[Categories] =>
[From] => 1738735200
[To] => 1738735200
[FromS] => 2025-02-05T07:00:00+01:00
[ToS] => 2025-02-05T07:00:00+01:00
[allDay] =>
[Alarms] => Array
(
)
)
BEGIN:VEVENT
DTSTAMP:20250201T072737Z
SUMMARY:Arbeiten
DTSTART;TZID=Europe/Berlin:20250203T223000
LOCATION:
RRULE:FREQ=DAILY;WKST=MO;COUNT=2
DURATION:PT30600S
TRANSP:OPAQUE
UID:b6a62d5b-374d-42df-8b54-888bce837c77
END:VEVENT
hier der 15:15 Uhr Eintrag.
DTSTAMP:20250204T134355Z
SUMMARY:ABC
DTSTART;TZID=Europe/Berlin:20240311T090000
RRULE:FREQ=WEEKLY;BYDAY=MO,WE,TH,FR
DURATION:PT6H15M
TRANSP:OPAQUE
UID:ee007417-773c-4ebb-8c5d-85e612b90d85
EXDATE;TZID=Europe/Berlin:20240111T090000
EXDATE;TZID=Europe/Berlin:20240125T090000
[noch ca. 15 weitere EXDATE...
END:VEVENT
Es gab bei wiederkehrenden Terminen mit einer Dauer als Zeitangabe ein Berechnungsproblem.
Ich habe eine neue Beta Version veröffentlicht.