CUL_HM und AES

tndx · 30 Dezember 2023, 13:35:09

Ich hatte lange Zeit AES-gesicherte Kommunikation bei den Fenstersensoren und Zugangssystem (Keymatic, Garagen-Toröffner, Türfernbedienungen) funktionierend am laufen. Seit einiger Zeit haben die Türöffner einer nach dem anderen Schwierigkeiten gemacht, so das wir wieder auf herkömmliche Schlüssel umgestigen sind (jaja, "Scheiß-Technik"). Nachdem ich nun etwas Zeit hatte, mir das ganze anzuschauen, ist mir aufgefallen, dass auch bei den Fenstersensoren AES nicht funktioniert. Dort ist es nur nicht aufgefallen, da ich die Sensor-Information nie richtig genutzt habe, und der Status wurde auch so angezeigt.
Konkret fällt mir auf, dass bei keinem meiner Sensoren mehr das Reading "aesKeyNbr 04" auftaucht und bei der Kommunikation ständig ein "trig_aes_HM_XXXXXX_YYYY: fail" kommt. Das Reading ist aber sehr wohl noch bei den beiden Aktoren vorhanden: Keymatic und HM-LC-SW1-PL-CT-R1.
Wie kann das sein? Ist das bei einem der FHEM-/CUL_HM-Updates entfernt worden?
Wie kann ich das am schnellsten wieder fixen, ohne gleich den Key ungesichert OTA zu verteilen?
Reicht das ggf. das Reading per cfg-Editor renzumogeln?

Edit: Reaings lassen sich offenbar nicht per cfg-Editor reinmogeln, hatte das wohl falsch in Erinnerung, habe auch seit Jahren nicht mehr die Config editiert. Gibt es irgendeine andere Möglichkeit, ohne den Schlüssel tatsächlich übertragen zu müssen?

frank · 30 Dezember 2023, 13:57:49

ich nutze eigentlich kein aes, aber letztens habe ich zufällig festgestellt, dass sich die io typen (hmlan, hmuart, hmusb, cul) bei den aes meldungen unterschiedlich verhalten.

tndx · 30 Dezember 2023, 14:11:26

Hm, das kann zeitlich gut mit meiner letzten IO-Umstellung zusammenhängen. Ich nutze zwar nach wie vor HMUART allerdings mit dieser Implementierung https://github.com/andyboeh/esphome-hmlgw. Bis jetzt habe ich keine anderen Auffälligkeiten festgestellt.
Wie äußern sich de von dir festgestellten Unterschiede, kann ich das irgendwie schtbar machen?
Aber dass die Readings verschwunden sind, dafür kann doch ein IO-Device nichts, oder?
Edit:
Mein altes HmUARTUSB angeschlossen, per IOgrp der Fernbedienung zugeordnet, leider dasselbe Verhalten, das Reading ist auch nicht wieder aufgetaucht. Im Eventmonitor taucht es aber durchaus auf "HM VCCU aesKeyNbr: 04", muss also weiterhin irgendwo bekannt sein. Leider löst es aber nicht das Problem mit "aesCommToDev: fail" und "trig_aes_VCCU: fail".

frank · 01 Januar 2024, 13:05:16

Zitat von: tndx am 30 Dezember 2023, 14:11:26Im Eventmonitor taucht es aber durchaus auf "HM VCCU aesKeyNbr: 04", muss also weiterhin irgendwo bekannt sein.

es geht also um trigger vom device an fhem/vccu. diese signierung initiert fhem, daher findest du das reading in der vccu.
wenn du am sensor zb ein register änderst sollte auch im sensor device dieses reading auftauchen, da dann der sensor aes initiiert.

Zitat von: tndx am 30 Dezember 2023, 14:11:26Leider löst es aber nicht das Problem mit "aesCommToDev: fail" und "trig_aes_VCCU: fail".

am besten mal mit allen io die raw messages sniffen.

und nach einem erneuten trigger je ein "get list full" vom sensor und der vccu posten.

tndx · 04 Januar 2024, 12:04:07

Moin,

ich komme im Moment nicht dazu, mich wieder mit dem Thema zu beschäftigen, aber sobald ich wieder Zeit habe, würden nicht ggf. die Aufzeichnungen eines AsksinAnalyzers reichen? Gefiltert auf problematische Devices als Sender oder Empfänger?

frank · 10 Januar 2024, 13:58:09

moin,

ich habe die tage mal bei einem fk "attr aesCommReq 1" gesetzt und mit unterschiedlichen prefered io getestet.
die readings aesCommToDev und trig_aes_ccu (meine vccu hat den namen ccu) beim fk haben immer ok gezeigt.

am besten sieht man den ablauf im eventmonitor mit eingeschalteter log option. (events plus rawmessages)
1. die events habe ich für den fk und die vccu gefiltert => (Tuer.SZ|ccu).*
2. im global device folgende attribute setzen:

Code Auswählen

attr global mseclog 1
attr global verbose 3

3. in jedem io "attr logIDs all" setzen.

hier ist der hmuart das prefered io. alle zeilen, die nach dem timestamp "CUL_HM" anzeigen, sind events:

Code Auswählen

2024.01.01 14:08:14.177 4: CUL_Parse: cul868 A 0C 13 A441 1DE620 1ACE1F 0106C824 -56
2024.01.01 14:08:14.187 5: cul868: dispatch A0C13A4411DE6201ACE1F0106C8::-56:cul868
2024-01-01 14:08:14.267 CUL_HM Tuer.SZ IODev: hmuart1
2024.01.01 14:08:14.306 4: CUL_Parse: cul868 A 11 13 A002 1ACE1F 1DE620 04AB6700006719004A -37
2024.01.01 14:08:14.309 5: cul868: dispatch A1113A0021ACE1F1DE62004AB670000671900::-37:cul868
2024-01-01 14:08:14.343 CUL_HM ccu aesKeyNbr: 00
2024.01.01 14:08:14.346 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:6EB6B83E d:FF r:FFD2     m:13 A002 1ACE1F 1DE620 04AB670000671900
2024.01.01 14:08:14.436 4: CUL_Parse: cul868 A 19 13 A003 1DE620 1ACE1F 640DB60246F3140ACEF58CDA0DE2A1F524 -56
2024.01.01 14:08:14.439 5: cul868: dispatch A1913A0031DE6201ACE1F640DB60246F3140ACEF58CDA0DE2A1F5::-56:cul868
2024-01-01 14:08:14.474 CUL_HM Tuer.SZ IODev: hmuart1
2024.01.01 14:08:14.479 0: HMUARTLGW hmuart1 recv: 01 05 02 00 3C msg: 13 A4 41 1DE620 1ACE1F 0106C8
2024-01-01 14:08:14.531 CUL_HM Tuer.SZ aesCommToDev: pending
2024-01-01 14:08:14.570 CUL_HM Tuer.SZ IODev: hmuart1
2024-01-01 14:08:14.619 CUL_HM Tuer.SZ aesCommToDev: ok
2024-01-01 14:08:14.619 CUL_HM Tuer.SZ contact: open (to ccu)
2024-01-01 14:08:14.619 CUL_HM Tuer.SZ open
2024-01-01 14:08:14.619 CUL_HM Tuer.SZ trig_aes_ccu: ok:6
2024-01-01 14:08:14.619 CUL_HM Tuer.SZ trigger_cnt: 6
2024.01.01 14:08:14.624 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:6EB6B934 d:FF r:FFD2     m:13 8002 1ACE1F 1DE620 00BC9D5E0D
2024.01.01 14:08:14.630 4: CUL_Parse: cul868 A 0E 13 8002 1ACE1F 1DE620 00BC9D5E0D4A -37
2024.01.01 14:08:14.632 5: cul868: dispatch A0E1380021ACE1F1DE62000BC9D5E0D::-37:cul868

nur der cul zeigt hier alle 4 gesendeten messages an.

Code Auswählen

2024.01.01 14:08:14.177 4: CUL_Parse: cul868 A 0C 13 A441 1DE620 1ACE1F 0106C824 -56
2024.01.01 14:08:14.306 4: CUL_Parse: cul868 A 11 13 A002 1ACE1F 1DE620 04AB6700006719004A -37
2024.01.01 14:08:14.436 4: CUL_Parse: cul868 A 19 13 A003 1DE620 1ACE1F 640DB60246F3140ACEF58CDA0DE2A1F524 -56
2024.01.01 14:08:14.630 4: CUL_Parse: cul868 A 0E 13 8002 1ACE1F 1DE620 00BC9D5E0D4A -37

aber unabhängig vom gewählten prefered io, sehe ich immer diese 4 events:

Code Auswählen

ccu aesKeyNbr: 00
Tuer.SZ aesCommToDev: pending
Tuer.SZ aesCommToDev: ok
Tuer.SZ trig_aes_ccu: ok:6

####################################

regelmässige fails kann ich provozieren, wenn gleichzeitig 2 io die aes kommunikation durchführen!!!

eq3 io machen aes autark, sobald sie durch fhem für bestimmte devices entsprechend präpariert wurden (assign). wenn die vccu zb das io wechselt, muss das bisherige io unassignt werden und das neue io wird assignt.

wenn bei mir der hmlan als prefered io mit dem fk assignt ist und aes wird einwandfrei regelmässig ausgeführt, ziehe ich beim hmlan das lan kabel raus.
spätestens beim nächsten trigger vom fk erkennt die vccu den disconnect und wechselt das io. allerdings kann beim hmlan ohne lan verbindung der fk nicht unassignt werden, wodurch er weiterhin autark seine aes messages sendet. zusätzlich nun auch das neu assignte und beide quatchen gleichzeitig.

da du neuerdings wlan verbindungen zu den io nutzt, würde es mich nicht wundern, wenn es hier zu ähnlichen situationen kommt. wenn dann noch häufige io wechsel dazukommen, falls keine prefered io genutzt werden, erhöht sich das risiko entsprechend.

gibt es nachbarn mit homematic, oder noch ein "vergessenes" aber unter strom stehendes io, das weiterhin autark sendet?
gibt es attack readings bei deinen devices?

das gleichzeitige quatschen kann ich in den sniffs aber nur selten erkennen. etwas mehr infos zeigen die hmuarts, wenn du bei diesen verbose=5 setzt.

tndx · 11 Januar 2024, 21:30:49

Hi Frank,

wie gesagt, ich hatte bis jetzt keine Zeit, mich wieder systematisch mit dem Problem zu befassen.

Aufgrund eines Stromausfalls wurde aber mein FHEM neu gestartet, seitdem funktioniert eine der 3 Fernbedienungen wieder, zumindest sporadisch. Die, die als Letztes den Dienst eingestellt hat, weigert sich weiterhin, die 3. ist im Moment nicht auffindbar, zu lange nicht benutzt

Ich habe zuletzt 2 IOs gehabt, beide per LAN angebunden. Gerade für die Fernbedienungen hatte ich keine preferred IOs gesetzt, weil sie ja immer an unterschiedlichen Positionen genutzt werden, und da dachte ich, lässt du mal VCCU entscheiden - offenbar ein Fehler?

Ich habe im Haus noch eine weitere HM-Installation laufen für die HmIP-Geräte mit HMCCU, aber ich habe sonst keine Auffälligkeiten, und beide Installationen laufen schon seit Jahren parallel, auch als das mit AES noch funktionierte. attack Readings habe ich zwar grundsätzlich schon mal gehabt, aber im Moment kann ich keine entdecken. Wo genau würden sie denn auftauchen: IO? Fernbedienungen? Aktoren?