partyMode setzt Sytemzeit bei at-Befehl!?

[USTA70]

Hallo, habe folgendes Problem. In Abhängigkeit des Schichtplans meiner Frau setzte ich per at-Befehl in einigen Räumen für die Zeit der Abwesenheit an den jeweiligen HM-CC-TC's die Temperatur mittels partyMode herab. Leider wird jedoch nicht die gewünschte Endzeit (im Beispiel 14:00 Uhr) gesetzt sondern die at-Zeit!?

if (($Kalendertext =~ /Frühdienst/) && ($wday < 6)) {
fhem("define at.Diele at 09:01:00 set Diele_Thermostat_Climate partyMode 14:00 0");
...

Mache ich wie so häufig etwas falsch oder ist hier ein Bug versteckt?

Dank + Grüsse
      Uli

Sent from my iPad using Tapatalk HD

[martinp876]

die "Party" soll also von 09:01:00 bis 14:00 stattfinden.
funktioniert
set Diele_Thermostat_Climate partyMode 14:00 0
und geht es nur beim "at" schief?
kannst du nach dem Setzen die Register
partyEndHr
partyEndMin
partyEndDay
ansehen (falls vorhanden)
und ggf einmal das set loggen? Auch ohne "at" falls der Fehler immer beim setzen auftritt

Gruss Martin

[USTA70]

Hallo Martin,

im Anhang findest Du die Readings zum heutigen Tag. Die Reaktion des TC war wie zuvor beschrieben. Im Display ist das Koffersymbol sichtbar. Die Ventile sind zugefahren, bleiben jedoch dann dauerhaft zu, weil als Partyendzeit 9:01 im TC gesetzt ist, da die beim Setzten ja bereits vorbei ist.

Ein manueller Set-Befehl über die Eingabe oder im FHEM Pulldown-Menü funktioniert problemlos.

Das der at-Befehl aus myUtils gesetzt wird ist doch zulässig, oder?
Ist es eigentlich notwendig vor dem Setzten ein getConfig auszuführen?

Das Loggen steht noch aus, welche Level soll ich wählen?

Dank und Grüsse
    Uli


Sent from my iPad using Tapatalk HD

[martinp876]

Hi Uli,

wenn ich beim CC-TC Partymode einschalte mit einem Zeitstempel der schon vorbei ist schaltet der TC automatisch nach ein paar minuten zurück.

kannst du einmal die rohmessages des TC mitloggen? Einfach die ID in logIDs des HMLAN eintragen.
Zeiten in der vergangenheit werde ich verbieten... auch wenn es eigentlich automatisch revidiert wird

Gruss Martin

[USTA70]

... kannst du einmal die rohmessages des TC mitloggen? Einfach die ID in logIDs des HMLAN eintragen....

So einfach ist das für mich leider nicht, was muss ich genau machen?

Grüsse Uli

[martinp876]

Hallo Uli,

nun
attr global mseclog 1
attr <hmlan> <IDdesDevice>

also z.B.
attr HMLAN1 123456

Gruss Martin

[USTA70]

Hallo Martin,

so, heute komme ich endlich dazu das Logfile-Auszug zu liefern. (siehe Anhang).
Dieser enthält Log-Einträge für die 3 TC`s, die über den at-Befehl wie folgt in den PartyMode gesetzt werden: 

if (($Kalendertext =~ /Frühdienst/) && ($wday < 6)) {
fhem("set LED16_Frueh_Spaetschicht led green");
fhem("define at.Diele at 06:01:00 set Diele_Thermostat_Climate partyMode 14:00 0");
fhem("define at.Kueche at 06:02:00 set Kuechen_Thermostat_Climate partyMode 14:00 0");
fhem("define at.WoZi at 06:03:00 set WoZi_Thermostat_Climate partyMode 14:00 0");
};

Die ID`s lauten wie folgt:
HMLAN=1C67FA
TC_Diele=1BF985
TC_Kueche=1BFA23
TC_WoZi=1BFA8D

Im aktuellen Fall haben sich alle drei TC so verhalten, wie Anfangs beschrieben . Allerdings muss ich meine Beobachtung etwas korrigieren. Ich hatte ja geschrieben, dass anscheinend die at-Schaltzeit als PartMode Endzeit gesetzt wird. Dem ist jedoch nicht ganz so. Es bleibt zwar dauerhaft die Schaltzeit im TC Display sichtbar (siehe jpg), jedoch blickt das Trennzeichen ":" im sekundentakt. Es scheint also, als würde die Systemzeit des TC gewissermaßen "einfrieren"!? Somit ist dann auch "klar", dass die TC's nach Abflauf der PartyMode Zeit (hier 14:00) nicht in den Auto-Modus zurückschalten.

Übrigens verhalten sich die TC nicht immer so, bei Versuchen den PartyMode aus der Kommandozeile heraus zu setzten konnte ich Gleiches bisher nicht reproduzieren.

Nun hoffe ich, dass Du eine Idee hast.

Dank + Grüße
   Uli

[martinp876]

Es ist so (schon lange her...) das wenn man den Partymode setzt hier die Uhrzeit irgendwie einfriert. Um das zu beheben schickt FHEM ein sysTime hinterher - dann kann man die Zeit wieder lesen
Was intern passiert und ob es operational Folgen hat, so man es nicht tut ist mir nicht klar - scheint aber so zu sein.
Schlecht (HM) ist, dass das setzen der Zeit grundsätzlich vom TC nicht quittiert wird. Somit kann ich nicht garantieren, dass es auch funktioniert hat. Und hier, denke ich, liegt das Problem.

Zum Testen kannst du ein sysTime kurz nach dem setzen des Partymode senden. Um sicher zu sein in einem Abstand von min 3min, da mit es in einem neuen "Zeitschlitz" gesendet wird.

Ich werden entsprechend nachdenken, wie ich so etwas implementiere.

Mit at hat es voraussichtlich nichts zu tun... ich denke das ist Zufall.

[USTA70]

...vielen Dank, ich werde es testen. Wäre ja prima, wenn das Problem so zu lösen wäre.

Nochmals Dank und Grüsse
    Uli

[USTA70]

Hallo Martin,

ich habe es nun mit dem Setzten der sysTime probiert. Es sah zunächst so aus, als würde das Problem beseitigt sein. Heute fand ich jedoch an allen Thermostaten die eingefrorene sysTime 9:05 vor, also die Zeit zu der ich die sysTime per at setzte (siehe Code). Hast du vielleicht noch eine Idee das Problem verlässlicher zu beseitigen!?

Grüsse Uli

if (($Kalendertext =~ /Frühdienst/) && ($wday < 6)) {
fhem("set LED16_Frueh_Spaetschicht led green");
fhem("define at.Bad at 09:00:00 set Bad_Thermostat_Climate partyMode 14:00 0");
fhem("define at.Diele at 09:00:00 set Diele_Thermostat_Climate partyMode 14:00 0");
fhem("define at.Kueche at 09:00:00 set Kuechen_Thermostat_Climate partyMode 14:00 0");
fhem("define at.WoZi at 09:00:00 set WoZi_Thermostat_Climate partyMode 14:00 0");
fhem("define at.sysTime at 09:05:00 set .*_Thermostat sysTime");
};

[martinp876]

hast du dann einmal manuell ein set sysTime gemacht?
Kannst du einmal rohmessages aufzeichnen?
Ich habe es manuel nachgestellt - das Funktioniert (ohne "at"). Somit sind die messages interessant.
Sicher auch zu beachten: Sind irgendwelche Protokoll-fehler aufgetreten?