plötzlich nach Updates aufgetauchtes Problem mit AES Kommunikation

[DeeSPe]

Hallo liebe Helfende,

vor ungefähr 2 Monaten kam ich auf die dumme Idee - als Sysadmin hätte ich es eigentlich besser wissen müssen - meinen FHEM Computer mal komplett zu aktualisieren.
Also FHEM aktualisiert und (ohne danach die Funktion verifiziert zu haben) gleich mal noch dem Debian eine volle Aktualisierung gegönnt.
Dann war irgendwann die SSH-Verbindung hin und nichts ging mehr. Auch ein Neustart des Computers brachte ihn nicht wieder hoch.
Nachdem ich den Computer abgebaut und anderenorts an einen Monitor angeschlossen hatte, sah ich das erste Debakel.
Bei der Aktualisierung von Debian wurde, neben etlichen anderen Paketen, auch "grub" mit aktualisiert und der weigerte sich mein System zu starten weil angeblich kein bootbares Medium gefunden wurde.
Etliche Stunden später fand ich dann heraus wie man das wieder über die grup-Konsole repariert bekommt.
Nun lief das System endlich wieder und auch FHEM lief für mich erst einmal ganz normal.
Kurze Zeit später begannen mich die Benachrichtigungen meines notify auf den ActionDetector zu erreichen dass etliche Geräte "dead" seien.
Die meisten Geräte die ich habe sind Kontakte vom Typ HM-SEC-SCO, die meisten davon (aber nicht alle) sind "dead" im ActionDetector, die Rauchmelder vom Typ HM-SEC-SD-2 stehen auf "unknown", der Aussensensor HM-WDS10-TH-O ist "alive".
Später fand ich dann auch heraus dass sich meine KeyMatic nicht mehr über FHEM steuern lässt.
Offenbar gibt es nun ein Problem mit der AES Kommunikation, denn alle Geräte mit "SEC" im Modell haben im Reading "aesCommToDev" nun entweder "fail" oder "pending" zu stehen.
Einzig, meine Alarmanlage von Typ HM-SEC-SIR-WM wird immer noch mit FHEM scharf und unscharf geschaltet.

Ich habe dann in den letzten Wochen noch öfter mal ein Update von FHEM gemacht weil ich dachte es könnte evtl. an CUL_HM.pm etwas fehlerhaft gewesen sein. Leider hat sich nichts zum Positiven verändert.

Da ich an meiner bestehenden HM Infrastruktur die letzten Jahre so gut wie nichts gemacht habe stehe ich mit meinem Kenntnissen hier vor einen Rätsel. Wenn ich mich recht erinnere habe ich auch keinen eigenen AES Schlüssel irgendwo zugewiesen, aber evtl. täusche ich mich da auch.
Was läuft hier plötzlich falsch?
Als IO Benutze ich eine VCCU mit zwei HM-MOD-UART (HMUARTLGW). Einem als Wifi-Version und der andere als USB.

Hier mal ein Logauszug von der KeyMatic mit "verbose 5" beim Versuch über FHEM zu sperren.

2020.09.21 14:18:47 3:  CUL_HM set fl_Tuerschloss lock noArg
2020.09.21 14:18:47 5:  CUL_HM set fl_Tuerschloss ?
2020.09.21 14:18:47 5:  CUL_HM set fl_Tuerschloss ?
2020.09.21 14:18:47 5:  CUL_HM set fl_Tuerschloss ?
2020.09.21 14:18:47 5:  CUL_HM fl_Tuerschloss protEvent:CMDs_pending pending:1
2020.09.21 14:18:47 5:  CUL_HM set fl_Tuerschloss ?
2020.09.21 14:18:47 5:  CUL_HM set fl_Tuerschloss ?
2020.09.21 14:18:47 5:  CUL_HM set fl_Tuerschloss ?
2020.09.21 14:18:47 5:  CUL_HM set fl_Tuerschloss ?
2020.09.21 14:18:47 5:  CUL_HM set fl_Tuerschloss ?
2020.09.21 14:18:47 5:  CUL_HM set fl_Tuerschloss ?
2020.09.21 14:18:47 5:  CUL_HM fl_Tuerschloss protEvent:CMDs_processing... pending:0
2020.09.21 14:18:47 5:  CUL_HM ignoring message for HMWIFI received on HMUART
2020.09.21 14:18:48 5:  CUL_HM ignoring message for HMWIFI received on HMUART
2020.09.21 14:18:49 5:  CUL_HM ignoring message for HMWIFI received on HMUART
2020.09.21 14:18:53 4:  CUL_HM_Resend: fl_Tuerschloss nr 2
2020.09.21 14:18:53 5:  CUL_HM ignoring message for HMWIFI received on HMUART
2020.09.21 14:18:54 5:  CUL_HM ignoring message for HMWIFI received on HMUART
2020.09.21 14:18:55 5:  CUL_HM ignoring message for HMWIFI received on HMUART
2020.09.21 14:18:57 5:  CUL_HM set fl_Tuerschloss ?
2020.09.21 14:18:57 5:  CUL_HM set fl_Tuerschloss ?
2020.09.21 14:18:57 5:  CUL_HM set fl_Tuerschloss ?
2020.09.21 14:18:57 5:  CUL_HM set fl_Tuerschloss ?
2020.09.21 14:18:57 5:  CUL_HM set fl_Tuerschloss ?
2020.09.21 14:18:57 5:  CUL_HM set fl_Tuerschloss ?
2020.09.21 14:18:57 5:  CUL_HM fl_Tuerschloss protEvent:CMDs_done_Errors:1
2020.09.21 14:18:57 5:  CUL_HM set fl_Tuerschloss ?
2020.09.21 14:18:57 5:  CUL_HM set fl_Tuerschloss ?
2020.09.21 14:18:57 5:  CUL_HM set fl_Tuerschloss ?

Ich liefere gerne gezielte benötigte weitere Informationen, möchte jetzt hier jedoch nicht sofort die Details von allen Geräten listen.

Bin für jede Hilfe dankbar die AES Kommunikation wieder zum Laufen zu bringen.

Gruß
Dan

[frank]

mach zunächst erneut fhem update, wegen der verbesserungen von gestern.

dann zeig je ein list von keymatic, vccu und beiden hmuart.

actiondetector sollte funktionieren, also noch ein list eines dead fk.

[DeeSPe]

Erneutes Update ist gemacht.

Nach dem Neustart waren natürlich erst mal alle Geräte im ActionDetector auf "alive". Einige Zeit später begannen die ersten wieder "dead" zu melden.

DATEN ENTFERNT!

Gruß
Dan

[frank]

1. setze in der vccu das attr IOgrp
alle devices, real oder virtuell, benötigen beide attribute IODev und IOgrp.

2. um timing probleme wegen wifi auszuschliessen, setze jeweils HMUART als prefered io.

3. weder bei vccu noch bei den ios ist ein attribut für den eigenen aes key zu sehen.

4. ich denke, du hast ein aes problem, siehe aes readings.
für bestimmte aes funktionen wird ein zusätzliches perl modul benötigt.
falls notwendig, ist das eventuell beim updaten "verloren" gegangen?

[DeeSPe]

Hallo Frank,

vielen Dank für Deine Hilfe vorab.

Ich habe nun in der VCCU sowie an allen HM-Geräten das Attribut "IOgrp" auf "VCCU:HMUART,HMWIFI" gesetzt, damit sollte ja HMUART das prefIO sein, richtig? Leider hat sich damit an der Kommunikation bisher nichts verändert.
Wie schon im ersten Beitrag geschrieben habe ich (soweit ich weiß) keinen hmKey vergeben, Wird der außer in dem Attribut evtl. noch woanders gespeichert? Wenn nein, gibt es einen default-hmKey?

"libcrypt-rijndael-perl" ist installiert und aktuell. Und ja, ich bin mir auch sicher dass ich ein AES Problem habe. Nur woher kommt das auf einmal!? Bis zu meinem Malheur mit der Aktualisierung lief doch alles jahrelang problemlos.

Gruß
Dan

[frank]

da das reading aesKeyNbr=02 ist, wurde der erste eigene key gefordert. beim default key, den fhem kennt, wäre aesKeyNbr=00.

bei der keymatic ist der timestamp auch aktuell.
beim fk ist der timestamp allerdings älter.

wenn du noch nie einen key gesetzt hast, sieht das nach einem unlösbaren problem aus.

wieviele devices zeigen den keyNbr02?
hattest du vielleicht mal ein 3. io mit gesetztem key?

[DeeSPe]

Hier mal alle Geräte mit gesetztem Reading aesKeyNbr und deren TimeStamps:

Code Auswählen Erweitern

AA                   2018-01-13 20:34:56    00
AA_RC                2018-01-14 16:39:31    00
VCCU                 2020-09-22 21:08:04    00
bz_Fenster           2019-12-07 13:19:12    02
bz_RM                2018-03-10 12:10:42    02
db_Tuer              2018-05-06 21:38:42    02
dz_Fenster           2019-03-06 00:16:15    02
ez_Fenster           2018-01-13 20:57:56    02
fl_FB_Tuer           2018-01-14 16:40:33    00
fl_RM                2018-01-13 20:35:43    00
fl_Tuer              2018-01-13 21:02:23    02
fl_Tuerschloss       2020-09-22 16:36:41    02
iz_Fenster1          2018-05-06 19:37:06    02
iz_Fenster2          2018-05-06 19:38:02    02
ku_Tuer              2018-01-13 21:04:46    02
wz_Fenster1          2018-01-13 21:08:06    02
wz_Fenster2          2018-01-13 21:08:54    02
wz_Fenster3          2018-01-13 21:06:42    02
wz_RM                2018-01-13 20:35:58    00

Da sind wohl die meisten der Devices mit 02 gesetzt, aber nicht alle. Besonders komisch sind die Rauchmelder (RM), denn die wurden alle am gleichen Tag eingerichtet und nur einer zeigt den Wert 02.

Ursprünglich wurde in dieser Installation ein anderes IODev benutzt, auch ein HM-MOD-UART. Kann mich leider nicht mehr erinnern warum ich das abgelöst hatte.
Ich kann mich aber irgendwie dunkel erinnern dass ich bei der Ablösung dann die VCCU definiert hatte. Hatte ich da wirklich vergessen den hmKey mit zu übertragen? Sieht wohl ganz so aus. Und nun?

Ich frage mich auch immer noch woher die Probleme auf einmal kommen wenn vorher alles okay war.

Gruß
Dan

[DeeSPe]

Ich habe heute meine sehr alten Backups rausgekramt und mit einem grep durchsucht und tatsächlich eins gefunden in dem ein "hmKey" an einer VCCU gefunden wurde.
Diesen "hmKey" habe ich meiner VCCU nun hinzugefügt und siehe da, es scheint der richtige zu sein. Die KeyMatic öffnet und schließt nun wieder und auch die FKs kommunizieren wieder und bestätigen das auch mit grünem Blinken.

Bleiben nur die Fragen offen warum der hmKey mal verschwunden ist und vor allem warum sich das so lange nicht ausgewirkt hat!?
Ich setzte das Thema erst mal auf gelöst. Falls sich neue Erkenntnisse ergeben werde ich diese hier noch ergänzen.

Bin jedenfalls froh dass es nun wieder läuft und bedanke mich herzlich bei Dir Frank für Deine Hilfe, ohne die ich wohl noch immer nach dem Problem suchen würde. Es hilft wirklich ungemein wenn jemand mit guter Erfahrung mal auf die Konfiguration schaut.

Und wieder einmal zeigt sich dass ein (gutes) Backup unerlässlich ist.

Gruß
Dan

[frank]

na dann,  glückwunsch. 

Und wieder einmal zeigt sich dass ein (gutes) Backup unerlässlich ist.

zb eine klassische, analoge sicherung auf einem zettel, den man auch immer findet. 

Bleiben nur die Fragen offen warum der hmKey mal verschwunden ist und vor allem warum sich das so lange nicht ausgewirkt hat!?

ist dein fhem eventuell ewig lange ohne restart gelaufen?
der key wird zumindestens beim restart auf die ios verteilt. fraglich, ob beim löschen des attributes hmKey der key in den ios zurückgenommen wird.