[GELÖST]Burstmodus abschalten sinnvoll? (HM-CC-RT-DN Heizkörper und HM-SEC-SC-2)

[FFHEM]

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

Code Auswählen Erweitern

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

[Beta-User]

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).

[Nobbynews]

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.

[FFHEM]

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