zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.87k stars 6.63k forks source link

No state of health or filtered state of charge in fuel gauge API #63206

Open ThomasGooijers opened 1 year ago

ThomasGooijers commented 1 year ago

The experimental fuel gauge API offers a lot of common properties that can be retrieved from fuel gauges.

When utilizing this API to implement a custom driver for the BQ27520 gauge I noticed the API does not provide a state of health estimate or a the filtered state of charge estimate, which this gauge and I assume many others can provide.

The ability to monitor the state of health could be very useful because it could indicate whether or not the battery of your device needs to be replaced. The filtered charge estimate is a more user friendly estimate for display purposes, that smooths out sudden changes in the estimate over some time (for example due to a sudden change in temperature or power consumption).

It could look something like this: "" FUEL_STATE_OF_HEALTH Battery state of health estimate (0-100%)

FUEL_GAUGE_FILTERED_RELATIVE_STATE_OF_CHARGE Relative state of charge estimate with filtering (0-100%) ""

If this or something like it could be added to a future version of the API I think that would be a good improvement.

github-actions[bot] commented 1 year ago

Hi @ThomasGooijers! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

aaronemassey commented 1 year ago

@teburd @rriveramcrus This seems similar to the charger health in https://github.com/zephyrproject-rtos/zephyr/pull/62551 How do we feel about exposing a type of health status from fuel gauges as well? Seems completely reasonable to me.

rriveramcrus commented 1 year ago

@aaronemassey the state of health (SoH) in gauging-land is different than charger health in #62551, so there is no risk of conflict or overlap. I am okay with this. charger_health is indicative of the conditional state of battery pack and/or charging circuit with respect to the ability to charge a battery, so it is of interest to the charger and the OS. The proposed fuel gauge STATE_OF_HEALTH is a dynamic characteristic of the battery pack only of interest to the gauge and OS.

aaronemassey commented 1 year ago

Ack. My first priority at the moment is creating a set of generic API tests to make it easier for fuel gauge contributions and assuring drivers are consistent. Let me get to that first and I'll grab this.

@ThomasGooijers If you'd like this done sooner I'm also happy to review a PR.

ThomasGooijers commented 1 year ago

@aaronemassey I don't need it done right now, it's just a improvement suggestion. I wouldn't mind working on this myself but unfortunately I have other priorities right now.