direc85 / harbour-batterybuddy Goto Github PK
View Code? Open in Web Editor NEWBattery level alert for Sailfish OS
License: GNU General Public License v3.0
Battery level alert for Sailfish OS
License: GNU General Public License v3.0
As of SailfishOS 3.4.0.24 (aka Sailfish Application SDK 3.3) aarch64 architecture is available for testing and developing purposes.
Battery Buddy doesn't do anything too fancy, just reads and writes to a few files and runs a few services, but its functionality on the platform needs to be tested and verified.
Verify functionality on different devices:
Hello,
it would be nice if the Jolla Tablet was supported.
On the Jolla Tablet I have the following in /sys/
when not plugged in,
[root@jolla-tablet ~]# ls -1 /sys/class/power_supply/
dollar_cove_battery
dollar_cove_charger
[root@jolla-tablet ~]# ls -1 /sys/class/power_supply/dollar_cove_battery/
capacity
charge_full
charge_full_design
charge_now
current_avg
current_now
device
health
model_name
power
present
status
subsystem
technology
temp
type
uevent
voltage_now
voltage_ocv
[root@jolla-tablet ~]# ls -1 /sys/class/power_supply/dollar_cove_charger/
cable_type
charge_control_limit
charge_control_limit_max
charge_current
charge_term_cur
charge_voltage
device
enable_charger
enable_charging
health
input_cur_limit
max_charge_current
max_charge_voltage
max_temp
min_temp
online
power
present
subsystem
type
uevent
[nemo@jolla-tablet ~]$ cd /sys/class/power_supply/dollar_cove_battery/
[nemo@jolla-tablet dollar_cove_battery]$ cat capacity
79
[nemo@jolla-tablet dollar_cove_battery]$ cat status
Discharging
[nemo@jolla-tablet dollar_cove_battery]$ cat present
1
[nemo@jolla-tablet dollar_cove_battery]$ cat temp
310
[nemo@jolla-tablet dollar_cove_battery]$ cat health
Good
[nemo@jolla-tablet dollar_cove_battery]$ cd /sys/class/power_supply/dollar_cove_charger/
[nemo@jolla-tablet dollar_cove_charger]$ cat charge_control_limit
0
[nemo@jolla-tablet dollar_cove_charger]$ cat charge_control_limit_max
4
[nemo@jolla-tablet dollar_cove_charger]$ cat enable_charging
0
[nemo@jolla-tablet dollar_cove_charger]$ cat enable_charger
0
and this when plugged in
[nemo@jolla-tablet dollar_cove_charger]$ cat charge_control_limit_max
4
[nemo@jolla-tablet dollar_cove_charger]$ cat charge_control_limit
0
[nemo@jolla-tablet dollar_cove_charger]$ cat enable_charger
1
[nemo@jolla-tablet dollar_cove_charger]$ cat enable_charging
1
[nemo@jolla-tablet dollar_cove_charger]$ cat charge_current
1800
[nemo@jolla-tablet dollar_cove_charger]$ cat charge_term_cur
250
[nemo@jolla-tablet dollar_cove_charger]$ cat charge_voltage
4350
[nemo@jolla-tablet dollar_cove_charger]$ cat /sys/class/power_supply/dollar_cove_battery/status
Charging
Is there anything else needed to add support for this (granted pretty old) hardware?
pcfe
It would be useful to be able to set the current for just this charge cycle until completed.
This might be to high for a fast charge, or to low because the charger is shutting down on overcurrent.
Subsequent charges it reverts to the usual set current.
Unless "Start Background Service" is enabled, "Start" does not.
Changing charge current slider, does not change actual charge current, unless the above.
So the bug is a silent fault: User changes slider - nothing happens. Pushes Start - nothing happens
X10III 4.5.0.24
PawelSpoon wrote:
Hi, since the last update I get notifications on low battery, but I did not choose the option. So should not receive any notification interval is also ignored. Do get a message every minute.
nephros wrote:
[General]
highAlert=@ByteArray(85)
highLimit=@ByteArray(85)
interval=@ByteArray(600)
limitEnabled=@ByteArray(0)
lowAlert=@ByteArray(10)
lowLimit=@ByteArray(49)
notificationHighText=Please disconnect the charger.
notificationLowText=Please connect the charger.
notificationTitle=Battery charge %1%
notificationsEnabled=@ByteArray(0)
I suspect that the daemon file watcher loses track of the config file, and has no mechanism to recover. It's rather unpleasant to debug, since restarting the daemon fixes the issue.
Damon not started on Sailfish OS 3.4.0.24 , both buttons start and stop disable. There not process "batterybuddy-daemon" in process list.
The current battery level indicator is a placeholder that stuck. Design and implement better-looking alternative, or even a few alternatives.
Hello @direc85
I happen to own a couple of "drawer" SFOS devices what I mainly keep in the drawer and pull out for testing/upgrading only.
As you may know the lithium batteries have a so called storage voltage which is the optimal for longer storage:
https://batteryuniversity.com/learn/article/how_to_store_batteries
I was thinking about creating a tool which would charge/discharge until the storage voltage is reached and the would shut down the device. By now that Battery buddy having a daemon mode this feature could be incorporated to it.
What do you think about this feature?
Implement optional logging mechanism, which logs battery percentage and current, and graphs them.
I want notified only 1 time for upper limit but very often for lower limit.
Would be nice you can split them.
You can use the smallest interval to switch off the notification and longest interval to notifiy only one time. (- sign for never, โ for one time)
Tiny typo to report:
in application/qml/pages/SettingsPage.qml (and the translation sources) there is the string "Notification treshold"
It should be "Notification threshold"
That's all :-)
Hello, maybe better to use a patch, but If usefull I want to a option which limits the max. usb current because I'm using a Qi-Pad with a limit of 1000 mA.
If this is not a good extension for the app, then it is also ok and I will check to add a patch with patchmanager.
Hello dear direc85!
Great to see you are involved in the AsteroidOS Sailfish client.
I am yearning for the great BatteryBuddy charge control feature to be usable on AOS.
Since the base is very similar, would it be possible to "easily" port the SailfishOS daemon you wrote?
Batteries in Smartwatches are pretty small and i guess it would not make too much sense for users to limit the charge, whereas i personally would love to limit the charge of watches that hold longer than a day to safe the battery a little.
Foremost, this might help developers developing on device and have it connected to a charging dock most of the time.
Currently this leads to constant 100% charge with only a small margin until the charging starts again.
Would love to read your thoughts on the matter!
Thank you for all your work.
SFOS 3.3.0.16
Sony Xperia X (Dual Sim)
BB 2.2-2
Automatic charging control is enabled
upper limit 85 %
lower limit 75 %
Use notification is enabled
Full notification 100 %
Low notification 25 %
Notification interval 1:00
BB is started and running, but charging will not suspend if the upper limit is reached and will charge up to 100 %.
Communation changes from GUI to daemon is not reliable, and likely doesn't support multi user environments. Investigate DBus, or properly support launching GUI from other users' profiles, too.
As lal883 said, it would be a nice feature to have charging pause when the battery is hot, and continue after it has cooled down.
SFOS 3.4 now uses defaultuser
as default user name, not nemo
. Fix the paths accordingly.
Sometimes during the night I tend to sleep and wish to not be disturbed. To achieve this I set my phone to flight mode and put it to some silent ambience. This is shown by a small crossed out note in the top bar.
Unfortunately Battery Buddy does not respect this setting so it woke me up when the battery dropped below my low threshold.
At first I thought that Battery Buddy should always obey the "silent" setting but after thinking about it this should be made optional, at least for the battery low notification. Reason: When I use my phone as an alarm clock that I rely on and I forget to connect the phone to the charger overnight and the battery depletes, it's probably good when the phone wakes me up before the battery is empty. This would however be very annoying when being e.g. at a movie theater, so maybe make it optional.
What do you think?
I have a Jolla 1 and Battery Buddy is running but I dont notice any action from the app.
Automatic charging control is on. Use notification is on. Limits are set. All seems fine. But nothing happend.
A status lookup gives:
Active: failed (Resault: signal) since Sa 2020-06-06 16:23:32 CEST; 24h ago Main PID: 1003 (code=killed, signal=SEGV)
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
And running from commandline with --verbose:
[nemo@Sailfish applications]$ harbour-batterybuddy --verbose
[I] unknown:0 - Loaded lowAlert 30
[I] unknown:0 - Loaded highAlert 90
[I] unknown:0 - Loaded interval 300
[I] unknown:0 - Loaded limitEnabled 1
[I] unknown:0 - Loaded notificationsEnabled 1
[I] unknown:0 - Loaded lowLimit 50
[I] unknown:0 - Loaded highLimit 80
[I] unknown:0 - Reading capacity from "/sys/class/power_supply/battery/capacity"
[I] unknown:0 - Reading charge state from "/sys/class/power_supply/battery/status"
[I] unknown:0 - Reading charger status from "/sys/class/power_supply/usb/present"
[W] unknown:0 - Charger control file "/sys/class/power_supply/usb/charger_disable" is not writable
[W] unknown:0 - Charger control feature disabled
[W] unknown:0 - Theme dir "/usr/share/themes/jolla/meegotouch/z0.9/" does not exist
[W] unknown:0 - Theme dir "/usr/share/themes/sailfish-default/meegotouch/z0.9/" does not exist
[I] unknown:0 - Saved limitEnabled 1
[I] unknown:0 - Saved notificationsEnabled 1
[I] unknown:0 - Launching GUI
And deamon gives:
[nemo@Sailfish applications]$ /usr/bin/harbour-batterybuddy-daemon --debug
[D] Settings::Settings:27 - Using "/home/nemo/.config/harbour-batterybuddy/harbour-batterybuddy.conf"
[D] Settings::updateConfig:76 - Reading values...
[I] Settings::loadInteger:66 - Loaded lowAlert 30
[I] Settings::loadInteger:66 - Loaded highAlert 90
[I] Settings::loadInteger:66 - Loaded interval 300
[I] Settings::loadInteger:66 - Loaded limitEnabled 1
[I] Settings::loadInteger:66 - Loaded notificationsEnabled 1
[I] Settings::loadInteger:66 - Loaded lowLimit 50
[I] Settings::loadInteger:66 - Loaded highLimit 80
[D] Settings::updateConfig:92 - Values read.
[D] Settings::updateConfig:101 - File OK
[I] Settings::Settings:49 - Loaded limitEnabled 1
[I] Battery::Battery:30 - Reading capacity from "/sys/class/power_supply/battery/capacity"
[I] Battery::Battery:34 - Reading charge state from "/sys/class/power_supply/battery/status"
[I] Battery::Battery:38 - Reading charger status from "/sys/class/power_supply/usb/present"
Segmentation fault
Any help or Ideas?
The daemon uses QTimer to trigger re-reading the battery, charger et. al. files. This works like a clock (ha) when the device is in use. When the screen is locked - and the device in a low power state - the intervals can be delayed / skipped altogether. This needs to be fixed.
Originally posted by @Fuzzillogic in #11 (comment)
Thanks for the update. May I suggest to use this feature, by setting the charge current to 0mA, instead of suspending charging (
/sys/class/power_supply/battery/input_suspend
) when the upper charge threshold is reached? This way the battery won't "yo-yo" between charging and discharging when full, but is kept topped up. This might fix this issue I see when using my phone as navigation device, while hooked up to USB power: it charges up to the limit, but given the high load because of active navigation, it drains rather quickly to the lower limit, at which point it starts charging again.I just tried this when charging the battery:
# echo 0 > /sys/class/power_supply/battery/constant_charge_current_max
and then checked the current. The current was ~20mA (draining), so while not exactly 0, it drained much slower than when disconnected. And tweaking worked as well, e.g. setting a charge current of 50mA.It could be combined with the current configured limits, and call it "slow charge mode within limits" or such. While I'm not sure this is actually better for the battery longevity, to me it seems it puts less strain on the battery, and thus might be beneficial.
Currently the daemon has to be run with root user privileges, but this makes it impossible to control the daemon from the UI side.
Thanks to the new logging mechanism, loading SettingsPage.qml
at GUI startup causes multiple saves to disk, triggering multiple config updates to the daemon. This is unnecessary and results in disk writes that could be saved.
I know, not every battery is the same, but maybe it would be good to give the user a hint on the "background" page or maybe directly above/below the limit sliders on what settings are good ones.
Maybe someone with more expertise than me could give good estimates. As far as I know/read most Batteries really dislike 80-100% (80% is approximately when the charging current drops) and 0-10%.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.