I just realized that. The last thing I added was the “energy saving mode”. Now if I turn the phone “face down”, starting the energy saving mode confirms with a sound, nice.
(EDIT: Done with sailfish 4.0.0.64, sonar had to be installed from github.)
I’m sorry to ask again: Today I deleted one of the “default situations” (at home). After a reboot of the Phone, I got an error. No tap on either button did anything.
I deleted Situations from the phone and reinstalled it → got the same failure.
Does someone has experience with such a failure?
Does someone know where the config-files of Situations are? Perhaps I could delete them all by ssh and reinstall it again.
With the help of Heikki Haveri, Pastilli Labs, I could reinstall it completly:
devel-su
[root@Xperia10III defaultuser]# pkcon remove situations
[root@Xperia10III defaultuser]# rm -r .local/share/harbour-situations2application/
rm: descend into directory '.local/share/harbour-situations2application'? y
rm: remove directory '.local/share/harbour-situations2application'? y
[root@Xperia10III defaultuser]# pkcon remove situations-sonar
Restart the phone.
Reinstall ‘Situations’ and ’ situations-sonar-0.0.9-9.aarch64.rpm’ (from github).
This time I deactivated the default situations, before I organized my personal “Pause”.
New try with 4.4.0.72:
- installation of situations (+add function: “display”)
- installation situations-sonar-0.0.9-9.aarch64.rpm (from github)
- configuration of Situation “display down” as desired, see picture:
Aim:
a) Save battery:
While the phone is worn in the trousers or laid down on the display → WiFi should be disabled.
b) Get notifications only when I actively check the phone.
Observations:
- First morning, the WiFi was disabled correctly, as seen on the router or by the messages of Situations.
- Problem: Some hours later, Situations disabled WiFi, although the display was “on”, when I came near to the proximity sensor (e.g. when tapping on a top corner in an app).
To solve this, I restarted the phone once. Now I got the same (white failure screen as mentioned on 5th of july)
If Situations works like configured, it would spare a certain amount of battery.
Can someone confirm this behaviour? How could I get Situations to work properly?
Hello,
it seems that “situations” app is not compatible with Sailjail. Do you start it from the launcher or from a terminal?
You can try to start it from the terminal (thus avoiding Sailjail restrictions) and see if the behaviour is the same.
1 Like
How can I start “situations” from the terminal?
If I tab “sit” in terminal, I got only “situations-sonar”.
harbour-situations2application
Ok, that’s my output now:
[defaultuser@Xperia10III ~]$ harbour-situations2application
[D] unknown:0 - Using Wayland-EGL
library “libGLESv2_adreno.so” not found
library “eglSubDriverAndroid.so” not found
library “vendor.qti.qspmhal@1.0.so” not found
QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: Datei oder Verzeichnis nicht gefunden
Created symlink /home/defaultuser/.config/systemd/user/user-session.target.wants/harbour-situations2application.service → /usr/lib/systemd/user/harbour-situations2application.service.
[W] unknown:8 - qrc:/qml/application/Background.qml:8:37: Unable to assign [undefined] to bool
Thank you for the hint. At the moment, Situations works well: The proximity sensor shows no malfunction and the app didn’t hang up.
I’ll observe some days.
Perhaps I’ll start Situations after a reboot per terminal per hand, using “arrow up” for recent commands; or I could add an entry in crontab (which I have not tested yet).
Why not to use systemd timers?
Further problems:
- Situations worked for 2 days as desired.
- Today -again- the sensor reacted, although the display was “on” → the display /WiFi is deactivated for a short moment each time, I come near the sensor.
- I uninstalled the app graphically.
- Nevertheless, the deactivation still went on, i.e. some task was still running.
- For documentation, I made a picture of the output of “top”
- Now, several hours later, the deactivation stopped (I didn’t anything more).
FYI, I didn’t reboot the phone the last days, nor did I install something else.
In the end it doesn’t work for me and I can’t understand, what’s the cause. I’m disappointed, because I thought it would be a good approach to save some battery power over the day.
Can you check:
systemctl --user status harbour-situations2application
and
devel-su systemctl status situations-sonar
[defaultuser@Xperia10III ~]$ systemctl --user status harbour-situations2application
● harbour-situations2application.service - Situations Background Service
Loaded: loaded (/usr/lib/systemd/user/harbour-situations2application.service;
enabled; vendor preset: enabled)
Active: inactive (dead) since Mon 2022-10-10 10:39:44 CEST; 8h ago
Process: 17085 ExecStart=/usr/bin/harbour-situations2application server (code=
exited, status=0/SUCCESS)
Main PID: 17085 (code=exited, status=0/SUCCESS)
[defaultuser@Xperia10III ~]$ devel-su systemctl status situations-sonar
Password:
● situations-sonar.service - Situations Companion Service
Loaded: loaded (/etc/systemd/system/situations-sonar.service; enabled; vendor
preset: enabled)
Active: active (running) since Fri 2022-10-07 20:36:09 CEST; 2 day
s ago
Main PID: 3248 (situations-sona)
Memory: 6.9M
CGroup: /system.slice/situations-sonar.service
└─3248 /usr/bin/situations-sonar
Warning: Journal has been rotated since unit was started. Log output is incomple
te or unavailable.
As far as I understand, the application “harbour-situations2application” when invoked graphically or from the terminal without any argument is only a graphical frontend to configure the user service running in background “harbour-situations2application.service”. This service “talks” with a server (also launched in the background as a root service) “situations-sonar”. Being launched as root, this service is allowed to enable/disable wifi, bluetooth, set airplane mode…
It seems that in your case the user service has ended (I don’t know why). You can try to restart it with:
systemctl --user start harbour-situations2application
1 Like
I had to install “Situations” again, which I did from the Jollastore. Then I opened a terminal on the phone and started Situations again with the command “harbour-situations2application”
After that, I opened a ssh-connection from my pc and got the following status:
● harbour-situations2application.service - Situations Background Serv
ice
Loaded: loaded (/usr/lib/systemd/user/harbour-situations2application.service;
enabled; vendor preset: enabled)
Active: active (running) since Mon 2022-10-10 21:13:21 CEST; 57s a
go
Main PID: 9234 (harbour-situati)
CGroup: /user.slice/user-100000.slice/user@100000.service/harbour-situations2
application.service
└─9234 /usr/bin/harbour-situations2application server
Tomorrow I’ll test it again and post the status, when I observe the malfunction again.
Now, my created situation “display down” works for over 10 days without problems.
The solution was to start the app in terminal (in my case over ssh) per harbour-situations2application.
With my usage behavior, WiFi is disabled by “Situations” for many hours. So I observe that my battery last longer.
Edit: In order to have situations started after every reboot, I added per crontab -e the line:
@reboot harbour-situations2application
Two remarkable small problems:
a) 24.10., again: Situations disabled WiFi, although the display was “on”, when coming near to the sensor
b) 31.10.: WiFi is not disabled, although is laid down with display off.
In both cases systemctl --user status harbour-situations2application and devel-su systemctl status situations-sonar showed the same as days before.
Funnily enough, it always occurred so far on monday mornings :-).
With 4.5. I tried it again, and it worked now for several weeks.
I did again:
- installation of situations (+add function: “display”)
- installation situations-sonar-0.0.9-9.aarch64.rpm (from github)
- pkcon install mpg123
- copy a short sound-file (Pink_Panther.mp3) to /home/defaultuser
- configuration of Situation “Batterie sparen” as desired, see picture:
This worked pretty well for my purpose: If I put the phone in my pocket or lay it “display down” on the table, Wi-Fi is disabled and I’m notified by my chosen sound (mpg123 Pink_Panther.mp3).
Using crontab -e, I inserted the following line, to grant a start of the app without sailjail:
@reboot systemctl --user start harbour-situations2application
With this configuration, my battery lasts for two days, concerning my habits of using.
More restrictive configurations should be tested.
Now I’d like to save more energy by diabling some cpus and Android app support.
I tried to use the hints given by @wetab73 and @miau here: High battery drainage Xperia 10 III - #251 by Speedy-10
- I saved these commands in the file situations-sleep:
# energy saving cpus
echo 0 > /sys/devices/system/cpu/cpu2/online
echo 0 > /sys/devices/system/cpu/cpu3/online
echo 0 > /sys/devices/system/cpu/cpu4/online
echo 0 > /sys/devices/system/cpu/cpu5/online
echo 0 > /sys/devices/system/cpu/cpu6/online
echo 0 > /sys/devices/system/cpu/cpu7/online
# energy saving android app-support
# Stop Android App Support
dbus-send --system --dest=com.jolla.apkd.control --print-reply /com/jolla/apkd com.jolla.apkd.control.controlService boolean:false
- I saved these commands in the file situations-wake-up:
# energy saving cpus
echo 1 > /sys/devices/system/cpu/cpu2/online
echo 1 > /sys/devices/system/cpu/cpu3/online
echo 1 > /sys/devices/system/cpu/cpu4/online
echo 1 > /sys/devices/system/cpu/cpu5/online
echo 1 > /sys/devices/system/cpu/cpu6/online
echo 1 > /sys/devices/system/cpu/cpu7/online
# energy saving android app-support
# Start Android App Support
dbus-send --system --dest=com.jolla.apkd.control --print-reply /com/jolla/apkd com.jolla.apkd.control.controlService boolean:true
If I test in terminal with sudo bash situations-sleep, 6 cores are off afterwards and android app support is disabled.
sudo bash situations-wake-up starts the cores and android app support again.
-
Now I tried to fit this into Situations by (edited):
-
Last step, edit the sudoers file:
[defaultuser@Xperia10III ~]$ devel-su
[root@Xperia10III defaultuser]# visudo /etc/sudoers
Here I tried:
ALL ALL=(root) NOPASSWD: /home/defaultuser/situations-*
which didn’t work
Uncomment %sudo ALL=(ALL) ALL didn’t help, too.
If I lay down and wake up the phone, the cores weren’t down and android app support wasn’t disabled; I can see an Android app starting promptly …
Can someone help me to get both sudo-commands get working in Situations?
That saves me perhaps more battery (disabling Android app support every time will maybe no fun to use in this way).
EDIT: It worked only once.
I. I start situations via terminal (over ssh) with harbour-situations2application
II. Edit only the single sudo-command sudo bash situations-sleep
III. Put the phone “display down” on the table. I hear the confirmation sound.
IV. Wait some seconds, take the phone again. Checked: android support was disabled and cores 2-7 were offline. So far so good.
Then tried a second time, but android app support wasn’t deactivated neither the cores.
systemctl status situations-sonar
Showed now:
● situations-sonar.service - Situations Companion Service
Loaded: loaded (/etc/systemd/system/situations-sonar.service; disabled; ven
dor preset: enabled)
Active: active (running) since Thu 2023-03-30 13:54:02 CEST; 1 d
ay 18h ago
Main PID: 32112 (situations-sona)
Memory: 2.5M
CGroup: /system.slice/situations-sonar.service
└─32112 /usr/bin/situations-sonar
Apr 01 07:59:57 Xperia10III situations-sonar[32112]: Connection accepted
Apr 01 08:00:10 Xperia10III situations-sonar[32112]: Connection accepted
Apr 01 08:01:04 Xperia10III situations-sonar[32112]: C
onnection refused: client not accepted!
Apr 01 08:01:48 Xperia10III situations-sonar[32112]: Connection accepted
IMHO, I would like to emphasize that it was necessary to start stitautions by terminal (sailjail?) to add the sudo command.
It seems, Situations does not execute the commands reliable.