2013-09-24 13:14:34 +01:00
|
|
|
|
|
|
|
|
This plugins receives packages with type "kdeconnect.battery" and reads the
|
|
|
|
|
following fields:
|
|
|
|
|
|
|
|
|
|
isCharging (boolean): If the battery of the peer device is charging
|
|
|
|
|
currentCharge (int): The charge % of the peer device
|
2013-11-14 15:32:16 +00:00
|
|
|
thresholdEvent (int) [optional when = 0, see below]:
|
|
|
|
|
means that a battery threshold event were fired on the remote device:
|
|
|
|
|
0 := no event. generally not transmitted.
|
|
|
|
|
1 := battery entered in low state
|
|
|
|
|
This is an int so in the future we'll be able to subscribe to more events.
|
|
|
|
|
(see BatteryPlugin.ThresholdBatteryEvent)
|
2013-09-24 13:14:34 +01:00
|
|
|
|
|
|
|
|
Symmetrically, it sends its own battery information in packages with the same
|
Finally, we have support for sending out Battery information.
## Summary
The core idea is as follows:
1. When a Link loads the BatteryPlugin, we query Solid for a list of batteries.
1. If the list is empty, we print a warning message and return quickly
2. Otherwise, we connect *two signals* to every object in that list
2. We send out a single new NetworkPacket as soon as we've processed that list
3. When either of those two signals emits, we send another new NetworkPacket
### Multi-battery Support
BUG: 357193
To handle devices with multiple batteries (requested in that bug), we average
together the battery percentages. This also includes a new field in the packet for
'number of batteries' called `batteryQuantity`. For backwards compatibility, we can
assume it has a default value of one.
This should ensure we support
- devices with no batteries at all (like many desktop machines)
- devices with hot-pluggable batteries (like those laptops with detachable screens)
### Concerns
Note that the implementation isn't perfect.
We'll need some new localizable text to make it clear that we now support sending
battery status information.
Then there's a rather significant question: maybe we should have two battery plugins
on each client, like we do for the `findmyphone`/`findthisdevice` plugins?
## Test Plan
We need to ensure that other clients (including those using the Android codebase)
will respond correctly. The main things to look at are
1. are these new packets sent when the plugin is enabled, and not sent when it's disabled?
2. is the charge percentage accurate?
3. is the charge state (charging, discharging, or full) accurate?
and
4. do we see the correct number of warnings for low-battery?
2020-04-13 06:54:11 +01:00
|
|
|
format. We only look for the 'primary' battery of the system, if one is present.
|
|
|
|
|
|
|
|
|
|
<TODO>
|
|
|
|
|
Support for devices with multiple batteries isn't there yet.
|
2013-09-24 13:14:34 +01:00
|
|
|
</TODO>
|
|
|
|
|
|
|
|
|
|
It also sends packages with type kdeconnect.battery and a field "request": true,
|
|
|
|
|
to ask the peer device to send a package like the mentioned above, and should
|
|
|
|
|
also answer this same kind of packages with its own information.
|
|
|
|
|
|
|
|
|
|
If the battery is low and discharging, it will notify the user.
|