OAK4 LED control with python API

RyanPaesschesooneVintecc

We were wondering if in the future, the control of the LED light could be done programmatically at runtime. I have found this solution (not tested yet) on the forum but I'm wondering if this will ever be Implemented in the python API.

In our custom application we would like to control the LED to show the status of the system and flash if the system is in error like communication issues.

If this feature is planned, when will this be released?

Kind regards

Ryan

Oskar-Luxonis

Hey RyanPaesschesooneVintecc - at runtime, the current way to control the OAK4 status LED is to write to /dev/status_led from code running on the device. For example:

echo "255,255,0,0" > /dev/status_led   # red
echo "255,0,255,0" > /dev/status_led   # green
echo "255,0,0,255" > /dev/status_led   # blue
echo "0,0,0,0" > /dev/status_led       # off

For an OAK App, you can expose this device in oakapp.toml:

required_devices = ["/dev/status_led"]

allowed_devices = [{ allow = true, access = "rwm" }]

Then your application can update the LED based on system state, communication errors, etc.

There is also an example using a DepthAI Script node here:
luxonis/oak-examplesblob/main/neural-networks/speech-recognition/whisper-tiny-en/utils/led_changer_script.py

Regarding a dedicated high-level DepthAI Python API for this, I don’t have a confirmed release timeline at the moment, so I wouldn’t want to promise an ETA. For now, /dev/status_led is the recommended approach.

Best,
Oskar

RyanPaesschesooneVintecc

Hi Oskar,

Could it be that the first value in the list does nothing. I assumed this was a brightness value but this is not.

To create effects like pulsing or blinking I change the RGB values in the correct ratio to keep the colour but lower the intensity.

Is this intended behaviour?

Kind regards

Ryan

Oskar-Luxonis

Hey RyanPaesschesooneVintecc - yes, your observation is correct: the first value is not a brightness value.

It is used as an alpha/override value for blending between the normal user LED control path (/dev/status_led) and the root/system LED control path (/dev/status_led:root). In practice, for user applications writing to /dev/status_led, you should control brightness/pulsing by scaling the RGB values, as you are already doing.

So for effects like blinking or pulsing while keeping the same color, changing the RGB values proportionally is the right approach.

Best,
Oskkar