Problem mit Calendar und Abfall

Begonnen von AmunRe, 10 Februar 2018, 14:17:53

Vorheriges Thema - Nächstes Thema

AmunRe

Hallo Zusammen,


ich hab da mal wieder ein Problem.
Mein Abfall Modul funktioniert nicht mehr so wie es soll.
Manchmal zeigt er überhaupt keine Tage an. manchmal 123 oder mehr. Das stimmt aber nicht, weil er schon vorher dran ist, ist auch in der ICS so hinterlegt. Jemand eine Idee?

Das war letztes Jahr nicht so. (Da hatte ich aber das Calendarmodul nicht über FILE sondern noch über URL laufen(Einzige Änderung). Was ich bisher sehen konnte ist das er auch im Log  Jetzt jede Menge davon hat:

Zitat2018.02.10 03:10:15 2: Calendar Muell: Duplicate VEVENT
2018.02.10 03:10:15 2: Calendar Muell: Duplicate VEVENT
2018.02.10 03:10:15 2: Calendar Muell: Duplicate VEVENT
2018.02.10 03:10:15 2: Calendar Muell: Duplicate VEVENT
2018.02.10 03:10:15 2: Calendar Muell: Duplicate VEVENT
2018.02.10 03:10:15 2: Calendar Muell: Duplicate VEVENT
2018.02.10 03:10:15 2: Calendar Muell: Duplicate VEVENT
2018.02.10 03:10:15 2: Calendar Muell: Duplicate VEVENT

Der kalendar um den es geht ist dieser:
https://www.kriftel.de/:download/pdf-pool-formulare-etc/abfall-abfallkalender/icalendar-abfallkalender-2018-1-3.ics?cid=m5

Ich lade ihn einmal im jahr runter. mit folgendem DOIF:
Internals:
   CFGFN     
   DEF        (($month == 12 and $mday == 31) and [00:00]) ({system ("./FHEM/calendar_renew.sh")})
   NAME       di_Kalenderaktualisieren_muell
   NR         289
   NTFY_ORDER 50-di_Kalenderaktualisieren_muell
   STATE      cmd_1
   TYPE       DOIF
   READINGS:
     2018-01-01 03:01:13   cmd             1
     2018-01-01 03:01:13   cmd_event       set_cmd_1
     2018-01-01 03:01:13   cmd_nr          1
     2018-01-01 03:01:13   error           {system ("./FHEM/calendar_renew.sh")}: -1
     2018-01-01 03:01:13   state           cmd_1
     2018-02-10 00:42:35   timer_01_c01    11.02.2018 00:00:00
   Regex:
   condition:
     0          ($month == 12 and $mday == 31) and DOIF_time_once($hash,0,$wday)
   days:
   devices:
   do:
     0:
       0          {system ("./FHEM/calendar_renew.sh")}
     1:
   helper:
     DOIF_Readings_events
     DOIF_eventas
     globalinit 1
     last_timer 1
     sleeptimer -1
   itimer:
   localtime:
     0          1518303600
   realtime:
     0          00:00:00
   time:
     0          00:00:00
   timeCond:
     0          0
   timer:
     0          0
   timers:
     0           0
   triggertime:
     1518303600:
       localtime  1518303600
       hash:
   uiState:
   uiTable:
Attributes:
   DbLogExclude .*
   do         always
   event-on-change-reading .*
   room       Abfall,Befehle

das Calendar_renew sieht so aus:
#!/bin/sh

jahr=$(date "+%Y")
jahr=$(($jahr+1))
URL="https://www.kriftel.de/:download/pdf-pool-formulare-etc/abfall-abfallkalender/icalendar-abfallkalender_"$jahr"_1_3.ics?cid=m5"

wget -P /opt/fhem/ $URL -O muell.ics


Das Calendar Modul sieht so aus:
Internals:
   CFGFN     
   DEF        ical file muell.ics 3600
   NAME       Muell
   NOTIFYDEV  global
   NR         275
   NTFY_ORDER 50-Muell
   STATE      triggered
   TYPE       Calendar
   READINGS:
     2018-02-10 14:10:05   calname         Abfallkalender 2018 1+3
     2018-02-10 14:10:05   lastUpdate      2018-02-10 14:10:04
     2017-12-16 21:37:21   modeAlarm       
     2018-02-07 23:42:44   modeAlarmOrStart
     2017-12-16 21:37:21   modeAlarmed     
     2018-02-03 12:12:34   modeChanged     
     2018-02-10 02:10:15   modeEnd         
     2017-12-30 00:36:01   modeEnded       
     2018-02-07 23:42:44   modeStart       
     2018-02-03 12:12:34   modeStarted     
     2018-02-10 02:10:15   modeUpcoming    AAAAAK3yXEAODfFNo6hS266Kt4HAI4WOohfS89Hj97jwWY1K7EAEbTznQYAAI4WOohfS89
     2018-02-10 14:10:05   nextUpdate      2018-02-10 15:10:04
     2018-02-10 14:10:05   nextWakeup      2018-02-10 15:10:04
     2018-02-10 14:10:05   state           triggered
Attributes:
   DbLogExclude .*
   event-on-change-reading .*
   room       Abfall,Kontrollraum


Internals:
   CFGFN     
   DEF        Muell
   KALENDER   Muell
   NAME       myAbfall
   NR         288
   NTFY_ORDER 50-myAbfall
   STATE      123
   TYPE       ABFALL
   READINGS:
     2018-02-10 14:10:05   Muell_GelberSack_datum 13.06.18
     2018-02-10 14:10:05   Muell_GelberSack_tage 123
     2018-02-10 14:10:05   Muell_GelberSack_text   Gelber Sack
     2018-02-10 14:10:05   Muell_GelberSack_wochentag Mittwoch
     2018-02-10 14:10:05   next            Muell_GelberSack_123
     2018-02-10 14:10:05   next_datum      13.06.18
     2018-02-10 14:10:05   next_tage       123
     2018-02-10 14:10:05   next_text         Gelber Sack
     2018-02-10 14:10:05   next_wochentag  Mittwoch
     2018-02-10 14:10:05   state           123
Attributes:
   DbLogExclude .*
   event-on-change-reading .*
   room       Abfall
4 x Echo Dot, HMLAN Gateway, und diverse HM Komponenten, Philips Hue + OSRAM Plugs

Franz Tenbrock

hab nicht genau mitbekommen seit wann aber auch bei mir Probleme mit dem Modul
hab dann
Abfall und Calendar vom 07.08.17 genommen
neu gestartet
alles ok
wo was geändert wurde ??
cubi3, Cul 868, ESA2000WZ, EM1000GZ,  FS20, dashboard, 1-Wire, Max Thermos, Max Wandthermo, Max Lan, Fritzbox callmonitor, , nanocul, HM Led16, HM Bewegungsmelder, HM Schalter, RPi, banana, ESP8266, DoorPi

AmunRe

Zitat von: Franz Tenbrock am 14 Februar 2018, 14:53:16
hab nicht genau mitbekommen seit wann aber auch bei mir Probleme mit dem Modul
hab dann
Abfall und Calendar vom 07.08.17 genommen
neu gestartet
alles ok
wo was geändert wurde ??


kann ja nicht die Lösung sein einen alten Stand zu nehmen.
4 x Echo Dot, HMLAN Gateway, und diverse HM Komponenten, Philips Hue + OSRAM Plugs

AmunRe

Ich konnte jetzt zumindest das Problem eingrenzen.


Es funktioniert richtig, wenn ich ein set <name> reloaddes Calendar Moduls mache. mache ich aber ein set <name> update läuft es schief.




Ist es eigentlich Absicht, wenn ich attr <name> update auf none setze das er auch nicht mehr manuell updatet? Dachte das Attribute sei dafür da die Automatischen Updates abzuschalten (oder eben auf async/sync)?
4 x Echo Dot, HMLAN Gateway, und diverse HM Komponenten, Philips Hue + OSRAM Plugs

betateilchen

#4
Zitat von: AmunRe am 10 Februar 2018, 14:17:53
Ich lade ihn einmal im jahr runter. mit folgendem DOIF:

Sowas macht man nicht per DOIF sondern auf Betriebssystemebene mit einem cronjob, der genau einmal im Jahr läuft.

Zitat von: AmunRe am 05 März 2018, 21:28:30
mache ich aber ein set <name> update


Ein set ... update macht keinen Sinn, wenn man nicht mit einer URL, sondern mit einer Datei arbeitet. Eine Lösung wäre, bei diesem Versuch eine Fehlermeldung zurückzuliefern.

Noch eleganter wäre eine Lösung, die einfach dafür sorgt, dass das device bei "set reload" und "set update" intern genau das gleiche tut. Dann wäre die Kompatibilität zu bestehenden Anwendungen gewahrt. Denn eine tatsächliche Notwendigkeit für die Unterscheidung zwischen update und reload gibt es in meinen Augen schon lange nicht mehr.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

AmunRe

Zitat von: betateilchen am 05 März 2018, 21:44:39
Sowas macht man nicht per DOIF sondern auf Betriebssystemebene mit einem cronjob, der genau einmal im Jahr läuft.

Geb ich dir recht, ist sehr wahrscheinlich auch Ressourcen sparender. Stelle ich um. Danke!
Für die, die nicht wissen wie:
30 12 31 12 * /opt/fhem/FHEM/calendar_renew.sh
wird jetzt am 31.12. um 12:30 ausgeführt.

Zitat von: betateilchen am 05 März 2018, 21:44:39Ein set ... update macht keinen Sinn, wenn man nicht mit einer URL, sondern mit einer Datei arbeitet. Eine Lösung wäre, bei diesem Versuch eine Fehlermeldung zurückzuliefern.

Noch eleganter wäre eine Lösung, die einfach dafür sorgt, dass das device bei "set reload" und "set update" intern genau das gleiche tut. Dann wäre die Kompatibilität zu bestehenden Anwendungen gewahrt. Denn eine tatsächliche Notwendigkeit für die Unterscheidung zwischen update und reload gibt es in meinen Augen schon lange nicht mehr.
Beides kann ich wohl kaum beeinflussen, richtig?
4 x Echo Dot, HMLAN Gateway, und diverse HM Komponenten, Philips Hue + OSRAM Plugs

betateilchen

Das Erste kannst Du schon beeinflussen, indem Du einfach set update nicht mehr verwendest.

Den Rest kann Boris beeinflussen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

AmunRe

Zitat von: betateilchen am 05 März 2018, 22:23:26
Das Erste kannst Du schon beeinflussen, indem Du einfach set update nicht mehr verwendest.

Den Rest kann Boris beeinflussen.


Dann bleibt mir aber nichts übrig, als den update intervall auf eine hohe zahl zu setzen(der führt ja auch ein set update aus). Dafür war ja eigentlich mal das attr update, damit ich das eben nicht mehr hochsetzen musste. Daher auch die frage, warum ich bei dem gesetzten attr auf none nicht mal mehr manuell updaten/reloaden kann.


4 x Echo Dot, HMLAN Gateway, und diverse HM Komponenten, Philips Hue + OSRAM Plugs

betateilchen

Naja, der grundlegende Unterschied zwischen "reload" und "update" ist, dass bei einem reload alle vorhandenen events verworden werden und der Kalender komplett neu geparst wird. Bei einem update erfolgt dieses Löschen nicht, daher kommen Deine Meldungen wegen "duplicate events".

Für mich ist "reload" immer die bessere Lösung, da sie klare Verhältnisse schafft.

Dass ein update-Attribut auf 0 gesetzt auch das manuelle Update verhindert, ist vermutlich so gewollt.
Da gibt es im Code keine Unterscheidung, ob die Aktualisierung von einem internen Timer angestoßen wird oder manuell per set Befehl.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Dr. Boris Neubert

Zitat von: betateilchen am 06 März 2018, 09:37:54
Dass ein update-Attribut auf 0 gesetzt auch das manuelle Update verhindert, ist vermutlich so gewollt.
Da gibt es im Code keine Unterscheidung, ob die Aktualisierung von einem internen Timer angestoßen wird oder manuell per set Befehl.

Aus meiner Sicht nicht gewollt - wenn der Benutzer ein Update will, soll er es bekommen. Muss ich mir ansehen.

(Verspätete Meldung, da ich keine Meldungen mehr aus diesem Board erhalten habe.)

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

AmunRe

Zitat von: Dr. Boris Neubert am 23 März 2018, 10:04:56
Aus meiner Sicht nicht gewollt - wenn der Benutzer ein Update will, soll er es bekommen. Muss ich mir ansehen.

(Verspätete Meldung, da ich keine Meldungen mehr aus diesem Board erhalten habe.)


Und schon was entdeckt?
4 x Echo Dot, HMLAN Gateway, und diverse HM Komponenten, Philips Hue + OSRAM Plugs

Dr. Boris Neubert

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

misux

Hi! Sorry das ich den alten Therad wieder hoch hole, aber mein Kumpel hat jetzt auch die besagten Probleme mit den massenweise Logeinträgen "Duplicate VEVENT" Das Modul ist deutlich Jünger als die Fehlerbehebung im Jahr 2018....

Muss man etwas noch einstellen oder gibt es wieder ein kleines Problemchen damit?

Dr. Boris Neubert

Zitat von: misux am 14 Oktober 2021, 12:04:50
Hi! Sorry das ich den alten Therad wieder hoch hole, aber mein Kumpel hat jetzt auch die besagten Probleme mit den massenweise Logeinträgen "Duplicate VEVENT" Das Modul ist deutlich Jünger als die Fehlerbehebung im Jahr 2018....

Muss man etwas noch einstellen oder gibt es wieder ein kleines Problemchen damit?

Bitte ein neues Thema eröffnen und die üblichen Mindestinformationen mitteilen, damit sich jemand sinnvoll mit der Meldung auseinander setzen kann.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!