Probleme nach Update von Calendar-Modul?

Begonnen von juelich, 09 März 2019, 17:02:58

Vorheriges Thema - Nächstes Thema

Otto123

Hallo Markus,
Zitat von: Otto123 am 07 April 2019, 22:31:11
Mir fällt allerdings ein: Beim Event am Terminende könnte die Abfrage mit from=0 vielleicht wirklich ein Problem sein. Immerhin ist der Termin in dem Moment zu Ende.
ZitatDas Notify geändert auf from=-10s. Und jetzt kommt das Log
Ja genau das meinte ich. Und genau das erklärt aus meiner Sicht warum es eine Weile funktioniert hat obwohl es einen Fehler enthielt. Der Fehler war from=0 -> damit ist es unter Garantie so, das bei schnellem System, wenig Last, Datum am Anfang oder am Ende des Monats, Sonnenschein - oder was auch immer - es klappt noch den aktuellen Termin zu lesen oder schon den neuen.

Sorry, ich hatte das mit dem Termin Ende nicht bedacht. Ich hatte das bisher noch nicht gemacht, mit Serienterminen am Ende triggern.

Zu deinem letzten Satz muss ich sagen: Leider hast Du dein Logging ja nur mit Teildaten gemacht. Mach das doch noch mal mit format:full damit man sieht welcher Termin wirklich gelesen wird.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

juelich

Hallo Otto,

Serientermin ab letzter Woche lautet jetzt: "Serie generell". Heute geändert auf "Termin heute", nächste Woche auf "nächste Woche".

Jetzt kommt folgendes Log:

2019.04.09 12:07:02 1: UID 5fliefc4rjr31l8nutj2p3ass3googlecom
2019.04.09 12:07:02 1: Kalender 5fliefc4rjr31l8nutj2p3ass3googlecom       end  09.04.2019 12:06-09.04.2019 12:07 Termin heute 
2019.04.09 12:07:02 1: Kalender aktuell 5fliefc4rjr31l8nutj2p3ass3googlecom       end  09.04.2019 12:06-09.04.2019 12:07 Termin heute


bei folgendem Test:

Internals:
   CFGFN     
   DEF        Kinder:end:.* {
my $uid= "$EVTPART1";
Log 1, "UID $uid";
my $termin= fhem('get Kinder events format:full limit:count=1');
my $termin1= fhem('get Kinder events format:full limit:count=1,from=-10s');
Log 1, "Kalender $termin";
Log 1, "Kalender aktuell $termin1";
}


Wie Du siehst (zumindest würde ich das so interpretieren) wird tatsächlich auch ohne "from" der aktuelle Termin und nicht der Serienstart gelesen.

Viele Grüße und noch mal vielen Dank für Deine fast chatähnliche Hilfe  ;)

Markus

Otto123

Hat denn der Termin wirklich einen älteren in der Serie?

Wenn ich bei mir Serientermine abfrage kommt mit limit:count=1 der erste und älteste.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

juelich

Ja, ich habe eine Terminserie mit Startdatum 02.04. angelegt, ohne Enddatum ,mit den von mir genannten Betreffs.
Merkwürdig.

Daran, dass der erste Termin ja nie aktiv wurde, weil er in der Vergangenheit liegt, dürfte es ja eigentlich nicht liegen, oder?

Ich will jetzt nicht meine vorhandene reale Temperaturserie durcheinander werfen - da liegen ja etliche bereits abgelaufene Termine drin.

Können eigentlich 2 Notifys auf dasselbe Ereignis triggern?
Dann würde ich heute Abend beide Notifys aktiv lassen, damit die Heizung ausgeschaltet wird und die o.g. Mitschnitte erfolgen.

Viele Grüße

Markus

juelich

Könnte das eventuell auch an dem "hideOlderThan" liegen?

Damit werden ja Events nach 1 Stunde ausgeblendet. Vielleicht sind sie dadurch auch nicht für "get Kinder events" sichtbar?


Internals:
   DEF        ical url https://xxx/basic.ics 14400
   FUUID      5c47609c-f33f-82e1-0016-b987038e2e9fbd8f
   NAME       Kinder
   NOTIFYDEV  global
   NR         63
   NTFY_ORDER 50-Kinder
   STATE      triggered
   TYPE       Calendar
   READINGS:
     2019-04-09 12:05:38   calname         Kinder
     2019-04-09 12:05:38   lastUpdate      2019-04-09 12:05:33
     2017-04-07 16:13:51   modeAlarm       
     2019-04-09 12:07:00   modeAlarmOrStart
     2017-04-07 16:13:51   modeAlarmed     
     2019-04-09 12:06:00   modeChanged     5fliefc4rjr31l8nutj2p3ass3googlecom
     2019-04-09 12:07:00   modeEnd         
     2019-04-09 12:05:38   nextUpdate      2019-04-09 16:05:33
     2019-04-09 12:07:02   nextWakeup      2019-04-09 12:30:00
     2019-04-09 12:07:00   state           triggered
Attributes:
   hideOlderThan 01:00
   removevcalendar 1
   room       Kalender


Viele Grüße

Markus

Otto123

Zitat von: juelich am 09 April 2019, 12:32:26
Könnte das eventuell auch an dem "hideOlderThan" liegen?
So ist es. Das ist die so etwas wie die "Alternative" zur Einschränkung mit from
;D
Die Frage nach den Attributen wollte ich Dir vorgestern auch schon stellen.  ;)

Ich bin unsicher welche Methode man wählen sollte. Ich habe bisher die hideOlderThan nicht verwendet.

Ich denke wenn die Abfrage präzise ist, ist das besser. Da sieht man es an einem Ort. Und besser eine Grenze mehr als eine zu wenig.

Halten wir fest: from=0 ist bei der Abfrage nach dem Trigger auf das Ende eines Termines falsch! Dort muss es ein Wert in der Vergangenheit sein.

Aber jetzt haben wir es geklärt.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

juelich

Super - gemeinsam sind wir stark  ;D

Ich verwende das "hideOlderThan", weil ich mir über CALVIEW einen Überblick über die Heizungszeitschaltzeiten für die einzelnen Räume gebastelt habe.
Da hatte ich ohne dieses Attribut natürlich die vergangenen Termine in der Ansicht und blende sie so aus.
Also könnte ich mi wahrscheinlich wirkich das "from" sparen, da es - hoffentlich - unschädlich ist werde ich es aber drin lassen.
Wer weiß, was sich alles nochmal in Zukunft ändert, da kann ich wenigstens darauf verweisen, dass ich alles so gemacht habe, wie der Profi mir empfohlen hat.  ;)

Also nochmal vielen Dank und viele Grüße

Markus