Hallo *,
ich hab da mal wieder ein Problemchen :-)
Habe einen virtuellen Fensterkontakt angelegt, der über den Status einer "Fenster"-structure (einige Fenster im Wohnbereich) mittels DOIF/notify angetriggert wird. Dieser ist gepeert mit den Heizkörperthermostaten im Wohnbereich und sendet über DOIF/notify dorthin seine "Fenster offen" bzw. "Fenster zu" Befehle.
Das Ganze ist nach diesem Beispiel eingerichtet: http://forum.fhem.de/index.php/topic,16954.msg110792.html#msg110792 (http://forum.fhem.de/index.php/topic,16954.msg110792.html#msg110792)
Funktioniert alles auch eigentlich so, wie es soll... es wird ein Fenster aufgemacht, und nach den festgelegten 60 sec gehen die Thermostate auch auf die eingestellte Fenster-auf Temperatur und zeigen das Symbol an.
Nur: nach ca. 2 Minuten bleibt das Symbol an den Thermostaten, aber die Temperatur wird wieder auf Normaltemperatur gesetzt. Keine Ahnung warum, ich habe da keinen DOIF/notify der das machen soll. In den Logs ist auch zu sehen, dass da keine CMDs laufen, also "entscheidet" wohl das Thermostat selbst zur Temperaturrücksetzung.
Ich weiß nicht, wo das Verhalten herkommt und wie das einzustellen wäre... habt ihr eine Idee?
Hier mal das Listing eines Thermostaten:
nternals:
DEF 3B056B
HMLAN1_MSGCNT 1394
HMLAN1_RAWMSG E3B056B,0000,0F3055AA,FF,FFC4,7186103B056B0000000AA8E00B0000
HMLAN1_RSSI -60
HMLAN1_TIME 2015-12-29 11:24:04
HMLAN2_MSGCNT 1398
HMLAN2_RAWMSG E3B056B,0000,00565FA4,FF,FFD1,7186103B056B0000000AA8E00B0000
HMLAN2_RSSI -47
HMLAN2_TIME 2015-12-29 11:24:04
IODev HMLAN2
LASTInputDev HMLAN1
MSGCNT 4207
NAME eg_wz_thermostat
NR 129
NTFY_ORDER 50-eg_wz_thermostat
STATE CMDs_done
TYPE CUL_HM
channel_01 eg_wz_thermostat_Weather
channel_02 eg_wz_thermostat_Climate
channel_03 eg_wz_thermostat_WindowRec
channel_04 eg_wz_thermostat_Clima
channel_05 eg_wz_thermostat_ClimaTeam
channel_06 eg_wz_thermostat_remote
hmusb_MSGCNT 1415
hmusb_RAWMSG E3B056B,0000,0E57AD2D,FF,FFCA,7186103B056B0000000AA8E00B0000
hmusb_RSSI -54
hmusb_TIME 2015-12-29 11:24:04
lastMsg No:71 - t:10 s:3B056B d:000000 0AA8E00B0000
protCondBurst on
protLastRcv 2015-12-29 11:24:04
protResnd 1 last_at:2015-12-28 23:32:32
protSnd 157 last_at:2015-12-29 11:23:52
protState CMDs_done
rssi_HMLAN2 avg:-38.4 min:-39 cnt:5 lst:-38 max:-38
rssi_at_HMLAN1 max:-57 lst:-60 min:-92 cnt:1394 avg:-67.43
rssi_at_HMLAN2 avg:-48.6 cnt:1398 min:-51 lst:-47 max:-41
rssi_at_hmusb max:-52 lst:-54 min:-58 cnt:1415 avg:-54.49
Readings:
2015-12-29 11:07:49 Activity alive
2015-12-29 11:23:52 CommandAccepted yes
2015-12-29 11:07:49 D-firmware 1.4
2015-12-29 11:07:49 D-serialNr MEQ0448234
2015-12-25 14:53:50 PairedTo 0xA24077
2015-11-29 15:27:41 R-backOnTime 10 s
2015-11-29 15:27:41 R-btnLock off
2015-11-29 15:27:41 R-burstRx on
2015-11-29 15:27:41 R-cyclicInfoMsg on
2015-11-29 15:27:41 R-cyclicInfoMsgDis 0
2015-11-29 15:27:41 R-globalBtnLock off
2015-11-29 15:27:41 R-localResDis off
2015-11-29 15:27:41 R-lowBatLimitRT 2.1 V
2015-11-29 15:27:41 R-modusBtnLock off
2015-11-29 15:27:41 R-pairCentral 0xA24077
2015-11-29 15:27:42 R-sign off
2015-12-29 11:24:04 actuator 0
2015-12-29 11:24:04 battery ok
2015-12-29 11:24:04 batteryLevel 2.6
2015-12-29 11:07:50 controlMode auto
2015-12-29 11:24:04 desired-temp 21.0
2015-12-29 11:24:04 measured-temp 22.4
2015-12-29 11:24:04 motorErr ok
2015-12-29 11:23:52 state CMDs_done
2015-12-29 01:37:40 time-request -
Helper:
HM_CMDNR 113
PONtest 1
cSnd 11A240773B056B86042C,11A240773B056B86042A
mId 0095
rxType 140
Expert:
def 1
det 1
raw 0
tpl 0
Io:
newChn +3B056B,00,00,00
nextSend 1451384644.27832
rxt 2
vccu vccu
p:
3B056B
00
00
00
prefIO:
HMLAN2
Mrssi:
mNo 71
Io:
HMLAN1 -60
HMLAN2 -45
hmusb -54
Prt:
awake 0
bErr 0
brstWu 0
sProc 0
sleeping 1
Rspwait:
Rspwaitsec:
cmd As0C4FA4411122343B056B013900
mNo 4F
reSent 2
Q:
qReqConf
qReqStat
Role:
dev 1
prs 1
Rssi:
Hmlan2:
avg -38.4
cnt 5
lst -38
max -38
min -39
At_hmlan1:
avg -67.4340028694404
cnt 1394
lst -60
max -57
min -92
At_hmlan2:
avg -48.6037195994278
cnt 1398
lst -47
max -41
min -51
At_hmusb:
avg -54.4961130742049
cnt 1415
lst -54
max -52
min -58
Shregw:
07 04
Attributes:
IODev HMLAN1
IOgrp vccu:HMLAN2
actCycle 000:10
actStatus alive
alias EG Wohnzimmer Thermostat
autoReadReg 4_reqStatus
burstAccess 1_auto
expert 1_on
firmware 1.4
model HM-CC-RT-DN
room CUL_HM,EG Wohnzimmer
serialNr MEQ0448234
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
und hier das list vom WindowRec channel:
Internals:
DEF 3B056B03
NAME eg_wz_thermostat_WindowRec
NR 145
NTFY_ORDER 50-eg_wz_thermostat_WindowRec
STATE last:eg_wz_vFK:0
TYPE CUL_HM
chanNo 03
device eg_wz_thermostat
peerList eg_wz_vFK,
Readings:
2015-12-27 14:13:11 R-eg_wz_vFK-shCtValLo 50
2015-12-27 14:13:11 R-eg_wz_vFK-winOpnTemp 12 C
2015-11-29 15:27:44 R-sign off
2015-12-29 10:41:36 peerList eg_wz_vFK,
2015-12-29 10:41:36 state unknown
2015-12-29 11:23:52 trigLast eg_wz_vFK:0
2015-12-23 14:44:06 trig_eg_bar_fk closed
2015-12-25 14:38:05 trig_eg_bar_tk closed
2015-12-25 10:38:31 trig_eg_wz_tk closed
2015-12-29 11:23:52 trig_eg_wz_vFK 0
Helper:
peerIDsRaw ,11223401,00000000
Expert:
def 1
det 1
raw 0
tpl 0
Prt:
brstWu 1
Role:
chn 1
Shadowreg:
RegL_07:eg_wz_vFK 05:18 00:00
Attributes:
model HM-CC-RT-DN
peerIDs 00000000,11223401,
stateFormat last:trigLast
Danke!
Hat sich erledigt... hätte ich vorher das hier gelesen:
http://forum.fhem.de/index.php/topic,46074.msg378568.html#msg378568 (http://forum.fhem.de/index.php/topic,46074.msg378568.html#msg378568)
Darin wird beschrieben, dass das Wandthermostat, das ich da einsetze, die Einstellung der Temperatur wieder übersteuert.
Ich habe nun noch den WindowRec am Wandregler gepairt, damit sollte das Thema erledigt sein.
Ist zwar doppelt gemoppelt, aber damit setze ich nach meiner DOIF Regel (60 sec) die Fenster-auf Funktion, und der Wandregler übersteuert nicht mehr (er hat ja auch die 12° bekommen)
Ne, auch ne blöde Idee... das Wandthermostat hat bereits die desired-temp auf 12° gestellt, jetzt warten die Thermostate auf das Update vom Wandthermostat.
Also schalte ich halt wieder nur über das WT, das ich mit dem virtuellen FK peere. Das Peering mehrerer realer FK mit dem WT hat ja zu Problemen mit den Rückmeldungen der FK gegeben (50% hat es "rot" geleuchtet, das irritierte).
Zitatas Peering mehrerer realer FK mit dem WT hat ja zu Problemen mit den Rückmeldungen
war bei allen auch peerNeedsBurst aktiv gesetzt?
Zitat von: martinp876 am 29 Dezember 2015, 15:46:27
war bei allen auch peerNeedsBurst aktiv gesetzt?
ja, war überall gesetzt... auch war expectAES auf "off"