LED visual signaling suggestion for Armbian 5.x at H3

[y52]

I am using Armbian 5.x images on the Orangi PI plus box since it appeared as it is stable and the most complete.

 

root@orangepiplus:/usr/src/h3monitor# uname -a

Linux orangepiplus 3.4.110-sun8i #18 SMP PREEMPT Tue Mar 8 20:03:32 CET 2016 armv7l GNU/Linux

 

The LED visual board status is helpful during initial launching or headless usage.

 

There is currently only one RED light for all the board statuses.

It is somewhat confusing as for the Good running status. It is worth switching to GREEN, once the Armbian is loaded successfully and back to RED during the shutdown procedure. It is worth turning the red LED off after shutdown.

 

This LED behavior has been adopted on OpenELEC @ orangepi and is very convenient.

 

Could the LED visual algorithm be improved in the next Armbian 5.x images ?

[tkaiser]

Already done a few days ago. We'll use the green led with newer images to indicate 'power on', blink a few seconds after the boot to signal 'ready to login', switch to blinking when the board shuts off and turns off after successful shutdown.

 

The red led is only used on 1st boot to indicate that some automatisms are running that should not be interrupted. When the board is running it's up to you what to do with the leds since they're easily accessible from user space /sys/class/leds/)

 

Everything else won't be touched now since we either develop universal led behaviour for all boards or simply leave it as it is (now and as described above)

[y52]

Another remark for the 5.10 release is that boots significantly slower and the 1st phase of booting is not indicated by any LED (all off). It is very confusing, as one may think, that the boot doesn't run.

Personally, having no indication for long time during the 1st boot, I interrupted the boot process.

[mariuszb]

 

 

It's ok

 

Btw. Is this led are accesible from WiringOP c librarry ?

 

Already done a few days ago. We'll use the green led with newer images to indicate 'power on', blink a few seconds after the boot to signal 'ready to login', switch to blinking when the board shuts off and turns off after successful shutdown.

 

The red led is only used on 1st boot to indicate that some automatisms are running that should not be interrupted. When the board is running it's up to you what to do with the leds since they're easily accessible from user space /sys/class/leds/)

 

Everything else won't be touched now since we either develop universal led behaviour for all boards or simply leave it as it is (now and as described above)

[mariuszb]

Already done a few days ago. We'll use the green led with newer images to indicate 'power on', blink a few seconds after the boot to signal 'ready to login', switch to blinking when the board shuts off and turns off after successful shutdown.

 

The red led is only used on 1st boot to indicate that some automatisms are running that should not be interrupted. When the board is running it's up to you what to do with the leds since they're easily accessible from user space /sys/class/leds/)

 

Everything else won't be touched now since we either develop universal led behaviour for all boards or simply leave it as it is (now and as described above)

 

In rc.local :

 

echo heartbeat | sudo tee "/sys/class/leds/red_led/trigger"

it works.

 

if do the same with green_led works only a while.

It looks like something changed operation green_led after aprox 10 sec.

 

Works well if you set it manually moment later

[tkaiser]

In rc.local :

 

echo heartbeat | sudo tee "/sys/class/leds/red_led/trigger"

it works.

 

if do the same with green_led works only a while.

It looks like something changed operation green_led after aprox 10 sec.

 

Works well if you set it manually moment later

 

There's no need to use sudo in etc/rc.local since everything written in there is executed by root, so this will work

echo heartbeat >/sys/class/leds/*red*/trigger
(sleep 15 && echo none >/sys/class/leds/*green*/trigger) &

I replaced the absolute paths to the sysfs nodes with wildcards since with mainline kernel the sysfs nodes are called differently (so the example above will survive a kernel switch from 3.4.x to 4.x later!). And the second line leads to the green led defined after our armhwinfo script is finished (we try to let the green led blink for 10 seconds and define it then as 'default-on' -- solid light -- to indicate when the system is ready for login therefore the 15 seconds delay will lead to led behaviour overriden later).

 

To get the available values simply do a

cat /sys/class/leds/*red*/trigger

[mariuszb]

 

There's no need to use sudo in etc/rc.local since everything written in there is executed by root, so this will work

echo heartbeat >/sys/class/leds/*red*/trigger
(sleep 15 && echo none >/sys/class/leds/*green*/trigger) &

I replaced the absolute paths to the sysfs nodes with wildcards since with mainline kernel the sysfs nodes are called differently (so the example above will survive a kernel switch from 3.4.x to 4.x later!). And the second line leads to the green led defined after our armhwinfo script is finished (we try to let the green led blink for 10 seconds and define it then as 'default-on' -- solid light -- to indicate when the system is ready for login therefore the 15 seconds delay will lead to led behaviour overriden later).

 

To get the available values simply do a

cat /sys/class/leds/*red*/trigger

 

Thanks 

 

Only one thing:

the first two lines work , second two lines not   (Image from latest ( one week old) Armbian sources, Debian)

What could be the reason?

 

echo heartbeat | sudo tee /sys/class/leds/*red*/trigger
(sleep 15 && echo mmc0 | sudo tee /sys/class/leds/*green*/trigger) &

echo heartbeat >/sys/class/leds/*red*/trigger
(sleep 15 && echo mmc0 >/sys/class/leds/*green*/trigger) &

[shahidali55]

Does anyone know a way to make the green LED blink on SD card access ? I have already configured the Red LED to light up solid via u-boot so that happens within 3 seconds after power is connected. Now just needed a way to monitor SD card access visually, in real time . . .

[tkaiser]

Does anyone know a way to make the green LED blink on SD card access ?

 

What about using the information from the last postings from this thread? Putting this into /etc/rc.local

(sleep 15 && echo mmc0 >/sys/class/leds/*green*/trigger) &

[shahidali55]

Thanks tkaiser,

 

Adding the below line to /etc/rc.local makes the green LED behave as an activity LED indicating SD card access.

sleep 15 && echo mmc0 | tee "/sys/class/leds/green_led/trigger" >/dev/null 2>&1 &

Can this be done earlier in the boot process ? Maybe in u-boot ? Also, what other scripts mess around with the green LED on the desktop image of Armbian 5.14 ? The green LED goes back to "heartbeat" as soon as "sudo shutdown -h now" is issued

[tkaiser]

Adding the below line to /etc/rc.local makes the green LED behave as an activity LED indicating SD card access.

sleep 15 && echo mmc0 | tee "/sys/class/leds/green_led/trigger" >/dev/null 2>&1 &

 

Why that complicated? What's wrong with the following (when called from /etc/rc.local)?

(sleep 15 && echo mmc0 >/sys/class/leds/*green*/trigger) &

Green led behaviour is as intended ('grep green /etc/init.d/armhwinfo'). Maybe you can mess around in script.bin (with Armbian not read by u-boot but just the kernel) or kernel config to get different default behaviour. Just out of curiousity: What's the purpose of visual feedback when SD card is accessed?

[shahidali55]

Adding it as is into rc.local did nothing. However running it as root works (sudo su, then the command). Similarly adding it as is into led.sh and executing it via "sudo ./led.sh" exits with code 2. Only the complicated version seems to work correctly . . .

 

The reason I needed a visual indication of SD card access is to have a visual cue when players are active on my minecraft server hosted on the Orange Pi One.

 

I've modified three lines in "/etc/init.d/armhwinfo". Now the green LED behaves as required

 

Why that complicated? What's wrong with the following (when called from /etc/rc.local)?

(sleep 15 && echo mmc0 >/sys/class/leds/*green*/trigger) &

Green led behaviour is as intended ('grep green /etc/init.d/armhwinfo'). Maybe you can mess around in script.bin (with Armbian not read by u-boot but just the kernel) or kernel config to get different default behaviour. Just out of curiousity: What's the purpose of visual feedback when SD card is accessed?

[tkaiser]

Adding it as is into rc.local did nothing.

 

Then most probably I missed to add that any statement in /etc/rc.local should be added before to the last line that reads 'exit 0'. Adding stuff to /etc/rc.local has to work and since all code therein will be executed as root no fiddling with 'tee' is needed. You only need 'tee' when you directly call a bunch of commands in the shell.

 

So again, simply adding

(sleep 15 && echo mmc0 >/sys/class/leds/*green*/trigger) &

to /etc/rc.local prior to 'exit 0' will work as it should (using the *green* wildcard will also ensure that this stuff still works when you might switch to vanilla kernel later).

 

Thanks for mentioning a useful use case of setting the led trigger to 'mmc0' (I was curious since most people who ask this question fear wear-out of their SD cards and then it's a better idea to buy a good card instead of trying to avoid accesses to the card).

 

BTW: SD card accesses don't have to be related to any server task so in case this server task can be queried for connected users then it might be a better idea to set up a cron job running every minute and use the 'timer' trigger instead (as soon as you set this trigger two more pseudo-files appear as sysfs nodes -- delay_off and delay_on -- which you can use to define blinking behaviour in milliseconds for example based on count of connected users)