57_Calendar.pm: beta-Test der neuen Version

Init · 31 Januar 2016, 15:17:36

Hallo zusammen,

hier die Logs

FileLog liefert leider nur das:

2016-01-31_15:13:28 myCalendar update
2016-01-31_15:13:35 myCalendar retrieved
2016-01-31_15:14:18 myCalendar lastUpdate: 2016-01-31 15:13:28
2016-01-31_15:14:18 myCalendar nextUpdate: 2016-01-31 18:13:28
2016-01-31_15:14:18 myCalendar triggered
2016-01-31_15:14:18 myCalendar nextWakeup: 2016-01-31 18:13:28

fhemLog:

Code Auswählen

2016.01.31 15:13:28.959 5: Cmd: >set myCalendar update<
2016.01.31 15:13:28.963 4: Calendar myCalendar: Updating...
2016.01.31 15:13:28.969 4: Calendar myCalendar: Getting data from URL <hidden>
2016.01.31 15:13:28.970 5: Triggering myCalendar (1 changes)
2016.01.31 15:13:35.392 5: Triggering myCalendar (1 changes)
2016.01.31 15:13:35.393 5: Notify loop for myCalendar retrieved
2016.01.31 15:13:35.461 4: Calendar myCalendar: parsing data
2016.01.31 15:14:17.486 4: Calendar myCalendar: merging data
2016.01.31 15:14:18.032 4: Calendar myCalendar: 330 records processed, 0 new, 330 known, 0 modified, 0 changed.
2016.01.31 15:14:18.035 4: Calendar myCalendar: creating calendar events
2016.01.31 15:14:18.146 5: Triggering myCalendar (2 changes)
2016.01.31 15:14:18.148 5: Notify loop for myCalendar lastUpdate: 2016-01-31 15:13:28

Viele Grüße
Marc

Dr. Boris Neubert · 31 Januar 2016, 15:30:11

Nanu? Die Zeit wird beim Parsen verbracht.

Kannst Du bitte mal im Dir vorliegenden Code von 57_Calendar in der

sub parseSub($$$) {
...
}

ab Zeile 900 die # vor den Debug-Anweisungen main::Debug wegmachen.

Dann bitte reload 57_Calendar und nochmal den Teil von fhemLog zeigen, den Du gerade gezeigt hast. Der sollte dann Zeilen mit DEBUG> en masse enthalten.

Init · 31 Januar 2016, 15:54:01

Hallo,

das Log folgt gleich als Datei.

Gruß
Marc

Dr. Boris Neubert · 31 Januar 2016, 15:57:45

Hallo,

hast Du den Rest bitte auch noch, also bis zu der Zeile:

Code Auswählen

Calendar myCalendar: 330 records processed, 0 new, 330 known, 0 modified, 0 changed.

Am besten als Anhang.

Grüße
Boris

Init · 31 Januar 2016, 16:06:21

Hallo,

hier die Datei...

VG
Marc

Dr. Boris Neubert · 31 Januar 2016, 16:19:34

OK, Danke.

Das Parsen braucht bei Dir ca. 1 Sekunde pro 200 Zeilen. Bei fast 10.000 Zeilen in der Datei ergibt sich dann die beobachtete Gedenkminute.

Ich muss mir in Ruhe anschauen, wie ich den Durchsatz optimieren kann.

Viele Grüße
Boris

betateilchen · 31 Januar 2016, 16:34:34

Zitat von: Dr. Boris Neubert am 31 Januar 2016, 16:19:34
Ich muss mir in Ruhe anschauen, wie ich den Durchsatz optimieren kann.

Das Parsen im nonblocking Teil ausführen? So mache ich das zumindest in meinem GDS Modul, wo ich zeitweise auch recht große Datenmengen verarbeiten muss.

Dr. Boris Neubert · 31 Januar 2016, 16:38:15

Zitat von: betateilchen am 31 Januar 2016, 16:34:34
Das Parsen im nonblocking Teil ausführen? So mache ich das zumindest in meinem GDS Modul, wo ich zeitweise auch recht große Datenmengen verarbeiten muss.

Die ganze Verarbeitung erfolgt im Callback des Nonblocking-Teils.

betateilchen · 31 Januar 2016, 16:46:03

Genau das ist aber das Problem:

Code Auswählen

callback => \&Calendar_ProcessUpdate,

Calendar_ProcessUpdate() wird doch selbst nicht mehr nonblocking ausgeführt.

Dr. Boris Neubert · 31 Januar 2016, 20:17:25

Zitat von: betateilchen am 31 Januar 2016, 16:46:03
Genau das ist aber das Problem:

Code Auswählen Erweitern
callback => \&Calendar_ProcessUpdate,

Calendar_ProcessUpdate() wird doch selbst nicht mehr nonblocking ausgeführt.

Das ist kein Problem. Bevor ich die Auswertung des Kalenders nebenläufig zum Rest des Geschehens mache und mir dabei alle möglichen Konfliktpotentiale einhandele, optimiere ich erst mal die Ablaufgeschwindigkeit der Übersetzung von ical in die interne Struktur (parse).

Dr. Boris Neubert · 31 Januar 2016, 20:22:46

Zitat von: Dr. Boris Neubert am 31 Januar 2016, 16:19:34
Das Parsen braucht bei Dir ca. 1 Sekunde pro 200 Zeilen. Bei fast 10.000 Zeilen in der Datei ergibt sich dann die beobachtete Gedenkminute.

Die Anlage jedes VEVENTs in der internen Struktur dauert bei Dir 70ms. Erstaunlich lange.

Bitte versuche es einmal mit der beiliegenden Version. Die habe ich darauf getrimmt, VEVENTs schneller anzulegen und Properties, die mit X- beginnen, zu ignorieren.

Bitte hänge wieder das Log mit den DEBUG-Meldungen an. Dazu musst Du bitte die Debug-Anweisungen wieder aktivieren durch Entfernen der # in parseSub().

Vor dem Release der offiziellen Version werde ich nicht mehr an dieser Aufgabe arbeiten.

Viele Grüße
Boris

Init · 31 Januar 2016, 21:57:52

Hallo Boris,

anbei das neue LogFile.

Ist es ein großes Problem nach dem Release das Parsing im HttpUtils_NonblockingGet laufen zu lassen?

VG
Marc

betateilchen · 01 Februar 2016, 10:04:01

Zitat von: Init am 31 Januar 2016, 21:57:52
Ist es ein großes Problem nach dem Release das Parsing im HttpUtils_NonblockingGet laufen zu lassen?

Ja, denn das geht nicht. HttpUtils_NonblockingGet() selbst ist keine Funktion des Calendar-Moduls, deshalb kann darin auch kein Parsen von Kalenderdaten stattfinden, sondern es werden dabei nur die Daten nonblocking vom Server geholt.

Um auch das Parsen nonblocking durchzuführen, ist ein (weiterer) größerer Umbau im Calendar-Modul erforderlich. Da habe ich schon Verständnis für Boris, wenn er sagt, dass er das vor dem offiziellen Release nicht mehr machen wird.

Gerold · 02 Februar 2016, 14:39:29

Hallo,
Ich nutze einen Kalender des örtlichen Entsorgerbetriebs, der in Auzügen wie folgt aufgebaut ist:

Code Auswählen


BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
METHOD:PUBLISH
X-WR-CALNAME:EBM-Abfuhrtermine
X-WR-TIMEZONE:Europe/Berlin
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20151215T142544Z
LAST-MODIFIED:20151215T142544Z
DTSTAMP:20151227T200602Z
UID:14512467621@muellmax.de
SUMMARY:EB Restabfall-Tonne
RRULE:FREQ=WEEKLY;UNTIL=20170101T000000Z;INTERVAL=2;BYDAY=TH
RDATE;VALUE=DATE:20151230
RDATE;VALUE=DATE:20160212
RDATE;VALUE=DATE:20160323
RDATE;VALUE=DATE:20160506
RDATE;VALUE=DATE:20160520
RDATE;VALUE=DATE:20161007
RDATE;VALUE=DATE:20161104
EXDATE;VALUE=DATE:20151231
EXDATE;VALUE=DATE:20160211
EXDATE;VALUE=DATE:20160324
EXDATE;VALUE=DATE:20160505
EXDATE;VALUE=DATE:20160519
EXDATE;VALUE=DATE:20161006
EXDATE;VALUE=DATE:20161103
DTSTART;VALUE=DATE:20151231
DTEND;VALUE=DATE:20160101

Termine des Kalenders, welche mit "RDATE" eingefügt sind, werden auch in der neuen Version nicht berücksichtigt.

VG
Gerold

zweiundzwanzig · 03 Februar 2016, 17:30:00

Zitat von: Dr. Boris Neubert am 28 Januar 2016, 20:06:58
ungetestet:

Code Auswählen Erweitern
attr CKalendar onCreateEvent { $e->{alarm}= $e->{start}-AttrVal($e->{location}, "Vorheizzeit", 0) }

$e ist ein Referenz auf ein Hash, welches den Termin darstellt. $e-> dereferenziert das Hash $e->{foo} gibt den Wert zum Schlüssel foo im Hash zurück.

Danke, jetzt habe ich das mit dem Hash verstanden. Wird hier auch ganz gut erklärt:https://wiki.selfhtml.org/wiki/Perl/Hashes Ich dachte immer an sowas wie Prüfsummen.

Kann es sein, dass man so wie in deinem Beispiel gar nicht aus dem onCreateEvent auf AttrVal zugreifen kann? Ich bekomme:

Code Auswählen

2: Erronenous onCreateEvent { $e->{alarm}= $e->{start}-AttrVal($e->{location}, "Vorheizzeit", 0) }: Undefined subroutine &ICal::Entry::AttrVal called at (eval 5294) line 1.