Doif Fenster offen Erkennung,mehrere Kontakte, aktl. Temp abfragen, zurücksetzen

D3ltorohd · 24 November 2019, 10:05:25

Hallo Com,

ich habe mir folgendes Doif erstellt :

defmod HT_Fensteroffen_Buero DOIF ([Buero_links_Sensor:"open"]) (set Buero_HT desiredTemperature off) DOELSE (set Buero_HT desiredTemperature 18)
attr HT_Fensteroffen_Buero do always
attr HT_Fensteroffen_Buero icon time_eco_mode
attr HT_Fensteroffen_Buero room Doif
attr HT_Fensteroffen_Buero wait 15

Das funktioniert soweit auch wunderbar. Nun sollte ich aber noch "Buero_rechts_Sensor" mit einbeziehen. Jetzt meine Frage kann ich ein 2. Devices mit in das Doif schreiben, oder muss ich für jeden Kontakt ein eigens Doif erstellen. Beispiel 3 Kontakte = 3 Doifs, die aber den Set Befehl an ein und den selben HT senden ?

Und die 2 Sache, kann ich die aktuelle Temp des HT's auslesen lassen, bevor er auf off stellt, das beim schließen des Fensters das Doif die ausgelesene Temp wieder einstellt ? Hier laufen nicht alle auf Auto und haben unterschiedliche Temps eingestellt, wäre halt komfortabler, wenn die aktuell eingestellte Temp einfach gelesen wird und dann so wieder gesetzt, nachdem man das Fenster wieder schließt.

Grüße,

Udomatic · 24 November 2019, 11:19:36

Zitat von: D3ltorohd am 24 November 2019, 10:05:25
Jetzt meine Frage kann ich ein 2. Devices mit in das Doif schreiben, oder muss ich für jeden Kontakt ein eigens Doif erstellen. Beispiel 3 Kontakte = 3 Doifs, die aber den Set Befehl an ein und den selben HT senden ?

Über den "or" Operator kannst du den zweiten Sensor mit einbinden in die Bedingung. Wenn dann einer der beiden Sensoren "open meldet wir die Bedingung ausgeführt.

Code Auswählen

([Buero_links_Sensor:"open"]) or ([Buero_rechts_Sensor:"open"])

Zur zweiten Frage. Springen deine HT nicht auf die vorher eingestellt Temp zurück, wenn das Fenster geschlossen wird? Also musst du überhaupt ein

Code Auswählen

(set Buero_HT desiredTemperature off) setzen?

MadMax-FHEM · 24 November 2019, 11:53:57

Welche HTs hast du?

Können die unterschiedliche Modi?

Also z.B. du betreibst die normalerweise im Automatikmodus, dann kannst du die ja auf manuell stellen und eine Temp mitgeben und danach wieder auf Automatik stellen...
Geht bei meinen Homematic...

Bei einigen mache ich das so, dass ich per Notify die Tempwerte "bekomme" und im Falle, dass das zugehörige Fenster zu ist mir den Wert merke (Dummy oder eben im HT als eigenes Reading / würde verm. auch als userReadings gehen) und dann eben nach dem schließen des Fensters wieder diesen Wert einstelle...

Gruß, Joachim

D3ltorohd · 24 November 2019, 12:27:57

Zitat von: Udomatic am 24 November 2019, 11:19:36
Zur zweiten Frage. Springen deine HT nicht auf die vorher eingestellt Temp zurück, wenn das Fenster geschlossen wird? Also musst du überhaupt ein
Code Auswählen Erweitern
(set Buero_HT desiredTemperature off) setzen?

Nein, ich muss den Befehl off setzten oder eine Temp, da ich keine original Max! Fensterkontakte habe. Damit würde es vllt schon gehen, da es im HT attr eine Lüftungsfunktion gibt.

Zitat von: MadMax-FHEM am 24 November 2019, 11:53:57
Welche HTs hast du?

Können die unterschiedliche Modi?

Also z.B. du betreibst die normalerweise im Automatikmodus, dann kannst du die ja auf manuell stellen und eine Temp mitgeben und danach wieder auf Automatik stellen...
Geht bei meinen Homematic...

Bei einigen mache ich das so, dass ich per Notify die Tempwerte "bekomme" und im Falle, dass das zugehörige Fenster zu ist mir den Wert merke (Dummy oder eben im HT als eigenes Reading / würde verm. auch als userReadings gehen) und dann eben nach dem schließen des Fensters wieder diesen Wert einstelle...

Gruß, Joachim

Ja die Max! Thermostate können manual oder Auto. Da in diversen Zimmern aber nur bei Anwesenheit geheizt wird, wird das mit Auto nicht wirklich funktionieren. Daher wäre so ein userReading gar nicht schlecht. Könntest du mir dabei helfen, hab da 0 Ahnung wie ich das hinbekommen soll.

MadMax-FHEM · 24 November 2019, 12:51:06

Wie ist denn deine Namensgebung?

Also kann man da etwas "generisches" machen?

Oder muss man das für jeden HK separat "programmieren"!?

EDIT: sind die alle so "durchlaufend" wie in dem Beispiel oder doch immer wieder anders?

Bei mir kann man vom HK-Namen auf den Fenster-Namen und umgekehrt "schließen"...

Bzw. ich hab grad mal in meinem Code geschaut, da habe ich das noch anders gelöst (war noch am Anfang meiner fhem-Tätigkeit

)...
...aber auch deswegen weil ich je nach Raum unterschiedliche "Verzögerungszeiten" haben wollte...

Gruß, Joachim

Beta-User · 24 November 2019, 13:35:27

Die MAX kennen doch auch "fake"-Fensterkontakte: https://wiki.fhem.de/wiki/MAX#Externer_Sensor_f.C3.BCr_Fenster-offen-Erkennung

Würde also gar nicht die Temperatur direkt regeln, sondern nur mitteilen, dass offen/zu ist.

(Irgendwo hier hatte ich auch mal code für notify gepostet, der (für offen verzögert) diese Meldungen rausschickt und dabei userAttr auswertet, in denen alle beteiligten FK's den HT's zugeordnet sind. Damit kann man auch erkennen, ob alle oder nur einer der beteiligten KF's geschlossen sind...

Müßte ich bei Interesse suchen, falls du es nicht selbst findest.)

MadMax-FHEM · 24 November 2019, 13:59:49

Ich poste mal was ich habe...
...wie geschrieben würde ich das heute wohl anders lösen...

Aber da es funktioniert...
...und andere Dinge wichtiger sind (und ich auch erst jetzt wieder gesehen habe wie "schlimm" es ist

) ist es halt immer noch so...

...und wird es verm. noch eine Weile so bleiben

Du brauchst vermutlich nicht alles davon...
...es reicht vermutlich der Teil wo ich mir in dem Dummy die aktuelle Temp VOR dem Öffnen "merke" und nachher (evtl. auch sogar ohne den "Verzögerungs-at") wieder einstelle was zuvor "gewünscht" war...

Also folgendes Notify bzgl. Fenster auf/zu (Beispiel, habe ein Notify für jedes Fenster, weil ich eben unterschiedliche "Zeiten" mitgeben will und ich auch mal vorhatte bzw. die Möglichkeit habe unterschiedliche WinOpenTemp mitzugeben / ansonsten ginge auch ein Notify, wenn die Namen der Fenster und HKs sich zueinander "auflösen" lassen / oder eben auch userReadings):

Code Auswählen


Fenster_Bad:(open|closed) {my_WindowOpenClose($EVENT, 12.0, "Heizkoerperthermostat_Bad", "+00:05:00")}

In Event steht, ob Fenster geschlossen oder geöffnet wurde (musst du halt schauen was da bei dir tatsächlich kommt!!).

Dann die WinOpenTemp (wenn du keine unterschiedlichen sondern fix die gleiche bzw. bei dir "off" haben willst, dann kannst du den Teil nat. einfach weglassen und auch den zugehörigen Code in der Sub streichen)...

Dann eben welcher Heizkörperthermostat geschalten werden soll (wenn man von Fensterkontakt auf HK "schließen" kann, dann kann man das auch anders lösen [würde ich wohl heute auch anders machen])...

Und dann noch die Verzögerung, also nach welcher Zeit die zuletzt gewünschte Temperatur wieder gesetzt wird.

Grund: der Raum "erwärmt" sich ja nach dem Schließen wieder ein wenig, oft schon wieder fast auf die zuletzt eingestellte "desired-temp" bzw. ist die Luft in der Umgebung des HK bei offenem Fenster ja eher sehr kalt (wenn der HK "unter" dem Fenster ist) und wenn dann sofort zurückgestellt wird, dann wird oft unnötigerweise gleich wieder geheizt obwohl nach ein paar Minuten die Raumluft anders verteilt ist und es beim HK gar nicht mehr so kalt ist

Und dann nat. die Subs, welche dann die entsprechenden Temperaturen einstellt/zurückstellt:

Code Auswählen


sub my_WindowOpenClose($$$$)
{
  my ($Event, $WinOpenTemp, $Device, $Delay) = @_;
  my $actTemp = 0.0;
  my $StoredStateDevice = "WinOpenActive_" . $Device;
  my $StoredWinOpenTemp = "WinOpenTemp_" . $Device;
  my $DeviceChannel = $Device . "_Clima";
  my $atDefine = "Restore_" . $Device . "_Delayed";
	
  Log(1,"my_WindowOpenClose    Event: $Event     WinOpenTemp: $WinOpenTemp         Device: $Device          Delay: $Delay");
  
  if ($Event eq "open")
  {
  	#check if WinOpenTemp is (still) active
	if(ReadingsVal("myDesHKTemps", $StoredStateDevice, "yes") eq "no")
	{
		# set the siganl that WinOpenTemp is active
		{fhem("setreading myDesHKTemps $StoredStateDevice yes")}
		# store actual temperatures
		$actTemp = ReadingsVal($DeviceChannel, "desired-temp", "0.0");
		{fhem("setreading myDesHKTemps $Device $actTemp")}
		# store WinOpenTemp
		{fhem("setreading myDesHKTemps $StoredWinOpenTemp $WinOpenTemp")}
		# set temperatures to low value
		{fhem("set $DeviceChannel desired-temp $WinOpenTemp")}
		
		Log(1,"my_WindowOpenClose    $StoredStateDevice was no");
		Log(1,"my_WindowOpenClose    temp was set to $WinOpenTemp");
	}
	else
	{
		Log(1,"my_WindowOpenClose    $StoredStateDevice was not no (yes)");
	    {fhem("delete $atDefine")}
		Log(1,"my_WindowOpenClose    $atDefine   stopped");
	}
  }
  elsif($Event eq "closed")
  {
    # restore previous temperatures delayed
    {fhem("defmod $atDefine at $Delay {my_RestoreHeating(\"$Device\")}")}
	Log(1,"my_WindowOpenClose    $atDefine   started");
  }
}

Code Auswählen


sub my_RestoreHeating($)
{
  my ($Device) = @_;
  my $savedTemp = ReadingsVal("myDesHKTemps", $Device, "17.5");
  my $DeviceChannel = $Device . "_Clima";
  my $actTemp = ReadingsVal($DeviceChannel, "desired-temp", "0.0");
  my $atDefine = "Restore_" . $Device . "_Delayed";
  my $StoredStateDevice = "WinOpenActive_" . $Device;
  my $StoredWinOpenTemp = "WinOpenTemp_" . $Device;
  my $WinOpenTemp = ReadingsVal("myDesHKTemps", $StoredWinOpenTemp, "12.0");
  
  # only set back if not meanwhile manually set to a different temperature
  if($actTemp <= $WinOpenTemp)
  {
    Log(1,"my_RestoreHeating     Device: $Device       temp set back     actTemp: $actTemp       WinOpenTemp: $WinOpenTemp");
    # set the temperature back to where it was before
    {fhem("set $DeviceChannel desired-temp $savedTemp")}
  }
  else
  {
    Log(1,"my_RestoreHeating     Device: $Device       temp NOT set back     actTemp: $actTemp       WinOpenTemp: $WinOpenTemp");
  }
  
  # reset the signal that WinOpenTemp is active
  {fhem("setreading myDesHKTemps $StoredStateDevice no")}
  # remove the 'at' (delayed reset) because we only want it to happen once
  {fhem("delete $atDefine")}

#  Log(1,"my_RestoreHeating     Device: $Device      Channel: $Channel      Reading: $Reading     Notify: $Notify");
}

myDesHKTemps ist ein "Hilfsdummy" in dem ich speichere, welche Temp VOR dem Öffnen eingestellt war und es wird auch gespeichert, dass WinOpen aktiv ist (ich glaube wegen mal Fenster auf und dann wieder schnell zu oder so / ist halt schon lange her

)...

Den musst du nat. "anlegen":

Code Auswählen

define myDesHKTemps dummy

Da ich mir die WinOpenTemp "merke" kann ich auch feststellen, ob inzwischen die Temperatur "korrigiert" wurde (also Fenster zu und irgendjemandem war es zu kalt und er/sie hat bereits hochgedreht) und dann stelle ich eben nicht mehr zurück sondern lasse den neuen Wunsch...

Kann nat. bei Bedarf (bzw. bei nicht-Bedarf

) auch weggelassen werden...

Oder eben statt dem Dummy die Temperaturwerte per "setreading HK oldtemp Temp" speichern statt im Dummy...

Etwas OT

Bei mir in der Wohnung merke ich mir die aktuelle Temp generell in einem Dummy (ja, jetzt würde ich wohl userReadings nehmen

).
D.h. ich habe ein Notify auf Temperatur (desired-temp) und wenn das Fenster geschlossen ist (ich kann bei mir von Thermostat auf Fenster "schließen"), speichere ich die Temp ansonsten nicht.
Daher weiß ich immer welche Wunschtemperatur ich vor dem Öffnen hatte...

Da mach ich das aber aus anderen Gründen:

Z.B. zeige ich farblich in einer readingsGroup an, wann es wohl besser ist das Fenster wieder zu schließen, weil die zuvor gewünschte eingestellte Temperatur langsam (stark) unterschritten wird/würde...

Dann kann ich sehen, ob es besser ist trotzdem weiter zu lüften (wegen Luftfeuchte beispielsweise) oder ob ich besser schließe um ein zu starkes Heizen zu vermeiden...

Ende OT

Gruß, Joachim

MadMax-FHEM · 24 November 2019, 14:04:56

Zitat von: Beta-User am 24 November 2019, 13:35:27
Die MAX kennen doch auch "fake"-Fensterkontakte: https://wiki.fhem.de/wiki/MAX#Externer_Sensor_f.C3.BCr_Fenster-offen-Erkennung

Würde also gar nicht die Temperatur direkt regeln, sondern nur mitteilen, dass offen/zu ist.

(Irgendwo hier hatte ich auch mal code für notify gepostet, der (für offen verzögert) diese Meldungen rausschickt und dabei userAttr auswertet, in denen alle beteiligten FK's den HT's zugeordnet sind. Damit kann man auch erkennen, ob alle oder nur einer der beteiligten KF's geschlossen sind...

Müßte ich bei Interesse suchen, falls du es nicht selbst findest.)

Stimmt, das ginge sicher auch...
...ich habe halt (bei mir) echte Fensterkontakte von Homematic, da geht das ohne fake

Bei meiner Freundin (wo das nicht passt/geht und sie auch mehr "individuell" haben möchte

) habe ich das mit dem geposteten Code gelöst...

Da ist dein Code sicher deutlich besser...
...ich würde das heute auch nicht mehr so machen

Evtl. (wenn mal viel Zeit ist und ich wirklich nichts anderes finde

) baue ich das mal um...

Wobei nat. die Gefahr besteht, dass es dann "anders" funktioniert (zumindest "zunächst" vielleicht) und dann gibt's Ärger

...daher vielleicht lasse ich es auch trotzdem (es nicht schön ist

) einfach...

Ich habe ja auch einige Jahre nicht mehr geschaut und wusste (bis jetzt) gar nicht wie ("schlimm") ich das damals gelöst habe

Gruß, Joachim

D3ltorohd · 24 November 2019, 20:34:30

Zitat von: Udomatic am 24 November 2019, 11:19:36
Über den "or" Operator kannst du den zweiten Sensor mit einbinden in die Bedingung. Wenn dann einer der beiden Sensoren "open meldet wir die Bedingung ausgeführt.
Code Auswählen Erweitern
([Buero_links_Sensor:"open"]) or ([Buero_rechts_Sensor:"open"])

Das klappt irgendwie nicht, will ich das in den Raw Data's ändern kommt folgendes ::

Code Auswählen

HT_Fensteroffen_Buero DOIF: expected DOELSEIF or DOELSE:  or ([Buero_rechts_Sensor:"open"]) (set Buero_HT desiredTemperature off) DOELSE (set Buero_HT desiredTemperature 18)

Eingegeben hatte ich es so ::

Code Auswählen

defmod HT_Fensteroffen_Buero DOIF ([Buero_links_Sensor:"open"]) or ([Buero_rechts_Sensor:"open"]) (set Buero_HT desiredTemperature off) DOELSE (set Buero_HT desiredTemperature 18)

Zitat von: Beta-User am 24 November 2019, 13:35:27
Die MAX kennen doch auch "fake"-Fensterkontakte: https://wiki.fhem.de/wiki/MAX#Externer_Sensor_f.C3.BCr_Fenster-offen-Erkennung

Würde also gar nicht die Temperatur direkt regeln, sondern nur mitteilen, dass offen/zu ist.

Das habe ich gesehen, aber leider überhaupt nicht verstanden mit dem fakeShutter, ich muss ja nun irgendwie den Fensterkontakt mit dem fakeShutter verbinden, oder ihm mitteilen wann Fenster offen/zu. Hab die Commandref und die Wiki dazu angeschaut, aber bis auf HT mit fakeShutter verknüpfen nichts kapiert. Wenn du dich da auskennst, wäre es super, wenn du mir da helfen könntest, dann kann man das alles so regeln, dann muss ich denke auch das mit der Temp nicht speichern, weil Max das selber auf die ursprünglichen Einstellungen zurück setzt.

amenomade · 24 November 2019, 20:38:36

Falsch:

Zitatdefmod HT_Fensteroffen_Buero DOIF ([Buero_links_Sensor:"open"]) or ([Buero_rechts_Sensor:"open"]) (set Buero_HT desiredTemperature off) DOELSE (set Buero_HT desiredTemperature 18)

Richtig:

Code Auswählen

defmod HT_Fensteroffen_Buero DOIF ([Buero_links_Sensor:"open"] or [Buero_rechts_Sensor:"open"]) (set Buero_HT desiredTemperature off) DOELSE (set Buero_HT desiredTemperature 18)

EDIT: Korrektur nach "open" - falsche Klammer

Beta-User · 25 November 2019, 09:57:50

Zitat von: D3ltorohd am 24 November 2019, 20:34:30
Das habe ich gesehen, aber leider überhaupt nicht verstanden mit dem fakeShutter, ich muss ja nun irgendwie den Fensterkontakt mit dem fakeShutter verbinden, oder ihm mitteilen wann Fenster offen/zu. Hab die Commandref und die Wiki dazu angeschaut, aber bis auf HT mit fakeShutter verknüpfen nichts kapiert. Wenn du dich da auskennst, wäre es super, wenn du mir da helfen könntest, dann kann man das alles so regeln, dann muss ich denke auch das mit der Temp nicht speichern, weil Max das selber auf die ursprünglichen Einstellungen zurück setzt.

Ich kenne mich damit nicht aus, ich habe auch nur Homematic-Kontakte (@MadMax-FHEM: das ist trotzdem zwischenzeitlich vollständig indirekt gelöst, da das v.a. außerhalb der Heizperiode die Zahl der burst-Messages deutlich reduziert und auch kurzfristige Fenster-Ereignisse nicht gleich in Aktion umgesetzt werden... Details/Links dazu sind hier zu finden.).

@D3ltorohd:
Wenn du dazu Fragen hast, wie das mit den FK's geht: Wzut scheint grade dabei zu sein, die Doku usw. zu überarbeiten. Ist evtl. ein guter Zeitpunkt, die Frage im passenden Forum isoliert zu plazieren...

D3ltorohd · 25 November 2019, 13:21:24

Danke dann werde ich das da mal tun.

Ansonsten läuft es ja so erst mal provisorisch und madmax seine Variante wäre dann auch noch da, hoffe bekomme das dann auch so hin falls es mit den fsc nicht klappt.

D3ltorohd · 25 November 2019, 19:50:59

So wutz hat mir geholfen, eigentlich ganz simpel. Schon mit einem doif, aber einfach nur den speziellen Befehl für die fakeshuttercontacts, somit schaltet er in eine Wunsch temp und danach zurück in den Zustand, den das Thermostat davor hatte.

Aber hier auch noch mal vielen Dank an MadMax-FHEM, der mir aufwändig geschrieben hat wie man das auch selber anstellen kann. Somit würde ich das aber nicht übernehmen, da es das CUL_Max Modul schon mit bringt und ich das ganz einfach bewerkstelligen kann. Dennoch Danke für deine Hilfe und Mühen, wie natürlich auch dem Rest hier... Das mit 2 devices hat jetzt auch geklappt.

Eine Frage hätte ich jetzt noch ich habe ja "attr wait 10" bevor er den Befehl Fenster offen sendet, wartet er jetzt 10 Sekunden. Das gleiche bräuchte ich, wenn ich das Fenster schließe, das er eben wie hier im Thread erwähnt nicht sofort hoch heizt, sondern erst nach einer gewissen Zeit, da sich die Temp wieder normalisiert hat. Gibts da auch ein fertiges attr. ?

D3ltorohd · 26 November 2019, 08:10:04

Das attr do always wird gebraucht ? Oder sendet dann nach Fenster auf das doif dauerhaft den Befehl, bis es wieder zu ist ? Hatte das so verstanden das man do always braucht sonst sendet das doif genau einmal den Befehl und danach nie wieder. Egal ob Fenster wieder zu und danach wieder auf.

Wait 10 verzögert den zu sende den Befehl ja nur um 10 Sekunden.

Ich habe nämlich jetzt das Problem y das meine Credits alle sind, seitdem ich das mit den fakeshuttercontacts mache.

https://forum.fhem.de/index.php/topic,105627.0.html

amenomade · 26 November 2019, 08:42:15

Ohne do always sendet das DOIF den Befehl 1 nicht mehr, so lange der eine oder andere Sensor kein closed geschickt hat.
Aber Vorsicht:
- Fenster1 wird geöffnet: cmd1
- Fenster2 wird geöffnet: nichts
- Fenster1 wird geschlossen: cmd2!!
- Fenster1 wird wieder geöffnent: cmd1!!
- Fenster 1 wird geschlossen: cmd2!!
- Fenster 2 wird geschlossen: nichts

Mit do always: die Befehle werden ggf wiederholt (statt "nichts" hieroben, wieder cmd1 bzw cmd2)

Ich weiss nicht genau, was Du machen möchtest (habe das ganze Thread nicht gelesen), aber in dem Fall würde ich eher mit Zustände statt mit Events arbeiten:

Code Auswählen

defmod HT_Fensteroffen_Buero DOIF ([Buero_links_Sensor] eq "open" or [Buero_rechts_Sensor] eq "open") (set Buero_HT desiredTemperature off) DOELSE (set Buero_HT desiredTemperature 18)

ohne do always. Somit wird nur einmal cmd1 geschickt und nichts mehr bis beide Fenster zu.

ZitatEine Frage hätte ich jetzt noch ich habe ja "attr wait 10" bevor er den Befehl Fenster offen sendet, wartet er jetzt 10 Sekunden. Das gleiche bräuchte ich, wenn ich das Fenster schließe, das er eben wie hier im Thread erwähnt nicht sofort hoch heizt, sondern erst nach einer gewissen Zeit, da sich die Temp wieder normalisiert hat. Gibts da auch ein fertiges attr. ?

Einfach das wait attr für den zweiten DO-Fall ergänzen