[Gelöst] DOIF: Fensterkontakt mit Wartezeit

FSausF · 07 Februar 2020, 01:11:12

Guten Abend, liebe Gemeinde!
Ich bin grad' nach ewigem 'Rumprobieren total vernagelt und seh' es wahrscheinlich einfach nicht mehr.
Zur Schaltung meiner Heizung ist DOIF mein Freund, DEF zum Beispiel:

(([Fenster_Wohnzimmer:state] eq "closed" and [Hauptschalter:state] eq "on") and
([Wohnzimmer_Climate:measured-temp] <= [Wohnzimmer_Climate:desired-temp]))
(set Heizkoerper_Wohnzimmer_Sw on)
DOELSE
(set Heizkoerper_Wohnzimmer_Sw off)

Funktioniert soweit ohne Fehl und Tadel. Trivial. Aber der Fensterkontakt ist mir zu nervös.
Der Soll die Mimik bitte erst auslösen, wenn der Status mindestens eine Minute konstant ist. Mit anderen Worten soll die Heizung an bleiben, wenn ich mir fix auf dem Balkon ein neues Bier hole. (Nein, die Lösung, das Bier in der Wohnung zu lagern, kommt nicht in Frage!)

Ich hab's probiert mit dem Attribut timestamp-on-change-reading bei dem Homematic-Fensterkontakt. Da kriege ich irgendwie die Zeit dann doch nicht ausgelesen.
Ich hab's probiert mit verschiedenen WAITs im DOIF. Das tut viel, aber nicht das, was es letztlich soll.
Aber es will irgendwie nicht...

Was kann ich meinem DOIF antun, um den Zeitstempel (eigentlich nur sein Alter gegenüber der aktuellen Zeit) auszuwerten und das Ding erst aktiv werden zu lassen, wenn er, sagen wir mal 60 Sekunden alt ist?

Ich hab' die Beispiele hier im Forum gelesen und durchprobiert, ich bin grad' schlicht zu vernagelt, es richtig zusammenzukriegen...

Habt Ihr vielleicht ein mitternächtliches halbes Neuron für mich?
Was muss in die DEF oder die Attribute des DOIF oder des ThreeStateSensors um ihn erst nach 60 Sekunden konstantem Reading umzusetzen?

Danke im Voraus für Eure geduld mit einem doofen Anfänger!

FSausF

amenomade · 07 Februar 2020, 01:26:20

Vielleicht https://fhem.de/commandref_DE.html#DOIF_Zeitspanne_eines_Readings_seit_der_letzten_Aenderung
EDIT: aber Achtung, :sec triggert nicht x Sekunden nach der Änderung des Readings. Es muss etwas anderes geben, das triggert.

amenomade · 07 Februar 2020, 01:44:13

Ansonsten kann man testen, welches Device getriggert hat:

Code Auswählen

(IF ($DEVICE eq "Fenster_Wohnzimmer")(sleep 10;set Heizkoerper_Wohnzimmer_Sw on) ELSE (set Heizkoerper_Wohnzimmer_Sw on))

Oder die Bedingungen entkoppeln:

Code Auswählen

([Fenster]... and [?andereBedingung] and [?andereBedingung])
     (set on)
DOELSEIF
([andereBedingung] and [andereBedingung] and [?Fenster])
    (set on)

wait 10,0

Ma_Bo · 07 Februar 2020, 02:12:49

Versuch es mal so:

(([?Fenster_Wohnzimmer:state] eq "closed" and [Hauptschalter:state] eq "on") and ([Wohnzimmer_Climate:measured-temp] <= [Wohnzimmer_Climate:desired-temp]))
(set Heizkoerper_Wohnzimmer_Sw on)

DOELSEIF (([Fenster_Wohnzimmer:state] eq "closed" and [Hauptschalter:state] eq "on") and ([Wohnzimmer_Climate:measured-temp] <= [Wohnzimmer_Climate:desired-temp]))
(set Heizkoerper_Wohnzimmer_Sw on)

DOELSE
(set Heizkoerper_Wohnzimmer_Sw off)

attr <DEINDOIFNAME> wait 0:60:60

Sonst wäre noch die Möglichkeit (wenn es sich bei dem Fensterkontakt um einen Homematic Fensterkontakt handelt) dass der Fensterkontakt erst eine Änderung nach 60 Sekunden sendet, den Befehl dafür müsste ich mal raussuchen, das habe ich bei meiner Balkontür nämlich auch gemacht, da muss ein Register Eintrag vom Fensterkontakt eingestellt werden...

Grüße Marcel

###Edit

Oder generell erst 60 Sekunden warten, bei einer Änderung

(([Fenster_Wohnzimmer:state] eq "closed" and [Hauptschalter:state] eq "on") and ([Wohnzimmer_Climate:measured-temp] <= [Wohnzimmer_Climate:desired-temp]))
(set Heizkoerper_Wohnzimmer_Sw on)
DOELSE
(set Heizkoerper_Wohnzimmer_Sw off)

attr <DEINDOIFNAME> wait 60:60

rabehd · 07 Februar 2020, 07:38:42

Das sieht nach Homematic Thermostat und Fensterkontakt aus.
Normalerweise peert man diese und gut ist. Damit lebe ich gut, auch wenn ich mal kurz auf die Terrasse gehe (mein Bier stehtr im Keller).
Den Sinn deiner Aufgabe hinterfrage ich also nicht.

Warum triggerst Du mit "close" ?
Das würde ich rausnehmen und somit on von der Temperatur und dem Hauptschalter abhängig machen.
Der Zustand "open" muss dann nur die Heizung ausschalten. Sobald dieser Zustand nicht mehr vorhanden ist gelten die anderen Bedingungen (wiedereinschalten) oder DOELSE (aussschalten).

FSausF · 07 Februar 2020, 07:41:23

Zitat von: Ma_Bo am 07 Februar 2020, 02:12:49
Sonst wäre noch die Möglichkeit (wenn es sich bei dem Fensterkontakt um einen Homematic Fensterkontakt handelt) dass der Fensterkontakt erst eine Änderung nach 60 Sekunden sendet, den Befehl dafür müsste ich mal raussuchen, das habe ich bei meiner Balkontür nämlich auch gemacht, da muss ein Register Eintrag vom Fensterkontakt eingestellt werden...
Grüße Marcel

Hallo Marcel,
genau das wäre glaube ich das, was ich suchen täte.

Die Lösung mit WAIT unterbindet nicht die nervöse Zustandsänderung des Fenstersensors.
Ich hatte auch drüber nachgedacht, mir einen Dummy zu bauen, der den Status so zeigt, wie ich will.

Aber irgendwo las ich auch, man könne den Zeitstempel oder auch das Alter der letzten Zustandsänderung auslesen.
Wenn ich den hätte, könnte ich ihn gegen die aktuelle Uhrzeit halten und schauen, ob er mindestens 60 Sekunden alt ist.
Aber auch das wollte nicht so recht gelingen.

Oder zum Fensterkontakt ein User-Reading mit der gewünschten Zeit basteln?

Es gibt da sicher viele Ansätze, aber ich will eigentlich nicht groß mit Dummies frickeln.
Bislang läuft bei mir praktisch alles über DOIF.
NOTIFY oder irgendwelche EVENT-Trigger habe ich praktisch nicht im Einsatz. (Wenn man das sagen darf, dann in diesem Bereich des Forums.)

Ich bin ganz großer DOIF-Fan, denn da sehe ich auf einem Bildschirm, was los ist...

Ich danke für Euer Hirnschmalz,

FSausF

FSausF · 07 Februar 2020, 07:49:24

Zitat von: rabehd am 07 Februar 2020, 07:38:42
Das sieht nach Homematic Thermostat und Fensterkontakt aus.

So ist es!

Zitat von: rabehd am 07 Februar 2020, 07:38:42
Warum triggerst Du mit "close" ?
Das würde ich rausnehmen und somit on von der Temperatur und dem Hauptschalter abhängig machen.
Der Zustand "open" muss dann nur die Heizung ausschalten. Sobald dieser Zustand nicht mehr vorhanden ist gelten die anderen Bedingungen (wiedereinschalten) oder DOELSE (aussschalten).

Das ist Jacke wie Hose. Im Ergebnis würde auch das die Heizung kurz aus und wieder anschalten.
Die soll aber bei kürzerer Öffnung der Tür einfach weiter laufen und sich erst abschalten, wenn die Tür wirklich zum Lüften offen ist.

Für die Heizung ist das übrigens nicht so ganz das Thema, da hast Du Recht. Ich habe mit der von Dir beschriebenen Logik bisher gut gelebt.
Jetzt hab' ich aber zusätzlich einen Luftentfeuchter am Start. Dessen Feuchtigkeits- und Taupunktabhängige Steuerung habe ich im Griff. Aber der mag es nicht, in kurzen Intervallen ein und ausgeschaltet zu werden.
Also braucht letztlich der den beruhigten Fensterkontakt.
Ich mag das aber lieber mit der Heizung üben, denn da ist das DOIF deutlich handlicher!

Danke!

FSausF

FSausF · 07 Februar 2020, 08:58:36

Könnte mir in der Sache eventuell helfen, das DOIF in drei Teile aufzuteilen und mit den Wait-Timern beziehungsweise Reset Wait zu arbeiten?

In der Struktur so etwa:
DOIF
(Fensterkontakt ist auf) -> (Heizung aus)
DOELSE IF
(Zieltemperatur nicht erreicht) -> (Heizung an)
DOELSE
(Heizung aus)

Und dann im ersten Teil dann einen WAIT auf 60 und RESETWAIT setzen?

xenos1984 · 07 Februar 2020, 09:32:29

Ich würde da etwa so herangehen (ungetestet):

Code Auswählen

DOIF ([Fenster_Wohnzimmer:state] eq "open")
(set Heizkoerper_Wohnzimmer_Sw off)
DOELSEIF (([Hauptschalter:state] eq "off") or ([Wohnzimmer_Climate:measured-temp] > [Wohnzimmer_Climate:desired-temp]))
(set Heizkoerper_Wohnzimmer_Sw off)
DOELSE
(set Heizkoerper_Wohnzimmer_Sw on)

Dazu die Attribute:

Code Auswählen

wait 60:0:0
do resetwait
repeatsame 1

rabehd · 07 Februar 2020, 09:44:45

ZitatFür die Heizung ist das übrigens nicht so ganz das Thema, da hast Du Recht. Ich habe mit der von Dir beschriebenen Logik bisher gut gelebt.
Jetzt hab' ich aber zusätzlich einen Luftentfeuchter am Start. Dessen Feuchtigkeits- und Taupunktabhängige Steuerung habe ich im Griff. Aber der mag es nicht, in kurzen Intervallen ein und ausgeschaltet zu werden.
Also braucht letztlich der den beruhigten Fensterkontakt.
Ich mag das aber lieber mit der Heizung üben, denn da ist das DOIF deutlich handlicher!

Ich halte es für falsch so zu tun, als ob eine Heizung und ein Luftentfeucher das Gleiche sind.
Mach Dir zum Testen einen Dummy "Luftentfeuchter".
Ich würde den über DOIF steuern. Das Ausschalten per Fenstersensor sollte doch mit einen Wait klappen. Wait wird abgebrochen, wenn Sensor "closed" meldet.

Ich frage mich ob ein Entfeuchter per Fenstersensor sinnvoll gesteuert werden kann.

Ma_Bo · 07 Februar 2020, 10:34:49

Zitat von: FSausF am 07 Februar 2020, 07:41:23
Hallo Marcel,
genau das wäre glaube ich das, was ich suchen täte.

....

Ich schaue heute Abend mal nach.

Ich gebe dir recht, da was mit DOIF oder so zu machen ist nicht die beste Lösung...
Das hatte ich damals auch versucht und bin aber dann dazu übergegangen, ein Delay für den Fenstersensor zu nehmen...

Grüße Marcel

Gesendet von iPhone mit Tapatalk

Ma_Bo · 07 Februar 2020, 10:50:47

Ich bin mir nicht mehr ganz sicher, aber es müsste wie bei der cyclicinfo gewesen sein:

https://wiki.fhem.de/wiki/HM-SEC-SC_Tür-Fensterkontakt

Nur anstelle cyclicInfoMsg war es eventDlyTime

Also so in etwa:

get NameMeines_HM-SEC-SC reg all
set NameMeines_HM-SEC-SC regSet eventDlyTime 60

eingeben. Danach sieht man beim Device, dass mindestens ein Kommando pendig ist und in den Readings, dass das eventDlyTime Register geschrieben werden soll. Danach FHEM in den pairing modus versetzten, z.B. mit:

set HMLAN1 hmPairForSec 30

und den Knopf im Batteriefach des HM-SEC-SC drücken (Büroklammer). Danach noch mal

get NameMeines_HM-SEC-SC reg all

in FHEM (Telnet oder WEbfrontend). Jetzt sollten keine pendig commands mehr zu sehen sein und in den readings genau

R-eventDlyTime 60

stehen.

Gesendet von iPhone mit Tapatalk

FSausF · 07 Februar 2020, 16:15:01

Zitat von: Ma_Bo am 07 Februar 2020, 10:50:47
Also so in etwa:
get NameMeines_HM-SEC-SC reg all
set NameMeines_HM-SEC-SC regSet eventDlyTime 60
eingeben. Danach sieht man beim Device, dass mindestens ein Kommando pendig ist und in den Readings, dass das eventDlyTime Register geschrieben werden soll. Danach FHEM in den pairing modus versetzten, z.B. mit:
set HMLAN1 hmPairForSec 30
und den Knopf im Batteriefach des HM-SEC-SC drücken (Büroklammer). Danach noch mal
get NameMeines_HM-SEC-SC reg all
in FHEM (Telnet oder WEbfrontend). Jetzt sollten keine pendig commands mehr zu sehen sein und in den readings genau
R-eventDlyTime 60
stehen.

Klang gut, hat aber mit meinem HM-SEC-SCO nicht geklappt.
Da bleiben auch nach wiederholtem Pairen übrig:
R-eventDlyTime set_60 s
Und CMDs pending.

Wie kriege ich das nun jetzt wieder gerichtet?
Reset des Devices?

Ich glaub', ich versuch' nochmal über ReadingsTimeStamp an die Zeit der letzten Änderung zu kommen und damit etwas Zahlenmystik zu betreiben...

FSausF · 07 Februar 2020, 16:21:01

Zitat von: rabehd am 07 Februar 2020, 09:44:45
Ich würde den über DOIF steuern. Das Ausschalten per Fenstersensor sollte doch mit einen Wait klappen. Wait wird abgebrochen, wenn Sensor "closed" meldet.
Ich frage mich ob ein Entfeuchter per Fenstersensor sinnvoll gesteuert werden kann.

Ich bastel' später nochmal mit den Anregungen aus dem Thread hier. Das mit dem Wait sieht gut aus, ich hab' bisher immer andersherum gedacht.

Der Entsafter wird nicht nur über den Fenstersensor gesteuert. Sondern über eine Abschätzung, ob der Taupunkt erreicht werden kann (Außentemperatur, Innentemperatur, Feuchtigkeit, Taupunkt der Luft innen).
Das Fenster ist nur die Randbedinung: Nicht entsaften, so lange das Fenster noch offen ist.
Sonst bin ich nachher schuld, wenn es da draussen nicht genug regnet...

Ma_Bo · 07 Februar 2020, 16:44:01

Zitat von: FSausF am 07 Februar 2020, 16:15:01
Klang gut, hat aber mit meinem HM-SEC-SCO nicht geklappt.
Da bleiben auch nach wiederholtem Pairen übrig:
R-eventDlyTime set_60 s
Und CMDs pending.

Wie kriege ich das nun jetzt wieder gerichtet?
Reset des Devices?

Ich glaub', ich versuch' nochmal über ReadingsTimeStamp an die Zeit der letzten Änderung zu kommen und damit etwas Zahlenmystik zu betreiben...

Gute Frage, evtl. mal mit 10 Sekunden versuchen, ich weiß nicht, bis zu wieviel Sekunden möglich sind...

Gesendet von iPhone mit Tapatalk