Nach Update von 10_CUL_HM.pm keine AES-signierte Kommunikation mehr möglich

[cthil]

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

[@tango]

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

[@tango]

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

[stephanr]

Problem kann ich leider bestätigen.

[alru]

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

Code: [Auswählen]

aesCommToDev    failangezeigt.

Alle anderen Readings sehen normal aus.

Edit: Die Befehle werden nicht zuverlässig ausgeführt!

[hugomckinley]

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

[frank]

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

[frank]

@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.

[alru]

@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.

[@tango]

Hallo,

IOgrp ist überall gesetzt.

Vor und nach update ist gemäß HMInfo rssi das HMUARTLGW das optimale.

[frank]

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.

[@tango]

Nach update den patch angebracht und restart durchgeführt.
Keine Verbesserung.
Kein IOgrp beim ActionDetector
Bei VCCU nur IOList

[frank]

actiondetector ist richtig.
aber setze iogrp auch mal in der vccu.

[@tango]

Mittlerweile bei beiden gesetzt. Keine Verbesserung.
Actiondetector nehme ich zurück.

Übrigens Danke für die Hilfe bisher

[frank]

probiere mal den workaround von tndx.
https://forum.fhem.de/index.php/topic,100911.0.html

[@tango]

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

[frank]

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?

[@tango]

Was heisst korrekt? die readings haben den wert, den ich wegen rssis erwarten würde.
Alle aesCommReq=1, die den hmuart nutzen, betroffen.

[@tango]

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

[frank]

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.

[Beta-User]

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).

[@tango]

Das HMUART hat ein Internal
   Clients   :CUL_HM:

Das HMLAN nicht.
Hab ich da Einfluß drauf?

list nach restart:

Code: [Auswählen]

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

Code: [Auswählen]

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


[frank]

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:

Code: [Auswählen]

  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.

[Beta-User]

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.

[frank]

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. 
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.

[Beta-User]

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...

[@tango]

Guten Morgen,

der hmkey liegt an der VCCU mit nr 1.

Reihenfolge ist bereits "ideal"

[@tango]

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?

[hugomckinley]

Hi frank,

eventuell verbessert diese gepatchte 00_HMURTLGW.pm das instabile verhalten?
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

Code: [Auswählen]

HMLAN1:UAS,HMLGW1:ok,HMLGW2:disconnectedWas ist dieses UAS?

Grüße
Hugo

[frank]

UAS => unassigned
vccu hat ihn entdeckt, aber nutzt ihn nicht.

[@tango]

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.

[Beta-User]

Ist das Problem im laufenden System weg, wenn du IOList in der VCCU änderst? Kann ein Leerzeichen am Ende  sein.

[@tango]

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.

[frank]

wie gesagt, meine ich, dass die nun fehlenden attribute IODev das verhalten hervorbringt.

[@tango]

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.

[Beta-User]

...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:

Code: [Auswählen]

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...)

[@tango]

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.

Code: [Auswählen]

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

Code: [Auswählen]

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.

Code: [Auswählen]

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.

[Beta-User]

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?

[@tango]

Woran erkenne ich das genau?

In meiner funktionierenden 10_CUL_HM.pm steht im header jedenfalls:

Code: [Auswählen]

# $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?

[Beta-User]

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:

Code: [Auswählen]

# $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).

[@tango]

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.

[Beta-User]

Bitte noch den Test mit der Version von nebenan machen, die pegatchte Datei sollte mit

Code: [Auswählen]

"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!) auch aus dem Backup isoliert holen, im Moment sehe ich auf die Schnelle nichts, das aus dem sonstigen FHEM-Kontext Probleme machen sollte.

[@tango]

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 

[Beta-User]

 
Danke für die Rückmeldung.

Das müßte dann übrigens auch "rereadcfg-fest" sein ...

[@tango]

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.

[Beta-User]

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...

[@tango]

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.

[@tango]

Hi,

aktuell verwende ich die in


https://forum.fhem.de/index.php/topic,123198.0.html


genannten Patches für CUL_HM und HMInfo mit Erfolg.