Hi,
ich habe ein kleines Problem. Und zwar bekommt manchmal mein Homematic Wandthermostat nicht mit wenn ein Fenster geschlossen ist. Fensterkontakt und Wandthermostat sind gepeert und die Fenstererkennung funktioniert zu 95% einwandfrei. Doch gerade heute morgen gab es den Fall dass das Wohnzimmer kalt war weil wir gestern abend kurz ein Fenster offen hatten. Meistens hilft dann Fenster kurz auf und wieder zu. Dann wird es auch wieder warm :-)
Jetzt würde ich mir gern was basteln. Ich habe an ein doif gedacht wenn das Fenster geschlossen ist und das Thermostat nach 5 Sekunden noch Fenster offen erkennt soll eine Nachricht per Telegram verschickt werden (Telegram ist schon eingerichtet). Also sowas in der Art
define ku.fd.Schiebetuer.GeschlossenErkannt doif ([ku.fk.Schiebetuer] eq "closed")) (doif (wz.wt.Heizung_WindowRec eq "open")(set gl.tb.Telegram message Wohnzimmer Fenster geschlossen nicht erkannt!))
wait 5
- Kann ich doif schachteln oder ist das nicht so elegant
- Wie kann ich den Status von wz.wt.Heizung_WindowRec richtig auslesen? Das Thermostat ist noch mit anderen Fensterkontakten gepeered. Ich fände es schön wenn es global für alle gepeerten Kontakte funktioniert.
- Vielleicht gibt es ja noch eine elegantere Lösung z.B. über notify.
Danke für Eure Hilfe!
das eleganteste wäre eine 100% erkennung. ;)
zeig mal je ein list vom fk und vom window_rec channel des thermostats.
Hier der Fensterkontakt:
Internals:
DEF 44257C
FUUID 5cb63bfb-f33f-d318-6683-f8d5e56a3dd28e23
HMLAN1_MSGCNT 6307
HMLAN1_RAWMSG E44257C,0000,04BB724F,FF,FFBC,7CA61044257C30123506010000
HMLAN1_RSSI -68
HMLAN1_TIME 2019-11-19 14:06:39
IODev gl.gw.Wemos
LASTInputDev HMLAN1
MSGCNT 18827
NAME ku.fk.Schiebetuer
NOTIFYDEV global
NR 60
NTFY_ORDER 50-ku.fk.Schiebetuer
STATE closed
TYPE CUL_HM
chanNo 01
gl.gw.Wemos_MSGCNT 12520
gl.gw.Wemos_RAWMSG 050100267CA61044257C30123506010000
gl.gw.Wemos_RSSI -38
gl.gw.Wemos_TIME 2019-11-19 14:06:39
lastMsg No:7C - t:10 s:44257C d:301235 06010000
protCmdDel 2
protLastRcv 2019-11-19 14:06:39
protRcv 12551 last_at:2019-11-19 14:06:39
protRcvB 1497 last_at:2019-11-19 06:49:25
protResnd 9 last_at:2019-04-20 01:42:06
protResndFail 2 last_at:2019-04-20 02:36:09
protSnd 6946 last_at:2019-11-19 14:06:39
protState CMDs_done
rssi_at_HMLAN1 cnt:6307 min:-94 max:-51 avg:-64.9 lst:-68
rssi_at_gl.gw.Wemos cnt:12520 min:-58 max:-32 avg:-39.57 lst:-38
READINGS:
2019-04-16 22:33:16 Activity alive
2018-07-19 08:03:50 CommandAccepted no
2017-09-16 11:54:39 D-firmware 1.0
2017-09-16 11:54:39 D-serialNr MEQ1723075
2019-04-19 23:01:38 PairedTo 0x301235
2017-09-16 12:20:32 R-cyclicInfoMsg on
2017-09-16 12:20:33 R-eventDlyTime 0 s
2017-09-16 12:20:32 R-pairCentral 0x301235
2017-09-16 12:20:32 R-sabotageMsg on
2017-09-16 12:20:33 R-sign on
2019-04-19 23:01:38 RegL_00. 00:00 02:01 09:01 0A:30 0B:12 0C:35 10:01 14:06
2019-04-19 23:01:39 RegL_01. 00:00 08:01 20:9C 21:00 30:06
2017-09-16 11:54:41 aesCommToDev ok
2017-09-16 11:54:40 aesKeyNbr 00
2019-11-19 14:06:39 alive yes
2019-11-19 14:06:39 battery ok
2019-11-19 14:06:39 contact closed (to VCCU)
2019-04-19 23:01:25 powerOn 2019-04-19 23:01:25
2019-11-19 14:06:39 recentStateType info
2019-11-19 14:06:39 sabotageError off
2019-11-19 14:06:39 state closed
2017-10-01 17:31:23 trigDst_2E75D1 noConfig
2017-10-01 17:31:22 trigDst_2E7BB3 noConfig
2017-10-01 17:31:23 trigDst_301235 noConfig
2017-10-01 17:31:22 trigDst_5241B3 noConfig
2017-10-10 15:23:32 trigDst_HM_2E75D1 noConfig
2017-10-10 15:23:31 trigDst_HM_2E7BB3 noConfig
2017-10-10 15:23:31 trigDst_HM_3CF0F8 noConfig
2017-10-10 15:23:31 trigDst_HM_5241B3 noConfig
2019-11-19 06:49:25 trigDst_az.ht.Heizung noConfig
2019-11-19 06:49:25 trigDst_ku.ht.Heizung noConfig
2019-11-19 06:49:26 trigDst_wz.Ht.Couch noConfig
2019-11-19 06:49:26 trigDst_wz.ht.Essecke noConfig
2019-11-19 06:49:26 trigger_cnt 72
helper:
HM_CMDNR 124
PONtest 0
cSnd 0130123544257C0103,0130123544257C0103
getCfgList all
getCfgListNo ,4
mId 00C7
peerFriend peerAct,peerVirt
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
newCh 1
newChn +44257C,00,00,00
nextSend 1574168799.29818
prefIO
rxt 2
vccu VCCU
p:
44257C
00
00
00
mRssi:
mNo 7C
io:
HMLAN1:
-68
-68
gl.gw.Wemos:
-30
-30
prt:
bErr 0
sProc 0
sleeping 0
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
rpt:
IO gl.gw.Wemos
flg A
ts 1574168799.20831
ack:
HASH(0x20b4a30)
7C800230123544257C00
rssi:
at_HMLAN1:
avg -64.9007452037417
cnt 6307
lst -68
max -51
min -94
at_gl.gw.Wemos:
avg -39.5717252396166
cnt 12520
lst -38
max -32
min -58
shadowReg:
Attributes:
IODev HMLAN1
IOgrp VCCU
actCycle 002:50
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-SEC-SCo
peerIDs
room Kueche
serialNr MEQ1723075
subType threeStateSensor
Und hier der Window_rec
Internals:
DEF 31DC4203
FUUID 5cb63bfd-f33f-d318-73b5-d420a606779dfe72
NAME wz.wt.Heizung_WindowRec
NOTIFYDEV global
NR 83
NTFY_ORDER 50-wz.wt.Heizung_WindowRec
STATE last:wz.fk.Garten:closed
TYPE CUL_HM
chanNo 03
device wz.wt.Heizung
peerList ku.fk.Schiebetuer,wz.fk.Garten,
READINGS:
2017-10-01 20:32:20 R-sign off
2019-03-17 09:23:50 RegL_01. 00:00 08:00
2019-03-17 09:23:51 RegL_03.ku.fk.Schiebetuer_chn-01 00:00 04:32
2019-03-17 09:23:52 RegL_03.wz.fk.Garten_chn-01 00:00 04:32
2019-03-17 09:23:52 RegL_07.ku.fk.Schiebetuer_chn-01 00:00 05:0A
2019-03-17 09:23:52 RegL_07.wz.fk.Garten_chn-01 00:00 05:18
2019-04-16 22:33:27 peerList ku.fk.Schiebetuer,wz.fk.Garten,
2019-04-16 22:33:27 state unknown
2019-11-19 06:48:44 trigLast wz.fk.Garten:closed
2019-11-19 06:48:44 trig_wz.fk.Garten Closed_236
helper:
peerFriend peerSens,peerVirt
peerOpt 3:thermostat,7p:thermostat
regLst 1,3p,7p
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
Attributes:
model HM-TC-IT-WM-W-EU
peerIDs 00000000,44257C01,58BBFC01,
room Wohnzimmer
stateFormat last:trigLast
Zitatwenn das Fenster geschlossen ist und das Thermostat nach 5 Sekunden noch Fenster offen erkennt
Sowas kenne ich von Homematic (bei mir) nicht.
Da wäre zuerst mal zu klären, ob der Fenstersensor überhaupt mitbekommen hat das das Fenster geschlossen wurde?
ZitatWie kann ich den Status von wz.wt.Heizung_WindowRec richtig auslesen? Das Thermostat ist noch mit anderen Fensterkontakten gepeered.
War, glaube ich, hier schon mal Thema. Forensuche schon ausprobiert?
Doch das kann ich nachvollziehen.
Und ja der Fenstersensor erkennt das geschlossene Fenster und meldet auch brav an fhem...
...aber auf dem WT ist immer noch das Fenster-Offen-Symbol (und somit auch die Heizung "unten").
Ich denke es ging halt das Funktelegramm verloren?
- Wobei ich kein "rotes Blinken" am FK gesehen habe (zumindest nicht bewusst)...
- Wobei der FK ja ein paar Mal wiederholt!?
Was ich mir da "gebastelt" habe ist folgendes:
Ein notify was eben auf "geschlossenes Fenster" lauscht:
defmod nCheckWinOpenReading notify Fenster_.*:closed {my_CheckWinOpenReading($NAME, "notify")}
Und eben eine Sub, die dann gleich und mit einem at später noch mal prüft (weil es schon mal etwas dauern kann, bis das Reading "umschlägt")...
Hier die Sub für myUtils:
#########################################
# Helper to check if a Wandthermostat missed a closed message of a window
sub my_CheckWinOpenReading($$)
{
my ($Device, $CallOption) = @_;
my @DeviceParts = split(/_/, $Device);
my $Channel = "Wandthermostat_" . $DeviceParts[1] . "_WindowRec";
my $WinOpenReading = (split(/:/, ReadingsVal($Channel, "trigLast", "x:open")))[1];
my $AtName = "atCheckWinOpenReading_" . $Device;
Log3(undef, 3, "my_CheckWinOpenReading Device: $Device ChannelName: $Channel WinOpenReading: $WinOpenReading CallOption: $CallOption");
if($WinOpenReading eq "open")
{
if($CallOption eq "notify")
{
fhem("defmod $AtName at +00:00:10 {my_CheckWinOpenReading(\"$Device\", \"timer\")}");
}
elsif($CallOption eq "timer")
{
fhem("set $myTelegramBot message $Channel hat falschen WinOpenStatus.");
}
}
}
Wichtig ist halt die "Namensgebung", damit man von Fenster auf WT schließen kann.
Bei mir "einfach", da die Namensgebung wie folgt ist:
Fenster_Raum
Wandthermostat_Raum_Kanal
Ob das Reading was mit dem "icon" (Fenster-Offen) und somit mit dem Runterdrehen der Heizung zu tun hat...
...hab ich noch nicht zweifelsfrei herausgefunden...
Vielleicht hilft es, vielleicht wird es auch durch mehr "Tester" klarer was man da tun kann... ;)
Gruß, Joachim
Ich habe zwischenzeitlich alle direkten FK-Peerings aufgehoben und arbeite nur noch mit etwas myUtils Code, ähnlich wie MadMax-FHEM, nur dass bei mir die Zugehörigkeiten über userAttr festgelegt werden.
Weitere Hinweise und links einsch. kleiner commandref ist hier zu finden:
https://forum.fhem.de/index.php/topic,104523.msg984028.html#msg984028
@teichtaucher
die list sind ja ziehmlich outdated.
fhem weiss nicht viel über die peerings der devices.
ich empfehle erst mal ein "get hminfo configCheck" ab zu arbeiten.
ich würde erst alle daten in fhem löschen mit "set clear all" und dann alles neu einlesen mit "set getConfig".
am fehlverhalten des fk ändert das allerdings nichts.
eventuell verbessert sich die erkennung, wenn das register eventDlyTime im fk auf zb 1s gesetzt wird.
Dieses Phänomen kenne ich leider auch. Obwohl alle Zustände korrekt erkannt werden (alle Readings im Fensterkontakt und im Wandthermostat sehen das Fenster als geschlossen an) bleibt das Fenster-Offen-Icon in der Anzeige des Wandthermostats. Und damit unterbleibt die Meldung an die dazugehörigen Thermostaten.
Meine Lösung dazu: in einem DOIF prüfe ich, ob Wandthermostat_Climate:desired-temp den Wert meiner Fenster-offen-Temperatur hat UND gleichzeitig, ob der Status des dazugehörigen Fensters closed ist. Wenn ja, kommt eine entsprechende Meldung.
LG
Holger