Sadly, there is no way to write battery data into bq27x00_battery chip - only possible way is calibration. there *is* a way to force learning capacity a little earlier than usual, but it's complicated, time sensitive, and completely not-worth-effort, compared to learning cycle.

So, saving and loading battery profiles won't be possible, due to hardware restrictions.

I haven't had idea about that. In early days, when first version of script was created (read: at least a year, or more, before I decided, that others may enjoy using it too, then moved my a** to package it and share through repos), I was switching between running it and bq27200.sh script. I needed a name that start the same way - so auto-completion via tab will show me both scripts - but is easily auto-completed to the end, with just 2nd letter provided. So, I've added "n" as "new" or "next", and "f" as a random letter. Despite unusual way of creating name, it got used to it, so I've kept it that way.

Unfortunately, I'm not GUI coder at all (or any real coder, if we stick to facts ). I'm all for other projects using BNF code/inspiration to achieve something, or just learn basic scripting by reading it - that's why BNF is very heavily commented in-code - but, it was meant to be ultra-lightweight way of having all major bq27x00 chip information at a glance, bindable to hardware button (allowing use in fullscreen programs too, without minimizing them). So, control panel applet is out of scope for this project.
---

It have been some time, since Pali fixed bq27x00_battery module, and released beta of his and freemangordon's BME FOSS Replacement kit. bq27x00_battery is loaded automatically, as a integral part of replacement solution. Hoever, one problem with bq27x00_battery - from bnf's perspective - is that it blocks access to i2c data. there *is* a way to access it simultaneously, via i2c_slave - but it's complicated, and no one is sure, if perfectly safe. Other than that, fixed bq27x00_battery is blessing, as it allows hassle-free access to most data provided by chip, as sysfs (and less hassle-free access to rest of them, via raw registers).

Some time ago, I've promised to release bnf that will work with bq27x00_battery, if it get fixed/incorporated into BME replacement. Hoever, I'm sure, that not all of bnf users want to jump into replacement bandwagon just yet (it's quite devel'ish in full sense of word) or at all, preffering i2c method (reinob, I'm thinking about you, especially )

So, I've created a new version of bnf, that works for *both* bq27x00_battery, and "old" i2cget method. It determines if user have bq27x00_battery loaded and if yes, use it - otherwise, transparently switches to i2cget method. For ease of maintaining, I've divided it into 3 scripts now - "bnf" which only does module checks, and then, run either "bnf-bq27x00" or "bnf-i2c". Of course, I could still keep it as one file (more than 2x as big as before), but I feel it's more cleaner this way. Also, for those of you, that only use one method, and never plan to use another, you may just delete unneeded file (and/or rename *needed* one to "bnf", replacing controller script).

If When autobuilder and repos ever start really working again, I'll update version in extras-*. Until then, you may download drop-in replacement .tar from this (and opening) post attachment - just untar it to /usr/sbin/, replacing old file.



Changelog:

• Uses either bq27x00_battery module, or i2cget method, transparently deciding which one is applicable.
• New value - "Average Time Remaining", which shows remaining time, calculated from averaged power usage since last complete charging.
• Minor code cleanup + more things commented for easy code understanding, even for sh beginners.

Happy using!

/Estel