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
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 ??
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.
Ich konnte jetzt zumindest das Problem eingrenzen.
Es funktioniert richtig, wenn ich ein set <name> reload
des 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)?
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.
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?
Das Erste kannst Du schon beeinflussen, indem Du einfach set update nicht mehr verwendest.
Den Rest kann Boris beeinflussen.
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.
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.
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.)
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?
Ja, und erledigt.
Hier: https://forum.fhem.de/index.php?topic=86148.msg785933#msg785933 (https://forum.fhem.de/index.php?topic=86148.msg785933#msg785933)
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?
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.