Moin,
wie ist denn die Best-Practice für 1 Wandthermostat, 1 Thermostat und 2 Fensterkontakte?
Ich habe aktuell beide Kontakte mit RT und Wandthermostat peered und das Wandthermostat mit dem Thermostat.
Nun wo es mal kälter wird hatte ich den Fall das beide Fenster open waren, WT sagt 5°C Soll-Temp und RT versucht die 16°C zu halten. Irgendwie hat der RT sein Programm trotz offenem Fenster weiter gefahren (16°C wäre laut Wochenprogramm dran und 5°C bei Fenster offen).
Nun lass ich im HM Forum das man am besten alle Direktverknüpfungen löscht und die CCU2 Gruppen Funktion nutzt. Dann nur noch das virt. Device bedienen oder die phys. Geräte aber keine Einstellungen an den Aktoren selbst in der CCU. Kann das jemand bestätigen?
Ich kann das bestätigen. Ich nutze die virtuellen Gerätegruppen der CCU in allen Räumen. Die größte Gruppe besteht aus:
- 2x Heizkörperthermostat
- 3x Fensterkontakt
- 1 x Wandthermostat
Das Wandthermostat muss m.W. zwingend in der Gruppe sein, damit es funktioniert. Um die ganzen Peerings kümmert sich die CCU. Die Steuerung kann dann entweder über das Gruppendevice oder das Wandthermostat erfolgen (das ist der Master der Gruppe). Auch die Wochenprogramme des Wandthermostats sind maßgebend. Eingestellt werden sie ebenfalls im Gruppendevice oder dem Wandthermostat.
Hier meine Konfiguration (Namen der Geräte in der CCU!):
- Gruppendevice = G-GZ-HZ
- Heizkörper Thermostate = KL-GZ-HZ-1,KL-GZ-HZ-2
- Wandthermostat = KL-GZ-TH
Hinweis: Die 3 Fensterkontakte müssen im Define nicht angegeben werden, da der Fensterstatus über den Datenpunkt WINDOW_OPEN_REPORTING des Wandthermostats angezeigt wird. Möchte man genau wissen, welches Fenster offen ist, müssen die Fenster-Devices noch beim Define angehängt und das Attribut ccureadingfilter erweitert werden.
Übrigens: Für Gruppen sind Defualt-Settings (set defaults) vorhanden.
define HM_G_GZ_HZ HMCCUDEV G-GZ-HZ group=KL-GZ-HZ-1,KL-GZ-HZ-2,KL-GZ-TH
attr HM_G_GZ_HZ IODev d_ccu
attr HM_G_GZ_HZ ccucalculate dewpoint:DEWPOINT:1.TEMPERATURE,1.HUMIDITY
attr HM_G_GZ_HZ ccureadingfilter (^SET_TEMPERATURE|^TEMPERATURE|^HUMIDITY|^VALVE|^CONTROL|^WINDOW_OPEN)
attr HM_G_GZ_HZ cmdIcon Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
attr HM_G_GZ_HZ controldatapoint 1.SET_TEMPERATURE
attr HM_G_GZ_HZ event-on-change-reading .*
attr HM_G_GZ_HZ eventMap /datapoint 1.MANU_MODE 20.0:Manu/datapoint 1.AUTO_MODE 1:Auto/datapoint 1.BOOST_MODE 1:Boost/datapoint 1.MANU_MODE 4.5:off/datapoint 1.MANU_MODE 30.5:on/
attr HM_G_GZ_HZ stateFormat T: KL-GZ-TH.1.TEMPERATURE° H: KL-GZ-TH.1.HUMIDITY% D: KL-GZ-TH.2.SET_TEMPERATURE° P: DEWPOINT° V: KL-GZ-HZ-1.4.VALVE_STATE% G-GZ-HZ.1.CONTROL_MODE
attr HM_G_GZ_HZ statedatapoint 1.SET_TEMPERATURE
attr HM_G_GZ_HZ stripnumber 1
attr HM_G_GZ_HZ substitute CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;;WINDOW_OPEN_REPORTING!(true|1):open,(false|0):closed
attr HM_G_GZ_HZ webCmd control:Auto:Manu:Boost:on:off
attr HM_G_GZ_HZ widgetOverride control:slider,4.5,0.5,30.5,1
Zu beachten ist auch, dass das Format für Readingnames bei Gruppen per Default 'name' ist, d.h. es wird der Gerätename in den Readingname übernommen. Das ist notwendig, um wie im Beispiel mehrere Thermostate voneinander unterscheiden zu können.
Aber was passiert wenn der FHEM Server mal für längere Zeit ausfällt...?
Besser wäre doch, wenn die Heizung autark auch noch funktionieren würde, oder..?
Ich habe den gleichen Aufbau wie der Threadersteller und habe bisher keine Probleme damit, allerdings ist es interessant, was tatsächlich am besten ist.
Grüße Marcel
Tapatalk iPhone, daher kurz gehalten.
Wenn das Ganze in der CCU angelegt ist, funktioniert die Steuerung bei einem Ausfall auch manuell über das Wandthermostat. Ist das auch kaputt, muss man eben die Heizkörperthermostate manuell bedienen.
Insofern sehe ich da kein Problem.
Ah ok, ich dachte es geht hier um die CCU mittels FHEM...
Klar wenn eine CCU vorhanden ist läuft es über diese...
Grüße Marcel
Tapatalk iPhone, daher kurz gehalten.
Ich habe jetzt mal 2 Gruppen erstellt (je 1 WT, 2 RTs und 2 SCO). Hatte es gestern nämlich wieder das die Fenster offen waren und der RT trotzdem 16°C statt 5°C fuhr. Hatte noch überlegt ob es mit der Windows Open erkennung zusammen hängen könnte da diese auch aktiv steht und ja nach 15 Minuten wieder auf 16°C geht. Diese sollte ja aber bei peered Fensterkontakten die open sind eigentlich nicht greifen oder)
Ich kapiers gerade nicht: diesen Fehler hast Du in FHeM oder mit den Gruppen in der CCU?
FHEM spielt kein Rolle. Ich hatte zu dem Zeitpunkt noch die Sensoren, RTs und Wandthermostat per Hand verknüpft gehabt. Windows open Meldungen am RT und Wandthermostat kamen, die Absenktemp wurde gesetzt. Nach einer Weile ging dann aber der RT auf die 16°C zurück. Ich denke hier hat die WindowOpenerkennung reingehauen das die ja stumpf nach 15 Minuten das Fenster quasie wieder zu macht
Die Temperatursturzerkennung greift nur, wenn sich kein Fensterkontakt in der Gruppe befindet. Sobald einer drin ist, bleibt die Absenktemperatur stehen, solange das Fenster offen ist.
Wenn kein Kontakt zur Gruppe gehört, muss man das Temperatursturzverhalten in den Geräteeinstellungen zur Gruppe einstellen.
In der Gruppe scheint das auch zu funktionieren, vorher mit Direktvverknüpfungen ohne Gruppen nicht