HM-CC-RT-DN: BurstXmit - Stromverbrauch?

[M_I_B]

Moin Kinnaz,

ich sende derzeit bei jedem Änderungsbefehl einen Burst hinterher. Bei den meisten Thermostaten passiert das genau 4 mal am Tag, bei einigen 1-3 mal.
Nun habe ich aber den Eindruck, das der Burst einen ungewöhnlich hohen Stromverbrauch generiert... rein subjektiv scheinen die Batterien deutlich schneller zur Neige zu gehen. Vielleicht liegt es auch nur daran, das gerade "Winter" ist und die Teile mehr zu tun haben... 

Daher mal meine Frage an Euch, welche Erfahrungen Ihr so mit den Teilen bezgl. Stromverbrauch im Zusammenhang mit einem Burst gesammelt habt... Vielleicht bilde ich mir das ja auch nur ein ...

[DeeSPe]

Also meine Thermostaten habe ich im Februar vor zwei Jahren gekauft. Habe sie an Tag 1 auf Burst gesetzt und meine Batterien sind immer noch die ersten.

Gruß
Dan

[frank]

bei burst, darfst du nicht nur ein device betrachten.

bei jedem burst, egal von wem, wachen alle devices auf, die burst aktiviert haben, um herrauszufinden, für wen der burst gedacht ist. ausserdem schlafen sie nicht mehr wirklich, da sie ja auf burst lauschen.

wenn nun noch schlechter funk dazu kommt, wird auch noch alles wiederholt, eventuell mehrfach.

vielleicht noch burst in der nachbarschaft?
und gepeerte fensterkontakte sollen ja auch sofort reaktonen bewirken.

[M_I_B]

... also Burst in der Nachbarschaft kann ich ausschließen. Ich scheine der Einzige im Dorf zu sein, der mit HM & Co. rum macht (ein paar MAXen gibt's, die aber nur mit Richtantenne zu empfangen sind...)
Die GeBursteten Nachrichten kommen bei mir alle zur gleichen Zeit, also z.B. in der WerkWoche um 05:30 an alle Thermostaten der Befehl "mach ma warm; muss auf Arbeit", dann um 08:00 "mach ma kalt; keine da"... das Ganze am späten Nachmittag und am späten Abend noch mal und, wie gesagt, zeitgleich.

Ich habe es leider nicht dokumentiert, aber in einem Jahr sind bestimmt bei einigen Thermostaten 2 Satz Bakterien drauf gegangen, jetzt mit dem Burst (seit einigen Wochen) scheint das massiv zugenommen zu haben...

[frank]

dass dein eh schon hoher batterieverbrauch durch burst steigt, ist ja erst mal normal.

poste mal hminfo configCheck und protoEvents.
sind fk gepeert, also häufiges schliessen/öffnen der regler?
eventuell auch interne fenster-offen-erkennung aktiv?
ist die vorlauftemperatur quasi konstant, oder müssen die regler ständig nachregeln?
du kannst ja mal die actuator änderungen pro tag summieren.

[Beta-User]

Das kommt mir auch viel vor, zwei Sätze je Winter. Meine laufen allerdings mit selten geänderten Wochenpgrogrammen, dabei gibt es aber eine ganze Anzahl von (in der Regel leicht verzögert sendenden) Fensterkontakten mit direktem peering (=burst).

Aber warum machst du von der Zentrale aus Burst? Da kommt es doch in der Regel auf die 2,5 Min. nicht an, die es max. dauert, bis der RT jeweils seine News abholt, oder? Da würde ich lieber die Zeit leicht nach vorne verschieben...

[M_I_B]

Also...

FK's gibt es nicht und in den Reglern habe ich die Erkennung deaktiviert. Das war eigentlich nicht nötig, da die Regler eh ein offenes Fenster nie erkannt haben, was vermutlich an der Bauart/Position liegt.
Das mit dem Burst hatte ich gemacht im Zusammenhang mit dem Umschreiben meiner Regelung. Ich wollte nicht immer warten, um kontrollieren zu können, ob alles dort angekommen ist wo es hingehört. Da aber in der Beziehung alles sauber ist, könnte ich das auch wieder raus nehmen.
Der Vorlauf ist konstant. Will sagen tagsüber konstant, nachts anders konstant. Viel Nachregeln im Sinne von "Hüh & Hop" müssen die also nicht.

Ich habe mir gerade mal eine Tabelle angelegt und werde mal dokumentieren, wann ich wo die Bakterien habe wechseln müssen. Dann kann ich zumindest nach einiger Zeit von subjektiv auf objektiv switchen, was den Verbrauch anbelangt.

HMinfo:

Code Auswählen Erweitern

Internals:
   CFGFN      /opt/fhem/_INC/900_Global.cfg
   NAME       hm
   NR         1125
   NTFY_ORDER 50-hm
   STATE      updated:2017-12-24 15:02:26
   TYPE       HMinfo
   Version    01
   READINGS:
     2017-12-24 15:02:26   CRIT__protocol  -
     2017-12-17 00:32:36   C_sumDefined    entities:209,device:43,channel:175,virtual:5
     2017-12-24 15:02:26   ERR__protocol   CmdDel:2,IOerr:1,ResndFail:2
     2017-12-24 15:02:26   ERR__unreachable 0
     2017-12-24 15:02:26   I_actTotal      alive:13,dead:0,unkn:12,off:0
     2017-12-24 15:02:26   I_autoReadPend  17
     2017-12-24 15:02:26   I_rssiMinLevel  59<:7 60>:9 80>:3 99>:0
     2017-12-24 15:02:26   I_sum_battery   ok:16,
     2017-12-24 15:02:26   I_sum_sabotageError off:1,
     2017-12-24 15:02:26   W__protocol     CmdPend:12,Resnd:13
   nb:
     cnt        0
Attributes:
   room       System
   sumERROR   battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed
   sumStatus  battery,sabotageError,powerError,motor
   webCmd     update:protoEvents short:rssi:peerXref:configCheck:models

ConfigCheck (die Fehlenden sind ok; einige sind eingerichtet, werden aber derzeit nicht verwendet (Batterie raus))

Code Auswählen Erweitern

configCheck done:

missing register list
    HM1RM1: RegL_00.
    HM1RM2: RegL_00.
    HM2DI1: RegL_00.
    HM2DI1_1: RegL_01.
    HM2DI1_2: RegL_01.
    HM2SD1: RegL_00.
    HM2SD1_1: RegL_01.
    HM2SD1_2: RegL_01.
    HM2SD1_3: RegL_01.
    HM2TA1: RegL_00.
    HM2TA1_1: RegL_01.
    HM2TA1_2: RegL_01.
    HM2TH1: RegL_00.
    HM2TH2: RegL_00.
    HM2TH3: RegL_00.
    HM4SW3: RegL_00.
    HM4SW3_1: RegL_01.
    HM4SW3_2: RegL_01.
    HM4SW3_3: RegL_01.
    HM4SW3_4: RegL_01.
    HM4SW4: RegL_00.
    HM4SW4_1: RegL_01.
    HM4SW4_2: RegL_01.
    HM4SW4_3: RegL_01.
    HM4SW4_4: RegL_01.
    HM5TH2: .RegL_00.
    HM5TH2_1: .RegL_01.
    HM5TH2_2: .RegL_01.,.RegL_07.,.RegL_08.,.RegL_09.
    HM5TH2_3: .RegL_01.
    HM5TH2_4: .RegL_01.
    HM5TH2_5: .RegL_01.
    HM6SP1: RegL_00.
    HM6SP1_1: RegL_01.
    HM6SP1_2: RegL_01.
    HM6SP1_F: RegL_01.
    HM6SP1_I: RegL_01.
    HM6SP1_P: RegL_01.
    HM6SP1_U: RegL_01.
    HM6SP2: RegL_00.
    HM6SP2_1: RegL_01.
    HM6SP2_2: RegL_01.
    HM6SP2_F: RegL_01.
    HM6SP2_I: RegL_01.
    HM6SP2_P: RegL_01.
    HM6SP2_U: RegL_01.
    HM6TA1: RegL_00.
    HM6TA1_1: RegL_01.
    HM6TA1_2: RegL_01.
    HM6TA1_3: RegL_01.
    HM6TA1_4: RegL_01.
    HM6TA1_5: RegL_01.
    HM6TA1_6: RegL_01.
    HM8SW1: RegL_00.
    HM8SW1_1: RegL_01.
    HM8SW1_2: RegL_01.
    HM8SW1_3: RegL_01.
    HM8SW1_4: RegL_01.
    HM8SW1_5: RegL_01.
    HM8SW1_6: RegL_01.
    HM8SW1_7: RegL_01.
    HM8SW1_8: RegL_01.
    HM8SW2: RegL_00.
    HM8SW2_1: RegL_01.
    HM8SW2_2: RegL_01.
    HM8SW2_3: RegL_01.
    HM8SW2_4: RegL_01.
    HM8SW2_5: RegL_01.
    HM8SW2_6: RegL_01.
    HM8SW2_7: RegL_01.
    HM8SW2_8: RegL_01.
    HM8TA1: RegL_00.
    HM8TA1_1: RegL_01.
    HM8TA1_2: RegL_01.
    HM8TA1_3: RegL_01.
    HM8TA1_4: RegL_01.
    HM8TA1_5: RegL_01.
    HM8TA1_6: RegL_01.
    HM8TA1_7: RegL_01.
    HM8TA1_8: RegL_01.

peer not verified. Check that peer is set on both sides
    VD1.1 p:HM6TA1_1
    VD1.1 p:HM6TA1_2
    VD1.1 p:HM6TA1_3
    VD1.1 p:HM6TA1_4
    VD1.1 p:HM6TA1_5
    VD1.1 p:HM6TA1_6

PairedTo missing/unknown
    HM2DI1
    HM2SD1
    HM2TA1
    HM2TH2
    HM2TH3
    HM4SW3
    HM4SW4
    HM5TH2
    HM6SP1
    HM6SP2
    HM6TA1
    HM8SW1
    HM8SW2
    HM8TA1

templist mismatch
    HM5TH1_2: file: ././tempList.cfg for HM5TH1_2 does not exist
    HM5TH2_2: file: ././tempList.cfg for HM5TH2_2 does not exist
    HM6TH01_4: file: ././tempList.cfg for HM6TH01_4 does not exist
    HM6TH02_4: file: ././tempList.cfg for HM6TH02_4 does not exist
    HM6TH03_4: file: ././tempList.cfg for HM6TH03_4 does not exist
    HM6TH04_4: file: ././tempList.cfg for HM6TH04_4 does not exist
    HM6TH05_4: file: ././tempList.cfg for HM6TH05_4 does not exist
    HM6TH06_4: file: ././tempList.cfg for HM6TH06_4 does not exist
    HM6TH07_4: file: ././tempList.cfg for HM6TH07_4 does not exist
    HM6TH08_4: file: ././tempList.cfg for HM6TH08_4 does not exist
    HM6TH09_4: file: ././tempList.cfg for HM6TH09_4 does not exist
    HM6TH10_4: file: ././tempList.cfg for HM6TH10_4 does not exist

... und die Protos:

Code Auswählen Erweitern

protoEvents done:
    name    :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr     
    HM1IR1  : done           |  -       | 4:       |  -       #  -       |  -       |  -       |  -       
    HM1IR2  : done           |  -       | 7:       |  -       #  -       |  -       |  -       |  -       
    HM1IR3  : done           |  -       | 6:       |  -       #  -       |  -       |  -       |  -       
    HM1NV1  : processing...  | 5 pending| 3791:    | 611:     # 1060     | 179:     |  -       | 4:       
    HM1RM1  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM1RM2  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM1RM3  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM2BB1  : done           |  -       | 13:      |  -       #  -       |  -       |  -       |  -       
    HM2BB2  : done           |  -       | 33:      |  -       #  -       |  -       |  -       |  -       
    HM2DI1  : done           |  -       | 131:     | 6:       #  -       |  -       |  -       |  -       
    HM2SD1  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM2TA1  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM2TH1  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM2TH2  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM2TH3  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM4NV1  : done           |  -       | 67:      | 2:       # 1        | 1:       |  -       |  -       
    HM4SW1  : done           |  -       | 3710:    | 108:     # 561      | 27:      |  -       | 1:       
    HM4SW2  : done           |  -       | 14:      |  -       #  -       |  -       |  -       |  -       
    HM4SW3  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM4SW4  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM4TB1  : done           |  -       | 81:      |  -       #  -       |  -       |  -       |  -       
    HM5TH1  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM5TH2  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM6SP1  : done           |  -       | 451:     |  -       #  -       |  -       |  -       |  -       
    HM6SP2  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM6TA1  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM6TA2  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM6TH01 : done           |  -       | 4:       |  -       #  -       |  -       |  -       |  -       
    HM6TH02 : done           |  -       | 4:       |  -       #  -       |  -       |  -       |  -       
    HM6TH03 : done           |  -       | 8:       | 4:       #  -       |  -       |  -       |  -       
    HM6TH04 : done_Errors:1  |  -       | 5:       | 3:       # 3        | 1:       |  -       |  -       
    HM6TH05 : done_Errors:1  |  -       | 5:       | 3:       # 3        | 1:       |  -       |  -       
    HM6TH06 : done_Errors:1  |  -       | 5:       | 3:       # 3        | 1:       |  -       |  -       
    HM6TH07 : done_Errors:1  |  -       | 6:       | 3:       # 3        | 1:       |  -       |  -       
    HM6TH08 : done           |  -       | 11:      | 4:       #  -       |  -       |  -       |  -       
    HM6TH09 : done_Errors:1  |  -       | 7:       | 3:       # 3        | 1:       |  -       |  -       
    HM6TH10 :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM8SW1  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM8SW2  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM8TA1  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
================================================================================================================
    sum     5                |5         |8363      |750       #1637      |212       |0         |5         

    CUL_HM queue length:1

    requests pending
    ----------------
    autoReadReg          : HM1RM1 HM1RM2 HM2DI1 HM2SD1 HM4SW3 HM4SW4 HM5TH2 HM6SP1 HM6SP2 HM8SW1 HM8SW2
        recent           : none
    status request       : HM1RM1 HM1RM2 HM1RM3 HM2SD1 HM4NV1 HM4SW1 HM4SW2 HM4SW3 HM4SW4 HM6SP1 HM6SP2 HM8SW1 HM8SW2
    autoReadReg wakeup   : HM2TA1 HM2TH1 HM2TH2 HM2TH3 HM8TA1
    status request wakeup:
    autoReadTest         :

    IODevs:SCC3:Initialized condition:-
           UFO1:opened pending=1 condition:ok
           VCCU:SCC3:ok,UFO1:ok, pending= condition:-

[martinp876]

Grundsätzlich kann man einschalten über Attribute, dass fhem immer einen burst sendet und damit sofort.
Empfehlen kann ich es nicht, verstehen auch nicht. Es gibt nur wenig Gründe bei einem trägen System wie einer Heizung nicht durchschnittlich 1,5 min, Max 3min warten zu können. Die burst heben den Energieverbrauch aller burst devices in Reichweite. Je mehr burst im System um so höher, egal wer an wen sendet.

[frank]

die fehler aus dem configcheck solltest du genau checken. wenn es wirklich alles "tote" devices ohne batterie sind, setze autoreadreg=0, sonst versucht fhem unnötig diese an zu funken. eventuell alle 30 min. hoffentlich dann nicht auch noch mit burst.

welche sind die thermostate? die namen sind wohl extra unkenntlich gemacht. 
die mit 3790 sends sind was?

[M_I_B]

... genau checken. ... setze autoreadreg=0

... guter Hinweis! Werde ich die Tage mal durchforsten und einstellen. Solche "Geparkten" entstehen bei mir hauptsächlich dadurch, das ich i.d.R. über aktuellen Bedarf einkaufe, alle einbinde und beschrifte und dann erst nach und nach verbaue. Der Tag hat zwar schon 38 Stunden (24h ein Tag + 12 die Nacht + hier ne Stunde & da ne Stunde), aber irgendwie fehlt dann doch immer noch Zeit oder anderes Material, um alles in einem Rutsch fertig zu stellen...
Ein paar Geräte zicken aber auch gerne mal so herum. Mein spezieller Freund ist z.B. HM1NV1 (HM-LC-SW1-BA-PCB), welcher ein 63A Schütz ansteuert. Obwohl der empfangsseitig am dichtesten am UFO ist und perfekte RSSI- Werte generiert, steigt der öfter mal aus und ist teilweise nicht ansprechbar. Der wird zeitnah durch einen WeMOS ersetzt und landet in der mit "eQ3-Schrott" beschrifteten Kiste ^^

welche sind die thermostate? die namen sind wohl extra unkenntlich gemacht. 
die mit 3790 sends sind was?

Hu? Ich habe nix unkenntlich gemacht. Thermostate sind bei mir immer HMxTHy_z, in diesem Fall die Heizkörperthermostate HM5THx_y, wobei x=Durchnummerierung (00-99) und y=int. Kanal (desired temp = 4)

3790 finde ich gar nicht; meinst Du 3791 und 3710? Der 3791 ist der oben genannte HM-LC-SW1-BA-PCB, der mit 3710 ist ein 4CH-Hutschienenaktor HM-LC-SW4-DR. Der hat auch viel zu tun; Außenlicht via Bewegungsmelder und viele Katzen umzu. Deshalb will ich die PIR bald durch Radar ersetzen oder ggf. PIR und Radar kombinieren. Eine Auswahl verschiedener Module liegt schon da; muss ich nur noch mal durchtesten, welche dafür am besten zu gebrauchen sind...

Unabhängig davon habe ich nun mal bei den Thermostaten den Burst komplett heraus genommen. Hat ja die vergangenen zwei Wochen alles so funktioniert wie erwartet und ist somit hinfällig...

BTW: Heute Abend werde ich mal den Rest der Batterien tauschen; sieht übel aus im Moment (siehe Anlache).
Muss ich denn nach Entfernen der Burst- Befehle an den Thermostaten noch was zurücksetzen, damit die nicht mehr 24/7 auf Befehle horchen? Denn Badezimmer hatte ich (resp. meine Holde via telefonischem Durchsprechen) gestern erst getauscht und sind jetzt bereits von 3,2V auf 2,9V runter... Bisschen reichlich...

[frank]

LC-SW1-BA-PCB ist laut liste ein burst device. 
das erklärt dann einiges.

[M_I_B]

LC-SW1-BA-PCB ist laut liste ein burst device. 
das erklärt dann einiges.

... hu? Wie Du meinen? Raff gerade den Zusammenhang nicht...

[frank]

dieser aktor hat scheinbar burst fest eingestellt.
demnach wurden eventuell 3791 befehle mit burst gesendet. vielleicht kommen sogar noch die 611 resends dazu.

erinnere dich: jeder burst befehl weckt alle devices, die im burst mode sind.

[M_I_B]

... ahhh ja, jetzt hab ich's, was Du meinst ... Dauert halt bei mir manchmal etwas länger
Ja, damit hast Du wahrscheinlich recht. Ist halt die Frage, wie oft der tatsächlich sendet; muss ich mal mitloggen... Oder ich schmeiß den gleich raus. Trotz DauerBurst (wie Du sagst) rafft der oft nicht, das er gemeint ist. Da stauen sich dann oft ohne Ende Kommandos in dem Teil, die einfach nicht abgearbeitet werden; sehr unzuverlässig. Da kommt dann z.B. so'n Schwachsinn raus wie u.s., was ich gerade gelistet habe; man beachte "STATE" und "state", was seit Tagen "set_on" da stehen hat so wie "protState" im Status "CMDs_pending" seit Tagen. Zudem "sabotageAttackId_ErrIoId_F10000 cnt:3"... Was für ein Schwachsinn... das ding hat m.E. voll den Schuss...

Code Auswählen Erweitern

Internals:
   .triggerUsed 1
   CFGFN      /opt/fhem/_HW/HM.aktoren.cfg
   DEF        361F53
   IODev      UFO1
   LASTInputDev UFO1
   MSGCNT     49922
   NAME       HM1NV1
   NOTIFYDEV  global
   NR         628
   SCC3_MSGCNT 25518
   SCC3_RAWMSG A0E128002361F53F100000101C80033::-88.5:SCC3
   SCC3_RSSI  -88.5
   SCC3_TIME  2018-01-12 10:54:33
   STATE      set_on
   TYPE       CUL_HM
   UFO1_MSGCNT 24404
   UFO1_RAWMSG RE9CAD93B,0201,0002FF4C,FF,FFCD,138002361F53F100000101C80033
   UFO1_RSSI  -51
   UFO1_TIME  2018-01-12 10:54:33
   lastMsg    No:13 - t:02 s:361F53 d:F10000 0101C80033
   protCmdDel 6319
   protIOdly  230 last_at:2018-01-12 10:54:38
   protIOerr  58 last_at:2018-01-12 10:39:03
   protLastRcv 2018-01-12 10:54:33
   protResnd  5714 last_at:2018-01-12 10:54:17
   protResndFail 1768 last_at:2018-01-12 10:54:11
   protSnd    28057 last_at:2018-01-12 10:54:33
   protState  CMDs_pending
   rssi_SCC3  max:-50 cnt:15222 lst:-93 min:-102 avg:-92.21
   rssi_UFO1  min:-93 lst:-51 avg:-51.2 max:-49 cnt:11043
   rssi_at_SCC3 cnt:25518 max:-80.5 avg:-87.03 lst:-88.5 min:-109.5
   rssi_at_UFO1 max:-50 cnt:24404 lst:-51 min:-63 avg:-52.72
   READINGS:
     2018-01-07 15:55:02   .D-devInfo      410100
     2018-01-07 15:55:02   .D-stc          10
     2018-01-07 15:58:55   .R-intKeyVisib  invisib
     2018-01-07 15:58:55   .R-ledMode      on
     2018-01-07 15:58:55   .R-lowBatLimitBA 14 V
     2018-01-07 15:58:56   .peerListRDate  2018-01-07 15:58:56
     2018-01-12 10:54:33   .protLastRcv    2018-01-12 10:54:33
     2018-01-12 10:54:33   CommandAccepted yes
     2018-01-07 15:55:02   D-firmware      1.7
     2018-01-07 15:55:02   D-serialNr      MEQ0592140
     2018-01-07 15:58:55   PairedTo        0xF10000
     2018-01-07 15:58:55   R-pairCentral   0xF10000
     2018-01-07 15:58:56   R-sign          off
     2018-01-07 15:58:55   RegL_00.        02:01 05:40 0A:F1 0B:00 0C:00 12:8C  00:00
     2018-01-07 15:58:56   RegL_01.        08:00 00:00
     2018-01-12 10:54:33   battery         ok
     2018-01-12 10:54:33   deviceMsg       on (to VCCU)
     2018-01-12 10:54:33   level           100
     2018-01-12 10:54:33   pct             100
     2018-01-12 10:54:33   recentStateType ack
     2018-01-10 22:38:44   sabotageAttackId_ErrIoId_F10000 cnt:3
     2018-01-12 10:54:33   state           set_on
     2018-01-12 10:54:33   timedOn         off
   cmdStack:
     ++B011F10000361F530201C80000
   helper:
     HM_CMDNR   20
     cSnd       11F10000361F530201C80000,11F10000361F530201C80000
     dlvl       C8
     dlvlCmd    ++A011F10000361F530201C80000
     mId        006C
     regLst     ,0,1,3p
     rxType     2
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +361F53,00,00,00
       nextSend   1515750873.89461
       rxt        0
       vccu       VCCU
       p:
         361F53
         00
         00
         00
     mRssi:
       mNo        13
       io:
         UFO1       -49
     prt:
       bErr       0
       sProc      2
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rssi:
       SCC3:
         avg        -92.2138352384715
         cnt        15222
         lst        -93
         max        -50
         min        -102
       UFO1:
         avg        -51.2094539527302
         cnt        11043
         lst        -51
         max        -49
         min        -93
       at_SCC3:
         avg        -87.0360921702325
         cnt        25518
         lst        -88.5
         max        -80.5
         min        -109.5
       at_UFO1:
         avg        -52.72242255368
         cnt        24404
         lst        -51
         max        -50
         min        -63
     tmpl:
Attributes:
   IODev      VCCU
   IOgrp      VCCU
   alias      Schütz 1
   autoReadReg 4_reqStatus
   devStateIcon off|set_on:euro@gray on|set_off:euro@lime
   expert     2_raw
   firmware   1.7
   group      Energie
   model      HM-LC-SW1-BA-PCB
   msgRepeat  3
   peerIDs    00000000,
   room       _90 HW - HM.SW,270 - Energie
   serialNr   MEQ0592140
   subType    switch
   webCmd     :

[frank]

hilfe, ... das ist ja noch viel krasser.

Code Auswählen Erweitern

   protCmdDel 6319
   protIOdly  230 last_at:2018-01-12 10:54:38
   protIOerr  58 last_at:2018-01-12 10:39:03
   protLastRcv 2018-01-12 10:54:33
   protResnd  5714 last_at:2018-01-12 10:54:17
   protResndFail 1768 last_at:2018-01-12 10:54:11
   protSnd    28057 last_at:2018-01-12 10:54:33


der deutliche unterschied zu hminfo protoevents liegt wohl daran, dass hminfo nur die daten bis heiligabend kennt:

Code Auswählen Erweitern

   STATE      updated:2017-12-24 15:02:26

mach mal:
set hm update
und dann ein aktuelles:
get hm protoEvents

den aktor solltest du umgehend ersetzen. hast du nicht irgendein anderen 230v aktor?

[M_I_B]

... der Aktor fliegt zeitnah in die Tonne; wie gesagt kommt da ein WeMOS hin, so bald ich Zeit habe. Nachher versuche ich erst einmal einen FactoryReset... Mal schauen, was passiert...

Code Auswählen Erweitern

protoEvents done:
    name    :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr     
    HM1IR1  : done           |  -       | 27:      |  -       #  -       |  -       |  -       |  -       
    HM1IR2  : done           |  -       | 36:      |  -       #  -       |  -       |  -       |  -       
    HM1IR3  : done           |  -       | 32:      |  -       #  -       |  -       |  -       |  -       
    HM1NV1  : processing...  |  -       | 750:     | 689:     # 535      | 224:     |  -       | 7:       
    HM1RM1  : done           |  -       | 1:       |  -       #  -       |  -       |  -       |  -       
    HM1RM2  : done           |  -       | 2:       |  -       #  -       |  -       |  -       |  -       
    HM1RM3  : done           |  -       | 1:       |  -       #  -       |  -       |  -       |  -       
    HM2BB1  : done           |  -       | 25:      |  -       #  -       |  -       |  -       |  -       
    HM2BB2  : done           |  -       | 64:      |  -       #  -       |  -       |  -       |  -       
    HM2DI1  : done           |  -       | 266:     | 21:      #  -       |  -       |  -       |  -       
    HM2SD1  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM2TA1  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM2TH1  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM2TH2  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM2TH3  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM4NV1  : done           |  -       | 172:     | 8:       # 1        | 1:       |  -       |  -       
    HM4SW1  : done_Errors:1  |  -       | 6988:    | 546:     # 1197     | 41:      |  -       | 2:       
    HM4SW2  : done           |  -       | 23:      |  -       #  -       |  -       |  -       |  -       
    HM4SW3  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM4SW4  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM4TB1  : done           |  -       | 299:     |  -       #  -       |  -       |  -       |  -       
    HM5TH1  : pending        | 1 pending| 2:       |  -       #  -       |  -       |  -       |  -       
    HM5TH2  : pending        | 1 pending| 1:       |  -       #  -       |  -       |  -       |  -       
    HM6SP1  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM6SP2  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM6TA1  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM6TA2  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM6TH01 : done           |  -       | 134:     | 24:      # 6        | 1:       |  -       |  -       
    HM6TH02 : done           |  -       | 12:      | 1:       #  -       |  -       |  -       |  -       
    HM6TH03 : done           |  -       | 12:      | 1:       #  -       |  -       |  -       |  -       
    HM6TH04 : done           |  -       | 11:      |  -       #  -       |  -       |  -       |  -       
    HM6TH05 : done           |  -       | 11:      | 1:       #  -       |  -       |  -       |  -       
    HM6TH06 : done           |  -       | 10:      |  -       #  -       |  -       |  -       |  -       
    HM6TH07 : done           |  -       | 12:      | 1:       #  -       |  -       |  -       |  -       
    HM6TH08 : done           |  -       | 9:       |  -       #  -       |  -       |  -       |  -       
    HM6TH09 : done           |  -       | 44:      |  -       #  -       |  -       |  -       |  -       
    HM6TH10 : done           |  -       | 14:      | 1:       #  -       |  -       |  -       |  -       
    HM8SW1  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM8SW2  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    HM8TA1  :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
================================================================================================================
    sum     1                |2         |8958      |1293      #1739      |267       |0         |9         

    CUL_HM queue length:2

    requests pending
    ----------------
    autoReadReg          : HM1RM1 HM1RM2 HM2DI1 HM2SD1 HM4SW3 HM4SW4 HM5TH2 HM6SP1 HM6SP2 HM8SW1 HM8SW2
        recent           : none
    status request       : HM1RM1 HM1RM2 HM1RM3 HM2SD1 HM4NV1 HM4SW1 HM4SW2 HM4SW3 HM4SW4 HM6SP1 HM6SP2 HM8SW1 HM8SW2
    autoReadReg wakeup   : HM2TA1 HM2TH1 HM2TH2 HM2TH3 HM8TA1
    status request wakeup:
    autoReadTest         :

    IODevs:SCC3:Initialized condition:-
           UFO1:opened pending=1 condition:ok
           VCCU:SCC3:ok,UFO1:ok, pending= condition:-

[M_I_B]

... hier scheint heute noch was ganz anderes im Argen zu liegen 
Ich habe mal auf ein paar andere Aktoren geschaut (4CH Hutschine u.ä.) Die stehen alle auf set_off resp. set_on im state  Das war gestern noch nicht. Es ist mir auch nicht möglich, dort einen klaren Status hin zu bekommen... Was ist das denn nun wieder?!?

[frank]

was zeigen die io's/vccu?

[M_I_B]

... m.u.M.n sind die vollkommen ok:

Code Auswählen Erweitern

Internals:
   .triggerUsed 1
   CFGFN      /opt/fhem/_HW/txrx.cfg
   DEF        F10000
   IODev      SCC3
   LASTInputDev UFO1
   MSGCNT     63374
   NAME       VCCU
   NOTIFYDEV  global
   NR         57
   SCC3_MSGCNT 38288
   SCC3_RAWMSG A0A728002F100004E749400::-79:SCC3
   SCC3_RSSI  -79
   SCC3_TIME  2018-01-12 15:23:52
   STATE      SCC3:ok,UFO1:ok,
   TYPE       CUL_HM
   UFO1_MSGCNT 25086
   UFO1_RAWMSG EF10000,0000,0008EF4A,FF,FFAE,A4A011F100003E46460201000000
   UFO1_RSSI  -82
   UFO1_TIME  2018-01-12 15:24:17
   assignedIOs SCC3,UFO1
   lastMsg    No:A4 - t:11 s:F10000 d:3E4646 0201000000
   protLastRcv 2018-01-12 15:24:17
   rssi_at_SCC3 max:-72 cnt:37929 min:-104.5 lst:-79 avg:-80.25
   rssi_at_UFO1 lst:-82 min:-99 avg:-81.86 max:-75 cnt:25086
   READINGS:
     2018-01-12 15:24:17   .protLastRcv    2018-01-12 15:24:17
     2018-01-12 15:23:52   CommandAccepted yes
     2018-01-12 15:22:14   recentStateType ack
     2018-01-12 15:14:37   state           SCC3:ok,UFO1:ok,
     2018-01-12 15:23:43   unknown_4DC279  received
     2017-12-29 04:14:08   unknown_536B50  received
   helper:
     HM_CMDNR   164
     PONtest    1
     mId        FFF0
     regLst     ,0
     rxType     1
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     io:
       nextSend   1515767057.16968
       prefIO     
       vccu       
       ioList:
         SCC3
         UFO1
     mRssi:
       mNo        A4
       io:
         UFO1       -82
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
     rssi:
       at_SCC3:
         avg        -80.2546863877239
         cnt        37929
         lst        -79
         max        -72
         min        -104.5
       at_UFO1:
         avg        -81.8638284302004
         cnt        25086
         lst        -82
         max        -75
         min        -99
     shadowReg:
     tmpl:
Attributes:
   IODev      SCC3
   IOList     SCC3,UFO1
   alias      Virtuelle CCU
   group      Virtuelle CCU
   model      CCU-FHEM
   room       System
   subType    virtual
   webCmd     virtual:update

Code Auswählen Erweitern

Internals:
   CFGFN      /opt/fhem/_HW/txrx.cfg
   CHANGED   
   DEF        192.168.1.198:1000
   DeviceName 192.168.1.198:1000
   FD         11
   IFmodel    LAN
   NAME       UFO1
   NR         46
   NTFY_ORDER 50-UFO1
   PARTIAL   
   RAWMSG     E4DAC33,0000,000971CB,FF,FFB4,3786104DAC330000000A98C5C71840
   RSSI       -76
   STATE      opened
   TYPE       HMLAN
   UFO1_MSGCNT 66868
   UFO1_TIME  2018-01-12 15:24:50
   XmitOpen   1
   assignedIDsCnt 19 report:18
   msgKeepAlive dlyMax:5.751 bufferMin:0
   msgLoadCurrent 1
   msgLoadHistoryAbs 5min steps: 1/1/10/4/4/2/16/13/12/10/9/8
   msgParseDly min:-186 max:5518 last:11 cnt:27084
   owner      F10000
   owner_CCU  VCCU
   uptime     000 00:10:30.677
   .clientArray:
     CUL_HM
   READINGS:
     2018-01-11 19:53:55   D-HMIdAssigned  F10000
     2018-01-11 19:53:55   D-HMIdOriginal  32260F
     2018-01-11 19:53:55   D-firmware      0.965
     2018-01-11 19:53:55   D-serialNr      LEQ0985718
     2018-01-12 15:14:37   Xmit-Events     ERROR-Overload:271 disconnected:440 Warning-HighLoad:276 ok:340 init:340
     2018-01-12 15:14:37   cond            ok
     2018-01-12 15:25:02   loadLvl         low
     2018-01-12 13:52:26   prot_ERROR-Overload last
     2018-01-12 13:52:12   prot_Warning-HighLoad last
     2018-01-12 15:14:36   prot_disconnected last
     2018-01-12 15:14:37   prot_init       last
     2018-01-10 18:33:43   prot_keepAlive  last
     2018-01-12 15:14:37   prot_ok         last
     2018-01-12 15:14:37   state           opened
   helper:
     assIdCnt   19
     assIdRep   18
     info       03C5,LEQ0985718,32260F,F10000
     setTime    46257
     cnd:
       0          340
       2          276
       253        440
       255        340
       4          271
     dly:
       cnt        27084
       lst        11
       max        5518
       min        -186
     ids:
       3E4646:
       446F6E:
         cfg        +446F6E,00,00,00
         name       HM4NV1
       448158:
         cfg        +448158,00,00,00
         name       HM2BB2
       448306:
         cfg        +448306,00,00,00
         name       HM2BB1
       4A1975:
         cfg        +4A1975,00,00,00
         chn        01
         flg        0
         msg       
         name       HM4TB1
         to         1515766936.22106
       4B2EB6:
         cfg        +4B2EB6,00,00,00
         name       HM6SP1
       4B2EE3:
         cfg        +4B2EE3,00,00,00
         name       HM6SP2
       4CEC0B:
         cfg        +4CEC0B,00,00,00
         name       HM6TH02
       4CEC10:
         cfg        +4CEC10,00,00,00
         name       HM6TH08
       4CEC21:
         cfg        +4CEC21,00,00,00
         name       HM6TH10
       4CEC23:
         cfg        +4CEC23,00,00,00
         name       HM6TH01
       4CEF6B:
         cfg        +4CEF6B,00,00,00
         name       HM6TH03
       4DAC26:
         cfg        +4DAC26,00,00,00
         name       HM6TH06
       4DAC2E:
         cfg        +4DAC2E,00,00,00
         name       HM6TH05
       4DAC2F:
         cfg        +4DAC2F,00,00,00
         name       HM6TH07
       4DAC33:
         cfg        +4DAC33,00,00,00
         name       HM6TH04
       4E748C:
         cfg        +4E748C,00,00,00
         name       HM1IR1
       4E7493:
         cfg        +4E7493,00,00,00
         name       HM1IR3
       4E7494:
         cfg        +4E7494,00,00,00
         name       HM1IR2
     k:
       BufMin     0
       DlyMax     5.751
       Next       1515767127.19273
       Start      1515767102.19273
     loadLvl:
       bl         40
       a:
         99
         90
         40
         0
       h:
         0          low
         40         batchLevel
         90         high
         99         suspended
     log:
       all        0
       sys        0
       ids:
         ARRAY(0x3ca8028)
     q:
       HMcndN     0
       answerPend 0
       hmLanQlen  1
       keepAliveRec 1
       keepAliveRpt 0
       loadLastMax 0
       loadNo     5
       scnt       3
       ald:
         1
         1
         10
         4
         4
         2
         16
         13
         12
         10
         9
         8
       apIDs:
     ref:
       drft       -0.00015999360025599
       hmtL       630677
       kTs        0
       offL       1515766471518
       sysL       1515767102195
Attributes:
   alias      UFO HomeMatic 868MHz
   event-on-change-reading .*
   group      Transceiver
   hmId       F10000
   hmLanQlen  1
   loadLevel  0:low,40:batchLevel,90:high,99:suspended
   room       System

Code Auswählen Erweitern

Internals:
   CFGFN      /opt/fhem/_HW/txrx.cfg
   CMDS       mBbCFiAZGMYRTVWXef*ltuxz
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        SCC2
   IODev      SCC2
   NAME       SCC3
   NOTIFYDEV  SCC2
   NR         54
   NTFY_ORDER 50-SCC3
   PARTIAL   
   RAWMSG     A0FD286104CEF6B0000000A98CA09034026
   RSSI       -55
   SCC3_MSGCNT 85361
   SCC3_TIME  2018-01-12 15:25:48
   STATE      Initialized
   StackLevel 2
   TYPE       STACKABLE_CC
   VERSION    V 1.26.01 a-culfw Build: 271 (2017-09-18_20-23-44) CSM868 (F-Band: 868MHz)
   initString X21
Ar
   owner_CCU  VCCU
   .clientArray:
     CUL_HM
     STACKABLE_CC
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-01-11 19:53:50   cmds             m B b C F i A Z G M Y R T V W X e f * l t u x z
     2018-01-12 15:25:48   state           Initialized
   helper:
Attributes:
   alias      SCC3 HomeMatic 868MHz
   event-on-change-reading .*
   group      Transceiver
   hmId       F10000
   rfmode     HomeMatic
   room       System

[frank]

naja.... , ganz schön was los an deinem ufo. 

Code Auswählen Erweitern

     2018-01-12 15:14:37   Xmit-Events     ERROR-Overload:271 disconnected:440 Warning-HighLoad:276 ok:340 init:340
     2018-01-12 13:52:26   prot_ERROR-Overload last
     2018-01-12 13:52:12   prot_Warning-HighLoad last


und 10min vor dem list hat er sogar ein reboot gemacht:

Code Auswählen Erweitern

uptime     000 00:10:30.677


die bezeichnung deines scc scheint etwas chaotisch:

Code Auswählen Erweitern

   DEF        SCC2
   IODev      SCC2
   NAME       SCC3
   NOTIFYDEV  SCC2
   NR         54
   NTFY_ORDER 50-SCC3


[M_I_B]

... den ReBoot löse ich aus, sobald Overload erkannt wird

Die SCC sind nicht so chaotisch wie es den Anschein hat: SCC1 = IT, SCC2 = MAX, SCC3 = HM

Wenn man ins Eventlog schaut ist auch ordentlich was los, die Masse aber nur Device (Stati) > RX...

... ich mach jetzt mal Feierabend; Nase voll von FIT- Werten und MIL-Norm  Wochenende 

[frank]

... den ReBoot löse ich aus, sobald Overload erkannt wird

an der "erkennung" solltest du noch mal einen "feinschliff" vornehmen, denn der letzte overload war ca 90 min vor dem reboot und die load war bereits auf moderate 10% gesunken. wenn du schon so nahe am abgrund arbeitest, würde ich allerdings spätestens bei highload rebooten.

Die SCC sind nicht so chaotisch wie es den Anschein hat: SCC1 = IT, SCC2 = MAX, SCC3 = HM

mag ja sein, aber sicher nicht gemischt in einem device.

[M_I_B]

... ach, jetzt habe ich erst gerafft, was Du meinst... Ja, der 3er war vorher der 2er. Ist aber nur der Name... Gerade mal glatt gezogen... Passt nun wieder.*** Die musste ich umdrehen, weil ich zu der Zeit keine UF.L Antennenbuchsen mehr hatte und sich die Antennen in die Wolle bekamen... Inzwischen ist überall UF.L verbaut und die Antennen via PigTail dran.

Das mit dem UFO ist komisch. Ok, wenn ich einen Overload erkenne setze ich den zurück. Aber warum der an der Stelle einen ReBoot gemacht hat, erklärt sich daraus nicht... Muss ich mal forschen, und beobachten, ob der das öfter macht...

Der problematische Aktor scheint nun ganz tot zu sein. Nach einem Firmware-Reset und neuem Anlernen ging der ein paar Minuten und das war's dann. Inzwischen ist sogar die LED tot, obwohl manuell das Schütz noch per Taste zu schalten ist. Ich baue den nachher mal aus und schaue mal, ob ich den wieder hin bekomme...

*** Also... die Bezeichnungen sind alle korrekt, aber ändern tut sich da nix im VCCU- List...

Definition der Transceiver und VCCU wie folgt und m.E. vollkommen OK:

Code Auswählen Erweitern

### HM- LAN einbinden ###
define UFO1 HMLAN 192.168.1.198:1000
attr UFO1 alias UFO HomeMatic 868MHz
attr UFO1 event-on-change-reading .*
attr UFO1 group Transceiver
attr UFO1 hmId F10000
attr UFO1 hmLanQlen 1
attr UFO1 loadLevel 0:low,40:batchLevel,90:high,99:suspended
attr UFO1 room System

### Initialisierung SCC's ###
define SCC1 CUL 192.168.1.192:2000 0706
attr SCC1 alias SCC1 InterTechno 433MHz
attr SCC1 event-on-change-reading .*
attr SCC1 group Transceiver
attr SCC1 rfmode SlowRF
attr SCC1 room System

define SCC2 STACKABLE_CC SCC1
attr SCC2 alias SCC2 Max 868MHz
attr SCC2 event-on-change-reading .*
attr SCC2 group Transceiver
attr SCC2 rfmode MAX
attr SCC2 room System
define Max_Eco CUL_MAX 121212
attr Max_Eco IODev SCC2
attr Max_Eco group Transceiver
attr Max_Eco room System

define SCC3 STACKABLE_CC SCC2
attr SCC3 alias SCC3 HomeMatic 868MHz
attr SCC3 event-on-change-reading .*
attr SCC3 group Transceiver
attr SCC3 hmId F10000
attr SCC3 rfmode HomeMatic
attr SCC3 room System

### Virtuelle CCU bauen füt HM ###
define VCCU CUL_HM F10000
attr VCCU IODev SCC3
attr VCCU IOList SCC3,UFO1
attr VCCU alias Virtuelle CCU
attr VCCU group Virtuelle CCU
attr VCCU model CCU-FHEM
attr VCCU room System
attr VCCU subType virtual
attr VCCU webCmd virtual:update

[M_I_B]

... noch was ...

Ich bekomme bei keinem einzigen Thermostaten R-burstRx zurück auf off. Ich habe den Befehl dazu jetzt mehrfach an alle Thermostaten gesandt (set HM6TH.* regSet burstRx off). Die stehen dann eine Weile auf "R-burstRx = set_off", aber dann irgendwann wieder auf "R-burstRx = on". Wird stumpf ignoriert ?!?

[frank]

mach das regset für jedes device einzeln. erst wenn alles ok ist den nächsten.
nutze grundsätzlich prefered io und schaue vorher, ob genügend credits beim io zur verfügung stehen. auch devices können in overload gehen.

[M_I_B]

... hilft nicht 
Setze ich das Kommando für einen einzelnen ab, habe ich das Gleiche in grün:
R_burstRx = set_off / protCmdPend = 3 CMDs_pending
Nach einiger Zeit entsteht ein Event auch bei R_burstRx, der aber dann nicht auf OFF schaltet, sondern zurüch auf ON

EDIT: Neuer Versuch. Nur diesen einen Thermostat in der Config gelassen. SCC3 ist das RXTX welches durch Fehlen der anderen Devices nur diesen Thermostaten bedient

[frank]

nutzt du die ts_culfw für den scc? wenn nicht, umflashen oder den hmlan nutzen.

[frank]

ein reset am thermostat geht natürlich auch. 

[M_I_B]

ts_cul? Was'n das? Noch ne Version?
Ne, die aktuelle a_culfw ist auf allen SCC's. Mit dem UFO erreiche ich nicht alle. Das UFO ist im Keller, um die dortige Infrastruktur zu erreichen, die SCC's sind im EG mit sehr schlechtem WAF an die Decke gepappt...
Reset und neu Pairen hatte ich auch schon ins Auge gefasst. Könnte man temprär per DOIF eine Schleife bauen, die den Pairingmode gleich wieder startet, sobald ein Pairing erfolgreich war? Dsa würde die Sache ungemein erleichtern ^^

[M_I_B]

... also das war ja mal echtes Geisterjagen 

Ein FW-Reset, zweifach durchgeführt, einmal über Menü, einmal über 3T + Batterie einlegen und anschließendes Pairen ergibt schlicht und ergreifend, das Register burstRx auch werksmäßig auf ON steht!
Ok, könnte ja sein, das ich Mist genaut habe oder was auch immer... Also habe ich aus meinem Vorrat einen fabrikneuen Thermostaten genommen und den mal gepairt... Das Ergebnis ist identisch.
Und auch dort lässt sich das Register nicht auf OFF setzen; alles andere kein Problem, aber das Register weigert sich

[Beta-User]

Bin nicht so recht sicher, aber ich glaube, an der Stelle jagst du Phantome. Die Burst-Anweisung kommt doch - so wie ich es verstanden habe - immer vom "Sensor" (also Fensterkontakt WT uä.) bzw. wird eben von der Zentrale aus ausgelöst. Damit braucht man am Thermostat eigentlich nichts zu ändern, es sei denn, er müßte einen anderen RT aufwecken. Da macht Zwangsburst aber vermutlich Sinn...

[M_I_B]

... dann haben wir aneinander vorbei geredet ...

Ich bin davon ausgegangen, das die Thermostate so lange auf einen ext. Burst (von einem FK oder Zentrale) hören, so lange das Register auf ON steht. Weiterhin bin ich davon ausgegangen, das bei einer Änderung des Registers im Thermostat auf OFF die Thermostaten eben nicht mehr jedesmal aufwachen, wenn von ext. eine ge'Burstete Nachricht die Runde macht. ALso habe ich mich daran begeben, die HalloWach- Pille in den Thermostaten auf OFF zu stellen um dann feststellen zu können, ob die Batterien dann länger durchhalten.

Aber so wie es ausschaut lässt sich dieses Register, obwohl vorhanden, nicht verändern (aus welchen Gründen auch immer).

BTW:
Der problematische Aktor funktioniert wieder wie er soll. Das Teil steckt ja in einem Hutschinengehäuse nebst 16A Relais und Netzteil (24V ~/= Versorgung). Ich hatte das dann ausgebaut und hier auf dem Tisch mit dem Labornetzteil versorgt. Nach einigen Reset- Versuchen nebst Abklemmen der Versorgung hat der sich wieder gefangen; keine Ahnung was das war.
In dem Zusammenhang fiel mir auch ein komisches Verhalten des daneben befindlichen 4CH Hutschinenaktors auf. Also wollte ich den ebenfalls zur Sicherheit reseten. Meine Überraschung war groß, als auch der sich nicht reseten ließ! Taste von CH1 festhalten bis blinkt, aber der blinkte nur einmal kurz auf und das war's; Reset nicht möglich. Erst nach Ab- und Anklemmen der Versorgung nebst einigen Versuchen war auch der wieder zur Mitarbeit zu bewegen.

Da beide im Zählerschrank stecken und beide zeimlich durch den Wind waren, vermute ich mal eine heftige Spannungsspitze, welche bei beide Aktoren den Speicher zermatscht haben. Anders kann ich es mir im Moment nicht erklären.

Netter Nebeneffekt: Im Eventlog ist deutlich mehr Ruhe eingekehrt. Vielleicht haben die einfach in ihrem Wirrkopp wild drauf los geplappert und somit quasi das Funknetz annäherend zum Erliegen gebracht, was auch die anderen Probleme mit Timeouts u.s.w. erklären würde. Im Moment herrscht zumindest Ruhe und alles scheint wieder zu funktionieren. Hatte sogar Zeit, dem SONOFF Basic einen Transistor und einen R zu spendieren; nu geht auch die rote LED (https://forum.fhem.de/index.php?topic=82634)

[frank]

Also meine Thermostaten habe ich im Februar vor zwei Jahren gekauft. Habe sie an Tag 1 auf Burst gesetzt und meine Batterien sind immer noch die ersten.

das hört sich aber an, als wären sie vorher auf burst=off.

ich habe nur die alten hm-cc-tc, bei denen man burst=on/off setzen kann.

[frank]

in diesem thread hat jemand 5 rt auf burst=off gesetzt.
https://forum.fhem.de/index.php/topic,21089.msg146490.html#msg146490

[M_I_B]

... kann ich mir nicht vorstellen ... Bei keinem der hier im Betrieb befindlichen Thermostate (FW 1.4), auch nicht bei dem mehrfach Reseteten und auch nicht bei dem heute frisch aus der Schachtel genommenen lässt es sich abschalten ...

[frank]

entweder ein bug in fhem, oder
dein scc schafft es mit der fw nicht.

vielleicht hast du auch jetzt nach der reparatur mehr erfolg.
tue dir trotzdem den gefallen und flashe die ts_culfw.

[M_I_B]

... wenn Du mir sagst, was ts_culfw ist, wo es das gibt und wo die Vorteile gegenüber a_culfw liegen, versuche ich das auch gerne noch mal. Ich glaube aber nicht an Probleme mit dem SCC oder dem UFO; mit beiden geht es nicht, alle anderen Register lassen sich aber sehr wohl "verbiegen".

Ich habe gerade ein Bildschirm- Video gemacht; liefer ich nach, sobald ich die Teile, in denen nichts passiert, herausgenommen habe ...

EDIT: Anbei der Vorgang als Ablauf, in dem die Zwischenzeiten, in denen nichhts passiert ist, herausgeschnitten wurden. DIe ganze Nummer hat insg. etwa 4 Minuten gedauert

[frank]

https://forum.fhem.de/index.php/topic,81718.msg737816.html#msg737816

[M_I_B]

... na super  Da sagt ein Tester schon, das er selbst schon Probleme hat, da durchzusteigen; wie soll ich das dann?!?

Es ist für mich nicht zu erkennen, welches die aktuelle FW ist und welche für die SCC notwendig ist. Zudem las ich was über irgend ein Zwischenbau, damit die SCC überhaupt laufen... Das ist ein bisschen viel Unsicherheit, um das an einem Lifesystem zu testen ...

[martinp876]

Es ist schon cool, wenn immer wieder von den Anwendern und Einsteigern erklärt wird, wo die Probleme liegen und wo nicht.
Wie schon gefühlt 1000 mal erklärt: Ein IO welches keinen Timestamp unterstützt wird nie 100% arbeiten. Es wird je nach System 85-98% der normalen und 80-90% der Konfiguratinsabeiten unterstützen. Wem das reicht, ok. Untersuchungen gibt es keine mehr.
Schönes Video - aber es zeigt nicht was passiert ist.
Ich meine, dass es nicht möglich ist, als admin das System im Griff zu haben, wenn man nicht ein paar Protokollgrundsätze verstanden hat (schon vor Jahren im Einsteigerdoc erklärt). Um es nutzen zu können stellt FHEM einiges zu Verfügung. Auch das ist dokumentiert und sollte von jedem bedient werden können.
Also mache dir einmal die Arbeit und verstehe, dass das Device die Protokoll Instanz der HM Devices ist. Dass daher auch dort die Protokollereignisse erfasst werden. Dass man mit einem clear msgevents das "nullen" kann, dann konfiguriert (oder sonst was) und nun in den Internals proto.... sehen kann, ob etwas los was. Dass HMInfo eine Zusammenfassung über das HM-System liefert und man auch dort alles "Nullen" kann.

So, wenn du nun also nachweisen kannst, dass es keine Protokoll-Probleme gibt (dein unscharfes Video zeigt eine Internal - ein Eventlog ist deutlich kleiner und besser!!!) dann (erst) können wir weiter sehen.
Aus deinem Video kann man zumindest erkennen, dass das Device seine Seriennummer neu sendet. Entweder hast du die Config-Taste gedrückt oder dein Device hat einen Reset gemacht. Leider im Video nicht zu sehen. Sollen wir raten, was du machst oder kannst du auch sinnvolle  komplette Infos liefern?

[M_I_B]

... sorry Martin, aber auf so arrogantes Gesülze erwartest Du doch sicherlich keine Antwort... oder doch?

[martinp876]

Nein, sinnvolle Auswertungen und Infos!

[M_I_B]

... ich wollte eigentlich darauf nicht mehr reagieren, aber meine Frau meinte vorhin, ich solle mich nicht ebenso verhalten; recht hat sie (wie so oft)...

Jeder hier, wie auch ich, weiß Deine Kompetenz in Sachen FHEM zu schätzen; Du hast nicht nur mir schon oft aus einer Sackgasse geholfen und dafür sind wir Dir sicherlich allesamt dankbar. Das heißt aber nicht, das jeder hier, ich zumindest, Deine Art und Weise zu schätzen vermag, wie Du hier auf recht arrogante Art mit den Fragenden resp. jenen unter Deinem Kenntnisniveau i.d.R. umgehst.
Ich habe nicht zum ersten mal den Eindruck, das es der harten Kern hier am liebsten hätte, wenn dieses Forum ein geschlossenes System wäre, um unter sich zu bleiben und die ach so nervigen Anfänger mit ihren ach so weit unter Eurem Niveau angesiedelten Problemchen, die sich zudem und vollkommen natürlich oft wiederholen, möglichst weit weg bleiben...
Ein Forum wie Dieses hat nun mal als grundlegende Eigenschaft inne, das sich Anfänger mit Null Vorkenntnissen hier Hilfe erhoffen. Wenn man das nicht möchte, dann sollte man solch ein Forum nicht online stellen oder sich einfach einen geschlossenen Bereich schaffen, in dem die Nerfer keinen Zutritt haben und sich hier einfach raus halten.

Zum Thema:
Wie ich mehrfach schrieb, besteht das Problem mit dem nicht löschbaren Registerwert nicht nur mit einem SCC, sondern auch mit einem original HM-LAN-Gateway. Zudem sind davon alle 10 im Betrieb befindlichen Thermostate betroffen, ebenso wie Werksneue, bei denen dieser Registerwert per Werkseinstellung bereits auf ON steht; ich habe noch 5 verpackte, fabrikneue Thermostate hier liegen, die ich gerne auch noch darauf hin untersuchen kann, wenn's denn was bringen würde...
Wie ich ebenfalls mehrfach schrieb, lassen sich alle anderen Register- Werte problemlos ändern, auch im Bulk und auch via SCC.
Also liegt es Deiner Meinung nach daran, das weder das HM-LAN-Gateway noch der SCC in der Lage ist, diesen, und nur diesen speziellen Register- Wert nicht ändern zu können? Sorry, aber diese Behauptung halte ich schlichtweg für dummes Zeug ...

Abschließend:

So, wenn du nun also nachweisen kannst, dass es keine Protokoll-Probleme gibt (dein unscharfes Video zeigt eine Internal - ein Eventlog ist deutlich kleiner und besser!!!) dann (erst) können wir weiter sehen.

Ich will und muss nichts nachweisen. Meine Kompetenzen reichen nicht aus, um hier explizit Protokollprobleme nachweisen zu können, wenn sie denn existent sind. Wenn ich das könnte, bräuchte ich hier nicht um die Hilfe von Dritten ,,betteln".
Und das dieses kleine Video Deinen Ansprüchen nicht genügt, ist ebenfalls klar und war auch nicht dafür gedacht, diesem Anspruch gerecht zu werden; für Dich würde ich natürlich ein Video in UHD generieren ^^ Der einzige Anspruch dieses Videos war und ist, den zeitlichen Verlauf der Events darzustellen und ggf. ein ,,aneinander vorbei Reden" zu verhindern... Nicht mehr und nicht weniger.

Entweder hast du die Config-Taste gedrückt oder dein Device hat einen Reset gemacht.

Wenn das Drücken der Config- Taste am Ergebnis irgend einen Unterschied generiert, hätte ich es mit Sicherheit erwähnt. Da ich es aber nicht erwähnt habe, macht es im Ergebnis auch keinen Unterschied. Wenn man alles erwähnen soll, was keine Auswirkungen auf das Ergebnis hat, würde das eigentliche Problem wohl jedesmal gnadenlos untergehen...

[frank]

weitere rt auspacken, macht keinen sinn.
am besten ist das sniffen der raw messages beim setzen des registers, wie im wiki homematic sniffen beschrieben.

[frank]

am besten natürlich mit dem hmlan, da ein falsches timing dann nicht die ursache sein kann.

[M_I_B]

... das mit dem Sniffen ist eine gute Idee; warum bin ich da nicht drauf gekommen? 

Mal sehen, wann ich das in Angriff nehmen kann. Diese Woche ist ziemlich viel los und von der Arbeit aus geht das nicht wirklich.

Ich werde dann zur Sicherheit einen fabrikneuen TH nehmen und den im Keller in der Nähe des HM-LAN positionieren so wie die VCCU außen vor lassen. Das sollte die bestmögliche Config sein, um nix unnötiges im Sniff aufzugreifen; man weiß ja nie...

[pc1246]

Moin Micha
Ich muss mal eine dumme Frage stellen. Warum schickst du soviel an die Thermostate? Meine Akkus halten ungefaehr 1,5 Jahre, da ich lediglich Fensterkontakte an den thermostaten sende. OK, das ist evtl. nicht ganz Dein Szenario, aber Du nutzt ja auch nicht die Temperaturlisten, womit man sich auch viel Funklast ersparen kann. Evtl. senkt das auch den Batterieverbrauch.
Wie waere das denn, wenn Dein fhem ueber zwei Tage tot ist, was machen dann Deine Heizkoerper? Von der Heizung mal abgesehen?
Gruss Christoph

[M_I_B]

... es gibt keine dummen Fragen, nur dumme Antworten 

Also... Die Tabellen in den Thermostaten sind mir zu starr. Wir haben nicht wirklich einen regelmäßigen Tagesablauf. Daher sende ich 4x am Tag zu bestimmten Zeiten (basierend auf Presence, Holiday, Außentemperatur und Heizkennlinie) die entsprechenden Sollwerte zu den Reglern. Sollte die FHEM- Hauptinstanz mal ausfallen, übernimmt eine FHEM- Nebeninstanz, in dem Fall der Heizungs- PI eine rudimentäre Steuerung und schaltet alle Thermostate auf Automatik, so das die werksseitigen Tabellen zum Einsatz kommen. Sobald die Hauptinstanz wieder lebt, übernimmt die wieder und schaltet zurück auf Manuell, damit die Tabellen nicht dazwischen funken.
Ein Ausfall der Hauptinstanz ist allerdings eher selten. Von selbstgebauten Ausfällen mal abgesehen ist die Hardware ziemlich robust (XEON 19" 1HE Server mit 16GB ECC und kleinem SSD-RAID10, angeschossen an eine 3kW UPS, die allerdings noch ein paar andere Dinge bei Netzausfall versorgt (Heizung, Netzwerk, Notbeleuchtung), bis bei Akku- Ende entweder die PV zugeschaltet wird oder des Nachts ein 3kW- Generator startet)

Die Heizung selber ist autark und basiert auf einem PI3. Ein zweiter PI3 liegt daneben, bestückt mit einem Mirror der aktiven SD- Karte. Sollte der PI oder die SD mal sterben (ist schon einmal vorgekommen; Blitzeinschlag in der Nachbarschaft), kann sogar meine Frau den eben mal tauschen, falls ich nicht daheim bin.

Sicherlich kann man solche Infrastruktur auch anders lösen, aber ich für meinen Teil und für meine Bedürfnisse denke, das dieser Aufbau so ganz brauchbar ist und sich zudem bereits bei Störungen (Stromausfall, Blitzschlag, Stillstand Hauptinstanz) bewährt hat...

[pc1246]

Hallo Micha
Da ich das mit deiner Heizung wusste, habe ich mir so etwas schon gedacht. Viermal am Tag ist jetzt aus meiner Sicht gesehen nicht sonderlich viel, so dass Du wahrscheinlich wirklich am Burst der anderen Devices drehen musst, damit die Thermostate nicht unnoetig aufwachen.
Viel Erfolg noch
Gruss Christoph

[M_I_B]

... ja, irgendwo liegt hier der Hase im Pfeffer begraben ... Immerhin haben die Batterien vorher recht gut gehalten. Dieser enorme Verbrauch ist erst in den letzten Wochen aufgetreten, so weit ich das beurteilen kann.
Im Moment sieht es so aus, als wenn sich die noch nicht getauschten Batterien erholen, so das ich guter Hoffnung bin, irgendwie das wild burstende Device erwischt zu haben... Ich tippe hier mal stumpf auf den ausgefallenen LC-SW1-BA-PCB ...

Bleibt die Frage nach dem nicht deaktivierbaren Register.... Das wurmt mich jetzt
Ich habe jetzt noch einige Oventrop- Adapter bestellt und werde in dem Zusammenhang die Heizkörper im Keller wie vorgesehen mit den restlichen Thermostaten bestücken; dann hat die Sniffing- Aktion wenigstens auch einen sinnvollen Nebeneffekt...

[M_I_B]

Update:
Die Adaptata sind gestern eingetroffen, die fabrikneuen Thermostate verbaut. Diese hören ausschließlich auf den HM-LAN (was anderes geht im Keller auch nicht).

Alle Register lassen sich ändern (wie schon bei den Vorhandenen), das per Default vom Werk her auf ON gesetzte Register burstRx aber nicht.

Ich nehme also zur Kenntnis, das dieses spezielle Register zumindest mit einer Infrastruktur und meinen 15 Thermostaten nicht änderbar ist. Da inzwischen auch der massive Batterievergrauch gefühlt auf den alten Stand zurückgekehrt ist (lag wohl tatsächlich an dem Unsinn babbelnden Aktor), ist dieses Thema für mich erst mal abgehakt.

Abschließend noch zwei FRagen, die vermutlich zusammenhängen; lohnt wohl keinen neuen Thread...

1.
Kann ich irgendwie zwei Thermostate synchronisieren, ohne dafür FHEM zur Hilfe zu nehmen? Also wenn ich an einem von zwei Thermostaten z.B. manuell die Temperatur ändere, soll der andere Thermostat mitziehen und umgekehrt...

2.
Kann ich einen Wandthermostaten gleichzeitig mit zwei Thermostaten peeren, so das der für beide Thermostaten das Sagen an an Stelle der eingebauten Sensoren?


Bisher habe ich solche Dinge aus FHEM heraus erledigt, aber in Bezug auf meinen anderen Thread stelle ich gerade entsprechende Überlegungen an ...

[pc1246]

Moin Micha
2. geht auf jeden Fall, das wird ja so auch beworben. Allerdings geht das nur bevor man gepairt hat! Sonst muss man es ueber fhem machen, und ist trotzdem losgeloest von fhem.
1. Weiss ich nicht, meine aber, dass es auch geht. Ist aber wieder wie 2, nur vor dem Pairen direkt, danach nur noch ueber fhem, aber dann trotzdem autark!
Gruss Christoph

[martinp876]

1. Sniffen muss man nichts wenn ja sich, wie du, sicher ist, dass keine Protokoll Fehler auftreten. Das hast du kontrolliert und man kann es auch in den internals des Device nachsehen. Aber das weißt du ja, das soll ich bei dir nicht in Frage stellen.
2. Man kann erst in Teams peeren. Und selbstverständlich kann man das einrichten NACHDEM gepairt ist. Sollte im Wiki beschrieben sein. Ist eine ganz normale Einstellung, wen man mehrere hk in einem Raum betreiben will.  Ich kenne NICHTS was man nach dem pairen nicht auch über fhem einstellen kann. Unklar, warum das immer wieder gesagt wird.
Teams kannst du einstellen und auflösen nach Gusto, ständig.
3. Ein Wandthermostat kann selbstverständlich mehrere RTs gleichzeitig steuern. Sollte in der Anleitung stehen.ich glaube es waren 4 oder 8.
4. Grundsätzlich gilt, dass das Device an dem der User eine Änderung im Team eingibt diese Änderung an alle Teammitglieder weitergibt. Ändert man von fhem muss fhem jeden einzelnen umstellen (ist implementiert für operationelle Kommandos). Ändert man am Device sendet dies die Aufforderung an alle Kollegen.
5. Regelmäßig die register setzen belastet das flash. Gut möglich dass dies den Akku belastet. Register sind m.e. nicht zum regelmäßig überschreiben erfunden. Ob sie dafür ausgelegt sind wirst du sehen. Möglich dass dies deutlich Strom kostet.
Fhem kontrolliert die Änderungen und schreibt ausschließlich, wenn sich etwas ändert.
Wenn man 4mal am Tag Register überschreiben will muss man keinen burst nutzen. Das ist doppelt .... Seltsam.
A. Hat man nichts geändert schreibt fhem auch nichts. Dann wird nur der burst gesendet, sonst nichts. Schade, Aussee Spesen nichts gewesen.
B. Warum nicht einfach warten. Fhem übernimmt das Schreiben wenn das Device aufwacht. Funktioniert wunderbar, ist effektiv. Burst ist komplett unnötig. Haben sich keine Werte geändert passiert gar nichts. Auch nicht schlecht.

[pc1246]

2. Man kann erst in Teams peeren. Und selbstverständlich kann man das einrichten NACHDEM gepairt ist. Sollte im Wiki beschrieben sein. Ist eine ganz normale Einstellung, wen man mehrere hk in einem Raum betreiben will.  Ich kenne NICHTS was man nach dem pairen nicht auch über fhem einstellen kann. Unklar, warum das immer wieder gesagt wird.
Teams kannst du einstellen und auflösen nach Gusto, ständig.

Ich habe auch nicht gesagt, dass es nicht geht! Nur, dass man gepairte Devices nicht mehr ohne Zentrale (fhem) peeren kann!
Gruss Christoph

[M_I_B]

Moin Kinnas, moin Martin,

zu 1.: Kann ich derzeit nichts zu sagen, da ich nie sicher bin, das ich alles richtig gemacht habe. Da sich aber das besagte Register auch nicht bei neuen HK's über ein HM-LAN zurücksetzen lässt, habe ich für mich selbst beschlossen, das als gegeben hinzunehmen und keine weitere Zeit damit zu verbraten, da der Batterieverbrauch sich nach Entfernen der Burst- Befehle in FHEM und vor allem der Reparatur des einen Aktors vollkommen normalisiert hat; eins von beiden oder beides war die Ursache; abgehakt.

zu 2-4.: Das ist schön zu hören. Ich muss mich da aber erst mal schlau lesen, da ich noch nie Devices aus FHEM heraus gepeert, geschweige denn s.g. Teams gebildet habe. Letztlich muss ich das nur für zwei Teams generieren, die jeweils aus einem Wandthermostaten und zwei HK's bestehen (Wohnzimmer & Esszimmer = WTH1, Elektronikwerkstatt hat zwei Heizkörper = WTH2)

zu 5.: Du meinst jetzt das Setzen der Solltemperatur 4 mal am Tag? Naja, die müssen dazu ja aufwachen, also kostet es auch Energie. Kann aber nicht so viel sein. Das mache ich jetzt ja schon über ein Jahr so (ohne Burst; der war ja nur 2 Wochen etwa zum Testen und auf Grund meiner Ungeduld drin). Der Batterieverbrauch war ja nur die letzten Wochen auffällig. Die Regelung, heißt das Ansteuern des Stellmotors dürfte deutlich mehr Strom verbraten; ich schätze so um den Faktor 100-1000 mehr als das Setzen der Solltemperatur. Ich habe es noch nicht nachgemessen, aber der Motor dürfte locker mindestens 200mA ziehen... Im Umkehrschluss ist der Stromverbrauch im Winter sowieso deutlich höher als im Sommer...
Daher zu A: Der Burst war mit dem Setzen der neuen Solltemperatur gekoppelt, wurde also nicht gesendet, wenn nix neues da war
und zu B: Hast ja Recht. Wie ich sagte war das eine Homage an meine Ungeduld für die Dauer des Umschreibens meiner diesbezüglichen Steuerung. Das Senden des Burst war nie für eine dauerhafte Steuerung gedacht. Da nun blöder Weise in dieser Zeit noch ein Aktor vollkommen und ein 4fach Aktor teilweise neben der Spur waren und beide hier munter in den Ähter geburstet haben, was ich ja zu Begin dieses Threads noch nich wusste, vermutete ich eben erst mal aus ganz anderer Richtung ein Problem... Ich kann jetzt allerdings nicht sagen, ob nun ausschließlich die AKtoren, ausschließlich mein Geburste oder beides für den hohen Energieverbrauch zuständig war. Wenn sich hier alles wieder eingependelt hat, werde ich noch mal ein paar Batteriesätze riskieren und 2 oder 3 Thermostate direkt wieder mit Burst setzen, um den Batterieverbrauch dieser HK's und der anderen mithörenden HK's zu überwachen. Danach kann ich dann hoffentlich abschätzen, um wieviel höher der Verbrauch sein wird, wenn man das so macht...

Nun gut... Ich werde mich dann mal die Tage schlau machen bezgl. Teambildung der HK's. Mal sehen, ob ich das hin bekomme

[martinp876]

1) ich wiederhole es ein letztes Mal: bei Problemen ist zu aller erst zu prüfen, ob Protokoll Fehler ausgetreten sind. Diese sind zu untersuchen ( mache ich bei hmlan,.. und Tscul). Hatte ich oben angemerkt worauf du dir dumme Fragen dazu verbeten hast. In deinem Fall für mich also erledigt.

2) ist egal, wie viele du teamen willst. Ist immer identisch. Muss man einmal verstehen ( nicht schwer) und dann umsetzen

5) du solltest dir auch die Übertragungsmode ansehen und dann aggieren. Die RTs Sachen alle 3min auf. Die Zentrale erkennt das und sendet ausstehende Kommandos. Wenn du also warten kannst, warte. Das ist in der Doku auch die Empfehlung. Lass den burst hier einfach weg, warte 3min zum setzen und 3min zur Antwort es Device ( beachte die Details, nimm dir 6min und beobachte es am rt und am Screen. Nicht nervös werden, warten!!!!!!)
Settemp ist weiter keine Registeraktion. Der Kommentar zu flashes trifft also nicht zu.
Unterschätze nicht den Stromverbrauch der Elektronik!

Noch Mal abschließend: die Zentrale MUSS NIE bursten. Ich nutze es ausschließlich zum testen, weil ich da keine Zeit habe. Da addieren sich die bursts.
Peerdevices können nicht warten. Die müssen bursten!

[M_I_B]

... worauf du dir dumme Fragen dazu verbeten hast ...

Lies es Dir in einer stillen Stunde doch noch mal durch. Dann wirst auch Du erkennen (wenn Du es überhaupt erkennen möchtest, was ich inzwischen bezweifle), das diese von Dir interpretierte Aussage an den Haaren herbei gezogen ist... Das wird mir jetzt wirklich langsam zu anstrengend, jeden geschrieben Satz daraufhin zu untersuchen, ob vielleicht ein Martin oder sonst wer diesen Satz oder jenen Absatz falsch auslegen könnte; das Leben könnte so entspannt sein, wenn... ja wenn....

Ich wollte hier jetzt eigentlich noch eine FRage zum Team los werden, aber ich habe da keinen Bock mehr drauf... Werde ich irgend wann schon selber heraus finden ...