HM-Sec-SC-2 doesn't report status but battery

[soosp]

Describe the issue you are experiencing

The HM-Sec-SC-2 doesn't report it's STATE but the battery. So if you open the window the GUI status remains unchanged (closed). It was tested with two devices, communication is OK, but both of two don't report the STATE.

Describe the behavior you expected

The GUI device state should be changed.

Steps to reproduce the issue

1. Open the GUI -> Status and Control -> Devices -> a HM-Sec-SC-2
2. Open the window equipped with the corresponding HM-Sec-SC-2
3. Check the GUI state of HM-Sec-SC-2
   ...

What is the version this bug report is based on?

3.73.9.20240130

Which base platform are you running?

rpi3 (RaspberryPi3)

Which HomeMatic/homematicIP radio module are you using?

RPI-RF-MOD

Anything in the logs that might be useful for us?

The corresponding log entries:

# tail -f /var/log/messages | grep MEQ

Mar 12 08:25:31 ccu3 local0.info ReGaHss: Info: Event="MEQ1142620:1"."LOWBAT"=false [execute():iseXmlRpc.cpp:331]
Mar 12 08:25:33 ccu3 local0.info ReGaHss: Info: Event="MEQ1142620:1"."LOWBAT"=false [execute():iseXmlRpc.cpp:331]
Mar 12 08:25:52 ccu3 local0.info ReGaHss: Info: Event="MEQ1142599:1"."LOWBAT"=false [execute():iseXmlRpc.cpp:331]
Mar 12 08:25:55 ccu3 local0.info ReGaHss: Info: Event="MEQ1142599:1"."LOWBAT"=false [execute():iseXmlRpc.cpp:331]

### Additional information

[soosp]

Meanwhile I made more tests.

• The LED of sensors signs the open and close events, but RaspberryMatic doesn't detect it.
• If you remove a sensor from it's base, the error/saboutage event appears on the GUI so the communication is OK.

[jens-maus]

Sorry, but this can't be a general issue in RaspberryMatic since other (ten of thousands of other users) would immediately jump in here. In addition, I do have a HM-Sec-SC-2 myself and didn't notice a problem with it last time. Will try to reproduce, but I am 99% certain that this isn't an issue/bug really but rather points at some local issue in your installation only.

[PH89]

@jens-maus I can confirm exactly the same issue.

@soosp
This is what I did to make it working again:

1. Switched AES transmission back to standard. It was working fine.
2. Switched back to AES transmission. It was broken again.

Solution was to change the System-Security-Key (I was changing it already many years ago)
After reconfiguration of all my devices (AES-Key-Change) it was working again with encryption.

[jens-maus]

Thanks for the hint and testing.Perhaps @jp112sdl knows of this is an already known issue with the HM-Sec-SC-2 ?

[soosp]

@PH89 Thanks for this solution! Inspired by this, I tried an another fix:
I reset the devices to factory defaults by long pressing the config button (without removing them from RaspberryMatic), re-paired them as usual, and voila. They work again.
But unfortunately we still don't know what caused the malfunction.

[jp112sdl]

@soosp

I tried an another fix:
I reset the devices to factory defaults by long pressing the config button

This works even with a custom key? Actually the reset shouldn't work.
That's the reason why people often have problems with 2nd-hand-devices that are not completely removed with factory settings from the CCU of the original owner.

@jens-maus

Perhaps @jp112sdl knows of this is an already known issue with the HM-Sec-SC-2 ?

No, this is the first time I've heard of it for the HM-Sec-SC-2.
I believe the HM-Sec-SCo and/or HM-Sec-RHS sometimes has a similar bug, that can be solved by re-enabling AES.

But that it only works with a new key?
Hmm... I've never researched the challenge response procedure in detail.
From the AskSinPP project I know, that not only the aes key is necessary but also the key index.
Maybe not the key is broken in the EEPROM of the HM-Sec-SC-2 but the index?