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]

aesCommToDev    failangezeigt.

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