HmIP-BROLL: CONFIG_PENDING permanently stuck after device configuration with OpenCCU 3.89.11.20260919

[pretschner-art]

HmIP-BROLL: CONFIG_PENDING permanently stuck after device configuration with OpenCCU 3.89.11.20260919

Environment

• OpenCCU: 3.89.11.20260919
• Platform: Raspberry Pi 3 Model B Plus Rev 1.3 (rpi3)
• CPU: Cortex-A53, 4 cores
• RAM: 941 MB
• OS: Buildroot 2026.08 / Linux 6.18.34 aarch64
• ReGaHss: R1.00.0388.0254
• Java: 21.0.12.1
• RF module: RPI-RF-MOD
• RF module firmware: 4.4.22
• RF device node: /dev/raw-uart
• HmIP duty cycle at time of diagnostics: 13 %
• HmIP CarrierSense: 1 %
• HmIP device type affected: HmIP-BROLL
• HmIP-BROLL firmware: 1.10.16
• More than 12 HmIP-BROLL devices are installed and normally operating on this CCU.

I suspect that this might be a regression related to a recent OpenCCU update, but I cannot confirm that yet.

Problem

Two HmIP-BROLL devices are now permanently reporting CONFIG_PENDING.

The interesting point is that both devices started showing this condition after accessing their device configuration in the WebUI.

Affected devices:

• 001118A9A75D9C – configuration was intentionally changed.
• 001118A9A75D9E – configuration was opened for comparison; no intentional change was made.

The .dev persistence files of both devices were modified within approximately two minutes of each other during these configuration operations.

All other HmIP-BROLL devices continue to work normally.

Device operation still works

Both affected devices remain fully reachable for normal operation:

• physical wall buttons work;
• shutter up/down commands from the WebUI work;
• configuration can be read;
• there is no UNREACH service message.

However, configuration transfer fails and CONFIG_PENDING remains permanently active.

The WebUI eventually reports a connection error when trying to complete/retry the configuration transfer.

Attempts to clear the condition

The following did not resolve the problem:

• restarting OpenCCU;
• electrically power-cycling the affected BROLL;
• retrying/checking the pending configuration through the WebUI.

The condition survives both CCU restart and device power cycle.

HMIPServer confirms CONFIG_PENDING

This is not just a stale ReGa service message.

A direct XML-RPC getValue against HMIPServer on port 32010:

getValue("001118A9A75D9E:0", "CONFIG_PENDING")

returns:

<boolean>1</boolean>

getServiceMessages() directly from HMIPServer reports exactly two active service messages:

001118A9A75D9C:0  CONFIG_PENDING  true
001118A9A75D9E:0  CONFIG_PENDING  true

There are no corresponding UNREACH messages.

Configuration can still be read

For example,

getParamset("001118A9A75D9E:0", "MASTER")

returns the expected configuration values.

getParamsetDescription() also works.

The device description is returned normally:

TYPE:                  HmIP-BROLL
SUBTYPE:               BROLL
ADDRESS:               001118A9A75D9E
FIRMWARE:              1.10.16
AVAILABLE_FIRMWARE:    1.10.16
FIRMWARE_UPDATE_STATE: UP_TO_DATE

Therefore basic communication between HMIPServer and the device appears to be functional.

restoreConfigToDevice fails inside HMIPServer

I tried the official XML-RPC recovery operation directly against 127.0.0.1:32010:

<methodCall>
  <methodName>restoreConfigToDevice</methodName>
  <params>
    <param><value><string>001118A9A75D9E</string></value></param>
  </params>
</methodCall>

HMIPServer responds:

faultCode:   -1
faultString: Generic error

I verified the call against /www/tools/devconfig.cgi, which uses exactly:

xmlrpc $url restoreConfigToDevice [list string $device]

So this appears to be an error returned internally by HMIPServer rather than an incorrectly constructed XML-RPC request.

clearConfigCache fails in the same way

I also tested:

clearConfigCache("001118A9A75D9E")

HMIPServer again returns:

faultCode:   -1
faultString: Generic error

The implementation in /www/tools/devconfig.cgi confirms the expected call:

xmlrpc $url clearConfigCache [list string $device]

Thus both official recovery operations fail for the affected device:

restoreConfigToDevice → -1 Generic error
clearConfigCache      → -1 Generic error

crRFD persistence

The current configuration contains:

Persistence.Home=/etc/config/crRFD/data

The corresponding persistence files are:

3014F711A0001118A9A75D9C.dev
3014F711A0001118A9A75D9E.dev

They contain Kryo-serialized PersistentDeviceConfiguration / PersistentDeviceLinkConfiguration data.

I did not modify these files manually.

No separate obvious transaction or CONFIG_PENDING persistence object could be found under /etc/config/crRFD.

Observation / possible regression

The unusual part is that normal device communication continues to work while configuration synchronization appears to be stuck inside HMIPServer.

Since:

1. only two of more than 12 HmIP-BROLLs are affected;
2. both became affected immediately after their configuration pages were used;
3. one of them was only opened for comparison;
4. normal shutter communication still works;
5. HMIPServer itself reports CONFIG_PENDING=true; and
6. both restoreConfigToDevice and clearConfigCache fail internally with -1 Generic error,

I suspect that this could be a regression in the configuration/transaction handling of the current OpenCCU/crRFD stack.

The problem is currently observed with OpenCCU 3.89.11.20260919.

I cannot yet confirm whether an earlier OpenCCU version would clear or avoid the problem.

Question

Is this a known issue with the current OpenCCU/crRFD version?

In particular, is there a safe way to reset/recover the stuck HmIP configuration transaction without deleting and re-pairing the HmIP-BROLL?

I can provide additional XML-RPC output, persistence information, or perform targeted tests on 001118A9A75D9E, since this device had no intentional configuration change and can therefore be used as the test device.