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.
Thanks for clarifying that. That's what I understood in the end.
That seems to me to be the better approach. However, I am not knowledgeable enough in this area.
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.
@Bebbi have you seen this? luci-app-wifischedule
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.
I want to keep it simple and understand OpenWRT better.
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?
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.
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.
I don't want to turn off the entire Wi-Fi, just Radio1.
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.
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.
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.