Bei uns werden 2 HM-CC-RT-DN-Heizkörperthermostate im Eingangsflur durch einen HM-SEC-SC-2 beim Öffnen der Haustür oder eines Fensters heruntergefahren (sind gepeert).
Da die Haustür oft nur sehr kurz geöffnet wird, andererseits die Thermostate durch den Burstmodus sehr schnell reagieren, werden die Heizkörper oft unnötig zugedreht und nach einer Zeit wieder aufgedreht. 10 mal am Tag Tür auf/zu -> 10 mal Ventil zu und wieder auf. Das verbraucht unnötig Batterieenergie.
Ist es sinnvoll/möglich, den Burstmodus komplett abzuschalten, so dass die Ventile erst nach den üblichen ca. 3 Minuten reagieren müssen und die Batterien dadurch geschont werden?
Muss der Burstmodus dann im HM-SEC-SC-2 und/oder den HM-CC-RT-DN abgeschaltet werden? Oder funktioniert dann das autom. Schließen garnicht mehr?
Danke vielmals,
Friedhelm
Internals:
DEF 70699A
FUUID 5eabe085-f33f-26cd-9205-1ac541a572b1ea7d
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 605
NAME HT_Flur_Gaeste_WC
NOTIFYDEV global
NR 1232
STATE CMDs_done
TYPE CUL_HM
channel_01 HT_Flur_Gaeste_WC_Weather
channel_02 HT_Flur_Gaeste_WC_Climate
channel_03 HT_Flur_Gaeste_WC_WindowRec
channel_04 HT_Flur_Gaeste_WC_Clima
channel_05 HT_Flur_Gaeste_WC_ClimaTeam
channel_06 HT_Flur_Gaeste_WC_remote
lastMsg No:3A - t:10 s:70699A d:000000 0A9CCE0E1F00
myHmUART_MSGCNT 605
myHmUART_RAWMSG 050000473A861070699A0000000A9CCE0E1F00
myHmUART_RSSI -71
myHmUART_TIME 2020-10-07 11:31:37
protLastRcv 2020-10-07 11:31:37
protRcv 605 last_at:2020-10-07 11:31:37
protSnd 1 last_at:2020-10-06 18:54:32
protState CMDs_done
rssi_at_myHmUART cnt:605 min:-83 max:-54 avg:-58.29 lst:-71
READINGS:
2020-10-06 10:14:41 Activity alive
2020-10-06 22:44:58 CommandAccepted yes
2020-05-01 11:58:49 D-firmware 1.5
2020-05-01 11:58:49 D-serialNr QEQ1462321
2020-05-01 10:45:02 PairedTo 0xFF3004
2020-05-01 10:42:08 R-backOnTime 10 s
2020-05-01 10:42:08 R-burstRx on
2020-05-01 10:42:08 R-cyclicInfoMsg on
2020-05-01 10:42:08 R-cyclicInfoMsgDis 0
2020-05-01 10:42:08 R-pairCentral 0xFF3004
2020-05-01 10:45:02 RegL_00. 00:00 01:01 02:01 09:01 0A:FF 0B:30 0C:04 0E:0A 0F:00 11:00 12:15 16:01 18:00 19:00 1A:00
2020-05-02 07:09:32 RegL_07.
2020-10-07 11:31:37 actuator 31
2020-10-07 11:31:37 battery ok
2020-10-07 11:31:37 batteryLevel 2.9
2020-10-05 16:56:27 cfgState ok
2020-10-06 18:54:32 commState CMDs_done
2020-05-25 09:29:32 controlMode auto
2020-10-07 11:31:37 desired-temp 19.5
2020-10-07 11:31:37 measured-temp 20.6
2020-10-07 11:31:37 motorErr ok
2020-05-01 10:41:01 powerOn 2020-05-01 10:41:01
2020-05-01 10:41:01 recentStateType info
2020-10-06 18:54:32 state CMDs_done
2020-10-06 18:54:32 time-request -
helper:
HM_CMDNR 58
mId 0095
peerFriend
peerOpt -:thermostat
regLst 0
rxType 140
supp_Pair_Rep 0
cmds:
TmplKey :no:1601973484.74942
TmplTs 1601973484.74942
cmdKey :0:1:0::0095:01
cmdLst:
assignHmKey noArg
burstXmit noArg
clear [readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
deviceRename newName
fwUpdate -filename- -bootTime- ...
getConfig noArg
getDevInfo noArg
getRegRaw [List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
inhibit [on|off]
raw data ...
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2- ...
regSet [prep|exec] -regName- -value- ... [-peerChannel-]
reset noArg
sysTime noArg
tplDel tmplt
tplSet_0 -tplChan-
unpair noArg
lst:
peer
peerOpt
tplChan
tplPeer
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +70699A,00,00,00
nextSend 1602063098.06745
rxt 2
vccu VCCU
p:
70699A
00
00
00
prefIO:
myHmUART
mRssi:
mNo 3A
io:
myHmUART:
-69
-69
prt:
bErr 0
sProc 0
sleeping 1
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
prs 1
rssi:
at_myHmUART:
avg -58.2942148760331
cnt 605
lst -71
max -54
min -83
shRegW:
07 04
shadowReg:
tmpl:
Attributes:
IODev myHmUART
IOgrp VCCU:myHmUART
actCycle 000:10
actStatus alive
alias HT_Flur_Gaeste_WC
autoReadReg 5_readMissing
event-on-change-reading .*
event-on-update-reading actuator,desired-temp,battery,batteryLevel
expert defReg,rawReg
firmware 1.5
group Heizkörperthermostat
model HM-CC-RT-DN
room CUL_HM
serialNr QEQ1462321
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
Ohne Burst wird der RT das nicht mitbekommen. Du könntest ein delay im SC hinterlegen, was aber ungeschickt ist, wenn du z.B. auch die Außenbeleuchtung darüber steuern wolltest.
Ich habe das ganze so gelöst, dass ich (alle) RT's nur noch (im Prinzip jeweils) mit einem virtuellen Fensterkontakt gepeert habe (ein Kanal eines virtuellen HM-Devices, ein zweiter macht häufig die Ist-Temperatur). Dann kann man via FHEM entscheiden, ob der RT davon überhaupt was mitbekommen soll (diese bursts braucht es nur in der Heizperiode, nicht außerhalb), und man kann das ganze verzögern (ich warte ca. 1,5 Min, bevor überhaupt was in dem Kanal landet). (Außerdem bin ich dann bei den Kontakten nicht mehr auf HM beschränkt, die bekommen nämlich alle so nach und nach einen "hau", grummel).
Bei Interesse: Das meiste ist dazu im Wiki zu finden (auch mit den virtuellen Temperaturen und wie man sicherstellt, dass die auch noch relevant sind), ansonsten kann ich auch gerne meinen Zusatz-Code posten, v.a., wie die Brücke vom SC zu den passenden Thermostaten gemacht ist (das ist teils eine n:m-Zuordnung).
Ist zwar nicht so ganz eine Antwort auf die Frage, aber ich habe das mit meinen MAX-Thermostaten und einem ungepeerten Fensterkontakt über ein watchdog-Device gelöst.
Erst wenn die Tür, in meinem Fall die Terassentür, länger als 15 Sekunden offen ist, werden die Thermostate runtergefahren.
Umgekehrt muss die Tür 1 Minute geschlossen sein, damit die Thermoastate wieder in die Normalposition fahren.
Also insgesamt zwei wartchdog devices.
Hallo Beta-User und Nobbynews,
vielen Dank für Eure ausführlichen Antworten, die mir sehr helfen.
Ich werde mir dann mal überlegen, wie ich es löse.
Gruß,
Friedhelm