Plötzliches Problem mit HM-LC-SW1-BA-PCB

Begonnen von flobeewan, 17 April 2023, 00:07:27

Vorheriges Thema - Nächstes Thema

flobeewan

Liebes Forum!
Ich brauche wieder mal Hilfe. Ich habe seit 3+ Jahren einen HM-LC-SW1-BA-PCB als Garagentorschalter im Einsatz. Seit der Zeit einige Male die Batterie (9V) gewechselt und FHEM x-Mal neu gestartet. Immer alles ohne Probleme. Seit ca. 10 Tagen bekomme ich auf jedes Kommando nur mehr ein MISSING ACK retour. Der Druckknopf auf der Platine funktioniert einwandfrei und auch die Rückmeldungen an FHEM kommen an. Folgendes habe ich schon alles versucht:
- neue Batterie
- Reset
- neu Anlernen
- Device löschen
- neuen Device autom und manuell erstellen.
und die meisten Kombinationen daraus.
Der einzige Unterschied den ich jetzt feststellen konnte ich, dass ich bei einem read reg die Meldung: RESPONSE TIMEOUT bekomme. bei einem Set kommt aber wieder MISSING ACK und nichts passiert.
Ich bin mit meinem Wissen am Ende und hoffe auf den einen oder anderen Tipp von euch, da ich nicht glauben kann, dass der Aktor einfach von heute auf morgen den Geist auf gibt.
Danke!

Pfriemler

Der Funk vom -BA kommt bei FHEM an, aber umgekehrt nicht. Wie waren zuletzt die rssi-Werte (beide Seiten)?
Könnte es sein, dass in der Nähe der Garage vor kurzem ein neues Gerät in Betrieb genommen wurde, welches den Funk stört? Auch ein "babbling idiot" käme in Frage.
Liegt die Antenne richtig?
Wenn es geht, den Aktor mal ausbauen und dichter an FHEM erneut testen. Wenn er dort funktioniert, wiederum die rssi-Werte vergleichen. Ist der Empfangspegel am Empfänger deutlich schlechter, könnte der Empfänger einen "Schuss" abbekommen haben.

Vor allen "set" und "readReg" den Sendecache löschen (clear msgEvents).

jm2c
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

flobeewan

Hallo jm2c,
ich habe mir den Sender ausgebaut und an verschiedenen Positionen probiert. Aktuell liegt er ca. 2m vom HMLAN2 weg.
RSSI aktuell:
Device          receive         from             last   avg      min_max    count
    HM_46A232       HMLAN1          HM_46A232        -65.0  -60.0  -65.0< -55.0     2
    HM_46A232       HMLAN2          HM_46A232        -56.0  -55.0  -56.0< -54.0     2
    HM_46A232       HmUARTusb       HM_46A232        -64.0  -59.5  -64.0< -55.0     2
schaut für mich jetzt nicht so schlecht aus.
Ein clear msgEvents habe ich auch schon durchgeführt, wie auch ein reset am Gerät.
Wie bereits erwähnt lief das Teil jetzt ohne ein Problem über Jahre und fängt plötzlich zum Zicken an.
Ich habe bei mir nichts geändert. In meiner Umgebung wäre mir auch noch nichts aufgefallen (zB neue Geräte bei den Nachbarn).
Trotz neuem 9V Block bekomme ich schon wieder die Meldung "Battery low"?
Danke für weiteren Input

flobeewan

Was mir heute Nacht noch aufgefallen ist: es gibt keinen RSSI Eintrag für Device -> VCCU (egal welcher HMLAN)?

Pfriemler

#4
Die rssi @ FHEM sind für das Problem weniger interessant - FHEM kennt den Status des Aktors ja gut, die Funkstrecke ist nicht betroffen.

Zitat von: flobeewan am 24 April 2023, 08:44:04Was mir heute Nacht noch aufgefallen ist: es gibt keinen RSSI Eintrag für Device -> VCCU (egal welcher HMLAN)?
Die entnehme ich immer dem "list" des Gerätes:
rssi_HMCUN cnt:1 min:-68 max:-68 avg:-68 lst:-68
rssi_at_HMCUN cnt:6 min:-60 max:-57 avg:-58 lst:-58
Hier sieht man eine Differenz vom 10 dB. Das ist wohl noch normal.
Wird immer nur ein IO zum Senden verwendet, liefert das Device entsprechend auch nur den zugehörigen rssi, während in Empfangsrichtung natürlich alle verfügbaren (und hörenden) IOs rssi liefern - die sind auch immer den physischen IOs zugeordnet, niemals der VCCU.

Nachträge:
1. in diesem Entfernungsbereich sollte der Aktor aber reagieren.
2. Battery low ist kein gutes Zeichen. Kannst Du Batteriespannung und -strom messen? Der Aktor benötigt aus meiner Erinnerung beim Senden um die 30 mA, fällt aber in weniger als 20 Sekunden in Tiefschlaf im zweistelligen µA-Bereich mit regelmäßigen kurzen mA-Spitzen - der Empfänger wird nur für Millisekunden aktiviert um Strom zu sparen, daher benötigen die Geräte ja auch einen "Burst" zum Aufwachen. Das wäre übrigens auch eine Fehlerquelle bei gepeerten Geräten (peerNeedsBurst nicht gesetzt), aber FHEM weiß von sich aus (korrektes "model" vorausgesetzt) wann es "burst"en muss und wann nicht.

2. Nachtrag
3. natürlich: Wenn es einen Störer gäbe, der das Funkband verstopft ("babbling idiot"), gehen auch die Empfänger der burst-Geräte wesentlich länger auf Empfang und nudeln die Batterien deutlich schneller leer.
Es gibt also ein ganzes Rudel möglicher Ursachen. Wenn Du einen anderen Empfänger testweise in der Nähe der Garage betreiben kannst (z.B. einen Zwischenstecker) und der funktioniert dort einwandfrei, ist die Wahrscheinlichkeit eines Funkstörers allerdings quasi null.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

flobeewan

Einen Störer gibt es imho nicht. Ich betreibe in der Garage neben dem HM-LC-SW1-BA-PCB auch noch 2 Schaltsteckdosen, 2 Lagesensoren und 2 Temp Sensoren. Alle ohne Auffälligkeiten.
Die Batterie werde ich die nächsten Tagen testweise durch ein Netzteil tauschen, damit ich das auch ausschließen kann.
Würde ein "list" zur Fehlersuche helfen?
Grüße
Florian

frank

ZitatWürde ein "list" zur Fehlersuche helfen?
infos sind immer gut, oder nicht?
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

flobeewan

Ich finde darin keinen weiteren Hinweis
Internals:
   CFGFN     
   DEF        46A232
   FUUID      643c6a06-f33f-360f-9eaa-c2800ce6ef7f4342
   HMLAN1_MSGCNT 8
   HMLAN1_RAWMSG E46A232,0000,30DE7824,FF,FFBE,0C841046A23200000006010080
   HMLAN1_RSSI -66
   HMLAN1_TIME 2023-04-23 22:43:34
   HMLAN2_MSGCNT 7
   HMLAN2_RAWMSG E46A232,0000,170E90F5,FF,FFD8,0C841046A23200000006010080
   HMLAN2_RSSI -40
   HMLAN2_TIME 2023-04-23 22:43:34
   HmUARTusb_MSGCNT 8
   HmUARTusb_RAWMSG 0500004E0C841046A23200000006010080
   HmUARTusb_RSSI -78
   HmUARTusb_TIME 2023-04-23 22:43:34
   IODev      HmUARTusb
   LASTInputDev HMLAN1
   MSGCNT     23
   NAME       HM_46A232
   NR         881
   NTFY_ORDER 48-HM_46A232
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   disableNotifyFn 1
   eventCount 69
   lastMsg    No:0C - t:10 s:46A232 d:000000 06010080
   protLastRcv 2023-04-23 22:43:34
   protRcv    2 last_at:2023-04-23 22:43:34
   protState  Info_Cleared
   rssi_at_HMLAN1 cnt:6 min:-71 max:-55 avg:-62.5 lst:-66
   rssi_at_HMLAN2 cnt:6 min:-56 max:-40 avg:-46.5 lst:-40
   rssi_at_HmUARTusb cnt:6 min:-80 max:-55 avg:-71.5 lst:-78
   READINGS:
     2023-04-23 22:42:09   IODev           HmUARTusb
     2023-04-23 22:39:36   LastLowBattMailSent 1
     2023-04-23 22:43:34   battery         low
     2023-04-24 08:43:33   cfgState        PairMiss,PeerIncom,RegMiss
     2023-04-23 22:43:05   commState       Info_Cleared
     2023-04-23 22:43:34   deviceMsg       off (to broadcast)
     2023-04-23 22:43:34   level           0
     2023-04-23 22:43:34   pct             0
     2023-04-23 22:43:34   recentStateType info
     2023-04-23 22:43:34   state           off
     2023-04-23 22:43:34   timedOn         off
     2023-04-23 22:42:10   trigLast        fhem:02
   helper:
     HM_CMDNR   12
     PONtest    0
     cSnd       012FC73746A232010E,112FC73746A2320201C80000
     cfgChkResult No regs found for:-ret--ret-HM_46A232 type:switch - -ret-list:peer    register         :value-ret-   0:          intKeyVisib      :set_invisib-ret-   0:          pairCentral      :set_0x2FC737-ret-                       -ret-                       -ret-
     cfgStateUpdt 0
     dlvlCmd    ++A0112FC73746A2320201C80000
     getCfgList all
     getCfgListNo ,3
     lastMsgTm  1682282614.42979
     mId        006C
     peerFriend peerSens,peerVirt
     peerOpt    3:switch
     regLst     0,1,3p
     rxType     2
     supp_Pair_Rep 0
     cfgChk:
       idPc01     fail
       idPz00     fail
       idRc01     RegL_00.,RegL_01.
     cmds:
       TmplKey    :no:1681680907.76154
       TmplTs     1681680907.76154
       cmdKey     1:1:0::HM_46A232:006C:01:
       cmdLst:
         assignHmKey noArg
         clear      [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         getVersion noArg
         inhibit    [(on|{off})]
         off        noArg
         on         noArg
         on-for-timer -ontime-
         on-till    -time-
         pair       noArg
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         peerIODev  [IO] -btn- [({set}|unset)] 'not for future use'
         peerSmart  -peerOpt-
         press      [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         sign       [(on|{off})]
         statusRequest noArg
         toggle     noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         unpair     noArg
       lst:
         condition  slider,0,1,255
         peer      
         peerOpt    Handsender_Btn_1,Handsender_Btn_2,Handsender_Btn_3,Handsender_Btn_4,S.Garagentor,S.Garagentor2,S.Wassermelder_Heizraum,S.Wassermelder_Waschkuche,S.Zisterne,S_R_OG_Z1N_down,S_R_OG_Z1N_up
         tplChan   
         tplDel    
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        0
       det        0
       raw        1
       tpl        0
     io:
       flgs       0
       newChn     +46A232,00,00,00
       nextSend   1682282614.52304
       rxt        0
       vccu       VCCU
       p:
         46A232
         00
         00
         00
       prefIO:
     mRssi:
       mNo        0C
       io:
         HMLAN1:
           -66
           -66
         HMLAN2:
           -40
           -40
         HmUARTusb:
           -76
           -76
     peerIDsH:
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf  
       qReqStat  
     role:
       chn        1
       dev        1
       prs        1
     rssi:
       at_HMLAN1:
         avg        -62.5
         cnt        6
         lst        -66
         max        -55
         min        -71
       at_HMLAN2:
         avg        -46.5
         cnt        6
         lst        -40
         max        -40
         min        -56
       at_HmUARTusb:
         avg        -71.5
         cnt        6
         lst        -78
         max        -55
         min        -80
     shadowReg:
     shadowRegChn:
       RegL_00.   00
     tmpl:
   nb:
     cnt        1
Attributes:
   DbLogExclude .*
   IOgrp      VCCU
   autoReadReg 4_reqStatus
   expert     rawReg
   firmware   1.7
   model      HM-LC-SW1-BA-PCB
   msgRepeat  1
   room       CUL_HM,TEST
   serialNr   NEQ0315216
   subType    switch
   verbose    5
   webCmd     statusRequest:toggle:on:off

frank

#8
0. ist fhem up-to-date?

1. setze hmlan2 als prefered io im attr IODev. seltsam, dass das schlechteste io zum senden genutzt wird.

2. device ist scheinbar nicht gepairt.
also drüberpairen.
warum wird immer reset gemacht?

3. bereinige alle fehler von "get hminfo configCheck"

4. zeige je ein list von vccu und allen 3 io.
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

Pfriemler

zur Erläuterung:
1.
rssi_at_HMLAN2 cnt:6 min:-56 max:-40 avg:-46.5 lst:-40
rssi_at_HmUARTusb cnt:6 min:-80 max:-55 avg:-71.5 lst:-78

Zwar sind diese Werte aktuell nicht bedenklich (min -80 dB ist i.d.R. ungefährlich), aber wenn man 25 dB mehr bekommen kann auf der Strecke, schadet das nie.
Trifft natürlich nur zu, wenn der Aktor zu diesen Messungen am Originalort ist. Wenn er noch "in Probe" liegt, ist der Unterschied mit 38 dB noch größer - es muss aber sichergestellt sein, dass HMLAN2 auch am Einsatzort richtig ist.
Schaue doch mal bei den anderen Aktoren, welche rssi die für die Garage melden. Bestimmte das IO, was dort am besten ankommt, hoffentlich gibt es da passende rssi-readings.
 
2.
    2023-04-23 22:43:34   deviceMsg       off (to broadcast)
Frank sagt "scheinbar nicht gepairt", ich behaupte "definitiv". Ein gepairtes Gerät sendet seinen Status immer an die Zentrale ("to vccu" wohl in Deinem Fall) und nicht "ungezielt in die Botanik" (to broadcast). Nur manche (bswp. Temperatur-)Sensoren senden trotz pairing Werte "to broadcast".
Status ist auch ohne ohne pairing in FHEM immer aktuell, aber Steuerung und Datenabfrage kann nicht funktionieren.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

flobeewan

Hi,
heute hatte ich wieder Zeit mich mit dem Teil zu beschäftigen:
fhem up-to-date: JA
neue Stromversorgnung 12V Netzteil: JA
Position neu: zwischen HM-LAN2 und HmUARTusb (andere Sensoren und Aktoren arbeiten mit dieser Distanz einwandfrei)
(rssi_at_HmUARTusb  cnt:16 min:-52 max:-36 avg:-44 lst:-36 )
Ich habe versucht mittels mehrfach neu zu pairen, aber ohne Erfolg.
Ein set getConfig funktioniert auch nicht.
List VCCUInternals:
   DEF        2FC737
   FUUID      5c5c0d8f-f33f-360f-ce79-633c43ca1d5e0987
   HMLAN1_MSGCNT 314
   HMLAN1_RAWMSG E2E6098,0000,4E07336F,FF,FFA9,AA86102E60980000000AA8DE8E1900
   HMLAN1_RSSI -87
   HMLAN1_TIME 2023-04-29 14:35:42
   HMLAN2_MSGCNT 92
   HMLAN2_RAWMSG E2FC737,0000,000D5F03,FF,FFAF,27B0012FC73746A23200040000000000
   HMLAN2_RSSI -81
   HMLAN2_TIME 2023-04-29 14:31:44
   HmUARTusb_MSGCNT 18
   HmUARTusb_RAWMSG 050000519981122FC737000000
   HmUARTusb_RSSI -81
   HmUARTusb_TIME 2023-04-29 14:17:20
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     424
   NAME       VCCU
   NR         78
   NTFY_ORDER 48-VCCU
   STATE      HMLAN1:ok,HMLAN2:ok,HmUARTusb:ok
   TYPE       CUL_HM
   assignedIOs HMLAN1,HMLAN2,HmUARTusb
   chanNo     01
   disableNotifyFn 1
   eventCount 16
   lastMsg    No:27 - t:01 s:2FC737 d:46A232 00040000000000
   protLastRcv 2023-04-29 14:31:36
   protRcv    41 last_at:2023-04-29 14:31:36
   protRcvB   16 last_at:2023-04-29 14:31:36
   rssi_at_HMLAN1 cnt:72 min:-78 max:-60 avg:-61.62 lst:-60
   rssi_at_HMLAN2 cnt:92 min:-90 max:-72 avg:-81.32 lst:-81
   rssi_at_HmUARTusb cnt:18 min:-81 max:-55 avg:-56.5 lst:-81
   READINGS:
     2023-04-29 11:34:20   CommandAccepted yes
     2023-04-29 11:33:00   IODev           HMLAN1
     2023-04-29 14:33:01   IOopen          3
     2023-04-29 14:35:12   cfgState        ok
     2023-04-29 14:33:26   hmPair          timeout
     2023-04-29 14:33:01   state           HMLAN1:ok,HMLAN2:ok,HmUARTusb:ok
     2022-12-01 01:52:16   unknown_129825  received
   helper:
     HM_CMDNR   39
     lastMsgTm  1682771496.27512
     peerFriend
     peerOpt    v:virtual
     regLst     
     rxType     1
     supp_Pair_Rep 0
     cmds:
       TmplKey    :no:1682760781.07877
       TmplTs     1682760781.07877
       cmdKey     1:1:1::VCCU::01:
       cmdLst:
         assignIO   -IO- [({set}|unset)]
         clear      [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
         defIgnUnknown noArg
         hmPairForSec [-sec-]
         hmPairSerial -serial-
         peerChan   -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
         postEvent  -condition-
         press      [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
         pressL     [(-peer-|{all})]
         pressS     [(-peer-|{all})]
         tplSet_0   -tplChan-
         update     noArg
         virtual    [(1..50;1|{1})]
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         listDevice noArg
         param      -param-
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     io:
       nextSend   1682771504.78814
       vccu       VCCU
       ioList:
       prefIO:
     mRssi:
       mNo        27
       io:
         HMLAN1:
           -56
           -56
         HMLAN2:
           -81
           -81
         HmUARTusb:
     peerIDsH:
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
     rssi:
       at_HMLAN1:
         avg        -61.625
         cnt        72
         lst        -60
         max        -60
         min        -78
       at_HMLAN2:
         avg        -81.3260869565217
         cnt        92
         lst        -81
         max        -72
         min        -90
       at_HmUARTusb:
         avg        -56.5
         cnt        18
         lst        -81
         max        -55
         min        -81
     shadowReg:
     tmpl:
Attributes:
   DbLogExclude .*
   IOList     HMLAN1,HMLAN2,HmUARTusb
   group      Server
   model      CCU-FHEM
   room       CUL_HM
   subType    virtual
   verbose    2
   webCmd     virtual:update

list HmUARTusb
AssignedPeerCnt 2
   CNT        28
   Clients    :CUL_HM:
   DEF        /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
   DEVCNT     47
   DevState   99
   DevType    UART
   DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0@115200
   FD         18
   FUUID      61e487b5-f33f-360f-ba7c-355f60cca1273efd
   LastOpen   1682760780.81865
   NAME       HmUARTusb
   NOTIFYDEV  global
   NR         75
   NTFY_ORDER 47-HmUARTusb
   PARTIAL   
   RAWMSG     0500004B828470417F6200000000D42F
   RSSI       -75
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   eventCount 7
   model      HM-MOD-UART
   msgLoadCurrent 31
   msgLoadHistory 0/6/6/7/0/6/-6/0/0/0/0/6
   msgLoadHistoryAbs 31/31/25/19/12/12/6/12/12/12/12/12/6
   owner      2FC737
   owner_CCU  VCCU
   Helper:
     CreditTimer 739
     FW         66561
     Initialized 1
     SendCnt    24
     AckPending:
     DBLOG:
       D-HMIdAssigned:
         logdb:
           TIME       1682760783.27331
           VALUE      2FC737
         logdb_bkp_bic_at:
           TIME       1682760783.27382
           VALUE      2FC737
       D-HMIdOriginal:
         logdb:
           TIME       1682760783.27899
           VALUE      4F69A4
         logdb_bkp_bic_at:
           TIME       1682760783.27941
           VALUE      4F69A4
       D-firmware:
         logdb:
           TIME       1682760783.28896
           VALUE      1.4.1
         logdb_bkp_bic_at:
           TIME       1682760783.28927
           VALUE      1.4.1
       D-serialNr:
         logdb:
           TIME       1682760783.2993
           VALUE      NEQ1327813
         logdb_bkp_bic_at:
           TIME       1682760783.29971
           VALUE      NEQ1327813
       cond:
         logdb:
           TIME       1682760783.32978
           VALUE      ok
         logdb_bkp_bic_at:
           TIME       1682760783.33065
           VALUE      ok
       loadLvl:
         logdb:
           TIME       1682760783.32978
           VALUE      low
         logdb_bkp_bic_at:
           TIME       1682760783.33065
           VALUE      low
     LastSendLen:
       3
       3
     Log:
       IDs:
     PendingCMD:
     RoundTrip:
       Delay      0.00299501419067383
     loadLvl:
       lastHistory 1682771583.31059
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
     46A232     +46A232,00,00,00
     72CA5D     +72CA5D,00,00,00
   READINGS:
     2023-04-29 11:33:03   D-HMIdAssigned 
     2023-04-29 11:33:03   D-HMIdOriginal 
     2023-04-29 11:33:03   D-firmware      1.4.1
     2023-04-29 11:33:03   D-serialNr     
     2023-04-29 11:32:59   D-type          HM-MOD-UART
     2023-04-29 11:33:03   cond            ok
     2023-04-29 14:32:00   load            31
     2023-04-29 11:33:03   loadLvl         low
     2023-04-29 11:33:00   state           opened
   helper:
Attributes:
   group      Server
   hmId       
   icon       cul_868
   room       CUL_HM
   verbose    2


list HMLAN2
Internals:
   Clients    :CUL_HM:
   DEF       
   DeviceName
   FD         20
   FUUID      61e3f7d9-f33f-360f-1198-168b4547a96bfa9e
   HMLAN2_MSGCNT 718
   HMLAN2_TIME 2023-04-29 14:42:09
   IFmodel    LAN
   NAME       HMLAN2
   NR         73
   NTFY_ORDER 47-HMLAN2
   PARTIAL   
   RAWMSG     E417F7D,0000,0016E795,FF,FFBB,288470417F7D00000000D72F
   RSSI       -69
   STATE      opened
   TYPE       HMLAN
   XmitOpen   1
   assignedIDsCnt 0
   eventCount 464
   msgKeepAlive dlyMax:1.492 bufferMin:3
   msgLoadCurrent 1
   msgLoadHistoryAbs 5min steps: 1/1/1/1/1/0/0/0/0/0/0/0
   msgParseDly min:8 max:2938 last:12 cnt:652
   nextOpenDelay 10
   owner      2FC737
   owner_CCU  VCCU
   uptime     000 00:25:12.197
   READINGS:
     2023-04-29 11:33:01   D-HMIdAssigned  2FC737
     2023-04-29 11:33:01   D-HMIdOriginal  23A579
     2023-04-29 11:33:01   D-firmware      0.965
     2023-04-29 11:33:01   D-serialNr     
     2023-04-29 14:17:20   Xmit-Events     init:2 disconnected:3 ok:2
     2023-04-29 14:17:20   cond            ok
     2023-04-29 14:42:20   loadLvl         low
     2023-04-29 14:16:52   prot_disconnected last
     2023-04-29 14:17:20   prot_init       last
     2023-03-25 04:25:27   prot_keepAlive  last
     2023-04-29 14:17:20   prot_ok         last
     2023-04-29 14:17:20   state           opened
   helper:
     assIdCnt   0
     assIdRep   0
     info       03C5,KEQ0852257,23A579,2FC737
     setTime    51354
     cnd:
       0          2
       253        3
       255        2
     dly:
       cnt        652
       lst        12
       max        2938
       min        8
     ids:
       46A232:
         flg        0
     k:
       BufMin     3
       DlyMax     1.492
       Next       1682772165.48472
       Start      1682772140.48472
     loadLvl:
       bl         40
       a:
         99
         90
         40
         30
         0
       h:
         0          low
         30         mid
         40         batchLevel
         90         high
         99         suspended
     log:
       all        0
       sys        0
       ids:
         ARRAY(0x56076b16f158)
     q:
       HMcndN     0
       answerPend 0
       hmLanQlen  1
       keepAliveRec 1
       keepAliveRpt 0
       loadLastMax 1
       loadNo     8
       scnt       2
       sending    0
       ald:
         1
         1
         1
         1
         1
         0
         0
         0
         0
         0
         0
         0
       apIDs:
     ref:
       drft       -0.000119990400767939
       hmtL       1512197
       kTs        0
       offL       1682770628313
       sysL       1682772115486
Attributes:
   DbLogExclude .*
   devStateIcon opened:10px-kreis-gruen disconnected:10px-kreis-rot
   do_not_notify 0
   group      Server
   hmId       
   hmLanQlen  1_min
   icon       hm_lan
   loadLevel  0:low,30:mid,40:batchLevel,90:high,99:suspended
   room       CUL_HM,TEST
   verbose    0
   wdTimer    25

Als letztes bin ich bei der Abarbeitung der "get hminfo configCheck" gelandet:
Das ich scheinbar eine größere Baustelle.
Mit Peering habe ich mich noch nicht beschäftigt, da bis jetzt auch alles ohne gut lief.
Beim pairing finde ich folgende Fehler:
PairedTo missing/unknown
    HK_Bad:   
    HM_46A232:   (Problemkind Garagentoröffner)
    Handsender:   
    LichtHuehnerstall:   
    R_EG_Kueche:
Kann ich nicht ganz nachvollziehen, da die restlichen Aktoren alle sauber funktioniern.

Und bei diesen Fehlern muss ich erstmal suchen gehen:
 missing register list
    HK_Bad:   RegL_00.,RegL_01.
    HM_46A232:   RegL_00.,RegL_01. (Problemkind Garagentoröffner)
    Handsender:   RegL_00.
    Handsender_Btn_1:   RegL_01.
    Handsender_Btn_2:   RegL_01.
    Handsender_Btn_3:   RegL_01.
    Handsender_Btn_4:   RegL_01.
    LichtHuehnerstall:   RegL_00.,RegL_01.
    R_EG_Kueche:   RegL_00.,RegL_01.

Mehr kann ich zur Zeit nicht bieten.
Danke jedenfalls für eure Hilfe!

frank

#11
leider sind deine infos wieder unvollständig.

1. mit welchem prefered io hast du nun gepairt?

2. wo ist list hmlan1?

3. warum hat die vccu kein attr iogrp?

4. warum fehlen beim hmuartusb die werte für die readings hmid-assigned, hmid-orig und serialnumber?
unkenntlich gemacht?

5. zeig mal die ausgabe vom fhem cmd "version".

6. mach mal ein fhem restart und poste anschliessend erneut ein list der vccu.

7. sniffe die raw messages beim pairing versuch. siehe wiki homematic sniffen.

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

Pfriemler

franks Einlassungen unterstütze ich wie immer zu 100%...
Nur zur Erkläuterung: Es kommt auch bei mir hin und wieder vor, dass Registerlisten unvollständig sind oder FHEM denkt, es fehlt das Pairing. Das betrachte ich als normal.
Es hat aber absolut keinen Sinn, Informationen von Geräten abzufordern, die auch sonst nicht auf FHEM reagieren. Da gehören zuallererst alle anstehenden Befehle gelöscht und das Pairing erneutert.
Pairst Du richtig? hmPairSerial funktioniert hier nicht immer, hmPairForSeconds eher.
Aber bringe erst mal FHEM in Ordnung, wie frank sagt.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

flobeewan

Nach vielen weiteren Stunden der Problemsuche habe ich den vermeintlich defekten  HM-LC-SW1-BA-PCB  gegen einen Shelly Plus 1 getauscht. Die Inbetriebnahme und Konfiguration als Taster für das Garagentor waren einfach. Damit funktioniert es bei mir wieder. Ich schließe das Thema.
Danke an alle für die Unterstützung beim Fehlersuchen.