FHEM Forum
FHEM - Hausautomations-Systeme => Homematic => Thema gestartet von: cthil am 17 August 2021, 15:15:40
-
Hallo zusammen,
nach dem letzten Update funktionieren Sensoren, bei denen die AES-Signatur aktiv ist, nicht mehr.
Es scheint als würden die Probleme durch 10_CUL_HM.pm ausgelöst. Ich bin bis SVN-Revision 24374 schrittweise zurück gegangen, das ist die letzte funktionierende.
Auffällig ist, dass es nur die Richtung Sensor -> FHEM betrifft. FHEM -> Aktor (auch AES-signiert) funktioniert mit dem letzten Stand einwandfrei.
Vielleicht noch relevant: Ich verwende eine VCCU mit HMUARTLGWs dahinter. Bei Sensor-Tastendrücken wird bei der kaputten Version ein aesKeyNbr 0 gemeldet, die funktionierende meldet (korrekt) 2.
Viele Grüße,
Christophe
-
Hallo *,
ich schließe mich cthil an.
Bei gleichem Kontext streiken bei mir Rollladenaktoren HM-LC-Bl1PBU-FM nach einem Update am 24.8.21.
Ein restore stellt korrekte Funktionalität wieder her.
Betroffen sind nur manuelle Betätigungen der Schalter. Auslösungen durch FHEM funktionieren.
Viele Grüße
-
Ergänzung:
An der VCCU hängen bei mir ein HMUARTLGW/HM-MOD-UART und ein HMLAN.
Weitere Versuche ergaben, dass nur beim HMUARTLGW AES Probleme aufteten nach FHEM update.
Nach restore gehts weiter.
Nochmals viele Grüße
-
Problem kann ich leider bestätigen.
-
Moin,
kann ich auch leider nur bestätigen. Bei mir ist es die AES-Verbindung zum Keymatic, die den falschen Status anzeigt. Darüber hinaus werden häufig "Missing Ack" Meldungen geschickt.
In den Readings wird
aesCommToDev failangezeigt.
Alle anderen Readings sehen normal aus.
Edit: Die Befehle werden nicht zuverlässig ausgeführt!
-
Muss mich leider anschließen. Auch HMUARTLGW.
Sporadisch funktioniert die Kommunikation, dann wieder nicht.
Ich erkenne kein System. Zuerst dachte ich, dass es an einem preferredIO der VCCU liegt. (IOgrp = vccu:HMLAN1 statt vccu) aber das war es dann doch nicht.
Nach dem Rollback auf den Zustand vor dem Update funktioniert es wieder.
Grüße
Hugo
-
Muss mich leider anschließen. Auch HMUARTLGW.
Sporadisch funktioniert die Kommunikation, dann wieder nicht.
eventuell verbessert diese gepatchte 00_HMURTLGW.pm das instabile verhalten?
https://forum.fhem.de/index.php/topic,122160.msg1168679.html#msg1168679 (https://forum.fhem.de/index.php/topic,122160.msg1168679.html#msg1168679)
-
@all
ist bei allen hauptdevices das attr IOgrp gesetzt?
falls ja: wird ein "optimales" io genutzt?
falls nein: ein "optimales" io als prefered io mit IOgrp setzen.
-
@all
ist bei allen hauptdevices das attr IOgrp gesetzt?
Ja
falls ja: wird ein "optimales" io genutzt?
Ja
falls nein: ein "optimales" io als prefered io mit IOgrp setzen.
-
Hallo,
IOgrp ist überall gesetzt.
Vor und nach update ist gemäß HMInfo rssi das HMUARTLGW das optimale.
-
IOgrp ist überall gesetzt.
wirklich in allen hm devices?
auch in allen virtuellen, zb die vccu?
probier doch auch mal die gepatchte 00_hmuartlgw.pm.
-
Nach update den patch angebracht und restart durchgeführt.
Keine Verbesserung.
Kein IOgrp beim ActionDetector
Bei VCCU nur IOList
-
actiondetector ist richtig.
aber setze iogrp auch mal in der vccu.
-
Mittlerweile bei beiden gesetzt. Keine Verbesserung.
Actiondetector nehme ich zurück.
Übrigens Danke für die Hilfe bisher
-
probiere mal den workaround von tndx.
https://forum.fhem.de/index.php/topic,100911.0.html (https://forum.fhem.de/index.php/topic,100911.0.html)
-
Experiment ausgeführt mit einer der Jalousien
und weiterhin dem 00_HMURTLGW.pm patch:
aesCommReq = 0
Manuelles Schalten am Aktor: korrektes Verhalten
aesCommReq = 1
Manuelles Schalten: korrektes Verhalten auch mit AES
restart durchgeführt:
wieder diverse aesCommToDev: pending, fail Paare
-
danke für die tests.
dann ist ja klar, dass durch das löschen aller attribute IODev in den aktuellen cul_hm versionen, das uralte "fehlverhalten" erneut zu tage tritt.
scheinbar gibt es einen unterschied beim initilisieren der io zwischen hmlan und hmuart bei fhem restart.
eventuell gibt es noch eine abhängigkeit bei der reihenfolge der io:
1. im attr IOList der vccu
2. oder in der reihenfolge der definitionen in der fhem.cfg
sind eigentlich alle devices mit attr aesCommReq, die den hmuart nutzen, betroffen?
ist bei den devices nach restart jeweils im internal und reading IODev korrekt gesetzt?
-
Was heisst korrekt? die readings haben den wert, den ich wegen rssis erwarten würde.
Alle aesCommReq=1, die den hmuart nutzen, betroffen.
-
Ich habe noch den Hinweis mit der Reihenfolge verfolgt.
Bisher an der VCCU nach restart:
IOList LANInterface,HMUART
Der Versuch die Reihefolge umzukehren gelinkt nicht wegen Fehlermeldung
LANInterface does not support CUL_HM
-
Was heisst korrekt?
gute frage. :)
zeig doch mal ein list vom aktor direkt nach restart.
und zum vergleich ein list nach dem workaround, wenn es wieder funktioniert.
vielleicht existiert ein unterschied.
attr iolist lässt sich in deiner version nur über editieren der fhem.cfg ändern mit anschliessendem fhem restart.
-
attr iolist lässt sich in deiner version nur über editieren der fhem.cfg ändern mit anschliessendem fhem restart.
Das stimmt nicht uneingeschränkt - wenn alle beteiligten IO's ein Internal "Clients" mit CUL_HM haben, kann man sehr wohl auch zumindest mit den (gepatchten) letzten Versionen dieses Attribut via FHEMWEB ändern; bei HMLAN geht das nur seltsamerweise irgendwie verloren (!). Eventuell hängt die AES-Funktionalität auch daran, dass (vermeintlich) nur noch ein Teil der IO's berücksichtigt werden kann (siehe auch https://forum.fhem.de/index.php/topic,122848.0.html (https://forum.fhem.de/index.php/topic,122848.0.html)).
-
Das HMUART hat ein Internal
Clients :CUL_HM:
Das HMLAN nicht.
Hab ich da Einfluß drauf?
list nach restart:
Internals:
CFGFN ./FHEM/myJalGEF.cfg
DEF 5C8351
FUUID 6127a5df-f33f-9dc6-9929-347556cb06a2dd48
IODev XX_HMUART
LASTInputDev XX_HMUART
MSGCNT 20
NAME JA_GEF_Jal
NR 1172
NTFY_ORDER 50-JA_GEF_Jal
STATE MISSING ACK
TYPE CUL_HM
XX_HMUART_MSGCNT 16
XX_HMUART_RAWMSG 05030020F7A4105C83512576CB0601C8003C
XX_HMUART_RSSI -32
XX_HMUART_TIME 2021-09-08 18:18:30
XX_LANInterface_MSGCNT 4
XX_LANInterface_RAWMSG E5C8351,0000,00042129,FF,FFC1,F7A4105C83512576CB0601C8003C
XX_LANInterface_RSSI -63
XX_LANInterface_TIME 2021-09-08 18:18:29
chanNo 01
disableNotifyFn 1
peerList RC_HM12_1_Btn_7,RC_HM12_1_Btn_8
protCmdDel 1
protResnd 3 last_at:2021-09-08 18:18:29
protResndFail 1 last_at:2021-09-08 18:18:35
protSnd 1 last_at:2021-09-08 18:18:14
protState CMDs_done_Errors:1
rssi_at_XX_HMUART cnt:8 min:-35 max:-32 avg:-32.75 lst:-32
rssi_at_XX_LANInterface cnt:4 min:-67 max:-63 avg:-64.5 lst:-63
READINGS:
2021-09-08 16:22:54 CommandAccepted yes
2020-11-11 17:17:23 D-firmware 2.11
2020-11-11 17:17:23 D-serialNr OEQ0984406
2021-09-08 18:18:14 IODev XX_HMUART
2021-06-28 15:35:16 PairedTo 0x2576CB
2020-11-11 18:09:14 R-RC_HM12_1_Btn_7-lgActionType jmpToTarget
2020-11-11 18:09:14 R-RC_HM12_1_Btn_7-lgOnLevel 100 %
2020-11-11 18:09:14 R-RC_HM12_1_Btn_7-shActionType jmpToTarget
2020-11-11 18:09:14 R-RC_HM12_1_Btn_7-shOnLevel 100 %
2020-11-11 18:09:24 R-RC_HM12_1_Btn_8-lgActionType jmpToTarget
2020-11-11 18:09:24 R-RC_HM12_1_Btn_8-lgOnLevel 100 %
2020-11-11 18:09:24 R-RC_HM12_1_Btn_8-shActionType jmpToTarget
2020-11-11 18:09:24 R-RC_HM12_1_Btn_8-shOnLevel 100 %
2020-11-11 18:08:48 R-driveDown 18 s
2020-11-11 18:08:48 R-driveTurn 0.5 s
2020-11-11 18:08:48 R-driveUp 18 s
2020-11-11 18:08:27 R-pairCentral 0x2576CB
2020-11-11 18:08:48 R-sign on
2021-06-28 15:35:16 RegL_00. 00:00 02:01 0A:25 0B:76 0C:CB 15:FF 18:00
2021-06-28 15:35:17 RegL_01. 00:00 08:01 09:00 0A:00 0B:00 0C:B4 0D:00 0E:B4 0F:05 10:00 30:06 56:00 57:24
2021-06-28 15:35:22 RegL_03.RC_HM12_1_Btn_7 00:00 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:44 0C:54 0D:93 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:93 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:44 8C:54 8D:93 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:05 9E:93 9F:00
2021-06-28 15:35:19 RegL_03.RC_HM12_1_Btn_8 00:00 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:11 0C:12 0D:68 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:68 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:11 8C:12 8D:68 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:05 9E:68 9F:00
2021-09-08 18:18:30 aesCommToDev fail
2021-09-08 16:22:54 aesKeyNbr 02
2021-07-06 22:32:50 aesReqTo XX_VCCU
2021-09-06 08:52:39 cfgState ok
2021-09-08 18:18:35 commState CMDs_done_Errors:1
2021-09-08 16:22:54 deviceMsg on (to XX_VCCU)
2021-09-08 16:22:54 level 100
2021-09-08 16:22:54 motor stop:on
2021-09-08 16:22:54 pct 100
2021-09-08 18:18:06 peerList RC_HM12_1_Btn_7,RC_HM12_1_Btn_8
2021-06-28 15:34:35 powerOn 2021-06-28 15:34:35
2021-09-08 16:22:54 recentStateType ack
2021-09-08 18:18:35 state MISSING ACK
2021-09-08 16:22:54 timedOn off
2021-09-08 16:22:53 trigLast fhem:02
2021-09-05 19:21:56 trig_RC_HM12_1_Btn_7 Short_47
2021-09-08 15:46:41 trig_RC_HM12_1_Btn_8 Short_46
helper:
HM_CMDNR 247
cSnd ,012576CB5C8351010E
mId 0005
peerFriend peerSens,peerVirt
peerIDsState complete
peerOpt 3:blindActuator
regLst 0,1,3p
rxType 1
cmds:
TmplKey RC_HM12_1_Btn_7,RC_HM12_1_Btn_8:no:1631117886.19279
TmplTs 1631117886.19279
cmdKey 1:1:0::JA_GEF_Jal:0005:01:RC_HM12_1_Btn_7,RC_HM12_1_Btn_8
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
down 'change:'[(0..100;1|{10})] [(-ontime-|{})] [(-ramptime-|{})]
eventL -peer- -cond-
eventS -peer- -cond-
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
pair noArg
pct -value- [-ontime-]
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})]
pressL [(-peer-|{self01})]
pressS [(-peer-|{self01})]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
statusRequest noArg
stop noArg
toggle noArg
toggleDir noArg
tplDel -tplDel-
tplSet_0 -tplChan-
tplSet_RC_HM12_1_Btn_7 -tplPeer-
tplSet_RC_HM12_1_Btn_8 -tplPeer-
unpair noArg
up 'change:'[(0..100;1|{10})] [(-ontime-|{})] [(-ramptime-|{})]
lst:
condition slider,0,1,255
peer RC_HM12_1_Btn_7,RC_HM12_1_Btn_8
peerOpt EZ_TuerKontakt,JZ_AutoWaechter_Sw_01,JZ_AutoWaechter_Sw_02,JZ_AutoWaechter_Sw_03,RC_HM12_1_Btn_1,RC_HM12_1_Btn_10,RC_HM12_1_Btn_11,RC_HM12_1_Btn_12,RC_HM12_1_Btn_2,RC_HM12_1_Btn_3,RC_HM12_1_Btn_4,RC_HM12_1_Btn_5,RC_HM12_1_Btn_6,RC_HM12_1_Btn_7,RC_HM12_1_Btn_8,RC_HM12_1_Btn_9,RC_HM12_2_Btn_01,RC_HM12_2_Btn_02,RC_HM12_2_Btn_03,RC_HM12_2_Btn_04,RC_HM12_2_Btn_05,RC_HM12_2_Btn_06,RC_HM12_2_Btn_07,RC_HM12_2_Btn_08,RC_HM12_2_Btn_09,RC_HM12_2_Btn_10,RC_HM12_2_Btn_11,RC_HM12_2_Btn_12,RM_TeamRauchmelder,WZ_TuerKontakt,XX_VCCU_Btn1,XX_VCCU_Btn10,XX_VCCU_Btn11,XX_VCCU_Btn12,XX_VCCU_Btn13,XX_VCCU_Btn14,XX_VCCU_Btn15,XX_VCCU_Btn16,XX_VCCU_Btn17,XX_VCCU_Btn18,XX_VCCU_Btn19,XX_VCCU_Btn2,XX_VCCU_Btn20,XX_VCCU_Btn21,XX_VCCU_Btn22,XX_VCCU_Btn3,XX_VCCU_Btn4,XX_VCCU_Btn5,XX_VCCU_Btn6,XX_VCCU_Btn7,XX_VCCU_Btn8,XX_VCCU_Btn9
tplChan
tplDel
tplPeer BlStopDnLg_long,BlStopDnLg_short,BlStopDnSh_long,BlStopDnSh_short,BlStopUpLg_long,BlStopUpLg_short,BlStopUpSh_long,BlStopUpSh_short,SwCondAbove_long,SwCondAbove_short,SwCondBelow_long,SwCondBelow_short,SwOnCond_long,SwOnCond_short
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 1
det 0
raw 1
tpl 0
io:
flgs 1
newChn +5C8351,01,00,02
nextSend 1631117910.4123
rxt 0
vccu XX_VCCU
p:
5C8351
01
00
02
prefIO:
XX_HMUART
XX_LANInterface
mRssi:
mNo F7
io:
XX_HMUART:
-24
-24
XX_LANInterface:
-63
-63
peerIDsH:
00000000 broadcast
223C9F07 RC_HM12_1_Btn_7
223C9F08 RC_HM12_1_Btn_8
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
rssi:
at_XX_HMUART:
avg -32.75
cnt 8
lst -32
max -32
min -35
at_XX_LANInterface:
avg -64.5
cnt 4
lst -63
max -63
min -67
tmpl:
Attributes:
IOgrp XX_VCCU:XX_HMUART,XX_LANInterface
aesCommReq 1
alias Fenster
autoReadReg 4_reqStatus
devStateIcon auf:fts_shutter_10@green ab:fts_shutter_100@black 9\d.*:fts_shutter_10@grey 8\d.*:fts_shutter_20@grey 7\d.*:fts_shutter_30@grey 6\d.*:fts_shutter_40@grey 5\d.*:fts_shutter_50@grey 4\d.*:fts_shutter_60@grey 3\d.*:fts_shutter_70@grey 2\d.*:fts_shutter_80@grey 1\d.*:fts_shutter_90@grey 0\d.*:fts_shutter_100@grey
eventMap off:ab on:auf
expert defReg,rawReg
firmware 2.11
group Jalousie Einzeln
icon fts_window_1w
model HM-LC-BL1PBU-FM
peerIDs 00000000,223C9F07,223C9F08
room Jalousien
serialNr OEQ0984406
subType blindActuator
userattr Alledirekt Alledirekt_map Vornedirekt Vornedirekt_map structexclude
webCmd auf:ab:stop
List nach
aesCommReq = 0
Manuelles Schalten am Aktor: korrektes Verhalten
aesCommReq = 1
Manuelles Schalten: korrektes Verhalten auch mit AES
Internals:
CFGFN ./FHEM/myJalGEF.cfg
DEF 5C8351
FUUID 6127a5df-f33f-9dc6-9929-347556cb06a2dd48
IODev XX_HMUART
LASTInputDev XX_HMUART
MSGCNT 30
NAME JA_GEF_Jal
NR 1172
NTFY_ORDER 50-JA_GEF_Jal
STATE auf
TYPE CUL_HM
XX_HMUART_MSGCNT 23
XX_HMUART_RAWMSG 05020126FEA4105C83512576CB0601C800
XX_HMUART_RSSI -38
XX_HMUART_TIME 2021-09-08 18:26:37
XX_LANInterface_MSGCNT 7
XX_LANInterface_RAWMSG E5C8351,0000,00053087,FF,FFBD,FEA4105C83512576CB0601C800
XX_LANInterface_RSSI -67
XX_LANInterface_TIME 2021-09-08 18:26:37
chanNo 01
disableNotifyFn 1
lastMsg No:FE - t:10 s:5C8351 d:2576CB 0601C800
peerList RC_HM12_1_Btn_7,RC_HM12_1_Btn_8
protCmdDel 1
protEvt_AESCom-ok 2 last_at:2021-09-08 18:26:37
protLastRcv 2021-09-08 18:26:37
protRcv 3 last_at:2021-09-08 18:26:37
protResnd 3 last_at:2021-09-08 18:18:29
protResndFail 1 last_at:2021-09-08 18:18:35
protSnd 4 last_at:2021-09-08 18:26:37
protState CMDs_done
rssi_at_XX_HMUART cnt:13 min:-44 max:-32 avg:-35.46 lst:-38
rssi_at_XX_LANInterface cnt:7 min:-72 max:-63 avg:-66.28 lst:-67
READINGS:
2021-09-08 16:22:54 CommandAccepted yes
2020-11-11 17:17:23 D-firmware 2.11
2020-11-11 17:17:23 D-serialNr OEQ0984406
2021-09-08 18:26:37 IODev XX_HMUART
2021-06-28 15:35:16 PairedTo 0x2576CB
2020-11-11 18:09:14 R-RC_HM12_1_Btn_7-lgActionType jmpToTarget
2020-11-11 18:09:14 R-RC_HM12_1_Btn_7-lgOnLevel 100 %
2020-11-11 18:09:14 R-RC_HM12_1_Btn_7-shActionType jmpToTarget
2020-11-11 18:09:14 R-RC_HM12_1_Btn_7-shOnLevel 100 %
2020-11-11 18:09:24 R-RC_HM12_1_Btn_8-lgActionType jmpToTarget
2020-11-11 18:09:24 R-RC_HM12_1_Btn_8-lgOnLevel 100 %
2020-11-11 18:09:24 R-RC_HM12_1_Btn_8-shActionType jmpToTarget
2020-11-11 18:09:24 R-RC_HM12_1_Btn_8-shOnLevel 100 %
2020-11-11 18:08:48 R-driveDown 18 s
2020-11-11 18:08:48 R-driveTurn 0.5 s
2020-11-11 18:08:48 R-driveUp 18 s
2020-11-11 18:08:27 R-pairCentral 0x2576CB
2020-11-11 18:08:48 R-sign on
2021-06-28 15:35:16 RegL_00. 00:00 02:01 0A:25 0B:76 0C:CB 15:FF 18:00
2021-06-28 15:35:17 RegL_01. 00:00 08:01 09:00 0A:00 0B:00 0C:B4 0D:00 0E:B4 0F:05 10:00 30:06 56:00 57:24
2021-06-28 15:35:22 RegL_03.RC_HM12_1_Btn_7 00:00 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:44 0C:54 0D:93 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:93 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:44 8C:54 8D:93 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:05 9E:93 9F:00
2021-06-28 15:35:19 RegL_03.RC_HM12_1_Btn_8 00:00 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:11 0C:12 0D:68 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:68 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:11 8C:12 8D:68 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:05 9E:68 9F:00
2021-09-08 18:26:37 aesCommToDev ok
2021-09-08 16:22:54 aesKeyNbr 02
2021-07-06 22:32:50 aesReqTo XX_VCCU
2021-09-06 08:52:39 cfgState ok
2021-09-08 18:26:37 commState CMDs_done
2021-09-08 18:26:37 deviceMsg on (to XX_VCCU)
2021-09-08 18:26:37 level 100
2021-09-08 18:26:37 motor stop:on
2021-09-08 18:26:37 pct 100
2021-09-08 18:18:06 peerList RC_HM12_1_Btn_7,RC_HM12_1_Btn_8
2021-06-28 15:34:35 powerOn 2021-06-28 15:34:35
2021-09-08 18:26:37 recentStateType info
2021-09-08 18:26:37 state on
2021-09-08 18:26:37 timedOn off
2021-09-08 16:22:53 trigLast fhem:02
2021-09-05 19:21:56 trig_RC_HM12_1_Btn_7 Short_47
2021-09-08 15:46:41 trig_RC_HM12_1_Btn_8 Short_46
helper:
HM_CMDNR 254
cSnd ,012576CB5C8351010E
lastMsgTm 1631118397.40736
mId 0005
peerFriend peerSens,peerVirt
peerIDsState complete
peerOpt 3:blindActuator
regLst 0,1,3p
rxType 1
supp_Pair_Rep 0
ack:
cmds:
TmplKey RC_HM12_1_Btn_7,RC_HM12_1_Btn_8:no:1631117886.19279
TmplTs 1631117886.19279
cmdKey 1:1:0::JA_GEF_Jal:0005:01:RC_HM12_1_Btn_7,RC_HM12_1_Btn_8
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
down 'change:'[(0..100;1|{10})] [(-ontime-|{})] [(-ramptime-|{})]
eventL -peer- -cond-
eventS -peer- -cond-
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
pair noArg
pct -value- [-ontime-]
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})]
pressL [(-peer-|{self01})]
pressS [(-peer-|{self01})]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
statusRequest noArg
stop noArg
toggle noArg
toggleDir noArg
tplDel -tplDel-
tplSet_0 -tplChan-
tplSet_RC_HM12_1_Btn_7 -tplPeer-
tplSet_RC_HM12_1_Btn_8 -tplPeer-
unpair noArg
up 'change:'[(0..100;1|{10})] [(-ontime-|{})] [(-ramptime-|{})]
lst:
condition slider,0,1,255
peer RC_HM12_1_Btn_7,RC_HM12_1_Btn_8
peerOpt EZ_TuerKontakt,JZ_AutoWaechter_Sw_01,JZ_AutoWaechter_Sw_02,JZ_AutoWaechter_Sw_03,RC_HM12_1_Btn_1,RC_HM12_1_Btn_10,RC_HM12_1_Btn_11,RC_HM12_1_Btn_12,RC_HM12_1_Btn_2,RC_HM12_1_Btn_3,RC_HM12_1_Btn_4,RC_HM12_1_Btn_5,RC_HM12_1_Btn_6,RC_HM12_1_Btn_7,RC_HM12_1_Btn_8,RC_HM12_1_Btn_9,RC_HM12_2_Btn_01,RC_HM12_2_Btn_02,RC_HM12_2_Btn_03,RC_HM12_2_Btn_04,RC_HM12_2_Btn_05,RC_HM12_2_Btn_06,RC_HM12_2_Btn_07,RC_HM12_2_Btn_08,RC_HM12_2_Btn_09,RC_HM12_2_Btn_10,RC_HM12_2_Btn_11,RC_HM12_2_Btn_12,RM_TeamRauchmelder,WZ_TuerKontakt,XX_VCCU_Btn1,XX_VCCU_Btn10,XX_VCCU_Btn11,XX_VCCU_Btn12,XX_VCCU_Btn13,XX_VCCU_Btn14,XX_VCCU_Btn15,XX_VCCU_Btn16,XX_VCCU_Btn17,XX_VCCU_Btn18,XX_VCCU_Btn19,XX_VCCU_Btn2,XX_VCCU_Btn20,XX_VCCU_Btn21,XX_VCCU_Btn22,XX_VCCU_Btn3,XX_VCCU_Btn4,XX_VCCU_Btn5,XX_VCCU_Btn6,XX_VCCU_Btn7,XX_VCCU_Btn8,XX_VCCU_Btn9
tplChan
tplDel
tplPeer BlStopDnLg_long,BlStopDnLg_short,BlStopDnSh_long,BlStopDnSh_short,BlStopUpLg_long,BlStopUpLg_short,BlStopUpSh_long,BlStopUpSh_short,SwCondAbove_long,SwCondAbove_short,SwCondBelow_long,SwCondBelow_short,SwOnCond_long,SwOnCond_short
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
dir:
cur stop
expert:
def 1
det 0
raw 1
tpl 0
io:
flgs 1
newChn +5C8351,01,01,02
nextSend 1631118397.63649
rxt 0
vccu XX_VCCU
p:
5C8351
01
01
02
prefIO:
XX_HMUART
XX_LANInterface
mRssi:
mNo FE
io:
XX_HMUART:
-30
-30
XX_LANInterface:
-67
-67
peerIDsH:
00000000 broadcast
223C9F07 RC_HM12_1_Btn_7
223C9F08 RC_HM12_1_Btn_8
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
rpt:
IO XX_HMUART
flg A
ts 1631118397.40736
ack:
HASH(0x58ae600)
FE80022576CB5C835100
rssi:
at_XX_HMUART:
avg -35.4615384615385
cnt 13
lst -38
max -32
min -44
at_XX_LANInterface:
avg -66.2857142857143
cnt 7
lst -67
max -63
min -72
tmpl:
role:
Attributes:
IOgrp XX_VCCU:XX_HMUART,XX_LANInterface
aesCommReq 1
alias Fenster
autoReadReg 4_reqStatus
devStateIcon auf:fts_shutter_10@green ab:fts_shutter_100@black 9\d.*:fts_shutter_10@grey 8\d.*:fts_shutter_20@grey 7\d.*:fts_shutter_30@grey 6\d.*:fts_shutter_40@grey 5\d.*:fts_shutter_50@grey 4\d.*:fts_shutter_60@grey 3\d.*:fts_shutter_70@grey 2\d.*:fts_shutter_80@grey 1\d.*:fts_shutter_90@grey 0\d.*:fts_shutter_100@grey
eventMap off:ab on:auf
expert defReg,rawReg
firmware 2.11
group Jalousie Einzeln
icon fts_window_1w
model HM-LC-BL1PBU-FM
peerIDs 00000000,223C9F07,223C9F08
room Jalousien
serialNr OEQ0984406
subType blindActuator
userattr Alledirekt Alledirekt_map Vornedirekt Vornedirekt_map structexclude
webCmd auf:ab:stop
-
für mich sieht es so aus, dass das device beim hmuart mit falschem aes key assigned wurde.
der 3. eintrag in helper/io/newChn "+5C8351,01,00,02" (oder entsprechend helper/io/p[2]) zeigt nach restart key=00 und nach erneutem setzen des attr aesCommReq key=01 (+5C8351,01,01,02).
über CUL_HM_hmInitMsg()/CUL_HM_hmInitMsgUpdt() wird newChn/p zusammengebaut und der key ermittelt:
my ($highestKey, undef) = CUL_HM_getKeys($hash);
my $key = sprintf("%02X",AttrVal($name,"aesKey",$highestKey));
@p = ("$id","00",$key,$mask) if (!$hash->{helper}{role}{vrt});
da ich keine unterschiedliche behandlung für hmlan/hmuart gefunden habe, spekuliere ich auf ein "reihenfolgeproblem" in fhem.cfg.
@tango
1. wo ist der aes key hinterlegt? vccu oder in den io?
2. hat dein key die nummer 1?
die reihenfolge der devices in fhem.cfg sollte idealerweise wie folgt sein:
1. alle io
2. vccu
3. alle hm devices
wie sieht das bei dir aus?
eventuell ist das problem behoben, wenn du die reihenfolge entsprechend änderst.
-
An ein Reihenfolgeproblem glaube ich nicht so richtig.
Falls das Umsortieren nicht hilft würde mal testweise alle HMLAN-TYPE IO's löschen.
Zum Hintergrund: bei meinem Test gestern waren _alle_ IO's nach der VCCU in der cfg gelistet. Hab's jetzt trotzdem mal nach vorne sortiert, und sobald ein HMLAN im Spiel ist, ist io->iolist leer.... Löscht man den HMLAN aus IOList, sind CUL und HMUARTLGW wieder drin.
-
Zum Hintergrund: bei meinem Test gestern waren _alle_ IO's nach der VCCU in der cfg gelistet. Hab's jetzt trotzdem mal nach vorne sortiert, und sobald ein HMLAN im Spiel ist, ist io->iolist leer.... Löscht man den HMLAN aus IOList, sind CUL und HMUARTLGW wieder drin.
hier geht es ja um den aes key.
wenn keiner gefunden wird, ist es der default key mit der nummer 00.
wenn der key in der vccu ist, sind die io sowieso erstmal uninteressant.
das andere problem mit "Clients" ist nagelneu.
aber das aes problem gab es ja wahrscheinlich schon im letzten jahrhundert. 8)
und nach erneutem setzen von attr aesCommReq hat sich beim hmlan ja nichts geändert. dennoch funktioniert es ja dann bis zum nächsten restart.
-
Na ja, selbe Symptome heißen ja nicht zwangsläufig, dass auch dieselbe Ursache vorliegt.
Irgendwo war zu lesen, dass das AES-Problem nur beim Senden besteht, nicht beim Empfang. Das wäre zumindest ein Indiz in die Richtung, dass es (auch?) was damit zu tun hat, dass gar kein IO zum Versenden gefunden wird.
Gebe aber zu, dass ich nicht ausreichend tief in der Materie drin bin, du wirst das schon besser beurteilen können...
-
Guten Morgen,
der hmkey liegt an der VCCU mit nr 1.
Reihenfolge ist bereits "ideal"
-
Noch als Ergänzung:
Der AES Fehler passiert bei mir nur von Jalousie switch -> HMUART z.B. beim manuellen Betätigen.
FHEM erhält dann keine Info über den neuen Status der Jalousie.
Der Weg HMUART -> Switch beim programmierten Auslösen geht einwandfrei.
Dann müsste der hmkey im HMUART eigentlich korrekt sein, oder?
-
Hi frank,
eventuell verbessert diese gepatchte 00_HMURTLGW.pm das instabile verhalten?
https://forum.fhem.de/index.php/topic,122160.msg1168679.html#msg1168679 (https://forum.fhem.de/index.php/topic,122160.msg1168679.html#msg1168679)
leider keine Verbesserung.
Vielleicht als Hinweis: Ich habe in meiner IOList auch einen HMLAN drinnen, der aber nicht online ist.
IOList = HMLGW1,HMLGW2,HMLAN1
Wobei der HMLAN1 und HMLGW2 nicht eingeschaltet sind.
Wenn ich den HMLAN1 aus der IOList entferne habe ich als state
HMLAN1:UAS,HMLGW1:ok,HMLGW2:disconnectedWas ist dieses UAS?
Grüße
Hugo
-
UAS => unassigned
vccu hat ihn entdeckt, aber nutzt ihn nicht.
-
Hallo *,
ich habe mit meiner "alten" funktionsfähigen FHEM Version ohne das update von CUL_HM noch experimentiert.
Versuchsweise habe ich mal statt restart einen rereadcfg durchgeführt.
Dann ergeben sich bereits danach die gleichen fehlerhaften AES Effekte wie mit der neuen CUL_HM!!!
Ein restart behebt den Fehler wieder.
Ich bilde mir ein, dass ich dass schon beim Inbetriebnehmen meines HMUARTs Mitte letzten Jahres beobachtet habe und rereadcg seit dem vermieden habe.
Vielleicht hilft es ja weiter.
-
Ist das Problem im laufenden System weg, wenn du IOList in der VCCU änderst? Kann ein Leerzeichen am Ende sein.
-
In meinem noch funktionsfähigen System ist IOList bisher Leerzeichen frei.
Wenn ich welche mittels attr ..... anhänge sind sie auch anschließend nicht vorhanden.
In der WEBUI zeigt "Save config" kein ?.
Dann hat sich wohl nichts getan.
Ein rereadcfg zeigt anschließend wieder aesCommToDev=fail bei den Jalousieschaltern am HMUART.
Am HMLAN scheint alles OK.
restart hats wieder gerichtet.
Scheint der gleiche Effekt zu sein wie nach CUL_HM update.
-
wie gesagt, meine ich, dass die nun fehlenden attribute IODev das verhalten hervorbringt.
-
Da hab ich meine Zweifel.
Den Effekt über rereadcfg hatte ich nach meiner Erinnerung schon vor einem Jahr.
Da waren an den Jal.Schaltern noch überall IODevs angebracht.
Die habe ich jetzt erst entfernt.
-
...so war das mit dem Leerzeichen nicht gemein...
Mein Verdacht: die interne Datenstruktur mit den vorhandenen IO's wird nicht in allen Fällen richtig initialisiert. Die aktuellen svn-Version (einschl. der von heute morgen) habe das z.B. beim Startup, dass helper-io-ioList NICHT gefüllt ist.
Wenn alles richtig läuft, sollte das m.E. in etwa so aussehen:
Internals:
[...]
TYPE CUL_HM
assignedIOs CUL_0,HmUART_Maple,mapleCUN1,myHmUART
[...]
READINGS:
2021-01-15 08:09:06 .associatedWith VCCU,VCCU_Btn1,VCCU_Btn2,VCCU_Btn3,VCCU_Btn4,VCCU_Btn5,VCCU_Btn6,VCCU
2021-09-12 18:15:06 .protLastRcv 20210912181506
[...]
helper:
[...]
io:
nextSend 1631463306.35471
vccu VCCU
ioList:
CUL_0
HmUART_Maple
mapleCUN1
myHmUART
prefIO:
mRssi:
io:
Vergrößert:
vccu VCCU
ioList:
CUL_0
Ändert man was Relevantes, wird dieses Array gefüllt.
"Was Relevantes" kann z.B. vielleicht der aes-Key sein, oder eben schlicht die IOList. Mein Vorschlag war, einfach das "anzufassen", indem du ein Leerzeichen anfügst (das wird ignoriert, dazwischen ist Käse). Was auch geht, ist z.B. ein IO da zu löschen und hinterher wieder zu ergänzen. Ganz egal, einfach irgendwie (akzeptabel) ändern.
Dann schauen, ob die IO's aaO gelistet sind und die Kommunikation anschließend wieder klappt.
(Falls das der Fall ist, bitte meine Version aus dem Nebenthread testen, da ist (u.A.) dann die Initialisierung der VCCU's beim Starten (und rereadcfg) geändert. "rereadcfg gehört verboten", hat einer, der es besser weiß wie ich schon vor längerem geäußert. Also einfach vergessen, dass es das je gab und shutdown+restart verwenden...)
-
Rereadcfg benutze ich schon lange nicht mehr. Seit halt der Fehler auftrat. Stattdessen eben restart.
Wird sich schon jemand was bei gedacht haben.
rereadcfg war jetzt nur ein Experiment.
list VCCU wenns funktioniert.
Internals:
CFGFN ./FHEM/MyLanInterface.cfg
DEF 2576CB
FUUID 5c44eb3c-f33f-9dc6-955e-3b26dd5c810a4994
IODev XX_LANInterface
LASTInputDev XX_HMUART
MSGCNT 58
NAME XX_VCCU
NOTIFYDEV global
NR 445
NTFY_ORDER 50-XX_VCCU
STATE XX_LANInterface:ok,XX_HMUART:ok
TYPE CUL_HM
XX_HMUART_MSGCNT 15
XX_HMUART_RAWMSG 050001369981122576CB000000
XX_HMUART_RSSI -54
XX_HMUART_TIME 2021-09-12 18:41:39
XX_LANInterface_MSGCNT 43
XX_LANInterface_RAWMSG E2576CB,0000,000FF7E2,FF,FFC6,C780022576CB6041B30101C800
XX_LANInterface_RSSI -58
XX_LANInterface_TIME 2021-09-12 18:35:22
assignedIOs XX_HMUART,XX_LANInterface
...
lastMsg No:99 - t:12 s:2576CB d:000000
protLastRcv 2021-09-12 18:41:39
protRcv 58 last_at:2021-09-12 18:41:39
protRcvB 1 last_at:2021-09-12 18:14:58
rssi_at_XX_HMUART cnt:15 min:-54 max:-52 avg:-53.06 lst:-54
rssi_at_XX_LANInterface cnt:43 min:-58 max:-56 avg:-57.11 lst:-58
READINGS:
2021-09-12 18:35:21 CommandAccepted yes
2021-09-12 18:09:43 IODev XX_LANInterface
2021-09-12 18:41:39 IOopen 2
2021-09-12 18:35:21 aesKeyNbr 02
2021-09-12 13:31:01 aesReqTo JA_WZT_Jal
2021-09-11 23:07:23 cfgState ok
2020-07-17 11:27:30 commState CMDs_done
2021-09-12 18:41:39 state XX_LANInterface:ok,XX_HMUART:ok
2021-09-10 08:21:18 unknown_2437B9 received
helper:
HM_CMDNR 153
mId FFF0
peerFriend -
peerOpt -:virtual
regLst
rxType 1
supp_Pair_Rep 0
ack:
cmds:
TmplKey :no:1631462984.8173
TmplTs 1631462984.8173
cmdKey 0:1:1::XX_VCCU:FFF0:00:
cmdLst:
assignIO -IO- [({set}|unset)]
clear [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
defIgnUnknown noArg
hmPairForSec [-sec-]
hmPairSerial -serial-
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 1631464899.53466
prefIO
vccu XX_VCCU
ioList:
XX_LANInterface
XX_HMUART
mRssi:
mNo 99
io:
XX_HMUART:
-54
-54
XX_LANInterface:
-52
peerIDsH:
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
at_XX_HMUART:
avg -53.0666666666667
cnt 15
lst -54
max -52
min -54
at_XX_LANInterface:
avg -57.1162790697674
cnt 43
lst -58
max -56
min -58
tmpl:
Attributes:
IODev XX_LANInterface
IOList XX_LANInterface,XX_HMUART
IOgrp XX_VCCU
alias VCCU
group Homematic
..
model CCU-FHEM
room Server
subType virtual
webCmd virtual:update
Nach rereadcfg wenn AES nicht funktioniert, mir fällt
aesKeyNbr 00
auf
Internals:
CFGFN ./FHEM/MyLanInterface.cfg
DEF 2576CB
FUUID 5c44eb3c-f33f-9dc6-955e-3b26dd5c810a4994
IODev XX_LANInterface
LASTInputDev XX_LANInterface
MSGCNT 47
NAME XX_VCCU
NOTIFYDEV global
NR 445
STATE XX_LANInterface:ok,XX_HMUART:ok
TYPE CUL_HM
XX_HMUART_MSGCNT 10
XX_HMUART_RAWMSG 050000361180022576CB6119DA0091EA1CC2
XX_HMUART_RSSI -54
XX_HMUART_TIME 2021-09-12 18:48:19
XX_LANInterface_MSGCNT 37
XX_LANInterface_RAWMSG E2576CB,0000,00099547,FF,FFC7,70A0022576CB5C83510457320000320C00
XX_LANInterface_RSSI -57
XX_LANInterface_TIME 2021-09-12 18:51:08
assignedIOs XX_HMUART,XX_LANInterface
...
lastMsg No:70 - t:02 s:2576CB d:5C8351 0457320000320C00
protLastRcv 2021-09-12 18:51:08
protRcv 47 last_at:2021-09-12 18:51:08
rssi_at_XX_HMUART cnt:10 min:-54 max:-54 avg:-54 lst:-54
rssi_at_XX_LANInterface cnt:37 min:-58 max:-57 avg:-57.43 lst:-57
READINGS:
2021-09-12 18:48:18 CommandAccepted yes
2021-09-12 18:47:43 IODev XX_LANInterface
2021-09-12 18:48:04 IOopen 2
2021-09-12 18:51:08 aesKeyNbr 00
2021-09-12 13:31:01 aesReqTo JA_WZT_Jal
2021-09-11 23:07:23 cfgState ok
2020-07-17 11:27:30 commState CMDs_done
2021-09-12 18:48:04 state XX_LANInterface:ok,XX_HMUART:ok
2021-09-10 08:21:18 unknown_2437B9 received
helper:
HM_CMDNR 112
mId FFF0
peerFriend -
peerOpt -:virtual
regLst
rxType 1
supp_Pair_Rep 0
ack:
cmds:
TmplKey :no:1631465275.25671
TmplTs 1631465275.25671
cmdKey 0:1:1::XX_VCCU:FFF0:01:
cmdLst:
assignIO -IO- [({set}|unset)]
clear [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
defIgnUnknown noArg
hmPairForSec [-sec-]
hmPairSerial -serial-
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 1631465468.26954
prefIO
vccu XX_VCCU
ioList:
XX_LANInterface
XX_HMUART
mRssi:
mNo 70
io:
XX_HMUART:
XX_LANInterface:
-51
-51
peerIDsH:
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
at_XX_HMUART:
avg -54
cnt 10
lst -54
max -54
min -54
at_XX_LANInterface:
avg -57.4324324324324
cnt 37
lst -57
max -57
min -58
tmpl:
Attributes:
IODev XX_LANInterface
IOList XX_LANInterface,XX_HMUART
IOgrp XX_VCCU
alias VCCU
group Homematic
..
model CCU-FHEM
room Server
subType virtual
webCmd virtual:update
Jetzt die beiden IOs in der IOList vertauscht, in meiner Version geht das ja noch.
Fehler weiterhin vorhanden.
Internals:
CFGFN ./FHEM/MyLanInterface.cfg
DEF 2576CB
FUUID 5c44eb3c-f33f-9dc6-955e-3b26dd5c810a4994
IODev XX_LANInterface
LASTInputDev XX_LANInterface
MSGCNT 48
NAME XX_VCCU
NOTIFYDEV global
NR 445
STATE XX_HMUART:ok,XX_LANInterface:ok
TYPE CUL_HM
XX_HMUART_MSGCNT 10
XX_HMUART_RAWMSG 050000361180022576CB6119DA0091EA1CC2
XX_HMUART_RSSI -54
XX_HMUART_TIME 2021-09-12 18:48:19
XX_LANInterface_MSGCNT 38
XX_LANInterface_RAWMSG E2576CB,0000,000B5606,FF,FFC6,82943F2576CB000000020428D0ECEE
XX_LANInterface_RSSI -58
XX_LANInterface_TIME 2021-09-12 18:53:03
assignedIOs XX_HMUART,XX_LANInterface
....
lastMsg No:82 - t:3F s:2576CB d:000000 020428D0ECEE
protLastRcv 2021-09-12 18:53:03
protRcv 48 last_at:2021-09-12 18:53:03
protRcvB 1 last_at:2021-09-12 18:53:03
rssi_at_XX_HMUART cnt:10 min:-54 max:-54 avg:-54 lst:-54
rssi_at_XX_LANInterface cnt:38 min:-58 max:-57 avg:-57.44 lst:-58
READINGS:
2021-09-12 18:48:18 CommandAccepted yes
2021-09-12 18:47:43 IODev XX_LANInterface
2021-09-12 18:56:04 IOopen 2
2021-09-12 18:51:08 aesKeyNbr 00
2021-09-12 13:31:01 aesReqTo JA_WZT_Jal
2021-09-11 23:07:23 cfgState ok
2020-07-17 11:27:30 commState CMDs_done
2021-09-12 18:56:04 state XX_HMUART:ok,XX_LANInterface:ok
2021-09-10 08:21:18 unknown_2437B9 received
helper:
HM_CMDNR 130
mId FFF0
peerFriend -
peerOpt -:virtual
regLst
rxType 1
supp_Pair_Rep 0
ack:
cmds:
TmplKey :no:1631465275.25671
TmplTs 1631465275.25671
cmdKey 0:1:1::XX_VCCU:FFF0:01:
cmdLst:
assignIO -IO- [({set}|unset)]
clear [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
defIgnUnknown noArg
hmPairForSec [-sec-]
hmPairSerial -serial-
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 1631465583.13224
prefIO
vccu XX_VCCU
ioList:
XX_HMUART
XX_LANInterface
mRssi:
mNo 82
io:
XX_HMUART:
XX_LANInterface:
-52
-52
peerIDsH:
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
at_XX_HMUART:
avg -54
cnt 10
lst -54
max -54
min -54
at_XX_LANInterface:
avg -57.4473684210526
cnt 38
lst -58
max -57
min -58
tmpl:
Attributes:
IODev XX_LANInterface
IOList XX_HMUART,XX_LANInterface
IOgrp XX_VCCU
alias VCCU
group Homematic
..
model CCU-FHEM
room Server
subType virtual
webCmd virtual:update
ioList scheint mir jedesmal passend.
-
Hmm, ok, dann scheint es das nicht gewesen zu sein.
Du bist jetzt grade wieder zurück auf
Ich bin bis SVN-Revision 24374 schrittweise zurück gegangen, das ist die letzte funktionierende.
Oder aktueller?
Mit der obigen Version hatte Martin das startup-Verhalten geändert und einige Plausibilitätstest eingeführt, die u.A. dazu geführt hatten, dass das tempListTmpl-Attribut nicht mehr gesetzt werden konnte. Das ist deswegen interessant, weil aus irgendeinem Grund die dazu passende Voraussetzung zum Prüfungszeitpunkt noch nicht gegeben war.
Bzgl. des genannten Attributs ist das mit der 24961 (von heute aus dem svn) nicht mehr so, (der Zusammenhang zwischen der Änderung und dem Effekt ist jedenfalls mir auf die Schnelle nicht einleuchtend gewesen).
Vielleicht könntest du die mal testen und es gibt da einen Zusammenhang/ähnlichen Effekt?
-
Woran erkenne ich das genau?
In meiner funktionierenden 10_CUL_HM.pm steht im header jedenfalls:
# $Id: 10_CUL_HM.pm 24449 2021-05-16 09:03:48Z martinp876 $
Wie kann ich konkret die 24961 runterladen? ich kenne mich da nicht sehr aus.
Oder reicht ein normaler update?
-
Seit kurz vor 8:00 Uhr ist die svn-Version per regulärem update verfügbar, ich hatte gestern nur auf svn verwiesen, weil das da noch nicht geklappt hätte.
In meiner funktionierenden 10_CUL_HM.pm steht im header jedenfalls:
# $Id: 10_CUL_HM.pm 24449 2021-05-16 09:03:48Z martinp876 $
Demnach kam das Problem nicht von 24374 nach 24449, sondern erst in der Folgeversion...? Das erhöht die Chancen, dass es jetzt wieder besser ist, denn meine Anmerkung von gestern abend trifft eigentlich deutlich besser auf den Wechsel in 24834 zu :) .
Bitte melden, falls das nichts hilft, dann könnte es noch an der VCCU-Initialisierung hängen (siehe anderen Thread (https://forum.fhem.de/index.php/topic,122422.msg1174414.html#msg1174414)).
-
Update ausgeführt, neue CUL_HM ist dabei, restart.
AES Fehler weiter vorhanden.
:(
Reicht es wenn ich nur die CUL_HM restore und nicht den gesamten update?
Ich würde gerne mit den restlichen Moduln auf einen aktuellen Stand kommen.
-
Bitte noch den Test mit der Version von nebenan machen, die pegatchte Datei sollte mit
"wget https://raw.githubusercontent.com/rejoe2/FHEM/master/10_CUL_HM.pm -O ./FHEM/10_CUL_HM.pm"(FHEM-kommando, einschl. der Anführungszeichen) zu bekommen sein.
Sonst kannst du das (zusammen mit HMinfo und HMConfig.pm (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/HMConfig.pm)!) auch aus dem Backup isoliert holen, im Moment sehe ich auf die Schnelle nichts, das aus dem sonstigen FHEM-Kontext Probleme machen sollte.
-
Gepatchte CUL_HM geladen. Restart ausgeführt.
Sieht gut aus!!!!
Nach restart scheint der AES Fehler behoben zu sein.
Jedenfalls nach einigen Stichproben.
Ich muss noch in Ruhe alles durchsehen.
Gratulation :)
-
8)
Danke für die Rückmeldung.
Das müßte dann übrigens auch "rereadcfg-fest" sein ::) ...
-
Ich bin nicht scharf auf rereadcfg.
Mir fehlt die Information, was Vor- und Nachteile von rereadcfg und restart sind.
Die Empfehlung, nicht mit fhem.cfg zu arbeiten kenne ich auch (warum nicht!)
Meine ist ziemlich stark mit includes strukturiert, da ich seit langem mit eigenen (Jalousie-) Templates implementiert mit shell-scripten arbeite und diverse includes pro Jalousie generiere.
Funktioniert bestens.
Ich habe mal gelernt: "never change a running program".
Der Rest läuft über die WEBUI. Geht schneller.
Aber aufwendige Analysen sind mit Linux Kommandos grep, etc. besser möglich bzw. fallen mir leichter.
Wie gehts weiter?
Kann ich verhindern, dass der Patch beim nächsten update überschrieben wird?
Bzw. wie sehe ich, dass er offiziell wird?
Jedenfalls noch mal besten Dank für die Hilfe.
-
Restart liest alles von Grund auf, rereadcfg eben nur die Konfigurationsdaten neu ein, was bei einigen neueren Modulen dann auch zu inkonsistenten Daten führen kann.
Zu "never" habe ich mal irgendwo aufgegabelt, dass das eine Ausrede für faule Programmierer sei; maN. sind einigermaßen regelmäßige updates bei Systemen, die via Netzwerk zu erreichen sind, auf praktisch allen Ebenen Pflicht...
Blöd nur, dass das hin und wieder auch zu regressions führt.
Was updates angeht, wird sich Martin vermutlich schon irgendwann melden, wenn bzw. wie er das Problem ggf. dann gefixt hat.
Ansonsten kannst du ja vorab auch hier nochmal nachfragen, wenn du ein entsprechendes update angeboten bekommst und nicht anderswo her weißt, ob es eine gute Idee ist...
-
Mit never meine ich eigentlich meine Script-Sammlung. Die würde ich ungern auf Perl oder FHEM Templates umstellen.
Da bin ich in der Tat zu faul. Da weiß ich was ich hab.
Mit (FHEM-, Raspi-, Windows-, etc) Updates strebe ich zeitnah immer einen aktuellen Stand an.
-
Hi,
aktuell verwende ich die in
https://forum.fhem.de/index.php/topic,123198.0.html
(https://forum.fhem.de/index.php/topic,123198.0.html)
genannten Patches für CUL_HM und HMInfo mit Erfolg.