Probleme nach Update von Calendar-Modul?

[juelich]

Ich verwende seit vielen Jahren das CALENDAR-Modul zur Heizungssteuerung. Und bis vor kurzem auch völlig zufriedenstellend.
Ich habe zwei verschiedene Steuerungen - eine für die Kinderzimmer und eine fürs Wohnzimmer.
Dazu gibt es zwei Google-Kalender. Im Termin-Betreff stehen jeweils zwei durch Leerzeichen getrennte Temperaturen. Die erste wird zu Terminbeginn eingestellt, die zweite am Terminende.
Wie geschrieben, das funktioniert seit Jahren und im Kinderzimmer nach wie vor. Merkwürdigerweise aber seit ein paar Tagen (ich würde sagen, seit dem letzten Update, bin mir aber da nicht sicher) funktioniert das Ganze nicht mehr im Wohnzimmer.
Ich habe alle Kalender per CALVIEW eingebunden. Die Termine sind alle korrekt von Google gelesen worden, daran liegt es also nicht. Da jede Temperaturänderung geloggt wird, sehe ich, dass das Wohnzimmernotify gar nicht schaltet, es liegt also auch nicht an einer fehlerhaften Übertragung. Es muss irgendwie an dem Notify liegen, dass scheinbar nicht mehr bei jedem Termin triggert.
Wiederum komisch ist, dass ein Tersttermin vorgestern getriggert wurde - und der schon lange hinterlegte Schalttermin für gestern auch. Heute früh blieb die Heizung wieder kalt. Ich habe langsam keine Idee mehr, deshalb dieser Hilfe-Ruf.

Das Log wirft folgende aus:

Code Auswählen Erweitern

2019.03.08 07:30:02 1: Temperatur Wohnzimmer 21
2019.03.08 08:00:00 1: Temperatur Flur ist 21 Grad
2019.03.08 12:00:01 1: Temperatur Kinderzimmer 21
2019.03.08 17:00:00 3: Abendbrot: Temperatur Wintergarten ist 22 Grad
2019.03.08 19:30:01 1: Temperatur Kinderzimmer 18
2019.03.08 22:00:02 1: Temperatur Wohnzimmer 18
2019.03.09 02:10:06 1: 192.168.178.30:1000 disconnected, waiting to reappear (HMLAN)
2019.03.09 02:10:06 1: HMLAN_Parse: HMLAN new condition disconnected
2019.03.09 02:11:06 1: HMLAN_Parse: HMLAN new condition init
2019.03.09 02:11:06 1: 192.168.178.30:1000 reappeared (HMLAN)
2019.03.09 02:11:07 1: HMLAN_Parse: HMLAN new condition ok
2019.03.09 07:30:04 1: Temperatur Kinderzimmer 21

Die Reconnects habe ich in letzter Zeit auch ständig, ohne dass ich weiß woher. ABer das sollte nichts mit meinen Notifys zu tun haben.

Das Wohnzimmer-Notify ist wie folgt:

Code Auswählen Erweitern

ohnzimmer:modeStarted:.*googlecom.* {
my $reading="$EVTPART0";
my $uid= "$EVTPART1";
my $dtemp;
my $termin= fhem("get Wohnzimmer summary $uid");
if (defined($termin)) {
my ($dtemp,undef)= split(/ /,fhem("get Wohnzimmer summary $uid"));
fhem("set hz.wohnzimmer desired-temp $dtemp");
Log 1, "Temperatur Wohnzimmer $dtemp";}
;;}

Wie geschrieben - für das Kinderzimmer sieht das Notify absolut identisch aus - und da funktioniert es.

Ich hoffe, Ihr habt eine Idee

Viele Grüße un vielen Dank


Markus

[betateilchen]

Die Syntax des Kalenermoduls hat sich zwischenzeitlich komplett geändert, insbesondere, wenn es um das Lesen von Informationen aus dem Ereignis selbst handelt. Die Änderung ist allerdings schon länger (gefühlt ein Jahr) her, Du hast vermutlich sehr lange kein Update gemacht.

Schau einfach mal in die commandref, da sind sowohl die Beschreibung aktualisiert als auch die neuen Beispiele festgehelten.

[juelich]

Ich mache regelmäßig Updates, daran kann es also nicht liegen.
Die Syntax wurde zwar geändert, aber nicht so, dass die meine Syntax nicht mehr funktionieren würde. In meinem anderen Kalender gibt es ja auch überhaupt keine Probleme, alles läuft wie gewünscht.
Auch im Wohnzimmer hat es vorhin bei einem Testtermin wieder geklappt.
Das nützt mir nur nichts, ich muss mich ja darauf verlassen können, dass es IMMER funktioniert.

Vor allem wüßte ich gerne, warum jetzt auf einmal diese Probleme auftreten...

Viele Grüße

Markus

[Dr. Boris Neubert]

Da hilft nur loggen.

Da Du ja Perl-Code im Notify einsetzt, würde ich dort auch gleich mit Debug(); die ganzen Variablen mitprotokollieren lassen, um dem Problem auf die Schliche zu kommen. 

[juelich]

Gute Idee. Werde ich umsetzen. Wie mit scheint, wird das Notify aber gar nicht immer getriggert. In der Commandref finde ich "modeStarted" auch nicht mehr. Vielleicht liegt da auch das Problem. Früher musste das Google zwingend mit rein. Ich habe das jetzt mal durch "start" ersetzt, vielleicht klappt das ja. Trotzdem merkwürdig, dass es nur einen von beiden Kalendern betrifft und dann auch nur manchmal.
Heute Abend bei meinem Testtermin wurde der Start nicht getriggert (Verbose 5), wohl aber das Ende.
Da dürfte mir das Debug() auch nicht weiter helfen...

[Dr. Boris Neubert]

Tipp: mit einem extra Notify alle Events loggen, die Dein Kalender erzeugt.

[Otto123]

Hi,

Du kannst Dir die Events auch einfach im Eventmonitor anschauen.
Ich verwende Google Kalender und nehme diesen Trigger TestKalender:changed:.*start  für das notify wenn es exakt zum Termin starten soll.

Das funktioniert täglich zuverlässig seit vielen Wochen.

Falls Dir meine Notizen helfen: https://heinz-otto.blogspot.com/2019/01/kalender-in-fhem-auf-bestimmte-termine.html

Ich lese von Anfang mit, habe aber keine wirkliche Idee warum dein notify einmal läuft und einmal nicht.

Gruß Otto

[juelich]

Danke für die vielen Tips, ich werde mich da rantasten.
Das mit dem changed klingt interessant, ich hatte es schon ohne "changed auf "end" geändert, und zumindest heute Abend hat es funktioniert:

Code Auswählen Erweitern

define Wohnzimmer_aus notify Wohnzimmer:end:.* {
my $reading="$EVTPART0";
my $uid= "$EVTPART1";
my $dtemp;
my $termin= fhem("get Wohnzimmer summary $uid");
if (defined($termin)) {
my (undef,$dtemp)= split(/ /,fhem("get Wohnzimmer summary $uid"));
fhem("set hz.wohnzimmer desired-temp $dtemp");
Log 1, "Temperatur Wohnzimmer $dtemp";}
}

Führte dann zu foldendem Log:

Code Auswählen Erweitern

2019.03.09 22:00:02 5: Triggering Wohnzimmer_aus
2019.03.09 22:00:02 4: Wohnzimmer_aus exec {
my $reading="$EVTPART0";;
my $uid= "$EVTPART1";;
my $dtemp;;
my $termin= fhem("get Wohnzimmer summary $uid");;
if (defined($termin)) {
my (undef,$dtemp)= split(/ /,fhem("get Wohnzimmer summary $uid"));;
fhem("set hz.wohnzimmer desired-temp $dtemp");;
Log 1, "Temperatur Wohnzimmer $dtemp";;}
}
2019.03.09 22:00:02 1: Temperatur Wohnzimmer 18

Und das Wohnzimmer hat wie gewünscht 18 Grad.

Sollte das Morgen früh auch klappen, dann werde ich das so lasse: Never touch a running system!

Du hast Dich in Deinem Blog ja auch mit Serienterminen beschäftigt, Otto.

In der alten Calendar-Version hat das nie funktioniert. Deshalb habe ich das sein lassen. Da meine Kinder nicht jeden Tag bei mir sind, aber in einem ganzen festen Rhythmus würden mir da  Serientermine natürlich sehr weiterhelfen. Du hast zwar geschrieben, dass die UID bei allen Serienterminen die Gleiche ist - aber würden die Termine denn trotzdem jetzt bei jedem einzelnen Termin den Start triggern? Das war früher nicht so...


Vielen vielen Dank erstmal für die Hilfe


Viele Grüße

Markus

[Otto123]

Hallo Markus,

hab gerade gesehen, ich muss ja meinen Artikel noch vervollständigen 

Ich habe so ein notify für den Start eines Servers am Morgen. Terminende spielt hier keine Rolle. Ich frage damit im wesentlichen Serientermine ab. Das funktioniert einwandfrei.

Code Auswählen Erweitern

defmod n_PraxisKalender notify PraxisKalender:changed:.*alarm {\
my $evt = "";;\
$evt = fhem('get '.$NAME.' events filter:uid=="'.$EVTPART1.'" limit:count=1,from=+0d,to=+1d filter:field(summary)=~"[Ss]prechstunde|[Nn]otdienst"',1);;\
my $ttt = $evt?"1":"0";;\
Log 1, "Der Eventtext: $evt und das Testergebniss: $ttt"\
}
Das sind bei mir auch keine Ganztagestermine sondern von bis Termine. Ich  muss nochmal über die Zeitfilter nachdenken, da hatte ich in einer Diskussion mit Udo mal noch neue Erkenntnisse
Die Zeit ist wirklich einfach vom aktuellen Zeitpunkt aus gerechnet, 0 ist jetzt und 1d ist alle Termine in den nächsten 24h.
Der Filter auf den konkreten Inhalt ist hier schon im get Befehl gesetzt, das Beispiel fragt also die Begriffe sprechstunde oder notdienst ab, egal was sonst noch im Termintext steht.
Dieses notify triggert auf alarm, der wird erzeugt mit einer Regel (stand im Artikel) vor dem eigentlichen Terminstart.

In der commandref steht das Beispiel von Udo "Switch actors on and off" das ist doch eigentlich genau das was Du willst?

Gruß Otto

[juelich]

Das mit Actors on und ob gab es in der alten Commandref auf schon. Meine Version ist geringfügig komplizierter: Ich übergebe zwei Temperaturen, die in den beiden Notifys gesplittet werden. Beim Start wird die erste Temperatur verwendet, beim Ende die zweite.
Dein Beispiel oben sieht für mich erstmal kompliziert aus, das muss ich mir mal im Hellen angucken 🤣.
Die Heizperiode ist ja auch schon so gut wie vorbei, mein Kalender ist schon bis Mitte April geschrieben 😉.
Viele Grüße Markus

[juelich]

Heute Morgen wurde mal wieder nicht geschaltet.
Und ich weiß auch warum. Klassicher Anfängerfehler.

Ich hatte gestern aus Frust mein altest Notify gelöscht und vom Kinderzimmer kopiert.
Und dabei natürlich einen Schreibfehler eingebaut.
Zumindest der Test hat jetzt funktioniert 

Vielen Dank fürs erste.
Ich werde mich dann nochmal mit Serienterminen beschäftigen.

Viele Grüße

Markus

[Otto123]

Moin Markus,

naja und Du musst den von Dir bisher verwendeten Abfrage Syntax verändern. Der geht zwar noch, aber Du solltest Meldungen im Log haben, dass er abgekündigt ist?
Bevor das Update mal unverhofft zuschlägt und im nächsten Winter Stress ansteht 

Das mit dem Inhalt im Termin war mir klar, es ging mir ums Prinzip: Du hast einen Termin zum Anfang passiert was und zum Ende passiert was. Du schaltest nicht den Aktor an und aus sondern liest zwei Temperaturen aus dem Inhalt und setzt diese.
Die Logik für die beiden Temperaturen hast Du ja musst Du "nur" mit der Logik für die Aktoren kombinieren.

Gruß Otto

[juelich]

Im Logfile habe ich zwar nichts gelesen, dass die alte Version abgekündigt wurde, wohl aber die neuen Features 
In der Commandref findet sich dazu auch kein Hinweis, dass die von mir abgefragten Zustände (modeStarted und modeEnded) nicht mehr existent seien:

"Ein Kalender-Device hat verschiedene Readings. Mit Ausnahme von calname stellt jedes Reading eine Semikolon-getrennte Liste von UIDs von Kalender-Ereignisse dar, welche bestimmte Zustände haben:

calname   Name des Kalenders
modeAlarm   Ereignisse im Alarm-Modus
modeAlarmOrStart   Ereignisse im Alarm- oder Startmodus
modeAlarmed   Ereignisse, welche gerade in den Alarmmodus gewechselt haben
modeChanged   Ereignisse, welche gerade in irgendeiner Form ihren Modus gewechselt haben
modeEnd   Ereignisse im Endemodus
modeEnded   Ereignisse, welche gerade vom Start- in den Endemodus gewechselt haben
modeStart   Ereignisse im Startmodus
modeStarted   Ereignisse, welche gerade in den Startmodus gewechselt haben
modeUpcoming   Ereignisse im zukünftigen Modus
Für Serientermine werden mehrere Termine mit der selben UID erzeugt. In diesem Fall wird die UID nur im interessantesten gelesenen Modus-Reading angezeigt. Der interessanteste Modus ist der erste zutreffende Modus aus der Liste der Modi start, alarm, upcoming, end.

Die UID eines Serientermins wird nicht angezeigt, solange sich der Termin im Modus: modeEnd oder modeEnded befindet und die Serie nicht beendet ist. Die UID befindet sich in einem der anderen mode... Readings. Hieraus ergibts sich, das FHEM-Events nicht auf einem mode... Reading basieren sollten."

Den letzten Satz kann ich nicht ganz verstehen, da er im Zusammenhang mit Serienterminen steht, aber vielleicht sind das ja meine Probleme.

Das Beispiel mit den Avtoren entspricht genau meinem Notify - die Änderung von "modeStarted" auf "Start" hatte ich gestern schon vorgenommen - und es scheint zu funktionieren.
Das von Dir verwendete "changed" taucht als Event auf, aber zusätzlich zu start, weshalb ich nicht darauf, sonder direkt auf Start triggere:

Code Auswählen Erweitern

2019-03-10 12:16:03 Calendar Wohnzimmer changed: xxxgooglecom start
2019-03-10 12:16:03 Calendar Wohnzimmer start: xxxgooglecom

Damit hat mein Notify jetzt folgenden Trigger:

Code Auswählen Erweitern

define Wohnzimmer_an notify Wohnzimmer:start:.* {
my $reading="$EVTPART0";
my $uid= "$EVTPART1";
my $dtemp;
my $termin= fhem("get Wohnzimmer summary $uid");
if (defined($termin)) {
my ($dtemp,undef)= split(/ /,fhem("get Wohnzimmer summary $uid"));
fhem("set hz.wohnzimmer desired-temp $dtemp");
Log 1, "Temperatur Wohnzimmer $dtemp";}
;;}

Und das funktionert im Moment.

Jetzt gucke ich mal, ob es mit Serienterminen auch klappt.

Viele Grüße

Markus

[juelich]

Nachtrag:

Jetzt habe ich das Ganze mal als Serientermin angelegt.
Und zumindest wurden beide Notifys (Start und Ende) getriggert. Das hat also schon mal funktioniert.

Allerdings wurde beim Ende der Titel (eigentlich "23 21") falsch ausgelesen - was natürlich zu Problemen führt:

Code Auswählen Erweitern

2019.03.10 12:32:02 1: PERL WARNING: Argument "21\n23" isn't numeric in multiplication (*) at ./FHEM/10_CUL_HM.pm line 5468.

Hast Du eine Ahnung, was hier das Problem ist?

Vielen Dank und viele Grüße

Markus

[Dr. Boris Neubert]

Du hast die Temperaturen in zwei Zeilen und Dein split() greift darauf nicht. Du musst an Whitespace splitten oder /[\s\n]/.

/\s/

[juelich]

Ja, so sieht es aus, aber wo kommt das her? Ich habe meinen Testtermin nicht verändert, er besteht aus einer Zeile mit durch Space getrennten Temperaturen. Ich hatte lediglich zum Testen einen Wiederholungstermin daraus gemacht. Da scheint aber zu bewirken, dass der Termin-Betreff falsch ausgelesen wird...

Es scheint bit dem von Otto beschriebenen Verhalten zusammen zu hängen:

Ich habe mir den ausgelesenen Termin mal loggen lassen - er besteht aus etlichen Wiederholungen von "18 21", jeweils in einer neuen Zeile. Dann ist auch klar, dass die Splitfunktion Ärger macht.
Leider reichen meine Perl-Kenntnisse nicht so weit, vielleicht hat ja einer eine Idee, wie ich aus diesem langen Text die Zahl nach dem ersten Space bis zum Zeilenende herausfiltern kann? Das würde für mein  Problem ja schon reichen und ich müßte nicht alles umprogrammieren...

Vielen Dank für die tolle Hilfe

Markus

Code Auswählen Erweitern

2019.03.10 12:56:02 1: 18 21
18 21
18 21
18 21
18 21
18 21
18 21
18 21
18 21
18 21
18 21
18 21
18 21
18 21
18 21
18 21
18 21
18 21
18 21
18 21

Du hast die Temperaturen in zwei Zeilen und Dein split() greift darauf nicht. Du musst an Whitespace splitten oder /[\s\n]/.

/\s/

[Otto123]

Du musst die get Abfrage ändern. Das musst Du nicht immer im notify testen, das kannst Du in der Oberfläche machen!
get Wohnzimmer summary $uid liefert Dir eben bei einem Serientermin viel zu viel, Du musst das einschränken auf den einen Termin.
z.B. limit:count=1
oder Zeit
limit:count=1,from=0,to=12h

Oder so etwas in der Art

Und get <name> summary taucht in der commandref nicht mehr auf und man bekommt das hier im Log:
2019.03.10 13:10:50 2: get AbfallKalender summary is deprecated and will be removed soon. Use get AbfallKalender events instead.

Das ist doch eindeutig oder kommt das bei Dir nicht?

Gruß´Otto

[juelich]

Nein,

in der Tat kam diese Meldung bei mir noch nie. Ich hatte ja heute ein Log vom Notify machen lassen, da kam nichts dergleichen:

Code Auswählen Erweitern

2019.03.10 12:32:02 4: Wohnzimmer_aus exec {
my $reading="$EVTPART0";;
my $uid= "$EVTPART1";;
my $dtemp;;
my $termin= fhem("get Wohnzimmer summary $uid");;
if (defined($termin)) {
my (undef,$dtemp)= split(/ /,fhem("get Wohnzimmer summary $uid"));;
fhem("set hz.wohnzimmer desired-temp $dtemp");;
Log 1, "Temperatur Wohnzimmer $dtemp";;}
}
2019.03.10 12:32:02 1: PERL WARNING: Argument "21\n23" isn't numeric in multiplication (*) at ./FHEM/10_CUL_HM.pm line 5468.

Gucke Dir bitte das Beispiel mit den Actoren aus der Commandref an, da steht die Syntax mit Get <name< summary genau wie auch von mir verwendet. Auch weiter oben in der commandref steht doch ausdrücklich get <name< summary - sogar ausführlich mit Beispielen.  Hingegen finde ich das Get <name> events nicht, obwohl es natrülich funktioniert...

Viele Grüße

Markus

[Dr. Boris Neubert]

Gucke Dir bitte das Beispiel mit den Actoren aus der Commandref an, da steht die Syntax mit Get <name< summary genau wie auch von mir verwendet. Auch weiter oben in der commandref steht doch ausdrücklich get <name< summary - sogar ausführlich mit Beispielen.  Hingegen finde ich das Get <name> events nicht, obwohl es natrülich funktioniert...

Dann ist bei Dir etwas faul und Du hast nicht die aktuelle Commandref. Lass mal ein volles Update über Dein FHEM laufen, damit auch die Commandref aktualisiert wird.

[juelich]

In der englischen Commandref steht es tatsächlich so drin - aber nicht in der deutschen.
Ein Update habe ich gestern erst gemacht, auch ein shutdown restart.
Dann werde ich meine Notifys mal auf die neue Nomenklatur umbasteln...
Viele Grüße

Markus

[Otto123]

Aber wenn im FHEM Log die Meldung nicht kommt? 
Wirft Dir version wirklich die Aktuelle aus?
57_Calendar.pm        18535 2019-02-08 20:59:50Z betateilchen

[juelich]

Ich habe jetzt versucht zu basteln, allerdings scheinbar nicht korrekt:

Um auf die Summary des aktuellen Termins zuzugreifen verwende ich:

Code Auswählen Erweitern

my $termin= fhem("get Wohnzimmer events format:custom='$S' filter:uid==$uid limit:count=1")

Was zu einem

Code Auswählen Erweitern

Global symbol "$S" requires explicit package name führt.

Wie kriege ich das maskiert?

ALs Version habe ich offensichtlich doch noch die Januar-Version

Code Auswählen Erweitern

57_Calendar.pm 18138 2019-01-05 07:59:07Z neubert

[Dr. Boris Neubert]

 Tip: use single quotes as outer quotes.

[juelich]

"Single quotes (') can be used instead of double quotes (") in the custom format."

So steht es in der Referenz. Aber was heißt denn nun "Tip: use single quotes as outer quotes."? Es tut mir leid, ich bin Amateur und kein Profi...

[Dr. Boris Neubert]

geht

Code Auswählen Erweitern

my $termin= fhem('get Wohnzimmer events format:custom="$S" filter:uid==$uid limit:count=1')

?

[Otto123]

Da werden doch aber die Variablen wie $uid nicht aufgelöst.
Ich mach es  mit concatenation

Code Auswählen Erweitern

my $actor = fhem('get '.$NAME.' events format:custom="$S" filter:uid=="'.$EVTPART1.'" limit:count=1')


[juelich]

Fast 

Das mit $uid geht so auch nicht.

Code Auswählen Erweitern

Wohnzimmer:start:.* {
my $reading="$EVTPART0";
my $uid= "$EVTPART1";
my $dtemp;
my $termin= fhem('get Wohnzimmer events format:custom="$S" filter:uid=="'.$uid.'" limit:count=1');
Log 1,$termin;
if (defined($termin)) {
my ($dtemp,undef)= split(/ /,fhem('get Wohnzimmer events format:custom="$S" filter:uid=="'.$uid.'" limit:count=1'));
fhem("set hz.wohnzimmer desired-temp $dtemp");
Log 1, "Temperatur Wohnzimmer $dtemp";}
;;}

Das klappt zumindest jetzt bei mir. Schwierige Geburt.
Jetzt werde ich mal die Notifys fürs Kinderzimmer umstricken und die Termine für die Kiddys in Serientermine umwandeln.
Und dann bin ich mal gespannt, was passiert 

Vielen Dank für die Hilfe hier und Euch noch einen schönen Sonntag

Viele Grüße

Markus

[juelich]

Jetzt hat sich das überschnitten, hatte meine Antwort nicht abgeschickt,

deckte sich ja mit der von Otto.

Ich habe jetzt alle meine Kindertermine umgemodelt auf Serientermine und bin mal sehr gespannt, ob das jetzt klappt. Wäre ja super.

Ich habe noch inen dritten Kalender im ANgebot. Mit dem kann ich FHEM beliebige Befehle erteilen, die dann zum Terminzeitpunkt ausgeführt werden.
Das sollte klappen. Es gibt allerdings einige Sondertermine:

Zum Beispiel "Urlaub". Hier wird dann der Terminstart und das Terminende ausgelesen. Nach einer gewissen Zeit die Alarmanlage aktiviert und vor allem die Thermostate, auf denen ein regelmäßiges Programm läuft in den Partymodus gesetzt.

Hierzu müßte ich den Starttermin des Termins auslesen - sehe ich das richtig, dass ich über timeFormat glich steuern kann, dass ich z.B. nur die Uhrzeit oder den Tag bekomme?
Das wäre natürlich super, auch wenn es wederheiß, alles umzustricken.

Aber FHEM ist ja nun mal eine Bastellösng...

Viele Grüße

Markus

[Otto123]

Du hast noch das mit dem Filter noch nicht komplett. Im Serientermin bekommst Du immer alle. Bei deinem Konstrukt bekommst Du jetzt den ersten Eintrag. Heute klappt das, morgen bekommst Du aber dann wieder den von Gestern.
Also das wäre glaub ich das minimum an Filter was bei einem Serientermin geht:
limit:count=1,from=0

Und in Zeile 5 hast DU doch das in $termin stehen, was Du in Zeile 8 wieder brauchst, das musst Du doch nicht 2x abfragen.

[juelich]

Mit dem $termin hast Du natürlich Recht.
Mich wundert, dass in dem Beispiel in der Commandref die Abfrage nach dem "defined" nicht mehr auftaucht. Früher war das Problem, dass bei jedem Kalenderupdate mein Notify getriggert hat, auch wenn gar kein Termin aktuell gestartet ist. Dadurch war mein $termin dann leer und es ga einen Haufen Fehler im Log. Das habe ich mit meiner Abfrage abgefangen...

Aber vielleicht ist das ja jetzt auch kein Problem mehr. Dann könnte diese Abfrage auch aus und ich ein bißchen Code sparen...

Zu den Serienterminen:

Ich frage doch nur den Betreff ab. Dieser ist doch bei allen Serienterminen einer Serie gleich. Oder bekomme ich mit meiner Abfrage den ersten Termin IRGENDEINER Serie? Das geht natürlich nicht.
Ich habe zum Beispiel Morgen früh einen Termin von 04.30 bis 06:00 mit dem Betreff  "21 16", der sich 14tägig wiederholt.

Wenn also Montag in 14 Tagen getriggert wird, soll er doch genau diesen Betreff wieder als Ergebnis haben.

Dienstag habe ich allerdings einen Serientermin 12.30 bis 20:00 mit "21 18". Diesen Betreff möchte ich natürlich in 14 Tagen auslesen.

Und das klappt mit meiner Abfrage nicht?

[Otto123]

Zu Deiner ersten Frage. Dein notify triggert auf einen Event genau von Deinem Termin. Eigentlich kann der nicht undef sein.
Zum Serientermin
Damit Du das bildlich verstehst ist es gut das interactive mit Abfragen zu testen. Das geht in der Weboberfläche mit einem String sehr gut!

Du kannst in einem Serientermin ja trotzdem im Betreff/Inhalt ändern, Du kannst auch einen einzelnen Termin terminlich ändern. Mit Deiner Abfrage fragst Du immer den ersten Termin der Serie ab, nicht den Termin der Serie heute.

[juelich]

Natürlich sollte es eigentlich so sein, dass das Notify genau auf das Event von einem Termin triggert. Leider hat das in der Vergangenheit nicht so funktioniert, wie mein Beitrag aus längst vergangenen Zeiten zeigt:

ch habe es mit Hilfe aus dem Forum nun selber hinbekommen:

Das Problem liegt im Calendar-Modul selber. Laut Commandref sollte das Notify eigentlich wie beschrieben nur aktiv werden, wenn ein Termin beginnt. Dem ist aber nicht so, das Notify wird bei jedem Aktualisieren des Kalender aktiviert - mit der Folge, dass ein leeres $EVENT mitgeliefert wird (es ist ja kein aktiver Termin vorhanden) und damit $EVTPART1 nicht definiert ist.

[juelich]

Das Abfragen auf der Weboberfläche klappt bei mir nicht so direkt - was meinst Du mit String? Die Abfrage in Anführungszeichen setzen?
Natürlich könnte ich bei einem Serientermin auch den Betreff ändern. Das würde ich bei meiner Heizungssteuerung aber nicht tun. Höchstens mal einen Termin aussetzen, aber dann wird mein Notify ja auch nicht getriggert. Und wenn ich manuell mal die Uhrzeit eines Termins ändern sollte hat das m.E. ja auch bloß Einfluß auf das Triggern des Notifys und nicht auf die Abfrage des Betreffs oder sehe ich das aus?

[Otto123]

Wenn im Betreff deine Temperatur drin steht und Du heute 21 und 17 drin stehen hast, in einem Jahr auf 22 und 15 änderst, bei der Änderung sagst: alle zukünftigen Termine ändern - dann wunderst Du Dich wenn du anschließend immer noch den Inhalt von heute bekommst.

Also ich würde zwingend Wert darauf legen, exakt den Termineintrag zu lesen, der zum Trigger geführt hat!
Für die FHEM Kommandozeile
Zur Abfrage (String):

Code Auswählen Erweitern

get Wohnzimmer events format:custom="$S" limit:count=1 sollte Dir doch was zurück geben?

Code Auswählen Erweitern

get Wohnzimmer events format:full limit:count=1

Code Auswählen Erweitern

get Wohnzimmer events format:full limit:count=1,from=0 gibt dir nur einen Eintrag von heute.

Code Auswählen Erweitern

get Wohnzimmer events format:full limit:count=1,from=+1d gibt dir was von morgen.

Du kannst auch in der Weboberfläche im Kalenderdevice bis events alles auswählen und im Feld dahinter
nur den Rest reinkopieren (ein String)

Code Auswählen Erweitern

format:full

[juelich]

Vielen Dank für die viele Mühe.
Ich hatte schon überalle "from=0" ergänzt. Sicher ist sicher, Du hast recht, auch wenn ich es für unwahrscheinlich finden würde, die Termine in der von Dir beschriebenen Form zukünftig zu ändern.
Aber es wird. Das schöne an FHEM ist: Es gibt immer wieder was zu tun 
Dir noch einen schönen Sonntag

[juelich]

So super,

jetzt hatte ich Gelegenheit, alle meine Notifys mit der neuen Nomenklatur zu test - und es funktioniert super, auch mit Wiederholungsterminen. Das spart viel Arbeit.

Vielen Dank und viele Grüße

Markus

[juelich]

Leider zu früh gefreut,

seit Dienstag dieser Woche funktioniert das Ausschalten der Heizung im Kinderzimmer nicht mehr. Und das, ohne, dass ich irgendetwas geändert hätte.
Jetzt ist für mich wieder guter Rat teuer:
Um 20 Uhr sollte die Heizung ausgeschaltet werden, dass Notify hat offensichtlich auch getriggert, aber nichts geschaltet:

Code Auswählen Erweitern

2019.04.07 20:00:01 4: Kinder_aus exec {
my $reading="$EVTPART0";;
my $uid= "$EVTPART1";;
my $dtemp;;
my $termin= fhem('get Kinder events format:custom="$S" filter:uid=="'.$uid.'" limit:count=1,from=0');;
if (defined($termin)) {
my (undef,$dtemp)= split(/ /,$termin);;
fhem("set hz.kinder desired-temp $dtemp");;
Log 1, "Temperatur Kinderzimmer $dtemp";;}
}

Ich gehe also davon aus, dass die if-Abfrage nicht korrekt abgearbeitet wurde. Ihr habe hier geschrieben, dass die Abfrage, ob der Termin "defined" ist, überflüssig ist (früher war das unbedingt notwendig!).
Also habe ich versucht, dass wegzulassen:

Code Auswählen Erweitern

Kinder:end:.* {
my $reading="$EVTPART0";
my $uid= "$EVTPART1";
my $dtemp;
my $termin;
$termin= fhem('get Kinder events format:custom="$S" filter:uid=="'.$uid.'" limit:count=1,from=0');
my (undef,$dtemp)= split(/ /,$termin);
fhem("set hz.kinder desired-temp $dtemp");
Log 1, "Temperatur Kinderzimmer $dtemp";
}

Das führt jetzt aber zu folgender Fehlermeldung:

Code Auswählen Erweitern

2019.04.07 20:44:01 1: PERL WARNING: "my" variable $dtemp masks earlier declaration in same scope at (eval 14789) line 7.
2019.04.07 20:44:01 1: PERL WARNING: Use of uninitialized value $termin in split at (eval 14789) line 7.
2019.04.07 20:44:01 1: PERL WARNING: Use of uninitialized value $dtemp in concatenation (.) or string at (eval 14789) line 8.
2019.04.07 20:44:01 1: PERL WARNING: Use of uninitialized value $dtemp in concatenation (.) or string at (eval 14789) line 9.
2019.04.07 20:44:01 1: Temperatur Kinderzimmer

Ich verstehe nicht, was plötzlich anders sein könnte, bis Dienstag hat alles problemlos mit meinem Urspungscode funktioniert, im WOhnzimmer ohne Wiederholungstermine tut es das auch heute noch. Bloß die Kinderzimmer schalten nicht mehr aus.

Viele Grüße

Markus

[Dr. Boris Neubert]

Bitte logge mal $termin mit, damit man sieht, was ankommt.

Grüße
Boris

[juelich]

Ich konnte den Fehler noch weiter eingrenzen:

Noch einmal mein Code:

Code Auswählen Erweitern

Kinder:end:.* {
my $reading="$EVTPART0";
my $uid= "$EVTPART1";
my $dtemp;
my $termin= fhem('get Kinder events format:custom="$S" filter:uid=="'.$uid.'" limit:count=1,from=0');
Log 1, "Kalender $termin";
my (undef,$dtemp)= split(/ /,$termin);
fhem("set hz.kinder desired-temp $dtemp");
Log 1, "Temperatur Kinderzimmer $dtemp";
}

führt zu folgendem Log:

Code Auswählen Erweitern

2019.04.07 21:02:01 4: Kinder_aus exec {
my $reading="$EVTPART0";;
my $uid= "$EVTPART1";;
my $dtemp;;
my $termin= fhem('get Kinder events format:custom="$S" filter:uid=="'.$uid.'" limit:count=1,from=0');;
Log 1, "Kalender $termin";;
my (undef,$dtemp)= split(/ /,$termin);;
fhem("set hz.kinder desired-temp $dtemp");;
Log 1, "Temperatur Kinderzimmer $dtemp";;
}
2019.04.07 21:02:01 1: PERL WARNING: "my" variable $dtemp masks earlier declaration in same scope at (eval 15067) line 7.
2019.04.07 21:02:01 1: PERL WARNING: Use of uninitialized value $termin in concatenation (.) or string at (eval 15067) line 6.
2019.04.07 21:02:01 1: Kalender
2019.04.07 21:02:01 1: PERL WARNING: Use of uninitialized value $termin in split at (eval 15067) line 7.
2019.04.07 21:02:01 1: PERL WARNING: Use of uninitialized value $dtemp in concatenation (.) or string at (eval 15067) line 8.
2019.04.07 21:02:01 1: PERL WARNING: Use of uninitialized value $dtemp in concatenation (.) or string at (eval 15067) line 9.
2019.04.07 21:02:01 1: Temperatur Kinderzimmer

Es ist also offensichtlich, dass der Get ... events -Befehl (der derselbe ist wie beim Terminstart) hier ein leeres Ergebnis bringt und nicht mehr den Betreff des Termins. Warum weiß ich nicht

[juelich]

Zeitlich sieht man alles schön im Log:

Code Auswählen Erweitern

2019.04.02 04:30:01 1: Temperatur Kinderzimmer 22
2019.04.02 06:00:01 1: Temperatur Kinderzimmer 18
2019.04.02 12:30:01 1: Temperatur Kinderzimmer 21
2019.04.02 14:00:02 1: Temperatur Wohnzimmer 21
2019.04.02 16:55:07 1: fenster.wz: Batteriewarnung battery: low
2019.04.02 17:00:00 3: Abendbrot: Temperatur Wintergarten ist 22 Grad
2019.04.02 18:55:22 1: HMLAN_Parse: HMLAN new condition Warning-HighLoad
2019.04.02 18:57:32 1: HMLAN_Parse: HMLAN new condition ok
2019.04.02 19:00:01 1: Temperatur Kinderzimmer off
2019.04.02 19:00:03 1: HMLAN_Parse: HMLAN new condition Warning-HighLoad
2019.04.02 19:01:21 1: HMLAN_Parse: HMLAN new condition ok
2019.04.02 19:04:06 1: HMLAN_Parse: HMLAN new condition Warning-HighLoad
2019.04.02 19:10:24 1: HMLAN_Parse: HMLAN new condition ok
2019.04.02 22:00:02 1: Temperatur Wohnzimmer 18
2019.04.03 04:30:01 1: Temperatur Kinderzimmer 22
2019.04.03 08:10:02 1: Temperatur Wohnzimmer 21

Am 04.02. um 19:00 Uhr tauchte zum ersten Mal ein "off" statt der Temperatur 18 Grad auf. Der gehörte da schon nicht hin.
Danach wurde die Kinderzimmertemperatur zwar erhöht, aber nicht mehr abgesenkt - ab dem 03.04. Uhr 6:00 wurde das Kinderzimmer nicht einmal ausgeschaltet. WIe man im Log sieht ist aber dazwischen nichts meinerseits verändert worden. Nun bin ich etwas ratlos

[Dr. Boris Neubert]

Würde auf der FHEM-Kommandozeile weiter debuggen, indem Du Dir den Output von

Code Auswählen Erweitern

get Kinder events format:custom="$S" filter:uid=="'.UID.'" limit:count=1,from=0

anguckst, wobei Du UID durch die UID des Events ersetzt. Was machen die beiden Punkte eigentlich da?

[juelich]

Da werden doch aber die Variablen wie $uid nicht aufgelöst.
Ich mach es  mit concatenation

Code Auswählen Erweitern

my $actor = fhem('get '.$NAME.' events format:custom="$S" filter:uid=="'.$EVTPART1.'" limit:count=1')


Da kommen die Punkte her...

Ohne die Punkte habe ich das nicht hinbekommen

[Dr. Boris Neubert]

Du wolltest vielleicht den Match-Operator statt des Gleich-Operators verwenden (siehe Commandref)?

[Otto123]

Hallo Markus,

genaugenommen keine Fehler sondern Warnungen, aber irgendwas ist an deinem Code Mist.
Ich verstehe nicht, was Du da gepostet hast? Ist das die DEF?

Es ist offensichtlich, dass er diese Zeile 7

Code Auswählen Erweitern

my (undef,$dtemp)= split(/ /,$termin);
nicht ausführt gar nicht ausführt.

Es ist besser ein list des Gerätes zu posten, dass ist für alle eindeutiger.

Dieses my Variable in der nächsten Zeile wieder mit my Variable zu wiederholen für zur ersten Warnung.

Die Punkte sind String concatenation .

Gruß Otto

[Otto123]

Du wolltest vielleicht den Match-Operator statt des Gleich-Operators verwenden (siehe Commandref)?

Was meinst Du damit?

So steht es doch in der commandref, Zitat:

Code Auswählen Erweitern

my $actor= fhem('get MyCalendar filter:uid=="'.$uid.'" format:custom="$S"');; \


Gruß Otto

[juelich]

Hallo Markus,

genaugenommen keine Fehler sondern Warnungen, aber irgendwas ist an deinem Code Mist.
Ich verstehe nicht, was Du da gepostet hast? Ist das die DEF?

Es ist offensichtlich, dass er diese Zeile 7

Code Auswählen Erweitern

my (undef,$dtemp)= split(/ /,$termin);
nicht ausführt gar nicht ausführt.

Er führt das deshalb nicht aus, weil $termin offensichtlich leer ist. Es wird einfach nichts zurück geliefert.
Ich verwende obigen Code schon seit vielen Jahren. Die Betreffs meine Termine haben die Form "Anfangstemperatur Endtemperatur". Mit dem Split wird zum Terminende die Endtemperatur eingestellt.
Aber wie gesagt - der Get-Befehl scheint nichts zu liefern, obwohl derselbe Get-Befehl zu Terminbeginn den Betreff zurückliefert.

Von welchem Gerät soll ich denn ein List liefern - es ist doch ein Notify?

[juelich]

Was meinst Du damit?

So steht es doch in der commandref, Zitat:

Code Auswählen Erweitern

my $actor= fhem('get MyCalendar filter:uid=="'.$uid.'" format:custom="$S"');; \


Gruß Otto

Und es hat ja offensichtlich auch bis zum 02.04. funktioniert (siehe mein Log). Ich habe nichts seitdem geändert!

[Otto123]

Von welchem Gerät soll ich denn ein List liefern - es ist doch ein Notify?

Naja das notify ist auch im Sinne FHEM ein "Gerät", Device, Define wie auch immer.

[juelich]

Code Auswählen Erweitern

Internals:
   DEF        Kinder:end:.* {
my $reading="$EVTPART0";
my $uid= "$EVTPART1";
my $dtemp;
my $termin= fhem('get Kinder events format:custom="$S" filter:uid=="'.$uid.'" limit:count=1');
Log 1, "Kalender $termin";
my (undef,$dtemp)= split(/ /,$termin);
fhem("set hz.kinder desired-temp $dtemp");
Log 1, "Temperatur Kinderzimmer $dtemp";
}
   FUUID      5c8527a8-f33f-82e1-53a7-882a4814dfb7bf85
   NAME       Kinder_aus
   NOTIFYDEV  Kinder
   NR         245
   NTFY_ORDER 50-Kinder_aus
   REGEXP     Kinder:end:.*
   STATE      2019-04-07 21:30:00
   TRIGGERTIME 1554665401.27008
   TYPE       notify
   READINGS:
     2019-04-07 21:28:06   state           active
Attributes:
   room       Notify
   verbose    5

besser?

[Otto123]

viel besser

Bist Du sicher, das Du nicht weiter Termine drin stehen hast?
Ich meine: Du triggerst nur auf end:.* und Du machst keinerlei weitere Prüfung.
Hast Du mal %uid mit geloggt? und dann mal explizit in der commandline diese $uid abgefragt?
Oder hast Du mal alle Termine des Tages abgefragt?

Gruß Otto

[juelich]

Ich hatte mich ja bei Dir bedient, OttO:

Du musst die get Abfrage ändern. Das musst Du nicht immer im notify testen, das kannst Du in der Oberfläche machen!
get Wohnzimmer summary $uid liefert Dir eben bei einem Serientermin viel zu viel, Du musst das einschränken auf den einen Termin.
z.B. limit:count=1
oder Zeit
limit:count=1,from=0,to=12h

Oder so etwas in der Art

Und daher sah meine Terminabfrage bis eben so aus:

Code Auswählen Erweitern

my $termin= fhem('get Kinder events format:custom="$S" filter:uid=="'.$uid.'" limit:count=1,from=0')

Jetzt habe ich vor 5 MInuten das "from=0" weggelassen - und plötzlich funktioniert es wieder!

Code Auswählen Erweitern

2019.04.07 21:41:01 1: PERL WARNING: "my" variable $dtemp masks earlier declaration in same scope at (eval 15284) line 7.
2019.04.07 21:41:01 1: Kalender 16 18
2019.04.07 21:41:01 1: Temperatur Kinderzimmer 18

Wenn es so bleiben würde wäre ja alles gut. Aber warum hat es bitteschön mit meinem alten Code bis Anfang der Woche funktioniert und jetzt nicht mehr? Ich habe nichts geändert, die Termine sind Wiederholungstermine, also auch nicht verändert und ein Update oder Neustart habe ich bis dahin auch nicht gemacht.
Zauberei?

Viele Grüße

Markus

[Otto123]

Markus, Du verstehst es nicht. Nichts ist gut. Du fragst jetzt wahrscheinlich alte Termine ab.

Frag doch einfach mal in der Oberfläche alles ab. get Kinder events wählst Du aus und dahinter kommt noch format:full

Und dann ein zweite Abfrage  und Du ergänzt noch limit:from=0

Gruß Otto

[juelich]

Hallo Otto,

das ist ja blöd. Aber ich muss jetzt leider ins Bett. Morgen 24-Stunden Dienst. Ich werde mich Dienstag Ran setzen.
Aber hast Du eine Erklärung dafür, was am 02.04. passiert sein könnte? Auch dieses "Off" muss ja irgendwo hergekommen sein. Danach ging nichts mehr.
Ich habe das Notify ja mit Deiner Hilfe gut hinbekommen.
Alles funktioniert, zum Beispiel auch im Wohnzimmer.
Nicht verändert. Und plötzlich nur noch Mist...

[juelich]

Ach und noch etwas - die Abfrage lieferte definitiv keine alten Termine:
Ich hatte ja extra etwas ausgefallenes als Betreff gewählt, was ich nie nehmen würde.
Und das wurde auch zurück geliefert...

[Otto123]

Gut, aber ohne den Inhalt der Abfragen hab ich keine Idee.
Du verwendest doch aber Serientermine?

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.

[juelich]

Ja, für die Kinderzimmer nehme ich Serientermine, für das Wohnzimmer nicht. Aber Du hast recht - mein Testtermin eben war keiner. Also könnte es bei einem Serientermin anders sein...
Aber offensichtlich hat das Weglassen von "from=0" dazu geführt, dass überhaupt mal wieder etwas zurück geliefert wurde.
Das gibt mir zu denken.

[Otto123]

Ja, für die Kinderzimmer nehme ich Serientermine, für das Wohnzimmer nicht. Aber Du hast recht - mein Testtermin eben war keiner. Also könnte es bei einem Serientermin anders sein...
Aber offensichtlich hat das Weglassen von "from=0" dazu geführt, dass überhaupt mal wieder etwas zurück geliefert wurde.
Das gibt mir zu denken.

Du sollst doch die Abfrage nicht mit irgendwelchen Faketerminen machen? Warum fragst Du nicht die normalen ab?

Mein Abfragevorschlag war doch nicht für bestimmte Termine sondern für alle? Wie kommt dann Deine Aussage zustande?

[juelich]

Welche Aussage meinst Du?
Ich verstehe immer noch nicht, wie unveränderter Code und unveränderte Termine zu so einer plötzlichen Fehlfunktion führen...


Aber ich muss jetzt wirklich ins Bett.
Ich mache Dienstag weiter.

Bis dahin vielen Dank und gute Nacht

[Otto123]

Welche Aussage meinst Du?

Diese:

Ach und noch etwas - die Abfrage lieferte definitiv keine alten Termine:

Aber Du hast recht - mein Testtermin eben war keiner. Also könnte es bei einem Serientermin anders sein...

Deine Antworten sagen mir eigentlich Du hast nicht das gemacht um was ich gebeten hatte. Also poste bitte beim nächsten mal, was Du gemacht hast und die Ergebnisse.

Ich verstehe immer noch nicht, wie unveränderter Code und unveränderte Termine zu so einer plötzlichen

Ganz einfach, weil manchmal etwas funktioniert obwohl man einen Fehler / eine Unzulänglichkeit eingebaut hat. 
Und weil man keinen Anspruch darauf hat, dass etwas immer funktioniert obwohl ein Fehler enthalten ist.

Gute Nacht
Otto

[juelich]

Ganz einfach, weil manchmal etwas funktioniert obwohl man einen Fehler / eine Unzulänglichkeit eingebaut hat. 
Und weil man keinen Anspruch darauf hat, dass etwas immer funktioniert obwohl ein Fehler enthalten ist.

Ganz so sehe ich das nicht, Otto. Eigentlich sollte ein Programm bei unveränderte Umgebung doch bei jedem Lauf dieselben Ergebnisse bringen - egal, ob diese nun richtig oder falsch sind 

Ich habe jetzt mal die gewünschten Abfragen gemacht. Ich habe dazu einen Testermin angelegt, der als Serientermin den Betreff "13 11" hat. Speziell für heute habe ich ihn geändert auf "15 16", damit man differenzieren kann welche Werte ausgelesen werden:

get Kinder events format:full

Code Auswählen Erweitern

0ahea04o1lki07l58lonidaeapgooglecom       end  09.04.2019 10:14-09.04.2019 10:15 15 16 
0ahea04o1lki07l58lonidaeapgooglecom  upcoming  16.04.2019 10:09-16.04.2019 10:10 13 11

jetzt das Ganze nochmal mit limit:from=0:

Code Auswählen Erweitern

0ahea04o1lki07l58lonidaeapgooglecom  upcoming  16.04.2019 10:09-16.04.2019 10:10 13 11 
0ahea04o1lki07l58lonidaeapgooglecom  upcoming  23.04.2019 10:09-23.04.2019 10:10 13 11

Erwartungsgemäß werden hier nur die zukünftigen Events angezeigt.

Interessant ist aber, was in dem Moment passiert, wenn der Termin endet, also das Notify Terminende getriggert wird. Ich habe dazu ein Testnotify geschrieben, was ein paar Daten mitloggt:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        Kinder:end:.* {
my $uid= "$EVTPART1";
Log 1, "UID $uid";
my $termin= fhem('get Kinder events format:custom="$S" filter:uid=="'.$uid.'" limit:count=1');
my $termin1= fhem('get Kinder events format:custom="$S" filter:uid=="'.$uid.'" limit:count=1,from=0');
Log 1, "Kalender $termin";
Log 1, "Kalender aktuell $termin1";
my (undef,$dtemp)= split(/ /,$termin);
fhem("set hz.kinder desired-temp $dtemp");
Log 1, "Temperatur Kinderzimmer $dtemp";
}

Und jetzt das Log dazu:

Code Auswählen Erweitern

2019.04.09 10:15:02 1: UID 0ahea04o1lki07l58lonidaeapgooglecom
2019.04.09 10:15:02 1: Kalender 15 16
2019.04.09 10:15:02 1: Kalender aktuell 13 11
2019.04.09 10:15:02 1: Temperatur Kinderzimmer 16

Und da sieht man meines Erachtens schon das Problem:

In dem Moment, wo der Termin gerade beendet wird, also das Notify triggert, wird, wenn man from=0 verwendet nicht der gerade beendete Termin ausgelesen, sondern bereits der Nächste!

Also habe ich weiter experimentiert:

Der Serientermin (begonnen letzten Dienstag mit dem Betreff "13 11" wurde für heute geändert auf "a b" und für nachsten Dienstag auf "c d".

Das Notify geändert auf from=-10s. Und jetzt kommt das Log

Code Auswählen Erweitern

2019.04.09 10:41:02 1: UID 0ahea04o1lki07l58lonidaeapgooglecom
2019.04.09 10:41:02 1: Kalender a b
2019.04.09 10:41:02 1: Kalender aktuell a b

Es scheint also zu funktionieren, es wird tatsächlich der Betreff des gerade beendeten Termins angezeigt. Aber noch ein zweiter Punkt ist erstaunlich:

Läßt man den Parameter "from" weg wird auch der richtige Betreff angezeigt - das steht im Widerspruch zu Deinen Aussagen über das angebliche AUslesen veralteter Daten!

Hast Du dazu eine Erklärung?

Viele Grüße

Markus

[Otto123]

Hallo Markus,

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.

Das 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

[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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[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?

Code Auswählen Erweitern

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]

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

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

[juelich]

Super - gemeinsam sind wir stark 

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