Hallo Martin,
da das Problem (nun) unabhängig vom ActionDetector ist, mache ich mal einen neuen Thread zu dem Thema auf.
Ein get getSerial zu meinem HM_SwT8fach funktioniert nicht. Hier das Log:
2020.08.15 09:35:47.938 3: CUL_HM set HM_SwT8fach getSerial
2020.08.15 09:35:47.943 4: TSCUL_Write: CUNX_HM868 sending As0BE9B001F110346A915A0009
2020.08.15 09:35:47.946 4: TSCUL_send: CUNX_HM868 247786 As 0B E9 B001 F11034 6A915A 0009
2020.08.15 09:35:47.950 4: TSCUL_XmitDlyHM: CUNX_HM868 id:6A915A rtoms:3348
2020.08.15 09:35:48.954 4: TSCUL_Parse: CUNX_HM868 248788 A F203 11097568 01 0B E9 B001 F11034 6A915A 0009 _bst _CCAdly:4
2020.08.15 09:35:48.961 4: TSCUL_Parse: CUNX_HM868 248788 A F203 11098176 01 0B E9 B001 F11034 6A915A 0009 _bst _CCAdly:4
2020.08.15 09:35:49.545 4: TSCUL_Parse: CUNX_HM868 249378 A F203 11098784 01 0B E9 B001 F11034 6A915A 0009 _bst _CCAdly:4
2020.08.15 09:35:49.804 4: TSCUL_ParseTsHM: CUNX_HM868 HM repeat failed to 6A915A/HM_SwT8fach: 249617 A F209 11099388 00 0B E9 B001 F11034 6A915A 0009 _bst _sfail _noAnsw
2020.08.15 09:35:51.299 4: TSCUL_XmitAwaitHMTo CUNX_HM868: timeout - 6A915A
2020.08.15 09:35:53.620 4: CUL_HM_Resend: HM_SwT8fach nr 2
2020.08.15 09:35:53.622 4: TSCUL_Write: CUNX_HM868 sending As0BE9B001F110346A915A0009
2020.08.15 09:35:53.626 4: TSCUL_send: CUNX_HM868 253466 As 0B E9 B001 F11034 6A915A 0009
2020.08.15 09:35:53.630 4: TSCUL_XmitDlyHM: CUNX_HM868 id:6A915A rtoms:3348
2020.08.15 09:35:54.005 4: TSCUL_Parse: CUNX_HM868 253838 A F203 11103228 01 0B E9 B001 F11034 6A915A 0009 _bst _CCAdly:4
2020.08.15 09:35:54.615 4: TSCUL_Parse: CUNX_HM868 254449 A F203 11103840 01 0B E9 B001 F11034 6A915A 0009 _bst _CCAdly:4
2020.08.15 09:35:55.224 4: TSCUL_Parse: CUNX_HM868 255058 A F203 11104448 01 0B E9 B001 F11034 6A915A 0009 _bst _CCAdly:4
2020.08.15 09:35:55.481 4: TSCUL_ParseTsHM: CUNX_HM868 HM repeat failed to 6A915A/HM_SwT8fach: 255298 A F209 11105052 00 0B E9 B001 F11034 6A915A 0009 _bst _sfail _noAnsw
2020.08.15 09:35:56.980 4: TSCUL_XmitAwaitHMTo CUNX_HM868: timeout - 6A915A
das Device antwortet reproduzierbar nicht darauf.
Änderung zu
elsif($cmd eq "getSerial") { ################################################
# CUL_HM_PushCmdStack($hash,'++'.$flag.'01'.$id.$dst.'0009'); #noansi does not work with HM-MOD-RE-8
CUL_HM_PushCmdStack($hash,'++A401'.$id.$dst.'0009');
$state = "";
}
funktioniert dagegen:
2020.08.15 09:38:42.273 3: CUL_HM set HM_SwT8fach getSerial
2020.08.15 09:38:42.277 4: TSCUL_Write: CUNX_HM868 sending As0BEBB401F110346A915A0009
2020.08.15 09:38:42.281 4: TSCUL_send: CUNX_HM868 422121 As 0B EB B401 F11034 6A915A 0009
2020.08.15 09:38:42.284 4: TSCUL_XmitDlyHM: CUNX_HM868 id:6A915A rtoms:3348
2020.08.15 09:38:43.246 4: TSCUL_Parse: CUNX_HM868 423081 A F303 11271464 01 0B EB B401 F11034 6A915A 0009 _bst _CCAdly:4
2020.08.15 09:38:43.256 4: TSCUL_Parse: CUNX_HM868 423081 A F301 11271960 00 14 EB 8010 6A915A F11034 0050455130353037383234 -48dB
Das eine Bit macht also einen Unterschied.
List vom Aktor (nach Neustart FHEM):
Internals:
CUNX_HM868_MSGCNT 8
CUNX_HM868_RAWMSG A0ED4A4106A915AF110340608000000::-44.5:CUNX_HM868:
CUNX_HM868_RSSI -44.5
CUNX_HM868_TIME 2020-08-15 10:41:42
DEF 6A915A
FUUID 5c837da1-f33f-d123-48cf-1aa9118e8322bf0c
IODev CUNX_HM868
LASTInputDev SCC_HM868
MSGCNT 15
NAME HM_SwT8fach
NOTIFYDEV global
NR 520
NTFY_ORDER 50-HM_SwT8fach
SCC_HM868_MSGCNT 7
SCC_HM868_RAWMSG A0ED4A4106A915AF110340608000000::-47.5:SCC_HM868:
SCC_HM868_RSSI -47.5
SCC_HM868_TIME 2020-08-15 10:41:42
STATE CMDs_done
TYPE CUL_HM
channel_01 HM_SwT8fach_Sw_01
channel_02 HM_SwT8fach_Sw_02
channel_03 HM_SwT8fach_Sw_03
channel_04 HM_SwT8fach_Sw_04
channel_05 HM_SwT8fach_Sw_05
channel_06 HM_SwT8fach_Sw_06
channel_07 HM_SwT8fach_Sw_07
channel_08 HM_SwT8fach_Sw_08
lastMsg No:D4 - t:10 s:6A915A d:F11034 0608000000
protLastRcv 2020-08-15 10:41:42
protRcv 8 last_at:2020-08-15 10:41:42
protSnd 16 last_at:2020-08-15 10:41:42
protSndB 6 last_at:2020-08-15 10:41:42
protState CMDs_done
rssi_at_CUNX_HM868 cnt:8 min:-48 max:-42.5 avg:-45.62 lst:-44.5
rssi_at_SCC_HM868 cnt:7 min:-47.5 max:-45 avg:-46.78 lst:-47.5
.attraggr:
.attreocr:
state
battery
.attrminint:
READINGS:
2020-08-14 20:49:00 .D-devInfo 480100
2020-08-14 20:49:00 .D-stc 10
2020-08-15 10:40:25 .associatedWith HM_SwT8fach,HM_SwT8fach_Sw_01,HM_SwT8fach_Sw_02,HM_SwT8fach_Sw_03,HM_SwT8fach_Sw_04,HM_SwT8fach_Sw_05,HM_SwT8fach_Sw_06,HM_SwT8fach_Sw_07,HM_SwT8fach_Sw_08,HM_SwT8fach
2020-08-15 10:41:42 .protLastRcv 20200815104142
2020-08-15 10:40:08 Activity alive
2020-05-17 14:26:23 CommandAccepted yes
from archivexx D-firmware 1.2
from archivexx D-serialNr PEQ0507824
2020-06-12 20:16:18 PairedTo 0xF11034
2020-01-26 21:57:40 R-intKeyVisib invisib
2020-01-26 21:57:40 R-ledMode on
2020-01-26 21:57:40 R-pairCentral 0xF11034
2020-06-12 20:16:18 RegL_00. 00:00 02:01 05:40 0A:F1 0B:10 0C:34 18:00 D7:A0
2020-06-14 20:28:11 aesKeyNbr 02
2020-08-15 10:40:53 cfgState ok
2020-08-15 10:41:42 commState CMDs_done
2020-02-03 00:25:57 level 0
2020-02-03 00:25:57 pct 0
2020-02-03 00:25:57 powerOn 2020-02-03 00:25:57
2020-02-03 00:25:57 recentStateType info
2020-08-15 10:41:42 state CMDs_done
2020-02-03 00:25:57 timedOn off
helper:
HM_CMDNR 212
cSnd 01F110346A915A070E,01F110346A915A080E
mId 00BE
peerFriend
peerOpt -:switch
regLst 0
rxType 2
supp_Pair_Rep 0
tmplChg 0
ack:
cmds:
TmplKey :no:1597480849.534
TmplTs 1597480849.534
cmdKey 0:1:0::HM_SwT8fach:00BE:01:
cmdLst:
assignHmKey noArg
clear [readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
deviceRename newName
fwUpdate -filename- -bootTime- ...
getConfig noArg
getDevInfo noArg
getRegRaw [List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
getSerial noArg
getVersion noArg
pair noArg
raw data ...
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2- ...
regSet [prep|exec] -regName- -value- ... [-peerChannel-]
reset noArg
tplDel tmplt
tplSet_0 -tplChan-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt
tplChan
tplDel
tplPeer
expert:
def 1
det 1
raw 1
tpl 0
io:
lstRecType 10
newChn +6A915A,00,01,00
nextSend 1597480902.86654
nxtSndMcnt D4
prefIO
rxt 0
tgtDly 88
vccu VCCU
lRcTm:
CUNX_HM868 619022356
SCC_HM868 54622544
tnms 826810491
p:
6A915A
00
01
00
mRssi:
mNo D4
io:
CUNX_HM868:
-42.5
-42.5
SCC_HM868:
-47.5
-47.5
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
prs 1
rpt:
IO CUNX_HM868
flg A
ts 1597480902.81015
ack:
HASH(0x2c601e8)
D48002F110346A915A00
rssi:
at_CUNX_HM868:
avg -45.625
cnt 8
lst -44.5
max -42.5
min -48
at_SCC_HM868:
avg -46.7857142857143
cnt 7
lst -47.5
max -45
min -47.5
tmpl:
Attributes:
.mId 00BE
IODev CUNX_HM868
IOgrp VCCU
actCycle 001:00
actStatus alive
aesKey 1
autoReadReg 5_readMissing
event-on-change-reading state,battery
expert defReg,allReg,rawReg
firmware 1.2
model HM-MOD-RE-8
msgRepeat 1
room Receiver
rssiSwitchHyst 2
serialNr PEQ0507824
subType switch
webCmd getConfig:clear msgEvents
Es ist mir aber auch aufgefallen, dass mein HM-DIS-EP-WM55 sich von der geänderten Code-Variante auch grün blinkend für eine kurze Zeit zum wach bleiben aufgefordert fühlt, wenn ich getSerial auf den HM_SwT8fach loslasse. Also wäre eine häufigen Verwendung des (geänderten) getSerial nicht so sehr zu empfehlen, wenn auch andere Burst devices wie das display reagieren und unnötig mehr Energie aus ihrer Batterie entnehmen.
Gruß, Ansgar.
Ich sollte getSerial sperren. Das Kommando ist eigentlich experimentell... nicht dokumentiert und somit nicht bestätigt.
Es wird auf lange Sicht immer Probleme machen und es braucht eigentlich keiner.
Hallo Martin,
ich kann damit leben und nutze und benötige es auch nicht.
Gruß und danke, Ansgar.