FK+HZ+WT; Temperaturänderung bei offenem Fenster

Begonnen von adn77, 30 Dezember 2018, 21:51:32

Vorheriges Thema - Nächstes Thema

adn77

Hallo zusammen,

Ich habe MAX(CUL) Wandthermostat, Heizkörperventil und Fensterkontakt gepairt.
Zum normalen Regeln benutzte ich Wochenprofile. Gelegentlich möchte ich allerdings nicht auf den nächsten Schaltzeitpunkt warten (z.B. beim Nachhausekommen) und schalte dann alles per "Lichtscene".

Nun zu meiner Frage, wie ist das beabsichtigte Verhalten, wenn ich bei offenem Fenster am WT per FHEM eine neue desiredTemperature setzte?

Ideal wäre ja, wenn das Ventil auf OFF bleiben würde, bis das Fenster wieder geschlossen wird.
Bei einem kurzen Test in zwei Räumen scheint das auch zu funktionieren. Ist das Wunschdenken?
Alternativ müsste ich ein Notify auf desiredTemperature aller WTs setzen und so die verbundenen FK auf FensterOffen überprüfen...

Danke schmal,
Alex

adn77

#1
Ich beantworte mir die Frage mal selbst:
Wenn FHEM während ein Fenster geöffnet ist ein "set ... desiredTemperature ..." bekommt, wir das ans WT geschickt.
Dies veranlasst das Heitzungsventil trotz FK=opened Status aufzudrehen.

Eine Möglichkeit wäre, bei "set <DevSpec> desiredTemperature ..." DevSpec einen "FILTER!=<WindowOpenTemperature>" anzugeben.
Allerdings unterstützt meine Scene (Modul Lightscene) diese DevSpec nicht.

Ich habe mir mit einem Notify beholfen:
.*:desiredTemperature\s.* {
my $r = substr($NAME, 3);
my $change = 0;
if ( $r eq "Wohnzimmer" ){
if ( ( Value("fk_${r}1") ne "closed" || Value("fk_${r}2") ne "closed" ) && $EVENT !~ /off/i ){
$change = 1;
}
}else{
if ( Value("fk_${r}") ne "closed" && $EVENT !~ /off/i ){
$change = 1;
}
}
if ( $change == 1){
fhem( "set wt_${r} desiredTemperature off" );
}
fhem( "setreading Zieltemperatur ${r} ${EVENT}" );
}

Dieses Notify funktioniert, da ich meine Geräte mit FK_/WT_/HZ_ "präfixe". Im Wohnzimmer habe ich zwei Fenstersensoren, deshalb die etwas kompliziertere Sonderbehandlung.

Da ich die Wunschtemperatur in den Dummy "Zieltemperatur" wegschreibe, kann ein weiters Notify bei "FK_.* eq 'closed'" auch die Temperatur setzen:
fk_.*:(closed|opened) {
if ( $EVENT ne OldValue($NAME) ){
my ($r) = $NAME =~ m/fk_(.*?)[0-9]?$/;
if ( $EVENT eq "closed" ){
my $t = ReadingsVal("Zieltemperatur", $r, "desiredTemperature auto comfort");
fhem( "set wt_${r} ${t}");
}else{
my $t = ReadingsVal("desiredTemperature", "wt_${r}", "comfort");
fhem( "setreading Zieltemperatur ${r} desiredTemperature auto ${t}");
}
}
}

Wzut

Da du in anderen Fred das Thema angesprochen hast hole ich es mal wieder hoch.
Leider ist die MAX Welt nicht immer so wie sie für den jeweiligen User zu sein scheint, das fängt bereits an mit 
Zitat von: adn77 am 30 Dezember 2018, 21:51:32
Ich habe MAX(CUL) Wandthermostat, Heizkörperventil und Fensterkontakt gepairt.
wer wurde hier mit wem assoziiert/gepeered (pairing ist das verheiraten mit der Zentrale) und was wurde tatsächlich davon von den Geräten angenommen ?
Gerade der zweite Teil der Frage ist nicht einfach zu beantworten da ja leider bei MAX keine Register zurückgelesen werden können, also bleibt eigentlich nur die Möglichkeit der Analyse des Funkverkehrs ( verbose 5 am CUL_MAX Device ). Mit der aktuellen Beta geht es etwas einfacher durch setzen der Attributes debug und Beobachtung der Readings sendTo_ , peerIDs & peerList . D.h. von allen drei Geräten die Readings notieren , Fentser aufmachen, wieder notieren , Fenster zu machen und nochmal notieren. Jetzt sollte man anhand der Werte schon sehen wer mit wem gesprochen hat.

Zu deinem konkreten Fall : Wenn ein FK seinen Status wechselt (open/close) ist entscheident welche Peers er hat. Hat er welche schickt er jedem eine direkte Nachricht und jedes Gerät zeigt das auch mit dem offen/geschlossen Fenstersymbol direkt an. Hat er keine Peers verschickt er seinen Status als Broadcast Nachricht.
Und genau hier liegt der Hund begraben : Wenn WT & HT die Nachricht bekommen haben und das WT wird jetzt mit set desiredTemperatur auf einen anderen Wert gesetzt nimmt es diesen an und schickt die Info an das HT weiter. Doch dieses wird nun seinerseits nicht das Ventil verändern da es nach wie vor im window Open Mode ist. Erst wenn das Fenster wieder geschlossen wurde und das Fenster Symbol am HT verschwunden ist veratbeitet es die neue Soll Temperatur vom WT. Dies geschieht auch nicht sofort sondern mit dem nächsten Telegramm des WT an seine HTs (ca alle drei Minuten) Das ist wie gesagt der Idealfall und genau so verhält sich auch meine Testumgebung.
Allerdings kann ich deine Beobachtung auch bestätigen, in einem meiner aktiven Räume ist der FK nicht mit WT & HT assoziiert, aber beide Geräte hören auf seine open/close Broadcast Nachrichten.

Nun stellt sich die Frage : Ursache behandeln oder das Symptom ?
     

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

adn77

Vielen Dank für die erhellende Antwort!
Sorry wg. pairing vs. peering - gemeint war "associate" ;)

Also das WT scheint in der Tat die Kontrolle zu übernehmen - nur dieses taucht in der peerList auf. Habe wegen der erweiterten Debug Möglichkeit auch gleich deine Beta Module installiert.
Ein erneutes "Associate" FK<->HT funktioniert nicht. Die SendQueue zeigt
        Time        | Destination | Command       
--------------------+-------------+---------------
2020-02-12 20:19:08 | fk_Kueche   | AddLinkPartner


Selbst wenn ich den Knopf am FK drücke. Das Log zeigt:
2020.02.12 20:51:33 4 : cm, send -> cmd:PairPong, msgcnt:0c, flags:00, Cmd2id:01, src:MAX_130577 , dst:fk_Kueche , gid:00 , payload:00 , cul:none
2020.02.12 20:51:33 5 : cm, send packet: 0b0c000113057718de750000
2020.02.12 20:51:34 5 : cm, Send Queue 2 packets in queue
2020-02-12 20:51:34 CUL cul01 credit10ms: 3600
2020.02.12 20:51:34 5 : cm, Send Queue cul01 -> needPreamble: 1, necessaryCredit: 110, credit10ms: 3600, cul01 CMD_LAST_H: 8
2020.02.12 20:51:34 4 : cm, Send Queue packet send : Zs0b0c000113057718de750000 to fk_Kueche with cul01
2020.02.12 20:51:35 5 : cm, Send Queue 2 packets in queue
2020.02.12 20:51:35 5 : cm, Send Queue 2 packets in queue
2020.02.12 20:51:36 5 : cm, IODev cul01, len 12, msgcnt 0C, msgflag 02, msgType Ack, src 18de75, dst 130577, group 0, payload 0112, rssi -55.5
2020.02.12 20:51:36 5 : cm, ACK from fk_Kueche for cmd PairPong , packet will be removed soon
2020.02.12 20:51:36 5 : cm, delete packet Index 1 in SendQueue direct !
2020.02.12 20:51:36 3 : cm, got ACK from ShutterContact fk_Kueche , checking SendQueue now !
2020.02.12 20:51:36 5 : cm, Send Queue 1 packet in queue , rTSC : 18de75
2020.02.12 20:51:36 5 : cm, Send Queue cul01 -> needPreamble: 1, necessaryCredit: 112, credit10ms: 3492, cul01 CMD_LAST_H: 9
2020.02.12 20:51:36 4 : cm, Send Queue packet send : Zs0e0a002013057718de7500145e8d01 to fk_Kueche with cul01
2020.02.12 20:51:36 5 : cm: dispatch MAX,1,Ack,18de75,0112
2020.02.12 20:51:36 5 : MAX_Parse, MAX,1,Ack,18de75,0112
2020.02.12 20:51:36 5 : MAX_Parse, MAX2,1,ShutterContactState,18de75,12
2020.02.12 20:51:36 5 : fk_Kueche, bat 0, rferror 0, isopen 1, unkbits 0
2020-02-12 20:51:36 MAX fk_Kueche opened
2020-02-12 20:51:36 MAX fk_Kueche RSSI: -56.5
2020.02.12 20:51:36 5 : cm, Send Queue 1 packet in queue
2020.02.12 20:51:37 5 : cm, Send Queue 1 packet in queue
2020.02.12 20:51:37 5 : cm, Send Queue 1 packet in queue
2020.02.12 20:51:38 5 : cm, Send Queue 1 packet in queue
2020.02.12 20:51:38 5 : cm, Send Queue 1 packet in queue
2020.02.12 20:51:39 5 : cm, Send Queue 1 packet in queue
2020.02.12 20:51:39 4 : cm, Send Queue retry fk_Kueche for AddLinkPartner count: 2
2020.02.12 20:51:42 5 : cm, Send Queue 1 packet in queue
2020.02.12 20:51:42 4 : cm, Send Queue packet for ShutterContact fk_Kueche exists


Bleibt also die Frage, ob man die Ursache überhaupt behandeln kann. Dann bleibe ich wohl erstmal beim Symptom fixen :)

Wzut

ja die FKs sind echt verdammt zickig und ich bin mit der heutigen Situation auch nicht zufrieden, aber nach mehren Versuchen reagiert der FK wie er soll und die Nachricht verschwindet aus der Queue. Ich habe immer noch die Hoffnung die Funktion der original ELV Software nachbilden zu können, den die macht das deutlich eleganter.
Das kann sie weil sie genau weis mit wem der FK reden muß und hängt sich im richtigen Moment da ran. Die neuen Readings sind der erste Versuch dieses Wissen auch in FHEM abzubilden.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher