HM-CC-TC nimmt desired temp nicht, wenn im Auto Mode

Begonnen von Freibeuter, 23 Februar 2015, 16:23:46

Vorheriges Thema - Nächstes Thema

Freibeuter

Hallo zusammen,
einer der 4   HM-CC-TC hat ein Eigenleben entwickelt.
Alle  HM-CC-TC laufen bei mir für gewöhnlich im controlMode Auto und werden z.b. beim Verlassen der Wohnung mit einem set desired-temp überschrieben.
Das lief auch ca 1 Jahr gut so.
Jetzt weigert sich ein  HM-CC-TC im Auto Mode Kommandos entgegen zu nehmen.
Auf set desired-temp kommt ein Cmd Done und 4 Sek. später springt er wieder auf die vorherige Temp.
Wenn ich Ihn auf Manual stelle nimmt der set desired-temp problemlos entgegen.
Für mich sie es so aus, als wenn der Zeitplan jetzt Vorrang hat?
Jemand eine Idee?



Trebxson

Habe ich auch schon festgestellt. Es spielt dabei auch keine Rolle ob Soll durch Stellrad oder durch FHEM eingestellt wird.
Eine Zeit lang war ich froh, dass zum Zeitpunkt x aus dem Zeitplan die Temperatur zurück gestellt wird (Temperatur temporär hochstellen und Stellrad "denkt" für mich ans zurück stellen :)). Aber in letzter Zeit ist es kaum noch möglich eine Temperatur im Auto-Modus vorzugeben.

Inzwischen geht das Problem soweit, dass ich nach dem Einstellen der desired-temp diese per Perl-Funktion in den Zeitplan aufnehme. Ob das dauerhaft funktioniert + praxistauglich ist teste ich momentan noch aus :)
FHEM auf NUC (NUC5i5MYBE) Lüfterlos (Akasa) bei ~10 W mit Abschaltung bei Nichtanwesenheit + Wake on Pattern Match mit EEE im Sommer.
Heizungssteuerung mit Homematic über FHEM im Winter.
Wassersäule mit Pumpe, WaKü-Technik, Luftsprudel, Wasserstrudel, RGB-Lichtorgel mit Homematic und ZWave.

Freibeuter

Gestern Abend habe ich den TC per Menü, RES zurückgesetzt.
Dann in fhem gelöscht und neu mit fhem und dem VF neu gepaird.

Danach die alte fhem.cfg wieder eingespielt und die Reg neu gesetzt ( burst Mode, Night temp und templists).
Danach lief wieder alles problemlos, wie vorher und bei den anderen TC.

Leider zu früh gefreut, heute Morgen dann wieder Befehlsverweigerung im Auto Modus :-(


Brockmann

Ich weiß, es ist ein Schuss ins Blaue (aber das Problem klingt ja auch recht sonderbar):
Vielleicht mal frische Batterien ins Gerät stecken? Die Teile verhalten sich manchmal sonderbar, wenn die Batterien nachlassen.

Trebxson

Sind das bei dir immer 4s? Ich warte manchmal Minuten über Stunden und weiß nicht ob der Fehler diesmal nicht doch ausbleibt... Manchmal auch nach Sekunden, manchmal kommt nach weiteren Sekunden die Auswahl doch an. Schwierig...

Batterieoption ist gemerkt ;)
FHEM auf NUC (NUC5i5MYBE) Lüfterlos (Akasa) bei ~10 W mit Abschaltung bei Nichtanwesenheit + Wake on Pattern Match mit EEE im Sommer.
Heizungssteuerung mit Homematic über FHEM im Winter.
Wassersäule mit Pumpe, WaKü-Technik, Luftsprudel, Wasserstrudel, RGB-Lichtorgel mit Homematic und ZWave.

Freibeuter

Die 4 Sek sind bei mir stabil, habe aber auch burstRx auf On.
Batterie messe ich heute Abend.


Trebxson

#6
Spannend.

Ich habe gerade ein Problem im Zusammenhang mit der Übertragung anderer Werte ausmachen, jedoch nicht verifizieren können.

  • am Regler 22.0 gestellt, kurz danach set ..._Clima regSet valveMaxPos 60 -> Regler steht wieder auf 16°C.
  • am Regler 22.0 gestellt, kurz danach getConfig: FHEM zeigt 22.0, danach set ..._Clima regSet valveMaxPos 61 -> Regler steht wieder auf 16°C + FHEM zeigt noch 22°C - alsbald 16°C
  • am Regler 22.0 gestellt, kurz danach getConfig: FHEM zeigt 22.0, danach set ..._Clima regSet valveMaxPos 62 -> Regler bleibt auf 22°C :( (wollte nun nochmal getConfig abschicken)

    Nach einigen (20) Minuten steht nach dem Senden weiterer valveMaxPos der Regler erneut bei 16°C. Es sieht aus als wenn der HM-CC-RT-DN nach der Änderung seiner Register irgendeine Art Grundkonfiguration wiederherstellt. Das war mir auch schon mit dem Homematic Konfigurator aufgefallen.

    Wenn sich bei dir die 4 s exakt rekonstruieren lassen, haben wir wohl jeder ein anderes Problem? Tritt das Problem bei dir auch auf, wenn du am Stellrad drehst?
FHEM auf NUC (NUC5i5MYBE) Lüfterlos (Akasa) bei ~10 W mit Abschaltung bei Nichtanwesenheit + Wake on Pattern Match mit EEE im Sommer.
Heizungssteuerung mit Homematic über FHEM im Winter.
Wassersäule mit Pumpe, WaKü-Technik, Luftsprudel, Wasserstrudel, RGB-Lichtorgel mit Homematic und ZWave.

frank

ZitatWenn sich bei dir die 4 s exakt rekonstruieren lassen, haben wir wohl jeder ein anderes Problem?
sind auch völlig verschiedene geräte.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Trebxson

Oh man. Na immerhin hat die Fehlerdiagnose mir geholfen. Vlt. nützt es dem TC-Kandidaten auch geringfügig.
FHEM auf NUC (NUC5i5MYBE) Lüfterlos (Akasa) bei ~10 W mit Abschaltung bei Nichtanwesenheit + Wake on Pattern Match mit EEE im Sommer.
Heizungssteuerung mit Homematic über FHEM im Winter.
Wassersäule mit Pumpe, WaKü-Technik, Luftsprudel, Wasserstrudel, RGB-Lichtorgel mit Homematic und ZWave.

Freibeuter

Gestern habe ich die Batterien gemessen, beide 1,48 V.
Dennoch habe ich sie gegen die von einem gut funktionierenden TC getauscht und siehe da,
Das Problem ist bisher nicht wieder aufgetreten.
Bei dem anderen TC der jetzt die 1,48V Batterien hat läuft es auch noch normal.
Verrückter Fehler :-(