Hallo zusammen,
bei den FHT gibt es die Möglichkeit
Wunschtemperatur
Absenktemperatur und
Temperatur bei Fenster auf
einzustellen.
Bei dem HM-CC-RT-DN gibt es auch diese Möglichkeiten. Bei der Installation habe ich aber ein Problem. Im Unterschied zu den FHT ist eine Temperaturerhöhung bei "Fenster auf" möglich.
Beispiel bei FHT:
Im Bad wird das Fenster um 7:50 Uhr geöffnet - die Temperatur wird von 22 auf 10 Grad abgesenkt.
Um 8:00 kommt von FHEM der Befehl die desired-temp von 22 Grad auf 18 Grad abzusenken - es passiert nichts, da Fenster auf.
Bei HM-CC-RT-DN geschieht (obwohl Fenster auf und die Raumtemperatur auf 10 Grad abgesenkt ist) die Einstellung von desired-temp auf 18 Grad.
Ist das so richtig? Gibt es einen Befehl, der diese Temperaturveränderung nicht zulässt, oder ist eine Steuerung nur über Dummy's möglich?
Gruß
laxmann
Hi,
ob das so richtig ist oder nicht kann ich dir nicht sagen, aber grundsätzlich ist das bei mir auch so.
Ich würde dieses ganze Temperaturgeregle aber nicht mit FHEM machen sondern innerhalb Homematic mit Temperaturlisten.
Dann wird die Temperatur auch nicht überschrieben falls das Fenster auf ist sondern greift erst wenn du das Fenster wieder schließt.
Grüße
Nils
Hallo Nils,
dann schau ich mal.
Gruß
laxmann
Guten Mittag,
ich habe mir deinen Vorschlag
ZitatIch würde dieses ganze Temperaturgeregle aber nicht mit FHEM machen sondern innerhalb Homematic mit Temperaturlisten.
angeschaut und dann in meiner Situation die Umsetzung vorgestellt.
Meine Frau kann bis zu drei unterschiedliche Dienstzeiten über sieben Tage haben und ich habe zwei unterschiedliche Dienstzeiten über fünf Tage. Mit allen Kombinationen, die möglich sind, komme ich auf 14 Wochenprogramme, die ich erstellen müsste. Bei täglich wechselnden Dienstzeiten müsste dann auch immer die entsprechende Temperaturliste auf die Thermostate übertragen werden, die dann auch eine entsprechende Funklast bedeuten.
Mein derzeitiges System habe ich mit FHT und Dummy's in DOIF-Verschachtelungen umgesetzt, die dann die entsprechenden Dienstzeiten berücksichtigen. Meine Idee wäre dann, in diesen DOIF-Verschachtelungen ein Dummy einzubauen, die bei offenem Fenster keine Veränderungen der "desired-temp" zulässt.
Oder gibt es für mein Problem eine bessere Lösung?
Gruß
laxmann
Ich habe eine Fensterauf Temperatur von 6 Grad. Wenn FHEM Manuell Temperaturen ändert, zum Beispiel ich komme nach Hause dann hat dieser Befehl immer einen Filter bei mir
set HeizungBadezimmer_Clima:FILTER=desired-temp!=6.0 desired-temp 19
So wird die Wunschtemperatur von 19 Grad nur eingestellt wenn desired-temp nicht 6.0 Grad ist.
Hallo CoolTux,
das ist zwar eine gute Idee, aber der aktuelle "desired-temp" wird nur in dem Moment eingestellt, wenn das Fenster geschlossen ist. Im nachhinein, wenn das Fenster geschlossen wird, nur der vorherige "desired-temp" eingestellt.
Das bedeutet:
Wenn das Fenster geöffnet ist, muss ich ein zweites mal "desired-temp" eingeben, nachdem das Fenster geschlossen worden ist.
Gruß
laxmann
Hallo zusammen,
ich hätte eine Idee, um eine "desired-temp"-Wert zu übergeben und anschließend wieder "winOpnTemp" einzustellen.
Dazu müsste ich aber meinen Fensterkontakt "HM-SEC-SCo" dazu bringen, einen aktuellen Fensterstatus (open/close) zu senden.
Ist dies möglich und wenn ja, wie?
Gruß
laxmann
ZitatDazu müsste ich aber meinen Fensterkontakt "HM-SEC-SCo" dazu bringen, einen aktuellen Fensterstatus (open/close) zu senden.
Was heisst für dich - aktuell?
Meine HM-SEC-SCo senden den aktuellen Status bei Betätigung (also sofort) oder je nachdem was in R-eventDlyTime eingestellt ist (ich hab auch einen HM-SEC-SCo der erst nach 30 Sekunden den Status meldet - das will ich aber auch so).
Für alles weitere wäre es hilfreicher (für die Helfer) wenn du genau beschreibst was du möchtest und ein list der beteiligten Devices einfügst (in Code-Tags) - und zwar für ALLE Devices die betroffen sind.
Hallo,
mir geht es darum, dass ich einen neuen "desired-temp" übergeben kann, obwohl das Fenster geöffnet ist und die "winOpnTemp" beibehalten wird.
Bei offenem Fenster erscheint
HM_3B0C2B_Clima T: 17.4 desired: 8.0 valve: 0Reading vom Fenster-Sensor
contact open (to vccu1) 2016-12-30 20:12:35Beim HM-CC-RT-DN erscheint dies
HM_3B0C2B_Clima T: 17.4 desired: 8.0 valve: 0Nun schicke ich den neuen "desired-temp" an den HM_3B0C2B_Clima bei offenem Fenster
HM_3B0C2B_Clima set_desired-temp 18.0im Log erscheint
2016.12.30 20:23:02.823 3: CUL_HM set HM_3B0C2B_Clima desired-temp 18.0Nachdem ich das Fenster geschlossen habe, wird der alte "desired-temp"-Wert wieder eingestellt
HM_3B0C2B_Clima T: 17.5 desired: 10.0 valve: 0obwohl ich 18.0Grad eingestellt habe.
Im Unterschied zum FHT, das Temperaturveränderungen bei Fenster "Auf" annimmt, um anschließend bei geschossenen Fenster den den neuen "desired-temp" annimmt, erfolgt das bei dem HM-CC-RT-DN nicht. Fenster zu - alter desired-Temp.
Was mir aber auffällt:
Es ändert sich nicht mehr die Temperatur bei "Window open", das ich oben beschrieben habe. Diese wird nun eingehalten.
ZitatFür alles weitere wäre es hilfreicher (für die Helfer) wenn du genau beschreibst was du möchtest
Ich möchte die "desired-temp" verändern, wenn das Fenster wieder geschlossen wird.
z.B. Vor dem öffnen des Festers, hatten wir eine Wunschtemperatur von 22.0 Grad - nach dem schließen des Fensters möchte ich aber nur noch 19.0 Grad.
Gruß
laxmann
bin nicht sicher, ob FHEM hier etwas machen kann. In jedem Fall solltest in deinen Beobachtungen den Mode mit einbeziehen. Ich gehe davon aus, dass es einen Unterschied macht ob du in manuell oder automode bist.
Mein Plan ist, wie bei den FHT, die Thermostate manuell zu steuern, weil ich 14 unterschiedliche Tagesprogramme haben könnte.
Ich habe unter
https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Simulation_von_Fensterkontakten_und_externen_Temperatursensoren (ftp://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Simulation_von_Fensterkontakten_und_externen_Temperatursensoren)
mir mal
ZitatSimulation von Fensterkontakten und externen Temperatursensoren
angeschaut und ausprobiert.
Das mit dem
ZitatpostEvent open:postEvent closed
verstehe ich nicht, weil ich eigentlich ein ordentliches open oder closed an den HM_3B0C2B_WindowRec
senden möchte.
Feiert schön!
2017 kommt
Gruß
laxmann
Hallo martinp876,
ich habe deine Vermutung
ZitatIch gehe davon aus, dass es einen Unterschied macht ob du in manuell oder automode bist.
nachgeprüft.
Ob automode oder manuell - es bleibt das gleiche, wobei mir diesmal aufgefallen ist, dass die Temperaturveränderung nach Fenster closed in beiden Modi beibehalten, obwohl ich das oben anders geschrieben haben - wieso weis ich nicht.
Ich habe auch mal den den Befehl
set Gerät_Clima regSet dayTemp 20in der Zeit, wenn das Fenster offen steht, durchgeführt. Die dayTemp wird zwar übernommen, aber nach Fenster closed nicht eingestellt.
Gibt es denn einen Befehl, der dayTemp einstellt, denn das könnte ja ein Weg sein.
Ich denke, es liegt hier ein FW-Problem vor.
Während das Fenster geöffnet ist, kann eine willkürliche Temperatur eingestellt werden und diese wird auch vom HM-CC-RT-DN eingestellt.
! Es wird gegen ein offenes Fenster geheizt!
In der Bedienungsanleitung Seite 43 wird diese Funktion (Fenster-auf-Funktion) aber eindeutig zugesagt.
Ich habe in dieser Angelegenheit auch eq-3 kontaktiert - ich werde berichten.
Gruß
laxmann
Nun, ein fw Problem ist es nicht. Es ist schlicht Definitionssache. Und so ist es definiert.
Du kannst controlMode das setzen. Viel gespielt habe ich nicht, was diesen Mode angeht.
So ist es also ein Problem, die Temperatur bei geöffnetem Fenster manuell einzustellen.
Vielleicht kann man auch ein Userreading definieren, welches mit der neuen Solltemp. gefüllt wird, wenn das Fenster geöffnet seien sollte. Beim Schließen wird dann der Inhalt des Userreadings als neuer Sollwert gesetzt...
Ich habe so was ähnliches bei meinen Rollläden im Einsatz: ist die Balkontür auf, so wird eine neue Position nur in das Userreading geschrieben und beim Schließen der Tür als Befehl an den Rolaaktor abgesetzt.
Uwe
Hallo zusammen,
danke für die Meldungen.
Ich habe Nachricht von eq-3 erhalten - sehen sich als nicht zuständig an und solle den Lieferanten kontaktieren (ELV). Habe ihn kontaktiert und leider das gleiche erfahren wie von euch.
Meine Vorstellung geht nur über Templisten.
Aus diesem Grund habe ich den vergangenen Tagen
1. https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat (ftp://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat)
2.https://wiki.fhem.de/wiki/HomeMatic_Type_Thermostat#Temperaturlisten (ftp://wiki.fhem.de/wiki/HomeMatic_Type_Thermostat#Temperaturlisten)
3.https://wiki.fhem.de/wiki/HomeMatic_HMInfo_TempList/Weekplan (ftp://wiki.fhem.de/wiki/HomeMatic_HMInfo_TempList/Weekplan)
angeschaut.
Alles nicht so einfach.
Gibt es ein Tutorial oder eine verständlichere Seite zum Thema Temperaturregelung HM-CC-RT-DN.
Wie ihr seht, gebe ich mein Projekt zur den HM-CC-RT-DN auf, so wie ich es mir vorgestellt habe - es geht wohl nur über "tempList".
Gruß
laxmann
Wenn der Schaltzeitpunkt in deiner Templist in dem Zeitraum liegt, in dem das Fenster offen ist, so wird das auch nichts. Du musst zum Schaltzeitpunkt prüfen, ob das Fenster offen ist (bzw. der RT "Frostschutz" meldet) - wenn ja dann neuen Sollwert merken und beim Schließen des Fensters neu abschicken; wenn nein dann neue Solltemp direkt setzen.
Bei meinen Rolläden (s.o.) mache sich das so:
([{sunset(60,"17:00","22:00")}] and [Rolaautomatik] eq "Ein" and ($month<5 or $month>9) and [WZ_Rolare] eq "Auf" and (ReadingsVal("Wetter","fc1_low_c",0)<5))
(IF ([WZ_Balkon] eq "geschlossen")(set WZ_Rolare Zu) ELSE (setreading WZ_Rolare last_state 0))
...
DOELSEIF
([WZ_Balkon] eq "geschlossen" and [?WZ_Rolare] eq "Auf" and [WZ_Rolare:last_state] < 100)(set WZ_Rolare [WZ_Rolare:last_state],setreading WZ_Rolare last_state 100)
last_state ist ein Userreading im WZ_Rolare, welches mit der gemerkten/gewünschten Position bei Bedarf gefüllt wird.
Im IF innerhalb des DOIFs wird geprüft ob Balkontür zu, wenn ja dann Rola zu sonst Position 0 (entspricht "zu") merken.
Im DOELSE-Zweig wird beim Schließen der Balkontür der Inhalt des Userreadings geprüft und dann der Schließbefehl abgesetzt und dann das Userreading resettet.
Umfriemeln auf RT und Temperaturen kannst du sicher selber...
Uwe
Hallo Uwe,
vielen Dank für deine Nachricht.
Zur Zeit bin mit der tempList-Erstellung beschäftigt, mit deiner Nachricht müsste ich dann in den DOIF-Konstruktionen deinen Vorschlag einarbeiten.
Auf der Seite
http://www.ziggymania.de/index.php/tutos/35-linux/rasberry-pi/89-fhem-homematic-heizungsthermostate-hm-cc-rt-dn (ftp://www.ziggymania.de/index.php/tutos/35-linux/rasberry-pi/89-fhem-homematic-heizungsthermostate-hm-cc-rt-dn)
habe ich eine verständlichere Form als Einstieg zu der Erstellung von Templisten gefunden.
Jetzt geht es voran - Danke an alle!
Gruß
laxmann
Hallo,
ich will noch eine Alternative zu den Templists in den Raum werfen. SChau dir mal weekprofiles an.
https://wiki.fhem.de/wiki/Weekprofile
Ich habe auch mehrere Programme und bin weg von den Templist hin zu den weekprofile da man die ganzen Temperaturen schön in der Weboberfläche anlegen, bearbeiten und zuweisen kann.
Wenn du weekprofiles hast kann sind die Temperaturen auch in den Thermostaten wie bei den templists. Somit funktioniert die "open window" Erkennung genau so gut oder schlecht.
Mein Setup ist folgendermaßen
1) Weekprofiles für jeden einzelnen Thermostat. Pro möglicher Auswahl ein Profile. Macht bei 3 Thermostaten x 5 Programmen = 15 Profiles. Am Anfang ist es Arbeit, aber später ist es einfach.
2) Dropdown mit Structure. Somit kann ich dann entweder mit einer einzelnen Auswahl alle Thermostate umschalten, oder - wenn gewünscht - auch einzelne Räume ausnehmen. Programme können durch die Gruppierung zu "structure" kann dann in Verbindung mit Google-Kalender oder zeitgesteuert schalten. Mit einem Notify setze ich dann das weekprofile an den ganzen Thermostaten.
3) Damit ich komfortabel auch einzelne Temperaturen schalten kann (manuell) habe ich noch zusätzlich eine ReadingsGroup.
Ich hänge dir von 1 - 3 ein Bild an dann kannst dir vorstellen wie das aussieht. Solltest du interesse haben kann ich dir bei der Konfig helfen.
Hallo kadettilac89,
wenn nur 5 Profile zulässig sind, dann ist es zu wenig.
Wie oben beschrieben habe ich zwei und meine Frau drei unterschiedliche Arbeitszeiten. Wenn ich jetzt alles kombiniere und sonstige Profile erstelle, dann komme ich auf 14 Programme, die ich einstellen muss.
Gruß
laxmann
Zitat von: laxmann am 08 Januar 2017, 13:44:08
Hallo kadettilac89,
wenn nur 5 Profile zulässig sind, dann ist es zu wenig.
Wie oben beschrieben habe ich zwei und meine Frau drei unterschiedliche Arbeitszeiten. Wenn ich jetzt alles kombiniere und sonstige Profile erstelle, dann komme ich auf 14 Programme, die ich einstellen muss.
Gruß
laxmann
Okay. Ich habe von der Einschränkung max. 5 nicht gewusst. Dann viel Spaß mit den Files 8)
Wo steht das? Dann muss ich für mich nochmal überdenken.
Da hast du mich falsch verstanden.
Ich leite das von diesem
Zitat1) Weekprofiles für jeden einzelnen Thermostat. Pro möglicher Auswahl ein Profile. Macht bei 3 Thermostaten x 5 Programmen = 15 Profiles. Am Anfang ist es Arbeit, aber später ist es einfach.
ab.
Ich habe mir Weekprofile mal angeschaut - dort steht nichts von dieser Einschränkung auf 5 - also ein Missverständnis meinerseits.
Weekprofile sieht vom Handling besser aus als tempList.