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,
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.
([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
(set Buero_HT desiredTemperature off) setzen?
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
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 (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.
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
Die MAX kennen doch auch "fake"-Fensterkontakte: https://wiki.fhem.de/wiki/MAX#Externer_Sensor_f.C3.BCr_Fenster-offen-Erkennung (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.)
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):
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:
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");
}
}
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":
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
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 (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
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.
([Buero_links_Sensor:"open"]) or ([Buero_rechts_Sensor:"open"])
Das klappt irgendwie nicht, will ich das in den Raw Data's ändern kommt folgendes ::
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 ::
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 (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.
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:
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
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 (https://forum.fhem.de/index.php/topic,104523.msg984028.html#msg984028).).
@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...
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.
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. ?
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
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:
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
Zitat von: amenomade am 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:
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.
Einfach das wait attr für den zweiten DO-Fall ergänzen
Ich möchte das das HT abschaltet wenn das Fenster geöffnet wird und wieder in den ursprünglichen Zustand vor dem lüften zurück. Dafür kann ich den Befehl set cm Heizung 1 und 0 senden. Damit steuere ich die fakeshutter contacts von Max an.
Ich werde deine Variante mal ohne do always probieren und mit eq arbeiten und schauen was passiert. Das ist wahrscheinlich die sauberste Lösung.
Erst wenn beide Kontakte Close melden soll der Befehl Fenster zu gesendet werden. Ob nun ein oder beide Fenster offen sind ist egal, der offen Befehl wird ja dann geschickt.
Das wait attr erweitern mache ich wie ? Wie kann ich das für doelse. Da gibt es noch waitend glaub hab's grad nicht im Kopf.
Zitat von: D3ltorohd am 26 November 2019, 09:37:06
Das wait attr erweitern mache ich wie ? Wie kann ich das für doelse. Da gibt es noch waitend glaub hab's grad nicht im Kopf.
https://fhem.de/commandref_DE.html#DOIF_wait
Zitat von: amenomade am 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:
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.
Einfach das wait attr für den zweiten DO-Fall ergänzen
So scheint das zu funktionieren, mit eq und ohne "do always".
In meinem Fall müsste ich das wait mit : erweitern für das doelse, oder kommt hier noch das , zum Einsatz ?
Sollte ich auch bei nur einem FK mit eq arbeiten, oder ist das nur notwendig, wenn man mehrere Kontakte hat ?
Zitat von: D3ltorohd am 26 November 2019, 18:04:41
Sollte ich auch bei nur einem FK mit eq arbeiten,
Meinetwegen ja
So mit mehreren Sensoren klappt das, wie kann ich nun einem weiteren HT sagen, das es schalten soll ?
defmod Fensteroffen_WZ_EZ_HT DOIF ([Wohnzimmer_li_Sensor] eq "open" or [Wohnzimmer_mi_Sensor] eq "open" or [Wohnzimmer_re_Sensor] eq "open" or [Esszimmer_Sensor] eq "open" or [Terrasse_Sensor] eq "open") (set MaxCube fakeSC WZ_HT 1) DOELSE (set MaxCube fakeSC WZ_HT 0)
Ich bräuchte gleichzeitig noch ein (set MaxCube fakeSC EZ_HT 1) und dann natürlich später ein (set MaxCube fakeSC EZ_HT 0)
mit dem attr wait komm ich auch noch nicht so klar... wait 10 klappt aber wait 10,10 oder wait 10.10 klappt irgendwie nicht. Für den ersten Befehl, funktioniert es, er wartet 10 Sekunden und schaltet erst dann, beim zumachen, macht er es aber sofort.
wait 10:10
Ich weiß nicht warum ich auf . gekommen bin, da ich in die Commandref geschaut habe. Aber vllt mach ich schon wieder zu viel auf einmal. Ich teste mal mit :
Und wegen mehreren Befehlen, oder brauch ich dann ein extra DOIF für den anderen HT ?
Man kann sowas auch generalisieren (geht vermutlich auch mit DOIF), ich nutze dazu notify-Code: https://github.com/rejoe2/FHEM/blob/master/99_myUtils_Homematic.pm (da ist ne cref dazu drin und müßte auf MAX angepaßt werden), der allerdings gleich nach Schließen auch den "geschlossen" versendet (wieso auch nicht gleich?).
Zitat von: Beta-User am 08 Dezember 2019, 14:26:50
Man kann sowas auch generalisieren (geht vermutlich auch mit DOIF), ich nutze dazu notify-Code: https://github.com/rejoe2/FHEM/blob/master/99_myUtils_Homematic.pm (da ist ne cref dazu drin und müßte auf MAX angepaßt werden), der allerdings gleich nach Schließen auch den "geschlossen" versendet (wieso auch nicht gleich?).
Weil ich grad bei dem Thema bin, HT aus beim lüften. Soll das HT nicht gleich wieder an und die Heizung auf volle pulle, sondern erst mal nach ner Zeit, die Luft aklimatisiert sich ja auch wieder. War hier nur mal ne Idee von jemand anderem der das so nutzt.
Na ja, aber 10 Sek. sind dann dafür auch wieder sehr kurz.
Bei den RT-DN scheint das aber nicht so zu sein, dass da gleich voll aufgedreht wird nach der "zu"-Info...
Das mit den 10 Sekunden war auch erst mal nur zum Test.
Also ich weiß nicht aber nach Fenster zu springt er direkt wieder auf die soll Temp. Denke der macht dann gleich volle Pulle. Müsste ich mal ausprobieren.
So das mit dem doppelten Befehl hat sich auch erledigt. Hab de beiden HT's die gleiche groupid gegeben. Somit schalten beide mit nur einem Befehl.