Archer C7 v2 - Switching off all LEDs at night

Installing and Using OpenWrt
#1

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

cat 0 > /sys/class/leds/tp-link:green:qss/brigthness
...

while the following list should switch them on again

cat 255 > /sys/class/leds/tp-link:green:qss/brigthness
...

Am I on the right track or is there a smarter way to implement this "night mode"?

Thank you for your attention,
LionHe

#2

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".

https://openwrt.org/docs/guide-user/base-system/led_configuration

#3

@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

(taken from https://randomcoderdude.wordpress.com/2013/08/11/controlling-leds-status-in-openwrt/)

The problem is how to get them back.

#4

/etc/init.d/led start

1 Like
#5

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
#6

You could also put a small towel on top of the front.

#7

@Sunspark Actually, I would not know how to set a Cron schedule for the towel action :wink:

@cezary thank you for your hint

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.

Thank you again,
LionHe

#8

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.

#9

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.

#10

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..

#11

This script is unclear to me. Why sleep, why & at the end?
Why not use cron?

If you want them permanently off, why not set them to off using UCI or Luci?

#12

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).

1 Like
#13

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:

tp-link:blue:lan1
tp-link:blue:lan2
tp-link:blue:lan3
tp-link:blue:lan4
tp-link:blue:wan

Can those please be re-implemented? I recall I had those on a previous OpenWrt version, I think it was 14.04 Chaos Calmer.

1 Like