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 Erweitern

aesCommToDev    fail
angezeigt.

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