svartalf/rust-battery

Rust crate providing cross-platform information about the notebook batteries

battery provides a cross-platform unified API to a notebook batteries state

battery

Rust crate providing cross-platform information about the notebook batteries.

Table of contents

  • Overview
  • Supported platforms
  • Install
  • Examples
  • FFI bindings
  • Users
  • License
  • Donations
  • Contributors
  • Backers
  • Sponsors

Overview

battery provides a cross-platform unified API to a notebook batteries state.

Its main goal is to wrap the OS-specific interfaces, cover all the hacks and legacy cases and get the batteries information (such as state of charge, energy rate, voltage and temperature) as a typed values, recalculated as necessary to be returned as a SI measurement units.

Supported platforms

  • Linux 2.6.39+
  • MacOS 10.10+
  • iOS
  • Windows 7+
  • FreeBSD
  • DragonFlyBSD

Do note that iOS implementation uses IOKit bindings, your application might be automatically rejected by Apple based on that fact. Use it on your own risk.

Install

As a prerequisite, battery crate requires at least Rustc version 1.36 or greater.

Add the following line into a Cargo.toml:

Examples

See the battery/examples/ folder in the repository for additional examples.

FFI bindings

Experimental battery-ffi crate provides the FFI bindings to the battery crate, so it can be used with other languages, such as C, Python or NodeJS.

Check its README and documentation for details.

Users

This an incomplete list of the battery crate users. If you are using it too, send me a message and I'll add your project here!

battop

battop is an interactive viewer, similar to top, htop and other *top utilities, but about the batteries installed in your notebook.
It is using the battery crate API to show the batteries information in your terminal.

starship

starship is a Rust port of the minimalistic, powerful, and extremely customizable prompt Spaceship ZSH.
It is using the battery crate to show the the current battery level and status in a shell prompt.

Here is what @matchai says:

I really appreciate how easily we were able to get your library up and running! Battery APIs were a headache for us in predecessors of this project 😅

And there is this tweet also!

License

Licensed under either of Apache License 2.0 or MIT license at your option.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this crate by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Donations

If you appreciate my work and want to support me, you can do it here or support this project at Open Collective.

Contributors

This project exists thanks to all the people who contribute.

Backers

Thank you to all our backers! 🙏 [Become a backer]

Sponsors

Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [Become a sponsor]

Issues

Collection of the latest Issues

ClementTsang

ClementTsang

Comment Icon2

One of the dependencies, nix 0.19, has a security vulnerability and 0.19 does not have a patch with the fix, with only versions 0.20 and greater having patches to fix the vuln.

Would be great if we could get a dependency version bump + release to address this. I tried updating nix to 0.22 and it seems to work fine (0.23 uses a newer version of bitflags which might problems for others).

Let me know if I can help in any way, thanks!

mkoakintomiwa

mkoakintomiwa

Comment Icon2

Operating system: windows First of all, Thanks for always being there svartalf. Please help me with this one too.

I got

lucassardois

lucassardois

C-enhancement
Comment Icon4

Is the batteries iterator having a fixed order? From my tests it seem to ne be the case. acpi gives me:

But the batteries iterator first give me Battery 1 then Battery 0. I didn't find anything about this in the documentation.

cjbassi

cjbassi

C-enhancement
Comment Icon4

First of all I just want to say I really appreciate this crate!

The issues I've had with uom regarding this crate are:

  1. It was difficult to understand how to work with the uom return type when first using this crate
  2. For some reason uom needs to recompile every time I compile my program which takes time and is annoying
  3. I don't really feel like uom provides any value as a return type. Personally, I would prefer just a simple f32/f64 or you could even alias it to a custom type.

Let me know what you think.

svartalf

svartalf

C-enhancement
Comment Icon0

Current Linux implementation is probing multiple files in order to fetch one specific value; for example, in order to get the design voltage parameter, four files will be opened consequently: "voltage_max_design", "voltage_min_design", "voltage_present" and the "voltage_now".

Even while all files are located at the sysfs filesystem and read operations from it are very quick, for a worse case scenario there will be three unnecessary open syscalls (assuming the Manager::refresh method calls, as battop does).

Battery instance should remember which file was opened successfully during the previous information update and should open it directly on a next "refresh" call. Yet, it is important to remember that some Linux drivers can remove or add these files on a fly, so, in case of failure, consequent probing should be started again.

In a result, it should reduce syscalls amount vastly.

svartalf

svartalf

C-enhancement
Comment Icon0

This battop issue had introduced the case, when the Battery struct instance can represent the missing device. While it is possible now to handle that case (see #29), this kind of error seems to be a recoverable type of error for library users (mostly to the battop at the moment), because it can be handled (for example, by removing the device from the batteries list).

battery::Error can be reworked as an enum with the "recoverable" and "non-recoverable" members, smth like this:

boomshroom

boomshroom

C-enhancement
Comment Icon3

As someone whose computer is connected via USB to an external power supply, I would love to be able to monitor its status from within battop. However it doesn't appear in the sysfs and as such is invisible to this library. Being able to support more types of batteries and power supplies should be a worthy goal for this type of library, but I don't know how much effort it would take to implement.

svartalf

svartalf

C-enhancement
Comment Icon0

This is a tracking issue for Solaris support.

svartalf

svartalf

C-enhancement
Comment Icon13

This is a tracking issue for NetBSD support.

svartalf

svartalf

C-enhancement
Comment Icon10

This is a tracking issue for OpenBSD support.

Versions

Find the latest versions by id

0.7.8 - Nov 01, 2020

0.7.7 - Nov 01, 2020

0.7.6 - Nov 01, 2020

0.7.3 - Jun 03, 2019

See CHANGELOG.md file for release notes: `https://github.com/svartalf/rust-battery/blob/master/CHANGELOG.md#073---2019-05-30

0.7.0 - Mar 10, 2019

See CHANGELOG.md file for release notes: https://github.com/svartalf/rust-battery/blob/master/CHANGELOG.md#070---2019-03-10

Each archive contains following files:

  • Compiled dynamic library (.so, .dylib or .dll depending on target platform)
  • C headers file for this library
  • Compiled CLI version of the battery-cli crate (not available for windows platforms at this release)

.asc and .sha512 files are created from the corresponding .tar.gz file.

Information - Updated Jun 14, 2022

Stars: 311
Forks: 31
Issues: 20

This is an example of a Rust server that functions as a remote schema for...

Rust + Hasura Rust server that functions as a Hasura

This is an example of a Rust server that functions as a remote schema for...

Newport Engine is a modular 2D and 3D game engine built in Rust for Rust

It is designed to be easily extendable and easy to use

Newport Engine is a modular 2D and 3D game engine built in Rust for Rust

liboqs-rust: Rust bindings for liboqs

Qyantum Safe liboqs rust bindings

liboqs-rust: Rust bindings for liboqs

msgflo-rust: Rust participant support for MsgFlo

Flowhub visual programming IDE

msgflo-rust: Rust participant support for MsgFlo
Actix

1.2K

How to be a full stack Rust Developer

Read Rust the Rust blog posts at Steadylearner

How to be a full stack Rust Developer

Rust library translation (rust-src/rust-std/stdlib/rustlib translation)

This is the place to translate Having a documentation in your native language is essential if you don't speak English, and still enjoyable even if...

Rust library translation (rust-src/rust-std/stdlib/rustlib translation)

False Positive for rust-lang/rust#83583

The deprecation lint proc_macro_derive_resolution_fallback is intended to catch proc macro generated code that refers to items from parent modules that should not be in scope:

False Positive for rust-lang/rust#83583

xbuild is a build tool for rust and rust/flutter projects with support for cross compiling...

xbuild is a build tool for rust and rust/flutter projects with support for cross compiling and

xbuild is a build tool for rust and rust/flutter projects with support for cross compiling...

Rust: setup Rust with rustup

wabt: --sysroot value in the Makefiles when using a different target localtion for wasi-sdk)

Rust: setup Rust with rustup

How to be a full stack Rust Developer

Read Rust the Rust blog posts at Steadylearner

How to be a full stack Rust Developer

Snake game developed in Rust using rust-sdl2 crate

Snake game developed in Rust using

Snake game developed in Rust using rust-sdl2 crate

This is a game engine for rust in rust

I'm building it as a learning experience to try and better understand rust and what goes into making a game engine

This is a game engine for rust in rust
Facebook Instagram Twitter GitHub Dribbble
Privacy