Probleme nach Update von Calendar-Modul?

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

Vorheriges Thema - Nächstes Thema

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

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.


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

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. 
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

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.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

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

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:

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

#8
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.
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
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

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

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:

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:

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:

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/
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!