Nach Update von 10_CUL_HM.pm keine AES-signierte Kommunikation mehr möglich

Begonnen von cthil, 17 August 2021, 15:15:40

Vorheriges Thema - Nächstes Thema

Beta-User

Restart liest alles von Grund auf, rereadcfg eben nur die Konfigurationsdaten neu ein, was bei einigen neueren Modulen dann auch zu inkonsistenten Daten führen kann.

Zu "never" habe ich mal irgendwo aufgegabelt, dass das eine Ausrede für faule Programmierer sei; maN. sind einigermaßen regelmäßige updates bei Systemen, die via Netzwerk zu erreichen sind, auf praktisch allen Ebenen Pflicht...
Blöd nur, dass das hin und wieder auch zu regressions führt.

Was updates angeht, wird sich Martin vermutlich schon irgendwann melden, wenn bzw. wie er das Problem ggf. dann gefixt hat.
Ansonsten kannst du ja vorab auch hier nochmal nachfragen, wenn du ein entsprechendes update angeboten bekommst und nicht anderswo her weißt, ob es eine gute Idee ist...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

@tango

Mit never meine ich eigentlich meine Script-Sammlung. Die würde ich ungern auf Perl oder FHEM Templates umstellen.
Da bin ich in der Tat zu faul. Da weiß ich was ich hab.
Mit (FHEM-, Raspi-, Windows-, etc) Updates strebe ich zeitnah immer einen aktuellen Stand an.

RASPI 4B, PI USV+, ext. SSD, ohne MicroSD
IO: CUL433,2xHMUART
HM, IT, Rev, AVM

@tango

RASPI 4B, PI USV+, ext. SSD, ohne MicroSD
IO: CUL433,2xHMUART
HM, IT, Rev, AVM