Turn off the 2.4 GHz Wi-Fi overnight

[Bebbi]

@RuralRoots

• What days and hours do you want Radio0 to become disabled/un-available.
• What days and hours do you want Radio0 to become enabled/available.

Radio1 should be turned off daily at 11 p.m. From Monday to Friday, it should be turned on at 8 a.m. On Saturdays and Sundays, it should be turned on at 10 a.m.

[Bebbi]

@kz2o84a3m

Take note that the command will not run if the router is down during the cron run time.

Thanks for clarifying that. That's what I understood in the end.

@kz2o84a3m

Probably is better to build an idempotent script that when run check the clock and set the wifi state. Put that on the cron and on the startup list, and you should be fine.

That seems to me to be the better approach. However, I am not knowledgeable enough in this area.

[RuralRoots]

See the post above in response to @Ramon
if you are using LuCI delete the content in System/Scheduled Tasks and paste this:

#Start Wi-Fi Weekday
00 08 * * 1-5 uci set wireless.radio1.disabled='0'; uci commit wireless; wifi reload; logger -s "WIFI ON" "Radio1 enabled"
#Start Wi-Fi Saturday, Sunday
00 10 * * 6,0 uci set wireless.radio1.disabled='0'; uci commit wireless; wifi reload; logger -s "WIFI ON" "Radio1 enabled"
#Stop Wi-Fi Daily
00 23 * * * uci set wireless.radio1.disabled='1'; uci commit wireless; wifi reload; logger -s "WIFI OFF" "Radio1 disabled"

Save it. Then go into terminal and enter service cron reload to restart cron with this schedule. You will find the same content in terminal cat /etc/crontabs/root

Check the system log in terminal after 8am or 10am (depending on day/wknd) by issuing logread -e root: and you should see the radio1 down and up status.

What you missed was needing the wifi reload that mimics the Save/Apply button in Network/Wireless/Radio Disable/Save and Apply.

[kz2o84a3m]

@Bebbi have you seen this? luci-app-wifischedule

[Bebbi]

Thanks for your overview of the scenarios. That's how I understood it too. Regarding the last point: a manual restart during the day would also be a problem.

You're right. I couldn't create that.

[Bebbi]

I want to keep it simple and understand OpenWRT better.

[Bebbi]

Basically, it works in normal operation. Therefore, I'm not entirely sure what this adjustment is supposed to be good for. “Wifi reload” is only necessary if you've just changed something, right?

[RuralRoots]

@Bebbi

“Wifi reload” is only necessary if you've just changed something, right?

Exactly! LuCI does that when you “Disable” or change an interface in the WiFi section and then click “Save/Apply.

In CLI/ssh if you issue the wifi --help command it will return:

Usage: /sbin/wifi [config|up|down|reconf|reload|status|isup]
enables (default), disables or configures devices not yet configured.

The reload argument tells wifi to re-read and use the most current configuration for wireless, That will also restart the wireless. You can read about the ‘wifi` command and it various arguments in the wiki.

@Bebbi

Regarding the last point: a manual restart during the day would also be a problem.

Unlikely given the timings (aka “race issues”). OpenWrt by default will use Network Time Protocol (ntp) to acquire current time for your system right after init. Cron only relies on your current internal system clock, so a simple manual restart really would not be a problem.

[Bebbi]

I don't want to turn off the entire Wi-Fi, just Radio1.

[Bebbi]

But why write the command “wifi-reload” in the configuration file under LuCI? You enter that in the console if you have changed the configuration file there. In LuCI, you press the Save button.

I didn't think that through: Cron commands are not repeated if the device was not active at the time. But once they have been executed, the settings are set and remain unchanged after a restart.

[RuralRoots]

@Bebbi

But why write the command “wifi-reload” in the configuration file under LuCI? You enter that in the console if you have changed the configuration file there. In LuCI, you press the Save button.

Let's be clear here, Cron is a system utility. Its role is to execute the commands you tell it to run at the date and time you tell it to do so. Cron doesn't give a turd what you have told it to do, it just sends the commands to do it. It is no longer relevant to anything once it has done its thing.

I didn't think that through: Cron commands are not repeated if the device was not active at the time. But once they have been executed, the settings are set and remain unchanged after a restart.

Yes they will. Without fail, cron will issue the commands expected at their specified time. That's it. Cron did it's job - set radio1 status to disable/enable, save that status in memory via commit then restart the changes to the wifi configuration it made to reflect the current device status (off/on). Two disparate systems working in synchronicity to accomplish your wants.

[Bebbi]

@RuralRoots

Cron did it's job - set radio1 status to disable/enable, save that status in memory via commit then restart the changes to the wifi configuration it made to reflect the current device status (off/on). Two disparate systems working in synchronicity to accomplish your wants.

Now I understand the commands better. Thank you.

[Bebbi]

Summary of the solution:

00 08 * * 1-5 uci set wireless.radio1.disabled=0; uci commit wireless; wifi

00 10 * * 0,6 uci set wireless.radio1.disabled=0; uci commit wireless; wifi

00 23  * * * uci set wireless.radio1.disabled=1; uci commit wireless; wifi

First number: minute

Second number: hour

1-5: Monday to Friday; 0,6: Saturday and Sunday

This is followed by the command that Cron executes at the specified times when the system is running. The command is no different from the command entered on cli.

“uci set wireless.radio1.disabled=X” (0=wifi on, 1=wifi off). “uci commit wireless” writes this to the configuration file. “wifi” restarts the wifi module, which then uses the modified configuration file.

[kz2o84a3m]

This script will set the Wi-Fi to the correct state. Could be schedule to run periodically (like 10/10 minutes), that way the router will converge to the desired state even if it shutdowns at some point.

#!/bin/sh

WIFI_DEVICE=radio1

CURR_HOUR=$(date +%H)
CURR_DAY=$(date +%u)

# Logic for start hour
if [ "$CURR_DAY" -le 5 ]
then
    START_HOUR=8
else
    START_HOUR=10
fi

# Logic for end hour
END_HOUR=23

# Determine if Wi-Fi should be ON (0) or OFF (1)
if [ "$CURR_HOUR" -ge "$START_HOUR" ] && [ "$CURR_HOUR" -lt "$END_HOUR" ]; then
    TARGET=0
else
    TARGET=1
fi

# Get state from config, default to 0
CURRENT=$(uci -q get wireless.$WIFI_DEVICE.disabled || echo 0)

# Apply changes, only if needed
if [ "$CURRENT" != "$TARGET" ]; then
    uci set wireless.$WIFI_DEVICE.disabled="$TARGET"
    uci commit wireless
    wifi
fi

[mstojek]

00 08 * * 1-5 uci set wireless.radio1.disabled=0; uci commit wireless; wifi

00 10 * * 0,6 uci set wireless.radio1.disabled=0; uci commit wireless; wifi

00 23 * * * uci set wireless.radio1.disabled=1; uci commit wireless; wifi

Why you are using “wifi” command instead of “wifi reload”?

[sammo]

You can just issue command wifi down radio0 or wifi down radio1 depend which radio 2.4Ghz on. Using uci writes to the flash and wear it down overtime. Also issue wifi or wifi reload interrupts the other radio. To turn it back on, wifi up radio0

[RuralRoots]

I agree with you here:

@sammo

You can just issue command wifi down radio0 or wifi down radio1 depend which radio 2.4Ghz on.

That is why I pointed out the `wifi --help’ prompt, at least twice.

@sammo

Using uci writes to the flash and wear it down overtime. Also issue wifi or wifi reload interrupts the other radio.

I disagree here though. Yes uci changes write to flash, but typical consumer routers are really not likely to exhibit flash failure under normal lifetime, including this cron commands minimal daily writes.

I am not seeing any evidence that my other radio is interrupted from looking at my syslog.