57_Calendar.pm: beta-Test der neuen Version

Begonnen von Dr. Boris Neubert, 10 Januar 2016, 16:48:46

Vorheriges Thema - Nächstes Thema

Dr. Boris Neubert

Hallo,

vom Kalendermodul gibt es eine neue Version. Der alpha-Test ist soweit erfolgreich verlaufen. Es beginnt nun der beta-Test.

Die wichtigsten Neuerungen:

  • Nicht-blockierende Aktualisierung des Kalenders
  • Alle Termine einer Terminserie innerhalb von +/-400 Tagen werden vorgehalten (bisher nur der nächste).
  • Plug-in, um Termine regelbasiert zu verändern - z.B. um eine Alarmzeit einen Tag vor Abholung der Mülltonne zu ergänzen.
  • Behandelt auch Termine einer Serie, die außer der Reihe sind.

Das Modul 57_Calendar.pm nebst wichtigen Hinweisen und künftige allfällige Änderungen aufgrund von Meldungen aus dem Test findet Ihr im ersten Beitrag dieses Themas: http://forum.fhem.de/index.php/topic,46608.0.html.

Bitte beachtet die dortigen Hinweise in dem eingebetteten Code-Fenster "What's new?". Das Modul ist weitestgehend aber nicht vollständig abwärtskompatibel.

Bitte berichtet in diesem und nur in diesem Thema über Eure Erfahrungen.

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Torben

Hallo Boris,

vielen Dank für die Weiterentwicklung des Moduls. Ich habe es gleich mal ausprobiert, bekomme es aber nicht zum Laufen - wahrscheinlich wegen CALVIEW. Zunächst habe ich es neu eingespielt und mit "reload" aktiviert. Dabei bekam ich folgende Fehlermeldung:
Too many arguments for main::Calendar_GetUpdate at ./FHEM/57_Calendar.pm line 1485, near "0)"
Too many arguments for main::Calendar_GetUpdate at ./FHEM/57_Calendar.pm line 1489, near "1)"
Too many arguments for main::Calendar_GetUpdate at ./FHEM/57_Calendar.pm line 1513, near "0)"
Too many arguments for main::Calendar_GetUpdate at ./FHEM/57_Calendar.pm line 1520, near "1)"
BEGIN not safe after errors--compilation aborted at ./FHEM/57_Calendar.pm line 1714.

Dann habe ich fhem neu gestartet. Dabei geht und bleibt die Last auf 100%, sodass ich über den Browser gar nicht zugreifen kann. Im Log finde ich folgendes:
2016.01.10 17:37:50 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/57_CALVIEW.pm line 93.
2016.01.10 17:37:50 1: PERL WARNING: Use of uninitialized value $M in concatenation (.) or string at ./FHEM/57_CALVIEW.pm line 94.
2016.01.10 17:37:50 1: PERL WARNING: Use of uninitialized value $D in concatenation (.) or string at ./FHEM/57_CALVIEW.pm line 94.
2016.01.10 17:37:50 1: PERL WARNING: Use of uninitialized value $Y in concatenation (.) or string at ./FHEM/57_CALVIEW.pm line 94.
2016.01.10 17:37:50 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/57_CALVIEW.pm line 94.
2016.01.10 17:37:50 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at ./FHEM/57_CALVIEW.pm line 113.
2016.01.10 17:37:50 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/57_CALVIEW.pm line 130.
2016.01.10 17:37:50 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/57_CALVIEW.pm line 140.
2016.01.10 17:37:50 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/57_CALVIEW.pm line 151.


Folgendermaßen nutze ich auf das Modul (inkl. Calview):
define myCal Calendar ical url https://p06-calendarws.icloud.com/ca/subscribe/1/***
define myGeb Calendar ical file /home/pi/Geburtstage.ics
define myCalView CALVIEW myCal 1
attr myCalView maxreadings 15
attr myCalView modes modeAlarm,modeStart,modeStarted,modeUpcoming
define myGebView CALVIEW myGeb 1
attr myGebView maxreadings 5
attr myGebView modes modeAlarm,modeStart,modeStarted,modeUpcoming


Muss ich etwas ändern, liegt es an CALVIEW oder am Calender-Modul?

Gruß
Torben

Dr. Boris Neubert

Danke, Torben, für die Rückmeldung.

Bitte prüfe zunächst über die Kommandozeile oder den Kommandoschlitz in FHEMWEB, ob Du die Ereignisse in Deinem Kalender siehst, die Du auch erwartest:


get myCal text next
get myCal full all
get myGeb text next
get myGeb full all


Damit stellen wir sicher, dass das Modul für Dich funktioniert.

Die Interaktion mit CALVIEW muss noch angepasst werden. Habe dieses Wochenende dessen Entwickler Chris leider nicht erreicht.

CALVIEW-Anwender also bitte noch warten, bis sich an dieser Front etwas Neues ergibt!

Viele Grüße
Boris


Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Torben

Hallo Boris,

ich habe es gerade ohne CALVIEW ausprobiert. Grundsätzlich läuft es, allerdings ist mein RPI 2 beim Start und auch bei einem set myCal update für etwa 1 Minute außer Gefecht, also 100% Last auf einem Prozessorkern, sodass das Frontend wieder nicht erreichbar ist.
Es kommen dann aber vernünftige Termine dabei raus.

Gruß
Torben

Dr. Boris Neubert

Sollen wir der Auslastung nachgehen?

Sind in Deinem Kalender Serientermine? Wenn ja, viele, oder häufige (täglich oder noch häufiger), oder solche, die weit in der Vergangenheit beginnen?
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Torben

Ich kann gerne noch weitere Infos liefern, wenn es zur Verbesserung beiträgt.
Zu den Serienterminen: Ja, es sind einige drin. Drei, die gerade noch laufen, davon zwei, die aus 2013 stammen, der andere erst 3 Monate alt. Zwei sind wöchentlich, der andere alte alle 8 Wochen. Dann gibt es noch einige alte, wöchentliche Serientermine, die schon abgeschlossen sind. Es sollten aber weniger als 20 sein. Insgesamt ist der Kalender nicht ganz klein und beginnt Anfang 2012.

Dr. Boris Neubert

Hallo Torben,

die beigefügte Version des Moduls rotzt Dir für jeden Termin eine Debug-Zeile folgender Art ins Log:

2016.01.10 18:40:36 1: DEBUG>createSingleEvent Start 2017-02-06 00:00:00

Mich würde interessieren, ob bei der Erzeugung der Termin die Zeit verbraten wird. Das wäre erkennbar am voranstehenden Zeitstempel beim ersten und beim letzten solchen Eintrag.

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Torben

Beim Starten kommt folgendes im Log.
2016.01.10 18:48:38 1: DEBUG>createSingleEvent Start 1960-08-11 00:00:00
2016.01.10 18:48:38 1: DEBUG>createSingleEvent Start 1961-08-11 00:00:00
2016.01.10 18:48:38 1: DEBUG>createSingleEvent Start 1962-08-11 00:00:00
2016.01.10 18:48:38 1: DEBUG>createSingleEvent Start 1963-08-11 00:00:00
2016.01.10 18:48:38 1: DEBUG>createSingleEvent Start 1964-08-11 00:00:00
2016.01.10 18:48:38 1: DEBUG>createSingleEvent Start 1965-08-11 00:00:00
... gleich kommt ein fast einminütiger Sprung
2016.01.10 18:48:40 1: DEBUG>createSingleEvent Start 2014-05-06 00:00:00
2016.01.10 18:48:40 1: DEBUG>createSingleEvent Start 2015-05-06 00:00:00
2016.01.10 18:48:40 1: DEBUG>createSingleEvent Start 2016-05-06 00:00:00
2016.01.10 18:48:40 1: DEBUG>createSingleEvent Start 2017-05-06 00:00:00
2016.01.10 18:49:09 0: SONOS0: Can't bind Port 4711: Bind failed: Die Adresse wird bereits verwendet at ./FHEM/00_SONOS.pm line 8242.

2016.01.10 18:49:09 0: SONOS0: Retries left (wait 30s): 8
2016.01.10 18:49:34 1: DEBUG>createSingleEvent Start 2016-11-18 08:00:00
2016.01.10 18:49:34 1: DEBUG>createSingleEvent Start 2012-07-16 00:00:00
2016.01.10 18:49:34 1: DEBUG>createSingleEvent Start 2012-09-16 00:00:00
...
2016.01.10 18:49:36 1: DEBUG>createSingleEvent Start 2015-01-24 18:00:00
2016.01.10 18:49:36 1: DEBUG>createSingleEvent Start 2015-12-02 20:00:00
2016.01.10 18:49:36 1: DEBUG>createSingleEvent Start 2015-03-26 19:30:00
2016.01.10 18:49:36 1: DEBUG>createSingleEvent Start 2013-06-04 00:00:00
2016.01.10 18:49:36 1: 192.168.178.39:1000 disconnected, waiting to reappear (HMLAN1)
2016.01.10 18:49:36 1: HMLAN_Parse: HMLAN1 new condition disconnected
2016.01.10 18:49:36 1: 192.168.178.39:1000 reappeared (HMLAN1)
2016.01.10 18:49:36 1: HMLAN_Parse: HMLAN1 new condition init

Das update dauert dann zwar eine Minute, was sich aber nicht im Log wieder spiegelt:
2016.01.10 19:01:17 1: PERL WARNING: Subroutine HandleTimeout redefined at ./FHEM/98_apptime.pm line 24.
2016.01.10 19:01:17 1: PERL WARNING: Subroutine CallFn redefined at ./FHEM/98_apptime.pm line 58.
2016.01.10 19:02:39 1: DEBUG>createSingleEvent Start 2012-04-06 19:00:00
2016.01.10 19:02:39 1: DEBUG>createSingleEvent Start 2013-11-22 20:00:00
2016.01.10 19:02:39 1: DEBUG>createSingleEvent Start 2013-12-06 00:00:00
2016.01.10 19:02:39 1: DEBUG>createSingleEvent Start 2013-12-06 00:00:00
2016.01.10 19:02:39 1: DEBUG>createSingleEvent Start 2013-10-29 00:00:00
2016.01.10 19:02:39 1: DEBUG>createSingleEvent Start 2012-08-11 00:00:00
...
2016.01.10 19:02:40 1: DEBUG>createSingleEvent Start 2013-12-04 17:00:00
2016.01.10 19:02:40 1: DEBUG>createSingleEvent Start 2013-03-29 08:05:00
2016.01.10 19:02:40 1: DEBUG>createSingleEvent Start 2014-07-21 00:00:00
2016.01.10 19:02:40 1: DEBUG>createSingleEvent Start 2014-04-22 18:00:00
2016.01.10 19:02:40 1: 192.168.178.39:1000 disconnected, waiting to reappear (HMLAN1)
2016.01.10 19:02:40 1: HMLAN_Parse: HMLAN1 new condition disconnected
2016.01.10 19:02:40 1: 192.168.178.39:1000 reappeared (HMLAN1)
2016.01.10 19:02:40 1: HMLAN_Parse: HMLAN1 new condition init
2016.01.10 19:02:43 1: HMLAN_Parse: HMLAN1 new condition ok

Auch apptime (gerade erst vor dem update gestartet) gibt irgendwie keinen Hinweis, oder?
name             function    max  count    total  average maxDly
                               Sonos           SONOS_Read   3702      1     3702  3702.00      0 HASH(Sonos)
                                 WEB               FW_Set     73      3       73    24.33      0 HASH(WEB); WEB; rereadicons
            WEB_192.168.178.42_52544            FW_Notify     49     35      194     5.54      0 HASH(WEB_192.168.178.42_52544); HASH(Sonos_Wohnzimmer)
                    Sonos_Wohnzimmer      SONOSPLAYER_Set     46      3      107    35.67      0 HASH(Sonos_Wohnzimmer); Sonos_Wohnzimmer; ?
                tmr-FReplacer_Update      HASH(0x1e3d930)     39      1       39    39.00  63165 HASH(kindledisplay)
                        Sonos_BRIDGE      SONOSPLAYER_Set     31      1       31    31.00      0 HASH(Sonos_BRIDGE); Sonos_BRIDGE; ?
                         Sonos_Kuche      SONOSPLAYER_Set     31      1       31    31.00      0 HASH(Sonos_Kuche); Sonos_Kuche; ?
                           Sonos_Bad      SONOSPLAYER_Set     30      1       30    30.00      0 HASH(Sonos_Bad); Sonos_Bad; ?
                              HMLAN1          HMLAN_Ready     27      2       27    13.50      0 HASH(HMLAN1)
                               myCal         Calendar_Set     20     16       20     1.25      0 HASH(myCal); myCal; update
          tmr-ROOMMATE_DurationTimer       HASH(0xdb5cf0)     16      1       16    16.00  38423 HASH(rr_Torben_DurationTimer)
                              HMLAN1           HMLAN_Read     15     12      105     8.75      0 HASH(HMLAN1)
          tmr-ROOMMATE_DurationTimer      HASH(0x36fdfb8)     14      1       14    14.00  38430 HASH(rr_Alex_DurationTimer)
          tmr-ROOMMATE_DurationTimer      HASH(0x35adb48)     13      1       13    13.00      1 HASH(rr_Torben_DurationTimer)
          tmr-ROOMMATE_DurationTimer      HASH(0x30dd310)     11      1       11    11.00      0 HASH(rr_Alex_DurationTimer)
          tmr-ROOMMATE_DurationTimer      HASH(0x31305c0)     11      1       11    11.00      0 HASH(rr_Alex_DurationTimer)
          tmr-ROOMMATE_DurationTimer      HASH(0x37012f8)     11      1       11    11.00      1 HASH(rr_Torben_DurationTimer)
            WEB_192.168.178.38_56062              FW_Read     10      1       10    10.00      0 HASH(WEB_192.168.178.38_56062)
                          LaptopBatt            dummy_Set      9      3        9     3.00      0 HASH(LaptopBatt); LaptopBatt; 54
             tmr-VVS_GetHttpResponse      HASH(0x1e44078)      8      3       22     7.33  33264 HASH(vvs)
                      SonosAenderung          notify_Exec      7     35       25     0.71      0 HASH(SonosAenderung); HASH(vvs)

Gruß
Torben

Dr. Boris Neubert

OK, Danke. Die Generierung der Termine scheint nicht das Problem zu sein.

Drehst Du bitte mal den Loglevel auf 5 (attr global verbose 5) und zeigst dann bitte die Meldungen im Log aus dem Kalender nach einem update?

(DEBUG-Meldungen kannst Du gerne wieder kürzen).

Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Torben

Voilá:
2016.01.10 19:42:48 1: HMLAN_Parse: HMLAN1 new condition ok
2016.01.10 19:43:12 4: Calendar myCal: Updating...
2016.01.10 19:43:12 4: Calendar myCal: Getting data from URL <hidden>
2016.01.10 19:43:15 4: Calendar myCal: parsing data
2016.01.10 19:43:24 4: Calendar myCal: merging data
2016.01.10 19:44:18 4: Calendar myCal: 574 records processed, 0 new, 574 known, 0 modified, 0 changed.
2016.01.10 19:44:18 4: Calendar myCal: creating calendar events
2016.01.10 19:44:19 4: Calendar myCal: Checking times...
2016.01.10 19:44:19 1: localhost:4711 reappeared (Sonos)
2016.01.10 19:44:19 1: 192.168.178.39:1000 disconnected, waiting to reappear (HMLAN1)
2016.01.10 19:44:19 1: HMLAN_Parse: HMLAN1 new condition disconnected
2016.01.10 19:44:19 1: 192.168.178.39:1000 reappeared (HMLAN1)
2016.01.10 19:44:19 1: HMLAN_Parse: HMLAN1 new condition init
2016.01.10 19:44:21 1: HMLAN_Parse: HMLAN1 new condition ok


Der deutlich kleinere Geburtstagskalender läuft schnell:
2016.01.10 19:46:03 4: Calendar myGeb: Updating...
2016.01.10 19:46:03 4: Calendar myGeb: Getting data from file /home/pi/Geburtstage.ics
2016.01.10 19:46:03 4: Calendar myGeb: parsing data
2016.01.10 19:46:03 4: Calendar myGeb: merging data
2016.01.10 19:46:03 4: Calendar myGeb: 38 records processed, 0 new, 38 known, 0 modified, 0 changed.
2016.01.10 19:46:03 4: Calendar myGeb: creating calendar events
2016.01.10 19:46:03 4: Calendar myGeb: Checking times...

Dr. Boris Neubert

Danke Torben. Die Zeit wird verwendet, um die neu abgeholten Termine und die bereits bekannten Termine zu verschmelzen.

Das schaue ich mir am kommenden Wochenende an.

Danach melde ich mich wieder hier.

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Torben


betateilchen

ist das bedenklich?

2016-01-12_18:29:15 oc_Heizung error (<hidden>: Can't connect(2) to https://...:443:  SSL wants a read first)

Tritt nicht regelmäßig auf, meist nach einem fhem restart. Macht man dann nochmal ein "shutdown restart", funktioniert es normalerweise.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Seit drei Tagen habe ich das neue Calendar-Modul auf einem meiner Produktivsysteme im Einsatz. Nachdem ich die zugehörigen notify angepasst habe, sind bisher keine negativen Effekte/Auffälligkeiten aufgetreten.

Das vorher beschriebene SSL Problem ist insgesamt weniger als zehn Mal (und das verteilt auf drei Systeme) aufgetreten. Warum auch immer.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Benni

Ich habe das Modul auch seit dem letzten Wochenende auf meinem Produktivsystem laufen.
Bei mir läuft darüber im Moment der Müllkalender und der Feiertags-kalender.
Werde am WE wahrscheinlich noch weitere Kalender aufnehmen.
Bisher läuft alles fehlerfrei.