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!
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
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
Was mir heute Nacht noch aufgefallen ist: es gibt keinen RSSI Eintrag für Device -> VCCU (egal welcher HMLAN)?
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.
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
ZitatWürde ein "list" zur Fehlersuche helfen?
infos sind immer gut, oder nicht?
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
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.
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.
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!
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.
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.
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.