Okey this was a long time request for myself, but since it was not made by somebody else, I took the callenge up by myself, with the help of some AI…
The plugin is called ‘ScheduledRestart’ and is awaiting approval from Volumio.
This is a screenshot:
You can select the time and day(s) for the scheduled restart.
In technical term, the schedule fires a cron job.
I tried my best to put in as many translations as possible.
Dear Sina, thank you for the great effort.
One request, Instead of using Cron, was there an issue not to take over the still robust working method described above and to connect it with a GUI like created by you? What was the intension to trigger the function with a Cronjob instead?
Cheers Korniman
@Korniman-the-Rooky I was just no able to get it to work with a system-reboot.timer. I tried to make an install script for a system-reboot.timer but I could not get the permissions right to do a reboot. Then I changed my approach to the system-reboot.timer firing a reboot script in the plugin directory, but it would stick in a reboot loop, no matter what I tried.
The method I’m now using is a very simple, but very effective one, so for now I’m sticking to node-cron.
Just a little more background information about ‘node-cron’ versus ‘reboot.service’.
Node-cron writes it schedule and command to the memory, here is the line of code in scheduledrestart:
var job = cron.schedule(cronTime, function() {
self.logger.info('Rebooting system as per schedule...');
exec('sudo reboot', (error, stdout, stderr) => {
if (error) {
self.logger.error(`Error executing reboot: ${error}`);
This causes the schedule to only stay persistent if Volumio is restarted correctly and the plugin with the schedule is reloaded into the memory. If you would power down unexpectedly or volumio would crash, you still could reboot and ‘ssh’ or get into the Volumio UI’. Also if the plugin is corrupt the system just keeps working.
The reboot service is handled by the systemctl-daemon and works outside of Volumio. This means that if the service has a problem, your system could become unusable and you can’t ‘ssh’ or get into the Volumio UI. The pro’s are it is working regardless of Volumio, but that’s also a risk, if the uninstall is not working as expected the deamon just keeps loading the service, untill you manually can stop it.
When I wrote the code and tried to use the service, I ended up with a system which kept on rebooting, I know this is due to my lack of knowledge, and had to reflash and reinstall Volumio multiple times, but when I used ‘node-cron’ and something was not correct, nothing happend.
In the end I could rewrite to use the reboot.service but I don’t see any advantage over using ‘node-cron’. Please let me know if you think that there are other pros or cons.
@balbuze yes I did, but I could not get it to work, which caused system reboot loops. That problem is being tackled by node-cron via the plugin.
Just to clarify ‘node-cron’ stores its action and schedule in the memory, cron on the other hand needs a cronjob file with the action and schedule. I could see why you would port cronjobs to system.d timers, but since I use ‘node-cron’, I don’t see any pros for this plugin. The fact that it is written to the memory is just a very good safeguard.
Okey beta version 0.7.1 of ScheduledRestart is released. To install it on Volumio go to your http://ip-of-volumio-instance/dev and set Plugins Test Mode to enable.
You could now install ScheduledRestart from plugins and then System tools.
If you set a new schedule and save it the log output should show something like this:
Today, I had time to test your new app for the first time.
Here are my findings:
First, I installed the plugin, activated it, and set the schedule timer.
The plugin successfully shut down the system as expected, but it did not reboot. The system remained off. I couldn’t check if any LEDs on the PCB were flickering because it is enclosed in a housing, but the external LED and display stayed off, and the network was not accessible.
Then, I manually disconnected the Raspberry Pi 4 from power, restarted the system, and set the timer again.
On the second attempt, the system successfully rebooted. Below are my logs from the properly working restart. Unfortunately, I don’t have logs from the failed attempt.
It seems that the system needs a refresh or internal update before it can restart properly.
Here are my settings:
System Information
OS info
Version of Volumio: 3.785
Hostname: v-bad
Kernel: 6.6.62-v7l+
Governor: performance
Uptime: 0 days, 0 Hrs, 15 Minutes, 1 Seconds
Network info
XXX
Audio info
Hw audio configured: HiFiBerry Amp
Mixer type: Hardware
Number of channels:
Supported sample rate:
Board info
Manufacturer: Raspberry Pi Foundation
Model: Raspberry Pi 4 Model B Rev 1.4 Raspberry Pi / 4B - 1.4 /
Version: b03114 / 4B - 1.4
Firmware Version: Nov 11 2024 15:48:13 version 903570ba72a9e117f92e5499de439f59dd96e417 (clean) (release) (start)
CPU info
Brand: BCM2711
Speed: 1.5 GHz
Family: Cortex-A72
Model: 3
Number of cores: 4
Physical cores: 4
Average load: 10%
Temperature: 47°C
Memory info
Memory: 1862756 Ko
Free: 1137000 Ko
Used: 725756 Ko
Software info
Mpd version: Music Player Daemon 0.23.15 (0.23.15)
Storage info
INTERNAL storage - Size: 4842Mo
Used: 566Mo
Available for storage: 4022Mo (83%)
Installed Plugins:
FusionDsp
Spotify
Schedule Restart
GPIO Buttons
GPIO Control
MPD OLED
Rotary Encoder II
System Information
Logs:
info: CoreCommandRouter::volumioGetState
info: CorePlayQueue::getTrack 0
info: CoreCommandRouter::volumioGetState
info: CorePlayQueue::getTrack 0
info: CoreCommandRouter::volumioGetState
info: CorePlayQueue::getTrack 0
info: CoreCommandRouter::volumioGetState
info: CorePlayQueue::getTrack 0
info: CoreCommandRouter::volumioGetState
info: CorePlayQueue::getTrack 0
info: CoreCommandRouter::volumioGetState
info: CorePlayQueue::getTrack 0
info: Rebooting system as per schedule…
volumio : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/sbin/reboot
pam_unix(sudo:session): session opened for user root by (uid=0)
Condition check resulted in Turns off Raspberry Pi display backlight on shutdown/reboot being skipped.
Stopping go-librespot Daemon…
received signal to exit (15)
Stopping MyVolumio SSH Tunnel…
Stopping MPD OLED Plugin…
systemd-rfkill.socket: Succeeded.
Closed Load/Save RF Kill Switch Status /dev/rfkill Watch.
Stopped target Graphical Interface.
Stopped target Multi-User System.
Stopped target Login Prompts.
Stopping Network Time Service…
ntpd exiting on signal 15 (Terminated)
Stopping UPnP Renderer front-end to MPD…
info: Connection to go-librespot Websocket closed
195.201.20.16 local addr 192.168.. →
Stopping Volumio Log Rotation Service…
185.207.105.38 local addr 192.168.. →
error: Upnp client error: Error: This socket has been ended by the other party
Stopping MPD Monitor Service…
217.14.146.53 local addr 192.168.. →
167.235.139.237 local addr 192.168.. →
178.63.67.56 local addr 192.168.. →
148.251.5.46 local addr 192.168.. →
78.46.102.180 local addr 192.168.. →
188.34.165.100 local addr 192.168.. →
Stopping Samba SMB Daemon…
185.244.195.159 local addr 192.168.. →
Stopping Shairport Sync - AirPlay Audio Receiver…
91.202.42.84 local addr 192.168.. →
Stopping triggerhappy global hotkey daemon…
185.248.188.98 local addr 192.168.. →
volumio-time-update.service: Succeeded.
131.234.220.231 local addr 192.168.. →
Stopped Volumio Time Update Utility.
Stopping volumio-remote-updater.service…
Thank you for your reply @Korniman-the-Rooky.
I’m not able to reproduce your bug.
Could you maybe uninstall the plugin, restart Volumio and the re-install the plugin and check the logs for any errors?
Hi Simania, as told the bug was only appearing direct after Install. After manual Reboot it was working. Maybe you could implement a refresh of the system in the install routine, Maybe this is enough so that scheduler would work directly.
Kind regards