[gelöst] HM-LC-Sw1-Pl-CT Steckdose schaltet nach restart

[HansDampfHH]

Wir haben bei uns in der Garage eine HM-LC-Sw1-Pl-CT um das Garagentor zu schalten.
Das funktioniert seit langer Zeit wunderbar.

Seit neustem schaltet die Steckdose allerdings wenn ich fhem neustarte, zum Beispiel nach einem update.
Und zack ist das Garagentor auf, das ist natürlich nicht optimal.

Hat da jemand einen Hinweis für mich?

Code Auswählen Erweitern


Internals:
   DEF        4EEF64
   FUUID      5c743f43-f33f-1bf5-16ee-fc52e2c8933c2236
   HMUSB_MSGCNT 8
   HMUSB_RAWMSG E4EEF64,0000,287C5D83,FF,FFB1,37A4104EEF6414080906010000
   HMUSB_RSSI -79
   HMUSB_TIME 2019-03-24 08:42:36
   IODev      HMUSB
   LASTInputDev HMUSB
   MSGCNT     8
   NAME       HM_4EEF64
   NOTIFYDEV  global
   NR         413
   NTFY_ORDER 50-HM_4EEF64
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:37 - t:10 s:4EEF64 d:140809 06010000
   peerList   self01,HM_5A2782_Btn_01,HM_5A2782_Btn_02,HM_5B2E1D_Btn_01,HM_5B2E1D_Btn_02,
   protLastRcv 2019-03-24 08:42:36
   protRcv    7 last_at:2019-03-24 08:42:36
   protSnd    8 last_at:2019-03-24 08:42:36
   protState  CMDs_done
   rssi_HMUSB cnt:5 min:-77 max:-76 avg:-76.59 lst:-77
   rssi_at_HMUSB cnt:8 min:-79 max:-77 avg:-77.99 lst:-79
   READINGS:
     2019-03-24 08:42:34   CommandAccepted yes
     2019-03-18 19:24:52   D-firmware      2.5
     2019-03-18 19:24:52   D-serialNr      NEQ1263648
     2019-03-18 22:00:02   PairedTo        0x140809
     2019-03-18 22:00:05   R-HM_5A2782_Btn_01-lgActionType jmpToTarget
     2019-03-18 22:00:05   R-HM_5A2782_Btn_01-shActionType jmpToTarget
     2019-03-18 22:00:06   R-HM_5A2782_Btn_02-lgActionType jmpToTarget
     2019-03-18 22:00:06   R-HM_5A2782_Btn_02-shActionType jmpToTarget
     2019-03-18 22:00:07   R-HM_5B2E1D_Btn_01-lgActionType jmpToTarget
     2019-03-18 22:00:07   R-HM_5B2E1D_Btn_01-shActionType jmpToTarget
     2019-03-18 22:00:08   R-HM_5B2E1D_Btn_02-lgActionType jmpToTarget
     2019-03-18 22:00:08   R-HM_5B2E1D_Btn_02-shActionType jmpToTarget
     2019-03-18 22:00:02   R-pairCentral   0x140809
     2019-03-18 22:00:02   R-powerUpAction off
     2019-03-18 22:00:04   R-self01-lgActionType jmpToTarget
     2019-03-18 22:00:04   R-self01-shActionType jmpToTarget
     2019-03-18 22:00:02   R-sign          off
     2019-03-18 22:00:02   RegL_00.        00:00 02:81 0A:14 0B:08 0C:09 15:FF 18:00
     2019-03-18 22:00:02   RegL_01.        00:00 08:00 30:06 56:00 57:24
     2019-03-18 22:00:05   RegL_03.HM_5A2782_Btn_01 00:00 02:00 03:00 04:32 05:64 06:00 07:04 08:00 09:FF 0A:01 0B:64 0C:66 82:00 83:00 84:32 85:64 86:00 87:06 88:00 89:FF 8A:21 8B:64 8C:66
     2019-03-18 22:00:06   RegL_03.HM_5A2782_Btn_02 00:00 02:00 03:00 04:32 05:64 06:00 07:04 08:00 09:FF 0A:01 0B:13 0C:33 82:00 83:00 84:32 85:64 86:00 87:06 88:00 89:FF 8A:21 8B:13 8C:33
     2019-03-18 22:00:07   RegL_03.HM_5B2E1D_Btn_01 00:00 02:00 03:00 04:32 05:64 06:00 07:04 08:00 09:FF 0A:01 0B:64 0C:66 82:00 83:00 84:32 85:64 86:00 87:06 88:00 89:FF 8A:21 8B:64 8C:66
     2019-03-18 22:00:08   RegL_03.HM_5B2E1D_Btn_02 00:00 02:00 03:00 04:32 05:64 06:00 07:04 08:00 09:FF 0A:01 0B:13 0C:33 82:00 83:00 84:32 85:64 86:00 87:06 88:00 89:FF 8A:21 8B:13 8C:33
     2019-03-18 22:00:04   RegL_03.self01  00:00 02:00 03:00 04:32 05:64 06:00 07:04 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:06 88:00 89:FF 8A:21 8B:14 8C:63
     2019-03-24 08:42:36   deviceMsg       off (to VCCU)
     2019-03-24 08:42:36   level           0
     2019-03-24 08:42:36   pct             0
     2019-03-24 08:42:19   peerList        self01,HM_5A2782_Btn_01,HM_5A2782_Btn_02,HM_5B2E1D_Btn_01,HM_5B2E1D_Btn_02,
     2019-03-24 08:42:36   recentStateType info
     2019-03-24 08:42:36   state           off
     2019-03-24 08:42:36   timedOn         off
   helper:
     HM_CMDNR   55
     cSnd       ,011408094EEF64010E
     count      4
     mId        00C8
     peerFriend peerSens,peerVirt
     peerOpt    3:switch
     regLst     0,1,3p
     rxType     1
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +4EEF64,00,00,00
       nextSend   1553413356.79608
       rxt        0
       vccu       VCCU
       p:
         4EEF64
         00
         00
         00
       prefIO:
         HMUSB
     mRssi:
       mNo        37
       io:
         HMUSB:
           -77
           -77
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         HMUSB
       flg        A
       ts         1553413356.69624
       ack:
         HASH(0x4f45b90)
         3780021408094EEF6400
     rssi:
       HMUSB:
         avg        -76.6
         cnt        5
         lst        -77
         max        -76
         min        -77
       at_HMUSB:
         avg        -78
         cnt        8
         lst        -79
         max        -77
         min        -79
     tmpl:
Attributes:
   IODev      HMUSB
   IOgrp      VCCU:HMUSB
   alias      Garagentor
   autoReadReg 5_readMissing
   devStateIcon on:general_an@green off:general_aus@red
   eventMap   press:Schalten
   expert     2_raw
   firmware   2.5
   group      Steckdose
   icon       ge_wht_steckdose
   model      HM-LC-Sw1-Pl-CT-R1
   peerIDs    00000000,4EEF6401,5A278201,5A278202,5B2E1D01,5B2E1D02,
   room       Garage
   serialNr   NEQ1263648
   subType    switch
   webCmd     Schalten


[KernSani]

Nachdem hier bisher keine Antwort kommt, vielleicht mal ins Homematic Board verschieben (Button ganz unten links).

[Pfriemler]

Das ist doch mal wieder was Spannendes...

a) hängengebliebene Befehle von FHEM, die nach dem Neustart abgearbeitet werden: klingt für mich sehr unwahrscheinlich, zumal mir neu wäre, dass so etwas überhaupt dafür zwischengespeichert wird.
b) automatisch ablaufende Vorgänge beim Neustart
Es gibt einige Peerpartner, die keine solche Aktion auslösen dürften. Aber vielleicht hast Du ein paar Steuerungen für das Tor aus FHEM eingebaut, bei denen die Startwerte nach dem Neustart zu einer ungewollten Aktion führen*. Schaue Dir alle Routinen diesbezüglich nochmal genau an. Idealerweise gibt es (mindestens) eine, die genau auch unter "Associated with" in der Def-Ansicht Deines HM-Aktors zu finden ist, aber es kann sich auch um eine globale Aktion oder Automation handeln (im Stile eines "set TYPE=..." oder so).
Deren Defs darfst Du uns auch gern hier posten...
Versuche zeitlich einzugrenzen, in welchem Zusammenhang das Problem erstmals aufgetreten sein könnte - auch ein Update wäre denkbar.
Setze verbose für den Aktor etwas herauf, damit seine Schaltaktionen im Log erscheinen, wenn Du sie dort nicht schon siehst...
So was mir auf die Schnelle einfällt...
Noch wer eine Idee?

*edit: z.B. ein DOIF, welches nach einem Start "initialized" ist und durch einen externen Trigger erst in eine andere Lage versetzt wird und dabei den Schaltvorgang auslöst ...

[HansDampfHH]

Oh man, die fhem.cfg beinhaltet bei mir mittlerweile zu viel.
Da ist tatsächlich ein notify gewesen welches an einem Dashbutton hing.
Den hatte ich immer disabled und vor einiger Zeit mal wieder in Gebrauch genommen.
Seit dem griff das notify natürlich wieder.

Danke für den Schubs !