Probleme bei Google-Steuerung für HM-CC-RT-DN

[juelich]

Hallo,

ich habe seit zwei Wochen eine Heizungssteuerung per Google für meine  HM-CC-RT-DN aktiv.
Das funktioniert auch einwandfrei, die Heizung wird wie gewünscht gesteuert, jedoch habe ich jede Stunde Fehler im Log, die ich mir nicht erklären kann.
Vielleicht könnt Ihr mir ja helfen:

Zum Procedere - ich verwende für jeden Raum einen eigenen Kalender. In diesem Sind die Schaltzeiten als Termin mit den gewünschten Temperaturen im Betreff eingetragen.
Als Besipiel Kalender_Kueche Termin von 19:00 bis 20:30 Uhr - Betreff: "21 17", d.h. um 19 Uhr soll die Küche auf 21 Uhr geheizt werden und um 20:30 Uhr soll auf 17 Grad abgesenkt werden.

Ich verwende dazu zwei Notifys:

Code Auswählen Erweitern

define HZ.Kueche_an notify Kalender_Kueche:modeStarted.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($dtemp,undef)= split(/ /,fhem("get Kalender_Kueche summary $uid")); { fhem("set hz.kueche desired-temp $dtemp"); } } und

Code Auswählen Erweitern

define HZ.Kueche_aus notify Kalender_Kueche:modeEnded.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my (undef,$dtemp)= split(/ /,fhem("get Kalender_Kueche summary $uid")); { fhem("set hz.kueche desired-temp $dtemp"); } }.

Im Log findet man dann folgendes:

2013.11.04 20:24:07 3: set hz.bad desired-temp  : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:24:07 3: HZ.Bad_an return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:24:07 3: set hz.bad desired-temp  : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:24:07 3: HZ.Bad_aus return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:00 3: set hz.kueche desired-temp  : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:00 3: HZ.Kueche_an return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:00 3: get Kalender_Kueche summary xxx: 21 17
2013.11.04 20:30:00 2: CUL_HM set hz.kueche desired-temp 17
2013.11.04 20:30:00 3: set hz.kueche desired-temp  : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:00 3: HZ.Kueche_an return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:00 3: set hz.kueche desired-temp  : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:00 3: HZ.Kueche_aus return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:11 3: set hz.bad desired-temp  : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:11 3: HZ.Bad_an return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:11 3: set hz.bad desired-temp  : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 20:30:11 3: HZ.Bad_aus return value: desired-temp requires parameter: [on|off|5.0..30.0]

Wie man sieht wird die Temperatur wie gewünscht aus dem Kalender ausgelesen und an den Thermostaten übermittelt (das funktioniert auch!)
Trotzdem kommen ein Haufen Fehlermeldungen - sowohl nach einem Schaltvorgang als auch exakt 1x pro Stunde (ich nehme an, immer wenn der Google-Kalender aktualisiert wird).

Wo liegt das Problem? Es funktioniert doch alles?
Falls jemand einen Rat weiß - bitte posten

Viele Grüße

Markus

[rudolfkoenig]

Entweder liefert  get Kalender_Kueche summary $uid nicht zwei Woerter zurueck, oder ist die Temperaturspezifikation nur mit eine Nachkommastelle korrekt, also 21.0 statt 21.

[martinp876]

man kann "21" oder "21.0" verwenden- "21." ist nicht zulässig

sollte immer ein "." vorhanden sein kann man einfach eine "0" anhängen. Sprich es geht auch "21.00"

[betateilchen]

Ich komme mir grade vor wie im Kindergarten.

• Erst wird das Thema im Thread zum RT breitgetreten, obwohl es mit ziemlicher Sicherheit ein Calendar-Problem ist und kein Homematic Problem.
• Dann wird nach endloser Diskussion endlich das Thema im (für Calendar) richtigen Unterforum "Unterstützende Dienste" eröffnet.
• Und dann wird der Mist prompt wieder nach Homematic verschoben.

Der Fehler (von irgendwoher kommt alle Stunde ein "falscher" Befehl an den Thermostaten) kommt garantiert nicht aus Homematic, denn der RT weiss überhaupt nix vom Kalender.

Ich behaupte nach wie vor, dass der Fehler von der Kalenderverarbeitung kommt. Und damit sind wir hier wieder im falschen Bereich.

[LuckyDay]

Ich reich Dir mal ein Sandkasten Schäufele, vielleicht gehts dir dann besser

[Rohan]

Hallo Hary

...

... es lohnt nicht 

Nur gut, dass unser Beta kein Mod ist, sonst müssten wir hier alle immer erst gerade stehen 

Gruß
Thomas

[juelich]

Jetzt noch einmal eine Rückmeldung von mir. Ich habe mit dem Verschieben ja nichts zu tun, würde das Thema am liebsten trotzdem wieder ins HM-CC-RT-DN-Unterforum verschieben, auch wenn es Betateilchen nicht gefällt.
Ich habe nämlich den ganzen Abend gegrübelt, warum ich für Wohnzimmer, Bad und Küche dasselbe (an den jeweiligen Raum angepaßte) Notify verwende, der Fehler aber ausschließlich in Bad und Küche auftritt.
Der einzige Unterschied, der mir auffiel ist der, daß ich im Wohnzimmer 4 Thermostate habe, die ich über eine gemeinsame structure wz.heizung ansteuere; in Küche und Bad wird jeweils der Thermostat direkt angesteuert.
Um diese Theorie zu überprüfen habe ich auch für Küche und Bad jeweils eine structure bestehend aus jeweils nur einem Thermostaten definiert und diese statt den HM-CC-RT-DN direkt angesprochen:

Code Auswählen Erweitern

define hz.bads structure room hz.bad

das Notify wurde lediglich auf hz.bads geändert:

Code Auswählen Erweitern

defi9ne HZ.Bad_an notify Kalender_Bad:modeStarted.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($dtemp,undef)= split(/ /,fhem("get Kalender_Bad summary $uid")); { fhem("set hz.bads desired-temp $dtemp"); } }

Und was soll ich sagen? Die Fehlermeldungen sind weg!!! (Küche wurde um 18.10 geändert, deshalb davor noch die Meldungen)

2013.11.05 17:05:50 3: HZ.Kueche_an return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.05 17:05:50 3: set hz.kueche desired-temp  : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.05 17:05:50 3: HZ.Kueche_aus return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.05 17:30:00 3: get Kalender_Bad summary xxx: 24 17
2013.11.05 17:30:00 2: CUL_HM set hz.bad desired-temp 24
2013.11.05 18:05:50 3: set hz.kueche desired-temp  : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.05 18:05:50 3: HZ.Kueche_aus return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.05 18:15:00 3: get Kalender_Kueche summary yyy: 24 20
2013.11.05 18:15:00 2: CUL_HM set hz.kueche desired-temp 24

Damit ist für mich bewiesen, daß die Probleme NICHT von der Kalenderverwaltung herrühren und nicht an einem fehlerhaften Notify liegen, sondern doch direkt etwas mit der Ansprache des HM-CC-RT-DN zu tun haben, auch wenn es Dir nicht paßt und Du bestimmt gleich wieder rummaulst, Betateilchen.

Viele Grüße

Markus

[betateilchen]

Damit ist für mich bewiesen, daß die Probleme NICHT von der Kalenderverwaltung herrühren und nicht an einem fehlerhaften Notify liegen, sondern doch direkt etwas mit der Ansprache des HM-CC-RT-DN zu tun haben,

Wenn ich jetzt rummaule, dann nur deshalb, weil Du erst JETZT mit der Tatsache rausrückst, dass Du mit einer structure arbeitest. Also ist es WEDER ein Problem des RT, NOCH der Kalenderverarbeitung, sondern eine ganz andere Baustelle: structure und gehört somit auch nicht hier in den Homematic-Bereich.

Auch wenn diese Möglichkeit Deinen Denkhorizont übersteigen mag.

[LuckyDay]

@ betateilchen

Ich hätte dir auch noch ein Eimerchen passend zum Schäufelchen zu vergeben

Wenn ich jetzt rummaule, dann nur deshalb, weil Du erst JETZT mit der Tatsache rausrückst, dass Du mit einer structure arbeitest. Also ist es WEDER ein Problem des RT, NOCH der Kalenderverarbeitung, sondern eine ganz andere Baustelle: structure und gehört somit auch nicht hier in den Homematic-Bereich.

Auch wenn diese Möglichkeit Deinen Denkhorizont übersteigen mag.

Auch wenn diese Möglichkeit Deinen Denkhorizont übersteigen mag.

Muss das wirlich sein?

[juelich]

Also Betateilchen, vielleicht sollte man sich auch in einem Forum mal einen vernünftigen Umgangston angewöhnen.

Wenn Du, außer zu kritisieren, Dir vielleicht auch ein paar Beiträge VERNÜNFTIG durchlesen würdest, wüßtest Du, daß ich im Wohnzimmer mit structure arbeite, steht nur ein paar Beiträge über dem den Du als nervig bezeichnet hast!.

Und es ist auch keine Baustelle der structure - schließlich funktioniert dort alles! Was nicht ohne Fehlermeldung funktioniert ist das direkte Anprechen des RT (auch wenn die praktische Umsetzung hier wiederum funktioniert)

Es ist doch offensichtlich so, daß die Kommandos, die über das Notify direkt an den RT geschickt werden mit einer Fehlermeldung beantwort (und trotzdem ausgeführt!) werden, dasselbe Kommando über den Umweg einer structure an denselben RT geschickt nicht zu einer Fehlermeldung führt.

Das ist die Frage, die ich mir nicht beantworten kann - und bisher ja auch kein Erfahrener hier im Forum.

Viele Grüße

Markus Jülich

[betateilchen]

- ich spreche alle meine RT ausschließlich über notify an - und das ohne jegliche Fehlermeldung.
- ich spreche viele meiner RT über Calendar an (also auch wieder über notify) - und das ohne jegliche Fehlermeldung.

Code Auswählen Erweitern

2013.11.04 20:24:07 3: set hz.bad desired-temp  :

Hier wird ein set desired-temp OHNE Temperaturangabe abgesetzt. Und Du musst herausfinden, warum HZ.Bad_an (ich vermute, das ist ein notify) das tut. Irgendein Event muss dieses notify falsch triggern.

[juelich]

 So etwas hätte ich mir auch gedacht, weiß aber beim besten Willen nicht, wo das herkommt. Mein Notify ist doch aber nur eine Modifikation von dem von Dir veröffentlichten. Ich habe jetzt nichts weiter gemacht, als im Notify HZ.Bad_an den RT hz.bad durch die structure hz.bads zu ersetzen - und es kommen keine Fehlermeldungen mehr. Das ergibt doch keinen Sinn. Es sei denn, structure würde falsche Kommandos einfach ohne Fehlermeldung ignorieren.

Viele Grüße

Markus

[betateilchen]

Du musst einfach rausfinden, WARUM das Notify getriggert wird. Notfalls mal ein bisschen Logging in die Verarbeitung einbauen, um der Ursache auf die Spur zu kommen.

[juelich]

Hallo Betateilchen, im Prinzip könnten wir den Thread ja zumachen - schließlich funktioniert ja alles und das Log ist fehlerfrei. Aber es wurmt mich trotzdem, warum es nur mit dem structure Trick funktioniert.
Wenn es nicht zu sehr nervt, möchte ich deshalb nochmal Deinen Beitrag von September zitieren:

Ein Eintrag im Google-Kalender hat im Titel einfach den Reglername und die Solltemperatur für Beginn und Ende stehen, also z.B. "wz_Thermostat 22 16"

Im Beispiel wird die Temperatur zuerst auf 22 Grad eingestellt und am Ende des Zeitraums auf 16 Grad zurückgeregelt.

Dazu gibt es zwei notify, die entsprechend getriggert werden und die sich nur im split unterscheiden:

Code Auswählen Erweitern


Kalender_Heizung:modeStarted.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($actor,$dtemp,undef)= split(/ /,fhem("get Kalender_Heizung summary $uid")); if(defined $actor) { fhem("set $actor desired-temp $dtemp"); } }


Code Auswählen Erweitern


Kalender_Heizung:modeEnded.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($actor,undef,$dtemp) = split(/ /,fhem("get Kalender_Heizung summary $uid")); if(defined $actor) { fhem("set $actor desired-temp $dtemp"); } }


Ich habe das lediglich dahingehend abgeändert, dass ich den Reglernamen weggelassen habe, da ich für jeden Raum einen eigenen Kalender habe.
Dazu die Notifys

Code Auswählen Erweitern

define HZ.Kueche_an notify Kalender_Kueche:modeStarted.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($dtemp,undef)= split(/ /,fhem("get Kalender_Kueche summary $uid")); { fhem("set hz.kueche desired-temp $dtemp"); } }
und

Code Auswählen Erweitern

define HZ.Kueche_aus notify Kalender_Kueche:modeEnded.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my (undef,$dtemp)= split(/ /,fhem("get Kalender_Kueche summary $uid")); { fhem("set hz.kueche desired-temp $dtemp"); } }


Ich finde da keinen Fehler, vielleicht habe ich was übersehen?

Die Idee eines erweiterten Logs ist sicher gut, an welcher Stelle sollte ich da ansetzen und wie programmiere ich das?

Wie gesagt, es muss niemand antworten, es funktioniert alles. Aber vielleicht besteht ja doch Interesse dem Rätsel gemeinsam auf die Spur zu kommen und so eventuell zukünftige Fehler zu vermeiden.

Eine Anmerkung noch: wenn irgendetwas ungewollt das Notify Tragegurt - müßte es da nicht auch bei einem structure-Device einen Logeintrag geben? Die gewollt ausgelösten Notifys stehen jedenfalls drin.

Viele Grüße

Markus

[betateilchen]

ich hab ja grundsätzlich schon eine (sehr technische) Idee, warum das so passiert...

Versuch doch einfach mal, den Kalendereintrag so zu verwenden, wie von mir ursprünglich vorgeschlagen (mit Aktorname) und arbeite mit den beiden Original-notify.