[gelöst] Probleme mit Homematic+AES

[tndx]

wahrscheinlich wirkt aescommreq nur bei sensoren, wenn diese trigger an fhem senden.

Die Aktoren senden ja auch, das sieht man ja auch in Ottos Auszug:

Code Auswählen Erweitern

2019-07-18_11:47:11 RolloAZL aesCommToDev: pending
2019-07-18_11:47:11 RolloAZL aesKeyNbr: 00
2019-07-18_11:47:11 RolloAZL aesCommToDev: ok

Macht ja auch Sinn bei Statusänderungen...

Bei meinen Sensoren funktioniert es aber wie gesagt auch, ohne dass sign=on gesetzt ist.

Viel interessanter ist aber nun, was passiert, wenn Du nun FHEM neustertest oder im laufenden Betrieb ein anderes IO-Device zuweist?

[Otto123]

nichts arbeitet nach wie vor.
Ich habe 3 IOs: HMLAN1,HMUART1,ser2netUart.
Der IO war (IOgrp VCCU) Internals -> IODev HMUART1 - klar weil der am nächsten dran ist.
Hab umgestellt IOgrp VCCU:ser2netUart - das bestätigt er auch in Internals -> IODev ser2netUart
Dann mal geschaltet

Code Auswählen Erweitern

2019-07-18_14:12:07 RolloAZL level: set_90
2019-07-18_14:12:07 RolloAZL set_90
2019-07-18_14:12:08 RolloAZL aesCommToDev: pending
2019-07-18_14:12:08 RolloAZL aesCommToDev: ok
2019-07-18_14:12:08 RolloAZL deviceMsg: auf (to VCCU)
2019-07-18_14:12:08 RolloAZL level: 100
2019-07-18_14:12:08 RolloAZL motor: down:auf
2019-07-18_14:12:08 RolloAZL auf
2019-07-18_14:12:13 RolloAZL deviceMsg: 90 (to broadcast)
2019-07-18_14:12:13 RolloAZL level: 90
2019-07-18_14:12:13 RolloAZL motor: stop:90
2019-07-18_14:12:13 RolloAZL pct: 90
2019-07-18_14:12:13 RolloAZL 90
2019-07-18_14:12:25 RolloAZL level: set_100
2019-07-18_14:12:25 RolloAZL set_100
2019-07-18_14:12:25 RolloAZL aesCommToDev: pending
2019-07-18_14:12:25 RolloAZL aesCommToDev: ok
2019-07-18_14:12:25 RolloAZL deviceMsg: 90 (to VCCU)
2019-07-18_14:12:25 RolloAZL level: 90
2019-07-18_14:12:25 RolloAZL motor: up:90
2019-07-18_14:12:25 RolloAZL 90
2019-07-18_14:12:32 RolloAZL deviceMsg: auf (to broadcast)
2019-07-18_14:12:32 RolloAZL level: 100
2019-07-18_14:12:32 RolloAZL motor: stop:auf
2019-07-18_14:12:32 RolloAZL pct: 100
2019-07-18_14:12:32 RolloAZL auf

[tndx]

Hast Du auch mal "shutdown restart" gemacht?

Dann weiß ich echt nicht mehr, woran es noch liegen kann. Natürlich kann es immer noch sein, dass ausgerechnet meine Sensorarten problematisch sind...

Ich habe im Übrigen vorhin noch mal geschaut, "sign" war definitiv "off", um da Abhängigkeiten auszuschließen, habe ich bei einem Sensor auf "on" gesetzt, trotzdem Probleme nach restart.

[frank]

peere mal einen sensor mit der vccu.

[tndx]

peere mal einen sensor mit der vccu.

Wie meinst Du das genau?

[frank]

du peerst einen sensorchannel mit einem channel der vccu. entweder mit peersmart oder peerchan.
ich würde erst einen sensor versuchen, der nur einen channel hat. da ist dann natürlich hauptdevice und channel identisch.

oder was hast du nicht verstanden?

[tndx]

Sorry, hab's nicht so mit Peerings.

Aber zufälligerweise sind die Channel der ebenfalls von dem Problem betroffenen Fernbedienung HM-RC-KEY4-2 mit einem virtuellen Channel der VCCU gepeert. Habe ich damals gemacht, damit die LED der Fernbedienung grün wird. Meinst Du das?

[frank]

genau so.

zeig mal je ein list von dem vccu_chn, fb_chn1 und fb_device.

[tndx]

list vccu_chn:

Code Auswählen Erweitern

Internals:
   DEF        F3A46001
   FUUID      5c489f6a-f33f-7a7c-dea0-a05a0a55be2f9c0a
   NAME       VCCU_Btn1
   NOTIFYDEV  global
   NR         262
   NTFY_ORDER 50-VCCU_Btn1
   STATE      ???
   TYPE       CUL_HM
   chanNo     01
   device     VCCU
   peerList   HM_400FE5_unlock,HM_400FE5_lock,
   READINGS:
     2019-07-18 20:32:22   CommandAccepted yes
     2019-07-18 15:04:43   peerList        HM_400FE5_unlock,HM_400FE5_lock,
     2019-07-18 20:32:22   recentStateType ack
     2019-07-18 11:13:55   trigLast        HM_400FE5_unlock:short
     2019-07-18 11:13:10   trig_HM_400FE5_lock Short_224
     2019-07-18 11:13:55   trig_HM_400FE5_unlock Short_129
     2019-07-18 11:15:23   trig_aes_HM_400FE5_lock fail:225
     2019-07-18 11:15:34   trig_aes_HM_400FE5_unlock fail:131
   helper:
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     role:
       chn        1
       vrt        1
     tmpl:
Attributes:
   model      CCU-FHEM
   peerIDs    400FE501,400FE502,
   webCmd     press short:press long

list fb_chn1:

Code Auswählen Erweitern

Internals:
   DEF        400FE502
   FUUID      5c489f66-f33f-7a7c-8f87-e0f4522e44ab6589
   NAME       HM_400FE5_lock
   NOTIFYDEV  global
   NR         169
   NTFY_ORDER 50-HM_400FE5_lock
   STATE      Short 3_224 (to VCCU)
   TYPE       CUL_HM
   chanNo     02
   device     HM_400FE5
   peerList   VCCU_Btn1,
   READINGS:
     2018-05-01 11:54:36   R-VCCU_Btn1-expectAES on
     2018-05-01 11:54:36   R-VCCU_Btn1-peerNeedsBurst off
     2018-05-01 11:44:42   R-sign          off
     2018-05-01 11:54:35   RegL_01.        04:10 08:00 09:00 00:00
     2018-05-01 11:54:36   RegL_04.VCCU_Btn1 01:80 00:00
     2019-07-18 15:04:40   peerList        VCCU_Btn1,
     2019-07-18 11:13:10   state           Short 3_224 (to VCCU)
     2019-07-18 11:15:23   trig_aes_VCCU   fail:225
     2019-07-18 11:13:10   trigger         Short_224
     2019-07-18 11:13:10   trigger_cnt     224
   helper:
     peerFriend peerAct,peerVirt
     peerOpt    4:remote
     regLst     1,4p
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
     tmpl:
   role:
Attributes:
   aesCommReq 0
   model      HM-RC-KEY4-2
   peerIDs    00000000,F3A46001,

list fb_device:

Code Auswählen Erweitern

Internals:
   DEF        400FE5
   FUUID      5c489f66-f33f-7a7c-b4dd-4669627734d3950d
   IODev     
   NAME       HM_400FE5
   NOTIFYDEV  global
   NR         163
   NTFY_ORDER 50-HM_400FE5
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_400FE5_unlock
   channel_02 HM_400FE5_lock
   channel_03 HM_400FE5_light
   channel_04 HM_400FE5_open
   READINGS:
     2018-05-01 11:56:21   CommandAccepted yes
     2018-05-01 11:56:21   D-firmware      1.2
     2018-05-01 11:56:21   D-serialNr      MEQ1115969
     2018-05-01 11:50:23   PairedTo        0xF3A460
     2018-05-01 11:43:33   R-pairCentral   0xF3A460
     2018-05-01 11:50:23   RegL_00.        02:01 0A:F3 0B:A4 0C:60 18:00 00:00
     2019-07-18 11:15:34   aesCommToDev    fail
     2018-05-01 11:48:52   aesKeyNbr       04
     2019-07-18 11:15:18   aesReqTo        VCCU
     2018-05-01 11:42:55   alive           yes
     2019-07-18 11:13:55   battery         ok
     2018-05-01 11:42:55   powerOn         2018-05-01 11:42:55
     2018-05-01 11:42:55   recentStateType info
     2019-07-18 11:15:18   state           CMDs_done
   helper:
     HM_CMDNR   56
     mId        00A6
     peerFriend
     peerOpt    -:remote
     regLst     0
     rxType     20
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +400FE5,00,00,00
       prefIO     
       rxt        2
       vccu       VCCU
       p:
         400FE5
         00
         00
         00
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     tmpl:
   role:
Attributes:
   IOgrp      VCCU
   aesCommReq 0
   autoReadReg 0
   expert     2_raw
   firmware   1.2
   model      HM-RC-KEY4-2
   room       CUL_HM
   serialNr   MEQ1115969
   subType    remote
   webCmd     getConfig:clear msgEvents

[Otto123]

Shutdown restart gemacht, arbeitet immer noch.

Code Auswählen Erweitern

2019-07-18_21:39:01 RolloAZL aesCommToDev: pending
2019-07-18_21:39:01 RolloAZL aesCommToDev: ok
2019-07-18_21:39:01 RolloAZL deviceMsg: zu (to VCCU)
2019-07-18_21:40:33 RolloAZL level: set_10
2019-07-18_21:40:33 RolloAZL set_10
2019-07-18_21:40:34 RolloAZL aesCommToDev: pending
2019-07-18_21:40:34 RolloAZL aesCommToDev: ok
2019-07-18_21:40:34 RolloAZL level: 0
2019-07-18_21:40:34 RolloAZL motor: up:zu
2019-07-18_21:40:34 RolloAZL zu
2019-07-18_21:40:39 RolloAZL deviceMsg: 10 (to broadcast)
2019-07-18_21:40:39 RolloAZL level: 10
2019-07-18_21:40:39 RolloAZL motor: stop:10
2019-07-18_21:40:39 RolloAZL pct: 10
2019-07-18_21:40:39 RolloAZL 10


[frank]

beim fb_device fehlt das attr IODev. das internal zeigt auch keinen eintrag.

setze es mit dem namen eines io.

attr autoReadReg über das frontend gesetzt, sollte "0_off" anzeigen. 

wenn alles nichts ändert, würde ich das device sniffen und versuchen, unterschiede beim umschalten der io zu erkennen.

zeig auch noch.ein list vom hauptdevice der vccu. keys verschleiern.

[tndx]

beim fb_device fehlt das attr IODev. das internal zeigt auch keinen eintrag.

OK, Recht hast Du, aber sollte sich nicht die VCCU darum kümmern? Ich habe extra konsequent alle IODevs entfernt und nur noch IOGrps stehen lassen.

Ich werde mir das heute Abend noch mal in Ruhe anschauen...

[Otto123]

Ich habe extra konsequent alle IODevs entfernt und nur noch IOGrps stehen lassen.

Es steht doch nirgendwo, dass man dies tun soll? Ich habe mal irgendwann gelernt/gelesen (Beispiel), das IODev erstmal nicht unbedingt was mit CUL_HM zu tun hat sondern "generischer" ist.
Die VCCU kümmert sich um die interne Verwendung und CUL_HM nimmt dann nicht mehr das attr IODev sondern verwendet das Internal IODev - mal etwas populärwissenschaftlich ausgedrückt, weil ich die Internas auch bloß nicht kenne.

Ich weiß nicht welche Seiteneffekte das Löschen von IODev haben kann.

Gruß Otto

[Otto123]

Ich war heute morgen noch etwas erschrocken, weil ich im Log den Eindruck hatte, dass ein Fenstersensor mit eingeschaltetem aesCommReq mehr plappert. Aber das war ein Trugschluss durch event-on-change-reading .*
Es kommt lediglich der gleiche Event zusätzlich wie bei den Rollladenaktoren. Mal zwei im Vergleich, der eine mit aesCommReq 1

Code Auswählen Erweitern

2019-07-19 11:10:42 CUL_HM FensterAZR alive: yes
2019-07-19 11:10:42 CUL_HM FensterAZR battery: ok
2019-07-19 11:10:42 CUL_HM FensterAZR contact: closed (to VCCU)
2019-07-19 11:10:42 CUL_HM FensterAZR sabotageError: off
2019-07-19 11:10:42 CUL_HM FensterAZR closed
2019-07-19 11:33:52 CUL_HM FensterAZL aesCommToDev: pending
2019-07-19 11:33:53 CUL_HM FensterAZL aesCommToDev: ok
2019-07-19 11:33:53 CUL_HM FensterAZL alive: yes
2019-07-19 11:33:53 CUL_HM FensterAZL battery: ok
2019-07-19 11:33:53 CUL_HM FensterAZL contact: closed (to VCCU)
2019-07-19 11:33:53 CUL_HM FensterAZL sabotageError: off
2019-07-19 11:33:53 CUL_HM FensterAZL closed
2019-07-19 12:11:02 CUL_HM FensterAZR alive: yes
2019-07-19 12:11:02 CUL_HM FensterAZR battery: ok
2019-07-19 12:11:02 CUL_HM FensterAZR contact: closed (to VCCU)
2019-07-19 12:11:02 CUL_HM FensterAZR sabotageError: off
2019-07-19 12:11:02 CUL_HM FensterAZR closed
2019-07-19 12:28:26 CUL_HM FensterAZL aesCommToDev: pending
2019-07-19 12:28:27 CUL_HM FensterAZL aesCommToDev: ok
2019-07-19 12:28:27 CUL_HM FensterAZL alive: yes
2019-07-19 12:28:27 CUL_HM FensterAZL battery: ok
2019-07-19 12:28:27 CUL_HM FensterAZL contact: closed (to VCCU)
2019-07-19 12:28:27 CUL_HM FensterAZL sabotageError: off
2019-07-19 12:28:27 CUL_HM FensterAZL closed
Was ich irgendwie noch nicht ganz verstehe, bei dem Rollladenaktor ist das aesCommToDev ja Teil des Steuerbefehls? Aber der Fenstersensor meldet sich doch selbstständig? Der bekommt doch keine Steuerbefehle?
Edit: ok, beim Betätigen gibt es noch einen Unterschied: 

Code Auswählen Erweitern

2019-07-19 13:25:09 CUL_HM FensterAZL trig_aes_VCCU: ok:80


Soll ich mal alle Rollladenaktoren mit sign on versehen? Und dann halbtäglich mal die IOgrp bei allen ändern? - da müsst ich mir einen Zufallsgenerator dafür einfallen lassen. 

[frank]

moin otto,

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?
sind das die optischen kontakte (sco)?

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

da müsst ich mir einen Zufallsgenerator dafür einfallen lassen

sunrise/sunset?