Hallo,
ich habe da ein seltsames Problem mit einem meiner Rolladenaktoren.
Nach einem (geplanten) Stromausfall kann dieser eine Aktor nicht mehr kommunizieren (MISSING ACK / unreachable / aescommtodev fail).
Alle anderen Aktoren und Sensoren funktionieren einwandfrei (auch mit AES).
Ich habe jetzt schon mehrfach folgendes versucht:
- Aktor stromlos machen
- Aktor "drüberpairen" mit "set <name> pair", aber auch mit hmPairForSec und die Config-Taste drücken
- versucht das AES auszuschalten mit "set <name> sign off" aber der Befehl kommt beim Aktor offenbar nicht an, in den Readings steht es dann immer auf "set_off"
Die Bedienung des Aktors an der Wippe selbst funktioniert noch einwandfrei.
Was kann ich jetzt noch tun? Wie gesagt, bei diesem Aktor ist AES aktiviert. Kann ich ihn einfach mal einen Werksreset versuchen oder wäre das keine gute Idee?
Soll ich ihn dazu vorher aus der fhem-config komplett rauslöschen?
Oder...?
Vielen Dank für jede Hilfe.
Hier noch ein List des Aktors:
Internals:
CFGFN ./FHEM/Rollaeden.cfg
DEF 307A0F
FUUID 5c45b665-f33f-d150-51d1-d18290e553540a72
HMLAN1_MSGCNT 20
HMLAN1_RAWMSG E307A0F,0000,4503BEFA,FF,FFB6,04A002307A0F8286FF04FA36B959FEFC02
HMLAN1_RSSI -74
HMLAN1_TIME 2019-03-19 14:08:00
IODev CUL_SER
LASTInputDev HMLAN1
MSGCNT 41
NAME EG_WZ_Rolladen_Terrasse
NOTIFYDEV global
NR 213
NTFY_ORDER 50-EG_WZ_Rolladen_Terrasse
STATE MISSING ACK
TYPE CUL_HM
hmPairSerial LEQ1179xxx
myHmUART_MSGCNT 21
myHmUART_RAWMSG 0500004704A002307A0F8286FF04FA36B959FEFC02
myHmUART_RSSI -71
myHmUART_TIME 2019-03-19 14:08:00
protCmdDel 5
protResnd 9 last_at:2019-03-19 14:08:00
protResndFail 3 last_at:2019-03-19 14:08:05
protSnd 4 last_at:2019-03-19 14:07:48
protState CMDs_done_Errors:1
rssi_at_HMLAN1 cnt:20 min:-76 max:-72 avg:-73.85 lst:-74
rssi_at_myHmUART cnt:21 min:-73 max:-57 avg:-63.28 lst:-71
READINGS:
2019-03-16 10:29:03 CommandAccepted yes
2019-01-14 08:03:53 D-firmware 2.8
2019-01-14 08:03:53 D-serialNr LEQ1179xxx
2019-01-23 11:36:18 PairedTo 0xxxxxxx
2019-01-23 11:36:19 R-driveDown 24.1 s
2019-01-23 11:36:19 R-driveTurn 1 s
2019-01-23 11:36:19 R-driveUp 26.5 s
2019-01-23 11:36:18 R-pairCentral 0xxxxxxx
2019-01-23 11:36:19 R-powerUpAction off
2019-03-19 12:53:45 R-sign on
2019-01-23 11:36:18 RegL_00. 00:00 02:01 0A:82 0B:86 0C:FF 15:FF 18:00
2019-01-23 11:36:19 RegL_01. 08:01 09:00 0A:00 0B:00 0C:F1 0D:01 0E:09 0F:0A 10:00 30:06 56:00 57:06
2019-03-19 12:37:56 aesCommToDev fail
2019-03-16 10:29:03 aesKeyNbr 02
2019-03-16 10:29:03 deviceMsg on (to CCU)
2019-03-19 14:07:48 inhibit set_on
2019-03-17 19:06:20 level set_0
2019-03-16 10:29:03 motor stop:on
2019-03-16 10:29:03 pct 100
2019-03-16 10:29:03 recentStateType ack
2019-03-19 14:08:05 state MISSING ACK
2019-03-16 10:29:03 timedOn off
helper:
HM_CMDNR 4
cSnd 018286FF307A0F01050000000001,118286FF307A0F0101
mId 006A
regLst ,0,1,3p
rxType 1
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +307A0F,01,00,02
nextSend 1553000880.99855
rxt 0
vccu CCU
p:
307A0F
01
00
02
prefIO:
CUL_SER
mRssi:
mNo 04
io:
CUL_SER:
HMLAN1:
-74
-74
myHmUART:
-71
-71
prt:
bErr 0
sProc 0
q:
qReqConf 00
qReqStat 00
role:
chn 1
dev 1
prs 1
rssi:
at_HMLAN1:
avg -73.85
cnt 20
lst -74
max -72
min -76
at_myHmUART:
avg -63.2857142857143
cnt 21
lst -71
max -57
min -73
shadowReg:
RegL_01. 00:00 08:01 09:00 0A:00 0B:00 0C:F1 0D:01 0E:09 0F:0A 10:00 30:06 56:00 57:06
tmpl:
role:
Attributes:
IOgrp CCU:CUL_SER
aesCommReq 1
alias EG_WZ_Rolladen_Terrasse
autoReadReg 4_reqStatus
devStateIcon up:fts_shutter_1w_10@green down:fts_shutter_100@black 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_100
eventMap on:up off:down
expert 2_full
firmware 2.8
group Rolladen
icon fts_shutter_1w_100
model HM-LC-Bl1PBU-FM
peerIDs 00000000,
room Hausstatus
serialNr LEQ1179xxx
subType blindActuator
webCmd stop:up:pct:down
widgetOverride pct:select,0,10,20,30,40,50,60,70,80,90,100
pair mit der Seriennummer
werksreset wird nicht funktionieren, da scheinbar ein eigener aes key hinterlegt ist (keynbr02).
setze mal ein anderes prefered io.
warum fehlt das attr IODev?
ist der cul in der vccu assigned und der key in der vccu eingetragen?
Zitat von: Wuppi68 am 19 März 2019, 14:36:05
pair mit der Seriennummer
Funktioniert auch nicht.
Zitat von: frank am 19 März 2019, 14:39:04
werksreset wird nicht funktionieren, da scheinbar ein eigener aes key hinterlegt ist (keynbr02).
setze mal ein anderes prefered io.
warum fehlt das attr IODev?
ist der cul in der vccu assigned und der key in der vccu eingetragen?
Ja, es ist ein eigener AES Key bei allen AES-aktivierten Devices hinterlegt.
IODev wurde mit Wechsel auf VCCU entfernt (war nicht nötig wie ich im Nachhinein bemerkt habe, habe es dann aber so gelassen. Es fehlt bei allen Devices.)
Der CUL ist der VCCU zugeordnet und diese hat auch den Key - wie gesagt, alles anderen Devices funktionieren ja noch mit AES (auch die anderen Rolladenaktoren, welche über oder unter dem "defekten" hängen. Diese kommunizieren auch alle über den CUL).
Es wird also nicht am CUL oder der AES Config an sich liegen.
Hast Du weitere Ideen?
Hier noch ein List der vCCU:
Internals:
CUL_SER_MSGCNT 12
CUL_SER_RAWMSG A0AF480028286FF4473B500::-56.5:CUL_SER
CUL_SER_RSSI -56.5
CUL_SER_TIME 2019-03-19 12:40:31
DEF 82xxxx
FUUID 5c45b665-f33f-d150-e178-2d2dee148d9a792b
HMLAN1_MSGCNT 121
HMLAN1_RAWMSG E8286FF,0000,45313CB7,FF,FFA1,5F80028286FF3CC1A600
HMLAN1_RSSI -95
HMLAN1_TIME 2019-03-19 14:57:41
IODev myHmUART
LASTInputDev HMLAN1
MSGCNT 197
NAME CCU
NOTIFYDEV global
NR 88
NTFY_ORDER 50-CCU
STATE myHmUART:ok,HMLAN1:ok,CUL_SER:ok
TYPE CUL_HM
assignedIOs CUL_SER,HMLAN1,myHmUART
channel_01 CCU_Btn1
channel_02 CCU_Btn2
channel_03 CCU_Btn3
channel_04 CCU_Btn4
channel_05 CCU_Btn5
channel_06 CCU_Btn6
channel_07 CCU_Btn7
channel_08 CCU_Btn8
channel_09 CCU_Btn9
channel_0A CCU_Btn10
lastMsg No:5F - t:02 s:8286FF d:3CC1A6 00
myHmUART_MSGCNT 64
myHmUART_RAWMSG 050000344880028286FF407BDF0101D900
myHmUART_RSSI -52
myHmUART_TIME 2019-03-19 14:47:14
protLastRcv 2019-03-19 14:57:41
protRcv 92 last_at:2019-03-19 14:57:41
protRcvB 5 last_at:2019-03-19 12:45:24
rssi_at_CUL_SER cnt:10 min:-77.5 max:-56.5 avg:-60.85 lst:-56.5
rssi_at_HMLAN1 cnt:90 min:-99 max:-80 avg:-85.56 lst:-95
rssi_at_myHmUART cnt:64 min:-53 max:-51 avg:-52.07 lst:-52
READINGS:
2019-03-19 14:57:41 CommandAccepted yes
2019-03-19 12:40:20 IOopen 3
2019-03-19 12:37:56 aesKeyNbr 00
2019-03-19 12:31:41 aesReqTo EG_WZ_Rolladen_Fenster
2019-03-19 12:40:20 state myHmUART:ok,HMLAN1:ok,CUL_SER:ok
2019-02-22 10:52:21 unknown_30DC99 received
2019-03-19 12:38:55 unknown_4097D6 received
2019-03-19 14:52:57 unknown_601274 received
2019-03-19 12:40:19 unknown_999999 received
2019-03-19 14:39:40 unknown_B19AD1 received
helper:
HM_CMDNR 95
PONtest 1
mId FFF0
regLst ,0
rxType 1
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 0
tpl 0
io:
nextSend 1553003861.80728
prefIO
vccu
ioList:
myHmUART
HMLAN1
CUL_SER
mRssi:
mNo 5F
io:
CUL_SER:
HMLAN1:
-95
-95
myHmUART:
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
at_CUL_SER:
avg -60.85
cnt 10
lst -56.5
max -56.5
min -77.5
at_HMLAN1:
avg -85.5666666666667
cnt 90
lst -95
max -80
min -99
at_myHmUART:
avg -52.078125
cnt 64
lst -52
max -51
min -53
tmpl:
Attributes:
IODev myHmUART
IOList myHmUART,HMLAN1,CUL_SER
group Gateways
hmKey 01:8e958d0fbdad605487325a53ccb1423d1
model CCU-FHEM
room CUL_HM
subType virtual
webCmd virtual:update
ändere trotzdem mal das prefered io, da es keine infos zum cul in den internals gibt. auch der letzte timestamp vom cul in der vccu ist schon länger her: 12:40 uhr
Habe gerade die anderen beiden IO-Devices eingetragen und ausprobiert, leider mit dem selben Ergebnis.
aescommtodev fail / MISSING ACK
Tja nun...als letzte Option habe ich nun ein Backup gemacht und danach ein Update von FHEM. Dabei wurde auch die 10_CUL_HM erneuert.
Das letzte Update habe ich im Januar durchgeführt.
Und was soll ich sagen..direkt nach dem Update war der Aktor wieder erreichbar. Muss ich nicht verstehen und ist ziemlich unbefriedigend, aber ich bin froh, dass der Aktor nicht in den E-Schrott musste.
Ich würde dennoch gerne verstehen, was da passiert ist...