1

I'm presently trying to use the built-in indicator lights on the Raspberry Pi B+ to provide status: Green = OK; Red = Problem

After turning off the triggers (writing none to /sys/class/leds/led[0,1]/trigger) I update the LED using the following java code:

    FileWriter fw = new FileWriter(brightnessFile);
    String writeString = isOn?"255":"0";
    fw.write(writeString);
    fw.close();

However, I am noticing situations where the program has written 255 to the brightness file (e.g. /sys/class/leds/led0/brightness ) but the LED is not illuminated. Similarly, if I read the value from /sys/class/leds/led0/brightness, it doesn't appear to correspond to the current status of the LED. E.g. the LED is not illuminated, but the value read from /sys/class/leds/led0/brightness is 255, etc.

Sometimes after seeing the issue, I might do the following in the shell:

sudo bash -c 'echo 255 > /sys/class/leds/led0/brightness'
sudo bash -c 'echo 255 > /sys/class/leds/led1/brightness'

which results in led1 going on, but led0 remains off (?!)

Alternating values seems to help however:

sudo bash -c 'echo 0 > /sys/class/leds/led0/brightness'
sudo bash -c 'echo 255 > /sys/class/leds/led0/brightness'

Is this a known bug? Is there a better way? - The more I read about pi4j (which also doesn't seem to support the onboard LEDs easily) and wiringPi, it appears that they use sysfs, which (correct me if I am wrong) would seem to be no different from what I am doing here. In addition to not being reliable, this method seems very slow.

Speculating to possible causes:

  • SD Card Wear (e.g. if the /sys/ filesystem also maintains a presence on the boot volume)
  • Power Supply (seems to be the most common answer to any kind of weird problem)
  • Hardware Damage (I will try with another board to see if I get the same thing)

Strangeness Examples:

pi@pitv:~ $ cat /sys/class/leds/led0/brightness
255
pi@pitv:~ $ sudo bash -c 'echo 0 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
0

(Okay)

pi@pitv:~ $ sudo bash -c 'echo 255 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
0

(Not Okay)

pi@pitv:~ $ sudo bash -c 'echo 255 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
0

(Not Okay)

pi@pitv:~ $ sudo bash -c 'echo 0 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
255

(Not Okay)

pi@pitv:~ $ sudo bash -c 'echo 255 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
255

(Okay)

pi@pitv:~ $ sudo bash -c 'echo 0 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
0

(Okay)

pi@pitv:~ $ sudo bash -c 'echo 255 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
0

(Not Okay)

pi@pitv:~ $ sudo bash -c 'echo 255 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
0

(Not Okay)

pi@pitv:~ $ sudo bash -c 'echo 255 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
0

(Not Okay)

pi@pitv:~ $ sudo bash -c 'echo 0 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
255

(Not Okay)

Just to illustrate that there is no other trigger interfering:

pi@pitv:~ $ cat /sys/class/leds/led0/trigger
[none] kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd- altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock timer oneshot heartbeat backlight gpio cpu0 cpu1 cpu2 cpu3 default-on input panic mmc0 mmc1 rfkill0 rfkill1 
pi@pitv:~ $ cat /sys/class/leds/led1/trigger
[none] kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock timer oneshot heartbeat backlight gpio cpu0 cpu1 cpu2 cpu3 default-on input panic mmc0 mmc1 rfkill0 rfkill1 
  • All the software and hardware modules are perfectly reliable. If you use them properly they produce the desired results. That being the case ... ? – joan Dec 4 '17 at 15:32
  • "this method seems very slow" -> Why, because you are using syscalls (open, write) with a kernel interface (sysfs)? How else do you propose to access hardware? ;) Admittedly, the other approach used on the pi, via mmap()ing hardware registers, is probably faster, but all of this is going to be sub-millisecond stuff either way. BTW, I believe wiringPi uses mmap() not sysfs. – goldilocks Dec 4 '17 at 16:29
  • 1
    "if the /sys/ filesystem also maintains a presence on the boot volume" -> No, it is RAM based. The linux kernel has a few of these kinds of language agnostic interfaces (/dev, /proc, /sys). – goldilocks Dec 5 '17 at 11:47
0

You are wasting your time trying to control the on-board LEDs.

They are controlled by kernel services, and additionally for the Red LED a hardware power monitor.

You CAN change their state, but the kernel will change them independently on its own schedule.

You can modify their behaviour, to a limited extent, by setting up the appropriate configuration in Device Tree.

  • I turned off the triggers by writing none to /sys/class/leds/led[0,1]/trigger... which I think (?) turns off the kernel services attached to the on-board LEDs. – xirt Dec 7 '17 at 2:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.