I'm a new owner of a TP-LINK Archer C7v2 with a newly installed LEDE firmware on it.
Excuse me if I ask noob questions.
I'm wishing to switch off all of the leds at night.
I've seen that LEDE provides a fine control of the leds but not a global on-off (as is done for wifi). Should I write a script myself and schedule its execution through cron? I'm wondering if someone already wrote such scripts and shared it somewhere.
A naif switch off script would be a sequence of lines
Depending on how you have the lights controlled, they likely will turn themselves back on again when the "trigger event" happens.
I'd look at using uci to control the trigger for the LEDs in your script. On my Archer C7 some are system.led_* and some of the other ones are system.@led[N]. The trigger property is likely the one you would want to change. Some of the others may "come and go" as the trigger changes, so you may need to re-add them when "turning on again".
@jeff Thank you for your prompt answer.
Googling around I've seen a post (related to GPIO controllable LEDS) that states that both brightness and triggers should be modified as follows
#!/bin/sh
for p in `find /sys/devices/platform/leds-gpio/leds -name trigger`
do
echo none > $p
done
for p in `find /sys/devices/platform/leds-gpio/leds -name brightness`
do
echo 0 > $p
done
There are already "triggers" available within OpenWRT to "make the LED do something useful" that are controlled at a higher level than the device-level triggers. They can be set through /etc/config/system or by making the proper uci calls (rather than directly editing the file and reloading the settings).
I think what you're trying to do is:
Save whatever the current trigger is ("on 2.4 GHz activity")
Change the trigger to "none" with default being off
then sometime later
Restore the previously saved or otherwise configured "trigger" and its parameters
As far as I understand the led script reads the system configuration file and sets the led brightness and triggers accordingly. But my system configuration file contains only a few led definitions (2 wifi leds and 2 usb leds). This is actually consistent with what is written in the wiki user guide about leds: this section of the system configuration file only controls non standard leds. The other ones (such as the power or network ones) are described in the developer section, but i've not been able to find them.
I tried to grep into all the /etc/ configuration files looking for leds but I did not succeed.
Where are other leds configuration files located?
Maybe there is a standard behavior which is overridden by the content of the system configuration file? I.e some process initializes leds at startup and after that the led script starts? But if this is true i should restart that process in order to recover normal operations.
Depending router model - not all led can be switched. Sometimes power, network etc is hardware controlled, you cannot use it. All leds you can use are located in /sys/class/leds.
I believe all of the LEDs on the Archer C7 can be controlled to some extent. The two on the back, power, the two wireless, and the "yin-yang" are the most flexible. The ones associated with the switch have a few peculiarities as a result, such as having a "flasher" built in.
Your can add the UCI sections to /etc/config/system by hand or through LuCI. You can name them for UCI as makes sense to you.
An addition if someone wants to accomplish the same as me: I just wanted the leds off.
Added the lines posted by @lionhe1966 to a script /root/leds_off.sh (don't forget to chmod +x /root/leds_off.sh) and added the following to /etc/rc.local:
cat /etc/rc.local
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
# wait for the defined time, then execute script
( /bin/sleep 5m && /bin/sh /root/leds_off.sh )&
exit 0
This way, I still see the leds after an intentional reboot and they are gone after 5 minutes..
why sleep:
because when I reboot, I may want to see some status lights (re-plugging ethernet cables, see if wifi is connected/has traffic, whatever).
why the & at the end:
because -as far as my understanding of the /etc/rc.local script goes- the commands get executed in order and the router would wait for the commands to finish before proceeding. The & at the end sends the command to the background and the script can continue.
The () around all commands have the effect, that everything inside these brackets get "treated as one command" which is sent to background (a separate shell gets spawned) - again, maybe my understanding is wrong. @any_Linux_expert: feel free to correct these statements.
why not cron:
because it is a one-time event in my case - I want the script executed once at one time after boot. I can simply comment the /etc/rc.local line and can run it later if I want the LEDs as they get initialized bacause I dont touch the default configuration.
why not UCI or LUCI:
because not every LED is defined there (e.g. the power led, at least for the TP-Link Archer C7)
The script posted by @lionhe1966 is independent of the router model, because it simply walks through every possible LED (on a level which is closer to hardware than luci or uci).
Unfortunately the above mentioned code does not work on Archer C7 v2 / v5 on OpenWrt 19.07.3 .
for p in `find /sys/bus/platform/drivers/leds-gpio/leds -name trigger`; do echo none > $p ; done
for p in `find /sys/bus/platform/drivers/leds-gpio/leds -name brightness`; do echo 0 > $p ; done
I've also tried to use this line: for i in /sys/class/leds/* ; do echo 0 > "$i"/brightness ; done
It turns all LEDs off except the main power LED and the five LAN/WAN LEDs. Any ideas?
According to another topic I'm missing the following LEDs in the "/sys/class/leds" path:
#!/bin/sh
for p in `find /sys/devices/platform/leds/leds -name trigger`
do
echo none > $p
done
for p in `find /sys/devices/platform/leds/leds -name brightness`
do
echo 0 > $p
done
