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.

[luedtkes-hub]

Thanks for the explanation — however it doesn’t really solve the issue from a user perspective.

The current behavior (permanently blinking blue LED) still looks indistinguishable from an error state and leads to unnecessary troubleshooting, because historically this indicated a problem.

If this behavior is now considered normal in the current firmware, it might be worth updating the documentation accordingly. Otherwise users will continue assuming a malfunction and start debugging network/RF issues that don’t actually exist.

At least in my case the system itself works fine, but the LED strongly suggests something is wrong.

I’m unfortunately not skilled enough in the OpenCCU internals to properly investigate the root cause — so from my perspective the main improvement would be clarification in the docs whether this blinking is expected behavior or not.

Till this is resolved, putting a black tape over the blue led resolves the issue :)

[jens-maus]

The current behavior (permanently blinking blue LED) still looks indistinguishable from an error state and leads to unnecessary troubleshooting, because historically this indicated a problem.

If this behavior is now considered normal in the current firmware, it might be worth updating the documentation accordingly. Otherwise users will continue assuming a malfunction and start debugging network/RF issues that don’t actually exist.

Sorry, I probably was not clear enough: Under normal circumstances and for other users the LED is not constantly blinking blue if there isn't any issue that results in hss_led letting the LED blink blue. Thus, there must be a reason in your specific installation / setup that causes the LED to constantly blink and this would require some investigation/debugging of yourself of course.

I’m unfortunately not skilled enough in the OpenCCU internals to properly investigate the root cause — so from my perspective the main improvement would be clarification in the docs whether this blinking is expected behavior or not.

Till this is resolved, putting a black tape over the blue led resolves the issue :)

Putting a black tape on the LED is not required, Just have a look at the "Extended Settings" part in the WebUI, There should be a WebUI setting to completly disable the LED if you don't need/trust it.

However, better would be of course to actually debug the root cause why your system seems to assume that letting the LED blink blue would be required. See here https://github.com/OpenCCU/OpenCCU/wiki/Administration#rpirfmod--ledstatuscodes for all possible explainations for the blinking codes. And if you read this table, then permanently blinking blue is definitely triggerd by some internet/connectivity issue. So your OpenCCU might not be able to completly/freely reach the internet and some firewall or similar might block its regulary internet check, I guess...

[jens-maus]

BTW: What you can also try is to execute checkInternet on the command-line (in a SSH session) and check what it returns. In my case it outputs that everything is fine, for example:

root@ccu:~# checkInternet 
Assuming internet connectivity: Could reach port 443 on google.com.

[luedtkes-hub]

Thanks. I should have mentioned this in the initial report:

1. Disabling the LED in Extended Settings → WebUI does not change the LED behaviour — it keeps blinking.

2. The internet connection works perfectly fine. Command outputs:

root@openccu:~# checkInternet
Assuming internet connectivity: Could reach port 443 on google.com.

root@openccu:~# date
Thu Feb 19 10:20:50 CET 2026

root@openccu:~# ping -c3 google.com
PING google.com (172.217.168.78): 56 data bytes
64 bytes from 172.217.168.78: seq=0 ttl=119 time=10.977 ms
64 bytes from 172.217.168.78: seq=1 ttl=119 time=10.795 ms
64 bytes from 172.217.168.78: seq=2 ttl=119 time=10.526 ms

Additional context: the blue LED started flashing immediately on a brand-new RPi3B with a new RPI-RF-MOD and the current firmware — i.e., straight out of the box, no modifications. Given that disabling the LED in the WebUI has no effect and checkInternet reports success, the blinking appears to be a false-positive indicator (or caused by a different check than checkInternet).

Could you confirm which exact check hss_led uses to decide on the blue blinking state (host/port/protocol/timeout)? If checkInternet is the canonical test, the LED should not be blinking when that command returns success.

Thanks!

[luedtkes-hub]

Further (with ChatGPT help) I performed a direct sysfs test on the RPI-RF-MOD LED.

echo none > /sys/class/leds/rpi_rf_mod:blue/trigger
echo 0 > /sys/class/leds/rpi_rf_mod:blue/brightness

Result: the blue LED immediately turned off - and stays off.
So the LED is clearly controlled from Linux userspace and not forced by the RF module firmware.

However:
The WebUI option to disable the LED has no effect
checkInternet reports success
The system works normally
The LED returns to blinking (trigger timer) after reboot.

Therefore something in OpenCCU continuously starts the timer trigger at boot although no error condition exists.
This suggests the issue is not connectivity related but a wrong LED state decision or a component that ignores the WebUI LED setting.

Which component is responsible for writing the trigger for
/sys/class/leds/rpi_rf_mod:blue/trigger?
I would like to trace what process keeps restoring the blinking state.

[jens-maus]

Which component is responsible for writing the trigger for /sys/class/leds/rpi_rf_mod:blue/trigger? I would like to trace what process keeps restoring the blinking state.

It is hss_led that is responsible for doing this (that's why it is actually named like that ;-)

So simply do a monit stop hss_led on the command-line to stop it. And then you can manually start it via:

hss_led -l 0 -c

And it should hopefully output something that explains why it feels the blue LED should blink.

[luedtkes-hub]

Thanks. Ok - guess we are getting closer :)
After rebooting the Led keeps flashing.
monit stop hss_led led keeps flashing.

root@openccu:~# hss_led -l 0 -c
2026/02/19 12:34:00.477403648 <Info> hss_led: Programm initialisiert.

No further messages.
Led keeps flashing.

I then disconnected the LAN cable and reconnected it after a while ...

2026/02/19 12:37:35.752211609 <Debug> Network::CheckNetState(): can't open hasLink file
Assuming internet connectivity: Could reach port 443 on google.com.

Led still flashing.

So the connectivity check detects the recovered connection, but the LED state does not change afterwards.

Is there supposed to be a state update after a successful connectivity check, or is the LED only set during initialization?

Edit:
Quick update with a new observation:
I disabled the LED via sysfs and it stayed off.
-> Unplugging the LAN cable did not make the LED light up.

When I plugged the cable back in, the blue LED started blinking again. Just reverse to what one would expect.

[jens-maus]

Then please start hss_led like:

strace hss_led -l 0 -c

And catch what it outputs over time and then post it here for investigation.

[luedtkes-hub]

log.log

ok - log attached. Grows pretty fast, hence sorry it is lengthy. Rather to its end (rows 700+) I disconnected the Network cable and reconnected it so that both states should be checked and do appear in the log. I had ChatGPT summarizing it but it did not reveal many insights other than that the cable reconnect was recognized and that the potential "disabledLed" and "/etc/config/hss_led_info.conf" Flag files are not present. Nothing that would explain the issue unfortunately.