Dreiecksbeziehung Fenstersensor, Wandthermostat, HM-CC-RT-DN

Begonnen von Louis Cypher, 17 November 2019, 17:17:34

Vorheriges Thema - Nächstes Thema

Louis Cypher

Liebes Forum,

ich bastle schon den ganzen Nachmittag an meiner Lösung für das Badezimmer, so ganz verstanden habe ich aber die Hintergründe noch nicht.

Setup:

  • Fensterkontakt HM-Sec-SC
  • HM Wandthermostat (WT)
  • HM-CC-RT Heizkörperthermostat (HT)

Das ganze Setup hat bis dato ohne den WT wunderbar funktioniert, jetzt habe ich es auf den Wandthermostat umgebaut. Leider verstehe ich den "Signalweg" für den Fensterkontakt (FK) nicht.

Der WT ist ja auf den Kanälen Climate und Wheather mit dem HT gepeert. Wie diese Signale laufen ist mir klar.

Nun ist ja der FK mit dem Wandthermostat gepeered, der HT aber nicht. Also muss der FK an den WT den Fensterzustand schicken (funktioniert auch), der WT schickt dann ein Kommando an den HT. Da der WT nur mit dem Climate Channel gepeered ist kann er das nur auf diesem Kanal. Ist das richtig so?

Damit der Heizkörper auch gleich ausgeschaltet wird muss ja ein "peerNeedsBurst" für den Weg vom FK zum WT gesetzt werden. Wie erreiche ich nun, dass das Kommando auch schnell genug beim HT landet? Muss ich dazu noch ein
set HT_Climate regSet peerNeedsBurst on WT_WindowRec
oder dergleichen absetzen? Wo in diesem Kommando muss die Quelle und das Ziel stehen?

Vielen Dank schon im Voraus

MadMax-FHEM

Warum schnell genug!?

Also ich habe folgendes Setup (und das reicht [mir]):

WT_Climate -> HT_Climate
WT_Weather -> HT_Weather

Somit kommt die IST-Temp (Weather) vom WT und auch die SOLL-Temp (Wochenprofil bei auto bzw. was man halt so dreht bei manu) ebenfalls vom WT...

WT_Windowrec -> Fensterkontakt

Wenn das Fenster auf geht, dann bekommt das das WT "sofort" mit und schickt dann eben bei der nächsten SOLL-Vorgabe statt der eingestellten (Drehrad/Wochenprogramm) die WinOpenTemp...
...ja kann bis zu 3min dauern aber das ist für mich ausreichend.

Wenn du schneller willst:

HT ebenfalls direkt mit dem FK peeren. Dann geht die Meldung auch sofort an den HT (dazu wird dann autom. peerneedsburst aktiviert: geht halt auf die Batterielebensdauer [theoretisch, praktisch konnte ich das noch nicht wirklich feststellen])

oder

Event vom FK abfangen und dann direkt neue Vorgabe an den HT (ebenfalls peerneedsburst).
Habe ich an einigen Stellen wo ich etwas Einfluss nehmen will auf die ganze Fenstergeschichte...
...und dort wo ich keinen WT habe...


Ob ein aktiviertes peerneedsburst beim HT auch dazu führt, dass es in deiner Konfiguration schneller geht: keine Ahnung (könnte/sollte / geht aber [theoretisch] auf die Batterielebensdauer)...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Hollo

Wenn ich mich richtig erinnere, habe ich den Fensterkontakt seinerzeit mit dem Heizkörperthermostat UND dem Wandthermostat gepeert.
Grund war (meine ich) wohl, dass die beiden auch das Fenster richtig mitbekommen.

Ich nutze den Wandthermostat nur für die Messung der IST-Temperatur und Luftfeuchtigkeit.

FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"