You can change settings in luci or directly in /etc/config/system
Blinking generally means data. You can change that to link. If you change in luci it is quite obvious
The above commands allow a cron job to turn the lights on and off by schedule. Before when executing the commands the lights would return to normal operation with */5 6-20 * * * find /sys/devices/platform/leds-gpio/leds ! -path ‘usb’ -name brightness -exec sh -c ‘echo 255 > {}’ ; && /etc/init.d/led start. Now the light return to just solid with no blinking for data activity.
Can’t see how anything in /etc/config/system will resolve that. Please provide an example on how to turn the LEDs on and off via cron like in the previous firmware
@frameslip which product/model do you have exactly?
Interesting. Works here for all LEDs with a GL.iNet White (AR-150 with firmware 3.201-release). However, I did not delete the existing action but instead created a new action for each LED. As trigger, I selected ‘none’ and kept the ‘default state’ unchecked = off. Consequently, I succeeded solely with the help of LuCI; I did not need the command-line interface at all.
@GL.iNet this is a favorite request. Why not adding a ‘LED timeout after five minutes’ or ‘LED off after fully started’ checkbox to your own Web interface? Many—all?—other manufactures have this option, some for more than a decade. Some even offer both options and allow to configure the timeout.
@GL.iNet the default action has a trigger on ‘phy0tpt’ but it’s LED is named ‘orange:wlan’. This is a bit confusing because what is this ‘orange’? I was not even able to create the very same action if I accidentally deleted it. Is that ‘orange’ intended and correct?
It is an AR750S. It is set up as a cron job so that lights are turned off at night then turned on at day automatically without manually using the web interface. This worked on the 3.1 firmware.
In some recent models you can turn the LED off via smartphone app. Better not to use some automated settings. It is quite easy to be confused if the router is actually working or not.
You need to change as the path changed.
# leds off
*/5 21-23,0-5 * * * find /sys/devices/platform/leds/leds \! -path '*usb*' -name brightness -exec sh -c 'echo 0 > {}' \;
# leds on
*/5 6-20 * * * find /sys/devices/platform/leds/leds \! -path '*usb*' -name brightness -exec sh -c 'echo 255 > {}' \; && /etc/init.d/led start
As I said in my previous post, I tried that:
Text from above:
“I had changed the file path to reflect the new file structure. The lights turn off, but when turn back on they are solid not blinking. A restart of /etc/init.d/led start has no effect.”
The lights never resume their normal functionality, just come back on solid. System needs to be rebooted to restore functionality
These commands worked with 3.1
Which ones exactly?
Why was that added?
That is the reason other manufacturers wait until everything is started and then apply a timeout for the LEDs. Because users are used to power-cycle a device in case something is wrong, there is not even a problem seeing that it does not work. However, in case of known failure, the LEDs lid of course. Did you create a feature request internally?
Is function, thx.
i put this in System-Schedule Tasks and reboot.
System: GL-MT300N-V2
# leds off
*/5 21-23,0-5 * * * find /sys/devices/platform/leds/leds \! -path '*usb*' -name brightness -exec sh -c 'echo 0 > {}' \;
# leds on
*/5 6-20 * * * find /sys/devices/platform/leds/leds \! -path '*usb*' -name brightness -exec sh -c 'echo 255 > {}' \; && /etc/init.d/led start