[gelöst] Probleme mit Homematic+AES

[Otto123]

gibt es das bei dir nicht?
sind das die optischen kontakte (sco)?

Gibt es nicht, ja es sind die optischen SCO

die stündlichen logmeldungen (ohne trigger_aes) sind dann also die stündlichen keepalive statusmeldungen?

Ja so wird es sein Macht die der Sensor eigenverantwortlich oder werden die von der Zentrale angeschubst?

Das wäre jetzt eine Sub mit der man per Zufall einen IO aus der liste "auswählt" und preferred setzt.

Code Auswählen Erweitern

sub randomIOgrp($)
# setzt einen zufälligen IO in IOgrp als preferred
{
    my ($devspec)= @_;
    my @vccu=devspec2array(".mId=FFF0");
    my @IOList=split /,/,AttrVal($vccu[0],"IOList","");
    my @list = devspec2array($devspec);
    foreach (@list) {
       fhem ("attr $_ IOgrp $vccu[0]:$IOList[int(1+(rand 3))-1]")
    }
}
sunset/sunrise ist ne gute Idee, da würde ich dann {randomIOgrp('subType=blindActuator')} aufrufen.

Ich finde gerade: ich habe schon ne kleine Macke

Gruß Otto

[frank]

ja, die meldungen des sco sind freiwillig und eventuell auch abschaltbar mit cyclicInfoMsg.

[tndx]

Es steht doch nirgendwo, dass man dies tun soll?

Im Wiki steht folgendes dazu:

Mit der Anlage einer VCCU wird ein eventuell angelegtes Attribut IODev eines HM_Devices funktionslos (das Attribut muss aber nicht entfernt werden). Statt dessen setzt die VCCU ein Internal IODev automatisch je nach Verfügbarkeit und Funklage.

"Muss nicht" heißt aber auch nicht "verboten", habe aber auch schon irgendwo andere Diskussionen drüber gelesen, dass die Benutzer das Attribut ohne Auswirkungen entfernt hätten

Wie auch immer, in meinem Fall war nach einem "getConfig" das Internal auch gesetzt. autoReadReg = 0_off habe ich auch gesetzt, leider das gleiche Problem. List der VCCU liefere ich später nach.

Da es wohl aufs Sniffen des Funkverkehrs hinausläuft, würde ich es gerne auf einem separaten System laufen lassen. Hat jemand eine Anleitung, wie ich nur relevante Daten möglichst detailliert mitsniffe und den Rest am besten gar nicht? Dafür kann man wohl logIDs angeben, aber welche sind damit gemeint, HMIDs? Und welche brauche ich in meinem Fall, nur die entsprechenden Sensoren?

[frank]

attr IODev hast du jetzt aber gesetzt?
alle hauptdevices, auch virtuelle, zb vccu.

zusätzlich, da du vccu nutz, ebenfalls IOgrp in allen devices.

ich kann mich schemenhaft erinnern, dass es auch schon aes probleme gab, weil manche devices kein IOgrp hatten.

sniffe erst mal nur die fb. dazu in beiden io "attr logIDs sys,HM_400FE5" setzen.

[Otto123]

"Muss nicht" heißt aber auch nicht "verboten", habe aber auch schon irgendwo andere Diskussionen drüber gelesen, dass die Benutzer das Attribut ohne Auswirkungen entfernt hätten

Es ist auch nicht verboten an den Weidezaun zu pinkeln - man muss es aber auch nicht tun

Ich habe bei mir vorhin noch ganz mutig, den hier abgesetzt:

Code Auswählen Erweitern

set subType=blindActuator regSet sign on
Und ein DOIF gebaut:

Code Auswählen Erweitern

defmod di_Test1 DOIF ([{sunrise()}] or [{sunset()}]) ({randomIOgrp('subType=blindActuator')})
attr di_Test1 do always
attr di_Test1 room Test

Mal sehen was meine Rollladen am Wochenende so tun. 
Sollte ich noch andere Geräte einbeziehen? Meine SCO sind ja alle Original, die haben ja kein Problem?!

Gruß Otto

[tndx]

Es ist auch nicht verboten an den Weidezaun zu pinkeln - man muss es aber auch nicht tun

OK, Du hast mich überzeugt, ich werde das Attribut wieder überall einfügen  Aber solange das im Wiki so beschrieben steht, werde ich nicht der letzte sein, der zu gründlich aufräumt 

Sollte ich noch andere Geräte einbeziehen? Meine SCO sind ja alle Original, die haben ja kein Problem?!

Mein Original-SCO hat auch das Problem, und ich hatte schon mal deutlich mehr davon im Einsatz, alle mit denselben Symptomen. Nur mein Original HM-SEC-RHS scheint resistent zu sein.

[tndx]

Hi,

attr IODev hast du jetzt aber gesetzt?
alle hauptdevices, auch virtuelle, zb vccu.

zusätzlich, da du vccu nutz, ebenfalls IOgrp in allen devices.

ich kann mich schemenhaft erinnern, dass es auch schon aes probleme gab, weil manche devices kein IOgrp hatten.

sniffe erst mal nur die fb. dazu in beiden io "attr logIDs sys,HM_400FE5" setzen.

Ich werde das mit IODev nachtragen und auch die Fernbedienung sniffen, komme wohl erst ab Sonntag Nachmittag dazu.

[Otto123]

OK, Du hast mich überzeugt, ich werde das Attribut wieder überall einfügen  Aber solange das im Wiki so beschrieben steht, werde ich nicht der letzte sein, der zu gründlich aufräumt 


Mein Original-SCO hat auch das Problem, und ich hatte schon mal deutlich mehr davon im Einsatz, alle mit denselben Symptomen. Nur mein Original HM-SEC-RHS scheint resistent zu sein.

Ok wenn wir hier schlauer sind, ändere ich das Wiki - versprochen. Die jetzige Formulierung, zumindest ein Teil, ist glaub ich sogar von mir.
Dann setzt  ich mal das attribute bei den SCO, da hab ich ja auch ein paar. Bei denen ist es ja sogar so, dass das attribute scheinbar etwas auslöst. Bei den Rollladen spielt das attribute wirklich eine Rolle?

Code Auswählen Erweitern

attr model=HM-SEC-SCO aesCommReq 1

Gute Nacht
Otto

[Otto123]

die fb von tndx zeigt auch noch das reading

Code Auswählen Erweitern

2019-07-18 11:15:18   aesReqTo        VCCU

gibt es das bei dir nicht?

Moin Frank,

an den Aktoren und Sensoren sehe ich diese Readings nicht. Aber die VCCU hat eines.
Kann man auch loggen:

Code Auswählen Erweitern

2019-07-20_10:29:11 VCCU aesReqTo: RolloGZR
2019-07-20_10:30:34 VCCU aesReqTo: RolloGZL
2019-07-20_10:33:48 VCCU aesReqTo: RolloAZR
2019-07-20_10:33:48 VCCU aesReqTo: RolloGZL
2019-07-20_10:33:49 VCCU aesReqTo: RolloGZR

Ansonsten läuft alles unauffällig. Ich habe mir überlegt, man könnte auch noch immer mal am Tag einen der 3 IOs außer Betrieb nehmen:

Code Auswählen Erweitern

sub randomIOclose()
# schließt zufällig einen IO der VCCU
{
    my @vccu=devspec2array(".mId=FFF0");
    my @IOList=split /,/,AttrVal($vccu[0],"IOList","");
foreach (@IOList) {fhem ("set $_:FILTER=state!=opened reopen")}
    fhem ("set $IOList[int(1+(rand 3))-1] close");
}
Das würde den IO aus dem Sendeweg und aus dem Empfangsweg nehmen. Aber alles was ich so probiere, zeigt eine zuverlässige Funktion der VCCU.

Gruß Otto

[frank]

moin otto,

an den Aktoren und Sensoren sehe ich diese Readings nicht. Aber die VCCU hat eines.
Kann man auch loggen:

Code Auswählen Erweitern

2019-07-20_10:29:11 VCCU aesReqTo: RolloGZR
2019-07-20_10:30:34 VCCU aesReqTo: RolloGZL
2019-07-20_10:33:48 VCCU aesReqTo: RolloAZR
2019-07-20_10:33:48 VCCU aesReqTo: RolloGZL
2019-07-20_10:33:49 VCCU aesReqTo: RolloGZR

interessant, und von der logik, so wie ich aes (bisher) verstehe, wesentlich besser an dieser stelle.
denn mit aesCommReq=1 in einem device fordert die zentrale/fhem/vccu den aes request vom device.

Code Auswählen Erweitern

2019-07-18 11:15:18   aesReqTo        VCCU
das reading im hauptdevice der fb von tndx, deutet ja dann auf einen aes request der fb an seine vccu hin. ausgelöst durch irgend eine messge der vccu. korrekterweise müsste dieser reqest aber durch ein gesetztes sign an der fb erfolgen. zumindestens im gezeigten chn ist sign aber off. hm...

warten wir mal auf neue info, zb list vccu.


übrigens:

Ok wenn wir hier schlauer sind, ändere ich das Wiki - versprochen. Die jetzige Formulierung, zumindest ein Teil, ist glaub ich sogar von mir.

an dieser stelle wurde sicherlich schon oft verbessert.
die erwartungshaltung der leser wird immer eine für sie passende interpretation finden.

[Otto123]

Ich habe mal bei meiner FB 12 aesCommReq gesetzt und voila:

2019-07-20_19:06:34 VCCU aesReqTo: FB12

Aber die FB12 hat kein Reading bekommen

Ich habe noch nicht genau verstanden was passiert. Das Reading aesReqTo wurde nur einmalig auf FB12 gesetzt, die Rollos setzen das wiederholt.

[tndx]

Guten Abend,

habe mich gerade wieder meinem Problem gewidmet. Zunächst mal ein list meiner VCCU:

Code Auswählen Erweitern

Internals:
   DEF        F3A460
   FUUID      5c489f65-f33f-7a7c-523a-b93c1b2fca92609c
   IODev      myHmUARTLGW
   LASTInputDev myHmUARTLGW
   MSGCNT     440
   NAME       VCCU
   NOTIFYDEV  global
   NR         78
   NTFY_ORDER 50-VCCU
   STATE      meinLGW:UAS,myHmUARTLGW:ok,myHmUARTUSB:ok
   TYPE       CUL_HM
   assignedIOs meinLGW,myHmUARTLGW,myHmUARTUSB
   channel_01 VCCU_Btn1
   lastMsg    No:3E - t:01 s:F3A460 d:469A98 010E
   myHmUARTLGW_MSGCNT 140
   myHmUARTLGW_RAWMSG 050000413EA001F3A460469A98010E
   myHmUARTLGW_RSSI -65
   myHmUARTLGW_TIME 2019-07-21 22:52:39
   myHmUARTUSB_MSGCNT 300
   myHmUARTUSB_RAWMSG 0500023E738002F3A4603E30D801012A00
   myHmUARTUSB_RSSI -62
   myHmUARTUSB_TIME 2019-07-21 22:50:30
   protLastRcv 2019-07-21 22:52:38
   protRcv    337 last_at:2019-07-21 22:52:38
   protRcvB   4 last_at:2019-07-21 22:48:39
   rssi_at_myHmUARTLGW cnt:140 min:-67 max:-64 avg:-65.84 lst:-65
   rssi_at_myHmUARTUSB cnt:300 min:-64 max:-62 avg:-62.16 lst:-62
   READINGS:
     2019-07-21 22:52:38   CommandAccepted yes
     2019-07-21 22:43:41   IOopen          2
     2019-07-20 22:00:50   aesKeyNbr       00
     2019-07-21 22:47:03   aesReqTo        Keymatic
     2019-07-21 22:43:41   state           meinLGW:UAS,myHmUARTLGW:ok,myHmUARTUSB:ok
   helper:
     HM_CMDNR   62
     mId        FFF0
     peerFriend peerSens,peerAct
     peerOpt    -:virtual
     regLst     0
     rxType     1
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     io:
       nextSend   1563742359.37566
       prefIO     
       vccu       VCCU
       ioList:
         myHmUARTLGW
         myHmUARTUSB
     mRssi:
       mNo        3E
       io:
         myHmUARTLGW:
           -61
           -61
         myHmUARTUSB:
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     rssi:
       at_myHmUARTLGW:
         avg        -65.85
         cnt        140
         lst        -65
         max        -64
         min        -67
       at_myHmUARTUSB:
         avg        -62.16
         cnt        300
         lst        -62
         max        -62
         min        -64
     tmpl:
Attributes:
   IODev      myHmUARTLGW
   IOList     myHmUARTLGW,myHmUARTUSB
   IOgrp      VCCU
   hmKey      01:XXX
   hmKey2     02:YYY
   model      CCU-FHEM
   room       VCCU
   subType    virtual
   webCmd     virtual:update

Ich habe heute wie versprochen mit der Giesskanne IODev und IOgrp gesetzt:

Code Auswählen Erweitern

attr TYPE=CUL_HM IODev myHmUARTLGW
attr TYPE=CUL_HM IOgrp VCCU

Außerdem habe ich mein FHEM auf die neueste Version aktualisiert, der Stand davor war 1-2 Monate alt.

Anschließend habe ich auf einem Laptop mit einer Minimal-FHEM-Konfiguration den Funkverkehr mitsniffen wollen:

Code Auswählen Erweitern

attr global verbose 1
attr global mseclog 1
attr logIDs sys,HM_400FE5

Anschließend war ich gleich doppelt irritiert, zum Einen von dem Inhalt der Logdatei:

Code Auswählen Erweitern

2019.07.21 22:40:20.091 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:40:20.099 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:40:20.099 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:40:20.099 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0074
2019.07.21 22:40:35.096 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:40:35.104 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:40:35.104 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:40:35.104 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0078
2019.07.21 22:40:50.098 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:40:50.107 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:40:50.107 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:40:50.107 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0078
2019.07.21 22:41:05.107 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:41:05.117 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:41:05.117 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:41:05.117 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0094
2019.07.21 22:41:20.113 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:41:20.131 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:41:20.132 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:41:20.132 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0182
2019.07.21 22:41:35.118 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:41:35.124 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:41:35.124 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:41:35.124 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0054
2019.07.21 22:41:50.123 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:41:50.130 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:41:50.130 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:41:50.131 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0069
2019.07.21 22:42:05.129 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:42:05.144 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:42:05.144 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:42:05.144 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0145
2019.07.21 22:42:20.133 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:42:20.150 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:42:20.150 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:42:20.150 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0161
2019.07.21 22:42:35.138 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:42:35.147 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:42:35.147 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:42:35.147 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0079
2019.07.21 22:42:50.143 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:42:50.158 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:42:50.158 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:42:50.158 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0145
2019.07.21 22:43:05.149 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:43:05.158 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:43:05.158 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:43:05.159 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0091
2019.07.21 22:43:20.153 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:43:20.161 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:43:20.161 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:43:20.161 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0067
2019.07.21 22:43:35.160 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:43:35.171 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:43:35.171 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:43:35.171 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0100
2019.07.21 22:43:50.163 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:43:50.174 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:43:50.175 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:43:50.175 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0107
2019.07.21 22:44:05.171 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:44:05.179 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:44:05.179 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:44:05.179 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0078
2019.07.21 22:44:20.174 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:44:20.184 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:44:20.185 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:44:20.185 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0102
2019.07.21 22:44:35.176 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:44:35.186 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:44:35.186 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:44:35.186 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0091
2019.07.21 22:44:50.179 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:44:50.184 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:44:50.184 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:44:50.185 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0052
2019.07.21 22:45:05.182 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:45:05.190 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:45:05.190 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:45:05.190 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0072
2019.07.21 22:45:20.184 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:45:20.191 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:45:20.191 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:45:20.191 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0062
2019.07.21 22:45:35.187 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:45:35.196 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:45:35.196 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:45:35.196 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0082
2019.07.21 22:45:50.193 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:45:50.205 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:45:50.206 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:45:50.206 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0114
2019.07.21 22:46:05.199 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:46:05.212 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:46:05.212 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:46:05.212 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0123
2019.07.21 22:46:20.204 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:46:20.217 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:46:20.218 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:46:20.218 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0131
2019.07.21 22:46:35.208 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:46:35.215 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:46:35.215 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:46:35.215 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0060
2019.07.21 22:46:50.211 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:46:50.220 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:46:50.220 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:46:50.220 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0080
2019.07.21 22:47:05.216 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:47:05.228 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:47:05.228 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:47:05.228 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0105
2019.07.21 22:47:20.220 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:47:20.235 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:47:20.235 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:47:20.235 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0145


Irgendwie kann ich dem nichts Sinnvolles entlocken, habe ich irgendeine Sniffing-Einstellung übersehen?

Zum anderen von der Tatsache, dass die AES-signierte Kommunikation einer FB-Taste nach mehrfachen (mind. 2x) FHEM-Neustarts funktioniert hat.

Leider fehlt mir jetzt die Zeit, noch mal das komplette Fehlerszenario durchzuspielen, aber ich habe wieder Hoffnung 

Melde mich morgen wieder, wenn ich mehr Zeit zum spielen gehabt habe.

[Otto123]

Moin,

ich kann, trotz ständigem Wechsel des preferred IO in Kombination mit genauso zufälligem Ausschalten eines IO von dreien, meinem System keinen Fehlerhaften aes Zustand abringen. Ich werde das dann mal wieder auf normal zurückstellen.
Entweder läuft das System so zuverlässig und macht genau das was es soll, oder mein Testszenario ist ungeeignet und besagt nichts. Ich bin nicht ganz sicher über diese beiden Möglichkeiten, habe aber für mich ein gutes Gefühl 
Zu meiner Konfiguration:
IODev nirgendwo gelöscht
IOgrp überall gesetzt, meist ohne preferred IO nur auf VCCU
Kein eigener AES Key im Einsatz, ich halte das für mich persönlich als unrelevant und spar mir die Arbeit für den Tag an dem alles andere getan ist

@tndx

2019-07-20 22:00:50   aesKeyNbr       00
...
     2019-07-21 22:43:41   state           meinLGW:UAS,myHmUARTLGW:ok,myHmUARTUSB:ok

Das mit dem dritten IO ist so gewollt? Der ist da aber der VCCU nicht zugeordnet, sollte aber kein Problem sein.
aesKeyNbr 00 macht mich stutzig: Du hast zwar eigene Keys definiert, aber die sind nicht in Verwendung? oder verstehe ich da was falsch?

Gruß Otto

[frank]

@otto

ich habe verstanden, dass tndx auf einem sehr guten weg ist, da die fb nach dem setzen aller IODev/IOgrp-attribute nun bereits 2 restarts überlebt hat.


@tndx

der sniff zeigt nur die regelmässige (15s) kommunikation von fhem (HMUARTLGW) mit dem io (abfrage der credits).
entweder konnte das io keine messages der fb empfangen, da ausserhalb der reichweite, oder es gab keine messages im zeitraum, oder der name der fb bei attr logids ist falsch.

Code Auswählen Erweitern

attr TYPE=CUL_HM IODev myHmUARTLGW
attr TYPE=CUL_HM IOgrp VCCU

das sollte falsch sein, da hiermit auch alle channel versorgt werden. folgendes sollte passen:

Code Auswählen Erweitern

attr TYPE=CUL_HM:FILTER=DEF=...... IODev myHmUARTLGW
attr TYPE=CUL_HM:FILTER=DEF=...... IOgrp VCCU

tip: solche massenhaften zuweisungen probiere ich vorher immer mit list:

Code Auswählen Erweitern

list TYPE=CUL_HM:FILTER=DEF=......

[Otto123]

Wir hatten nach der immer wieder auftauchenden Verwirrung mit den 6 Punkten mal noch dieses Filter erarbeitet:

Code Auswählen Erweitern

TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6}
Die spart den Actiondetector aus

Mit der FB wollte ich nochmal experimentieren, meine Gedanken,Fragen:

Man kann attr aesCommReq am Hauptdevice und an den Kanälen separat setzen - was bewirkt es genau wo?
aesCommReq  ist ja ein attribute, d.h. das Gerät weiß davon gar nichts - es steht ja nicht im Register.
Es kann eigentlich nur so wirken: Die Zentrale fragt das Gerät etwas mit aesCommReq und das Gerät antwortet darauf signiert. Wird damit die Antwort auf einen Befehl (ack) signiert angefordert? Denn:
- Die Rollladen Aktoren (oder die VCCU) setzen bei jeder Aktion das Reading aesReqTo in der VCCU.
- die FB hat es bei mir genau einmal gesetzt: nach setzen des attributes und nach dem ersten Tastendruck. Dann nie wieder? (Ich habe ein peering gelöscht)

Ich muss mich mit dem Thema aes mal mehr beschäftigen

Gruß Otto