Open ThomasGooijers opened 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. 🤖💙
@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.
@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.
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.
@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.
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.