Here’s how I use Situations to power save and be quiet overnight:
Three Situations:
Basic “Sleep” setup (NB: careful with do-not-disturb mode, it will turn OFF alarms!!)
Powersave when charger not connected (powersaving and charging don’t mix):
Flight mode when display is not in use (so flight mode is not activated while doing some late-night internetting).
I am very familiar with situations from my old Nokia, but it’s not the same. Auto ON / OFF with BBOS means that the device is really completely off. This can only be achieved by combining hardware and software. I don’t know of any modern device that can do that. This requires an independent, buffered clock with calendar and a special hardware layout. Situations is just an app. However, any function that relieves the battery is welcome.
If the phone completely switches off and on controlled by clock, the SIM PIN must be switched off. Otherwise the phone hangs on SIM PIN input when switching on again. I consider this not as a good idea. But clock controlled switching to flight mode could be a way.
Note that from command line you can select any percentage value, e.g.
mcetool --set-psm-threshold=100 --set-power-saving-mode=enabled
means power save mode gets activated whenever charger is disconnected.
Power save mode tweaks phone behaviour when the device is in use / handling background synchronization / whatnot - and atm the savings are rather limited.
From idle power consumption point of view: inactivity leads to display dimming and blanking. After which the device gets suspended → whether psm is use/active or not does not matter and power consumption is order of magnitude smaller than what power save mode can accomplish.
[But turning radios off etc according to some kind of schedule as suggested in other comments would lead to further reduction in power consumption.]
IMHO, this group of settings {20%, 15%, 10%, 5%, off} should be extended with two others values {90%, 50%, 20%, 15%, 10%, 5%, off} where 50% indicates a strong propency to saving energy and 90% almost keep the phone locked in energy saving mode.
Moreover, the option:
should change in this more useful:
The reason it is obvious, it is enough that I connect the smartphone just the time to trasfer some data from it with the MTP via USB and the energy saving mode will be reset to the normal but no a very little charge has been transfered to the battery.
Finally, the threshold in charging at {80%, 90%} will do the rest. In order to keep the smartphone always in energy saving mode. At the cost of few meaningful changes. Personally, I would add 70% at the values above, for those the battery is somehow compromised.
Is it possible to generate a patch for PatchManager to changes this behaviour? Which files are involved in changing reconfiguring the UI and/or its business logic? Because for the message to change, it is supposed to be translated in many languages in order to correctly address the various localisations.
POST SCRIPTUM
The mcetool command line should be installed with
devel-su pkcon install mce-tools
Maybe. It is unless there are changes to any binary files required (i.e. source code change and recompilation).
In that case, Patchmanager is not the right tool to use.
(Although in theory, everything PM does should also work for patches to binaries. I don’t think it has been tried though, and it’s not what it’s designed for.)
Take a look at /usr/share/jolla-settings/pages/battery/mainpage.qml from package jolla-settings.
Also, MCE is open-source and you can look at its source code at GitHub - sailfishos/mce, e. g. mce/modules/powersavemode.h at master · sailfishos/mce · GitHub
Also of interest: GitHub - sailfishos/nemo-qml-plugin-systemsettings
Those being Open Source components means you should submit changes as a pull request to Jolla, rather than creating a patch or distributing your own, changed binaries.
Look here on how to localize patches.
Cron jobs were for that purpose. Maybe it’s also with a systemd service possible with a timer. Chatgpt says this: Yes, you can write a systemd timer to shut down the system at a specific time. Here are the steps to do so:
sudo nano /etc/systemd/system/shutdown.service
[Unit]
Description=Shutdown system
[Service]
Type=oneshot
ExecStart=/sbin/poweroff
[Install]
WantedBy=multi-user.target
Save and close the file.
Create a new timer file by running the command:
sudo nano /etc/systemd/system/shutdown.timer
[Unit]
Description=Shutdown at HH:MM
[Timer]
OnCalendar=--* HH:MM:00
Unit=shutdown.service
[Install]
WantedBy=timers.target
Save and close the file.
Reload systemd to pick up the new files:
sudo systemctl daemon-reload
sudo systemctl enable shutdown.timer
sudo systemctl start shutdown.timer
The system will now shut down at the specified time every day.
Oh and that for the original question, i would only edit the mcetool command to go into power saving mode: Yes, it is possible to create a systemd timer that puts the system into energy-saving mode after a period of inactivity. Here are the steps to do so:
sudo nano /etc/systemd/system/sleep.service
[Unit]
Description=Put system into energy-saving mode
[Service]
Type=oneshot
ExecStart=/usr/bin/mcetool --set-display-power-state=off
[Install]
WantedBy=multi-user.target
Save and close the file.
Create a new timer file by running the command:
sudo nano /etc/systemd/system/sleep.timer
[Unit]
Description=Put system into energy-saving mode after X minutes of inactivity
[Timer]
OnIdleSec=Xm
Unit=sleep.service
[Install]
WantedBy=timers.target
Save and close the file.
Reload systemd to pick up the new files:
sudo systemctl daemon-reload
sudo systemctl enable sleep.timer
sudo systemctl start sleep.timer
The system will now go into energy-saving mode after X minutes of inactivity.
I would use the second flag: -T, --set-psm-threshold=<10|20|30|40|50>
-F, --set-forced-psm=<enabled|disabled>
From the good old BB10 times, I have a habit to keep the phone with the display facing down when I don’t use it. So for that use case it would be useful to have an option to have the power saving mode enabled when the phone is placed face down. I guess that a very simple service reading the orientation sensor (it doesn’t have to be too frequently, even once a minute should suffice) and turning the psm mode on/off accordingly would do the job. It might also offer some additional options like enabling/disabling BT, GPS, WiFi etc. when the display is facing down. Maybe I’ll do it if/when I find some spare time…
What exactly does the powersave mode do? Or is this the same mode, when you get the battery warning and your phone is nearly unresponsive, because of the cpu locked to its lowest frequency?
initially I thought of this. This is long ago. Meanwhile this problem seems to no more appear in an annoying way after some SFOS updates since 2021. For me no more a problem.
But i still couldn’t find an explanation what this mode does.
It saves battery power while standby / idle. The CPU clock frequency goes down, therefore the CPU consumes less power. Also some circuits of the phone are are switched to standby mode or to deep sleep mode and not full working.
I think that there is a typo here, this would solve
ExecStart=/usr/bin/mcetool --set-power-saving-mode=enabled
However, there is not the counterpart that brings back to the normal state when the screen is unlocked - whetever it needs a PIN or not but just completed the unlock.
I enabled power saving mode with ‘mcetool --set-power-saving-mode=enabled’ turned the display off, wifi disabled, mobile data enabled and checked the log of battery buddy after 45 minutes and it made no difference in power consumption. Has anyone checked this with a phone which doesn’t suffer from battery drain in idle?
try with one of these two:
mcetool --set-power-saving-mode=enabled -T 100%
or
mcetool --set-power-saving-mode=enabled -T 100% -F
In my case the first move the battery drain from 12%/h to 8%/h.
Does the Battery saving mode also enable the power saving mode? Because on my phone enabling the BSM doesn’t provide absolutely any benefits when it comes to battery life and also the CPU clocks do not seem to get reduced.
By looking in mcetool I think you need to use --set-forced-psm=enabled to activate PSM if battery charge is above the threshold.
Power-saving-mode seem to be always enabled and forced-psm gets enabled when you activate PSM in setting.
I did some tests about power saving reported here:
which are based on some information collected in this thread, starting from this post
After these tests, my opinion is that the Xperia 10 II & III should be equipped with few templates (system configurations) about power management. Below, I will describe these templates in terms of their features.
nightly stand-by
WiFi, Bluetooth, mobile data, fingerprints reader, sensors, photo cameras and GPS all off and as far as possible their hardware subsystems should be powered off. For the GPS, the gpstoggle can do that but for the other hardware subsystems I have not checked, yet.
The Android Support should be disabled and zRAM swap should be off-loaded with the script from this patch.
CPUs [0-3] for Xperia 10 II and CPUs [0-1] for Xperia 10 III should be set to minimum working frequency and to conservative scaling mode. The other CPUs, the same but put off-line (all the processes will switch to other online CPUs). Linux kernel, real-time and some few specific system processes that need to deal with time jittering tend to rely on CPU #0 only. Moreover because the [0-3] belong to the same multiple-cores CPU, all of them can be kept online. Update: considering that on Xperia 10 II, the CPUs [0-4] are 1.8GHz while the others are at 2.0GHz the first CPUs set is also the one more conservative in terms of power consumption. Instead, in Xperia 10 III the most powerful CPUs probably will be at [7-8] enumeration. Therefore for the Xperia 10 III, putting just those 2 cores off-line will result in a smaller power save.
the external MMC card should be unmounted and its hardware controller powered off while the internal SSD flash should be put in the power saving mode.
the display should be kept powered off unless hardware keys are triggered.
daily stand-by
This templates is similar to night stand-by but with these differences:
the second set of the CPUs are kept online without enforcing their working frequency but the max working frequency can be limited to the half of the hardware max working frequency aka top scaling cap.
the Android Support - if it is running - keeps running thus the zRAM swap off-loading will be not performed when this template is applied, unless the Android Support was not running.
only the hardware related to unused/inactive services (WiFi, Bluetooth, GPS, mobile connection, etc.) should be powered off.
sensors should be kept powered on because they can be useful for some apps like shaking the phone to switch on/off the flashlight but not the compass unless GPS is active or used by an application. Like the fingerprints reader, the compass should be awakened when requested by an application.
external MMC can be mounted and kept ready. Most depends how fast / reliably we can mount and umount such a partition when it is not used by any application or by the implication about having a fake-root filesystem-overlay (probably none but it has to be verified and tested).
daily power saving mode
This templates is similar to daily stand-by but with these differences:
the first set of CPUs are put in interactive (mark2) or ondemand (mark3) frequency scheduling policy while the others are in conservative mode. A top cap about the max working frequency can be set for the second group of CPUs. Therefore the user can decide between daily power saving mode or daily power saving plus mode by an option (one or another).
without the plus option activated, also the internal flash are set to a more responsive / performing power saving mode.
daily performance mode
When a battery is less important than productivity or the smartphone is connected to a power source then all the policies can be set to the most performing option available.
general settings
These following settings apply to all the power management templates.
The fingerprint reader and the photo cameras should be kept switched off unless the few cases in which should be temporarily awakened for its duty.
The GPS should be powered off when it is not used. The same for Bluetooth and WiFi subsystems.
The WiFi tethering should be not ask which is the source of data networking (SIM1, SIM2, WiFi) because the user may want to use it to access to the smartphone locally and we do not know which network services s/he installed to be used. Moreover, when WiFi tethering is asking for which source should be used to share the data connection, it mess-ups the state of the toggle button in the topmenu about mobile data when a SIM is chosen. Under this PoV the related Settings page should be renamed from “internet sharing” to “wifi tethering”
The WiFi tethering should be powered off when it is not used by any client for a user-customizable timeout (eg. 5, 10, 15, 30, 60 minutes) but the user can disable this by default.
Few default native applications takes too much time to be started {phone, SMS/text, contacts/people, photo camera} but these applications are supposed to be used also in emergency situation like calling the 112/911 or call/texting the home/family or take a shot/video of an incident and any other situations in which a photo/video proof can have a sensible impact about legal consequences. For this reason, these apps should be put in run, kept in run, restarted quickly when they are not running (1-min or immediately waiting on their /proc/$pid/cmdline¹) as many times is necessary and the user should be notified when N restarts fail consecutively in such a way s/he can act accordingly.
The default camera app should be replaced in the above role by the Advanced Camera when the end-user decides so (optional). Therefore a Settings page about always-running apps should be created.
Some other native default apps that the user optionally can decide to keep ready are clock/alarms, calendar, todo-list, notes. These apps lag-to-start can have a social impact: you are in a hurry and meet a person, then you need to set some quickly some schedule, alarm or simply take a note/todo reminder. Some todo reminders should have an alarm associated but I did not see this feature implemented.
The always running native apps should not be closed in the default way (with kill $pid, probably) but set to a suspended state (with kill -STOP $pid) and then awaken when they are started again (with kill -CONT $pid). This is an efficient way to have them ready to run.
notes
¹ In all the Linux systems that I had the chance to work on, the /proc/$pid/cmdline still exists when a process is terminated but it is a zombi. In such a case that procfs item is void with zero size. Therefore, the suggestion to wait on /proc/$pid/cmdline is not completely correct but choosing another instance in the same folder is subjective/arbitrary.