HM-TC-IT-WM-W-EU Vs. HM-Sec-SC-2: Absenktemperatur wird beibehalten

Begonnen von peterk_de, 20 Januar 2016, 20:10:53

Vorheriges Thema - Nächstes Thema

peterk_de

Liebes Forum,

ich habe einen weiteren Raum mit einem HM-TC-IT-WM-W-EU ausgestattet und (nach 3 so ausgestatten und super funktionierenden anderen Räumen) erstmals Probleme:

Mache ich den letzten noch offenen Fensterkontakt wieder zu, verschwindet zwar sowohl im RT-DN als auch im TC-IT sofort das Fenster-offen-Symbol. Aber die Fenster-Offen-Temperatur (5.0) bleibt und geht nicht wieder hoch - sie steht danach bei TC-IT UND RT_DN auf 5.0 Grad.

Das ganze passiert aber erst, wenn zwischen Öffnen und Schließen des Fensters einige Minuten lagen (m.a.W. der Wandthermostat wohl mindestens einmal seine Werte an den HK-Thermostaten übermittelt hat) Bei dieser Übermittlung selbst bleibt das Fenstersymbol aber bei beiden zu sehen!

Schließt man das letzte Fenster sehr schnell wieder - sagen wir, nach 30s - klappt alles wie es soll.


Genauere Beschreibung des Setups:


  • Zuvor hingen die 2 TFK (1x HM-Sec-SC mit FW2.1, 1xHM-Sec-SC-2 mit FW2.4) direkt am RT-DN, Alles funktionierte einwandfrei. Jetzt hängt der TC-IT mit dazwischen und das Problem tritt auf.
  • Mit dem TC-IT habe ich die TFKs gepeert gelassen und zusätzlich mit dem HM-TC-IT-WM-W-EU gepeert (für schnelle Fenstererkennung + hohen WAF-Faktor).
  • Peerneedsburst ist gesetzt.
  • _Climate Channels sind auch korrekt verbunden, Änderungen der Solltemp direkt am Gerät wird korrekt an das jeweils andere weitergegeben;
  • FHEM kann Temperatur beim Wandthermostaten ebenfalls setzen.

Lösungsversuche:


  • FW-Update des RT-DN und des TC-IT auf die aktuellen Versionen brachte keine Änderung.
  • Unpairen und danach neues Pairing von Wand- und HK-Thermostat brachte nichts.
  • Vollständiges unpeeren und danach neues peeren der TFKs (beider Fensterkontakte an beiden Thermostaten) brachte nichts

Auffällig: Beim TC-IT ist auch nach dem neuen Pairen kein getConfig auf den Channel _Climate möglich - CMDs_done_Errors:1 - bei allen anderen Channels läuft es mit CMDs_done durch.


Bevor ich hier genaue Logs und Listings reinkippe ;-) hat vllt schon jemand eine Idee, was ich noch versuchen kann? Mir scheint als hat der Wandthermostat ne Macke, ich habe zumindest nix wissenstlich anders gemacht als in den anderen Räumen ...
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

peterk_de

OK ich bin der Sache auf die Schliche gekommen und halte es mal für die Nachwelt fest: Die Temperatur wird wieder erhöht - allerdings erst nach dem nächsten Sendeintervall des TC-IT. Ich war einfach zu ungeduldig.

Eigentlich ist es aus Homematic-Sicht auch ganz logisch. Angenommen die aktuelle desired-temp ist 20 Grad und die Fenster-offen-temp ist 5 Grad:


  • Das Fenster wird geöffnet. Durch peerNeedsBurst gehen sowohl Wandthermostast als auch HK-Thermostat binnen Sekunden auf 5 Grad und zeigen "Fenster offen" im Display. WAF ist damit zu 100% gegeben.
  • Wird das Fenster jetzt gleich wieder geschlossen, hat der HK-Thermostat seine "eigentliche" desired-temp von 20 Grad noch gespeichert und nimmt diese dank Burst des Fensterkontaktes sofort wieder an. Beide stehen sofort nach dem Schließen wieder auf 20 Grad - alles ist gut.
  • Ist das Fenster noch geöffnet, überträgt nach einer Weile der Wandthermostat seine aktuelle desired-temp regulär an den Heizkörper. Problem: Er sendet natürlich die 5-Grad-Fenster-offen-Temperatur! Der Heizkörper nimmt diese als neue "richtige" desired-temp bei geschlossenem Fenster entgegen und speichert sie weg. Das fenster-Offen-Symbol zeigt der HK weiter an -- alles noch gut.
  • Wird das Fenster jetzt erst wieder geschlossen, verschwindet im HK-Thermostat dank Burst des Fensterkontaktes das Fenster-Offen-Symbol zwar sofort. Er geht aber gleichzeitig auf die 5 Grad desired-temp, die er zwischendurch vom Wandthermostaten bekommen hat! Der WAF ist futsch. Ich bekomme ein Anruf auf Arbeit.
  • Nach ein paar Minuten erst kommt dann die "richtige" desired-temp von 20 Grad beim HK an. Ab dann stimmt wieder alles.

Leider ist das also genauso suboptimal, wie die Fensterkontakte gar nicht mit dem HK zu peeren. Man muss halt drauf vertrauen, dass der HK "in 5 minuten wieder angeht", statt es ggf. gleich prüfen zu können. Und das tun hier nicht alle Bewohner ;-) Daher wird das jetzt einfach peer Notify und FHEM gelöst ...
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

frank

und wie wäre es, wenn du nur den hk mit dem fk peerst? überschreibt dann eine routinemässige desired-temp des wt von 20 grad eine gerade durch ein geöffnetes fenster eingestellte temp von 5 grad?
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

peterk_de

#3
Zitat von: frank am 21 Januar 2016, 20:01:10
und wie wäre es, wenn du nur den hk mit dem fk peerst? überschreibt dann eine routinemässige desired-temp des wt von 20 grad eine gerade durch ein geöffnetes fenster eingestellte temp von 5 grad?

Genau so ist es, das geht daher noch weniger. Was ich bis vor kurzem - für über ein Jahr - hatte, war nur den Weather-Channel zu peeren, u.A. weil ich im Forum von den ganzen Problemen las. Dann kann man den Raumthermostaten zwar nur als Thermometer mit LC-Display benutzen, aber es läuft doch sehr viel reibungsfreier als mit dem kompletten Dreiergespann, weil alles wirklich sehr flott reagiert.

Mit dem Auto-Korrektur-Notify flutscht es jetzt allerdings wieder richtig gut. Nur die Funklast ist natürlich erhöht.

Edit: @Frank nee das geht tatsächlich nicht. Dann steht Fenster offen und 20 Grad im HK-Display.
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...