Status LED permStatus LED permanently blinking blue despite working network – hss_led error “UDP_CHANNEL: can't bind Port” on RPI-RF-MOD (OpenCCU)

[luedtkes-hub]

Describe the issue you are experiencing

Description

I am running OpenCCU on a Raspberry Pi 3Bs with an integrated
RPI-RF-MOD module. The device exposes a single multicolor status LED through
a light pipe in the enclosure.

According to the official OpenCCU documentation (Status-LED Function):

• Slow blue blinking = no network
• Fast blue blinking = no internet connection

However, the LED on my device always stays in blue blinking mode, even
though network connectivity is fully operational.

Symptoms

• LED blinks blue continuously.
• LED behavior does not change whether the LAN cable is connected or disconnected.
• OpenCCU WebUI works without problems.
• SSH works, ICMP ping works, DNS resolution works.
• LED never switches to any color (even on alarms, while Led is configured for that in WebUI
• Service/Alarm LED functions in “General Settings” have no effect at all.

Error from hss_led (SSH)

Running: hss_led -c
Produces:
hss_led: Program initialized.
UDP_CHANNEL: can't bind Port. err: -1

It appears the LED daemon cannot bind to its UDP port and therefore cannot
receive status updates from system components. This presumably results in
the LED falling back to a default blinking state.

Hardware / Setup

• Board: Raspberry Pi 3B within ELV HB-RF-RK-2 Case
• RF module: RPI-RF-MOD
• LED: Multicolor LED from the RPI-RF-MOD, forwarded via light pipe
• System: OpenCCU (latest release)
• Router: FritzBox 5590 Fiber
• IPv6 enabled/disabled → no change
• DHCP enabled/disabled → no change
• LAN connectivity confirmed (WebUI + SSH functional)

Describe the behavior you expected

Expected Behavior

• LED should correctly represent network/internet state as documented.
• LED should react to service and alarm messages based on Info-LED settings.

Actual Behavior

• LED always shows blue blinking, regardless of connectivity.
• LED does not react to service or alarm conditions.
• hss_led reports UDP bind errors.

Possible Cause

• LED subsystem (hss_led) fails to bind its UDP port
• LED mapping for RPI-RF-MOD on OpenCCU may not initialize correctly
• A process conflict or missing initialization step

Request

Could you please verify:

• Whether the UDP bind error is expected or a bug?
• Whether hss_led should fully support RPI-RF-MOD LED handling in OpenCCU?
• If the LED-mapping logic for RPI-RF-MOD devices might be broken?

I can provide additional logs or system dumps if required.

Thank you!

Steps to reproduce the issue

1. ssh
2. hss_led -c

3
...

What is the version this bug report is based on?

3.83.6.20251025

Which base platform are you running?

rpi3 (RaspberryPi3, ARM64/aarch64)

Which HomeMatic/homematicIP radio module are you using?

RPI-RF-MOD

Anything in the logs that might be useful for us?

hss_led: Program initialized.
UDP_CHANNEL: can't bind Port. err: -1

Additional information

No response

[luedtkes-hub]

Hi - thanks for checking in.
The issue remains with the latest software version with no improvement. Tested with 3.85.7.20260131 (rpi3)

[jens-maus]

Of course you are getting the

hss_led: Program initialized.
UDP_CHANNEL: can't bind Port. err: -1

error, because there is usually always a hss_led daemon running blocking the UDP port. So instead of trying to manually start the hss_led you need to stop the other first and then start it manually to see if the manually returns some information on why and which LED lights up.