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

Begonnen von M_I_B, 11 Januar 2018, 14:23:16

Vorheriges Thema - Nächstes Thema

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
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

M_I_B

#6
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:
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))
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:
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?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

M_I_B

#9
Zitat von: frank am 12 Januar 2018, 01:02:22... 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 ^^


Zitat von: frank am 12 Januar 2018, 01:02:22welche 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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

M_I_B

Zitat von: frank am 12 Januar 2018, 09:36:48LC-SW1-BA-PCB ist laut liste ein burst device.  :)
das erklärt dann einiges.
... hu? Wie Du meinen? Raff gerade den Zusammenhang nicht...

frank

#12
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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

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

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.

   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:
   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?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html