fix status parsing

[haennes]

Previously there was an error where a earlier
POWER_SUPPLY_ENERGY_FULL_DESIGN can overwrite a POWER_SUPPLY_ENERGY_FULL

Error when we match the string exactly a second time

[doums]

Sorry but for this one I will need more details (I do not accept code that I don't fully understand):

1. I do not understand the issue as you described it, can you write up something with more details and clear steps, including example values, to help me understand the problem? Did bato crashed? Can you share logs? (I've been using bato as daily driver since years and still today, never saw an issue related to status parsing)
2. do not use local function, i.e. parse_line should be declared as a (static) method of Bato struct or even as standalone (in lib.rs)
3. let's avoid generic for this, it can make things more hard to follow (especially on code I don't own), and we don't really need generic for such limited logic

[doums]

.

[haennes]

Sorry,
almost thought you would need that but just wanted to make the pr quickly
1.
content of /sys/class/power_supply/BAT0/uevent

DEVTYPE=power_supply
POWER_SUPPLY_NAME=BAT0
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_CHARGE_TYPES=Standard
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-poly
POWER_SUPPLY_CYCLE_COUNT=708
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=15360000
POWER_SUPPLY_VOLTAGE_NOW=15995000
POWER_SUPPLY_POWER_NOW=15083000
POWER_SUPPLY_ENERGY_FULL_DESIGN=71000000
POWER_SUPPLY_ENERGY_FULL=56040000
POWER_SUPPLY_ENERGY_NOW=44600000
POWER_SUPPLY_CAPACITY=80
POWER_SUPPLY_CAPACITY_LEVEL=Normal
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_MODEL_NAME=L22M4PA1
POWER_SUPPLY_MANUFACTURER=SMP
POWER_SUPPLY_SERIAL_NUMBER=1712

This results in 56040000 overwriting the previous 71000000 in the line POWER_SUPPLY_ENERGY_FULL=56040000

Added:

        trace!("capacity: {capacity}");
        trace!("energy: {energy}");

Both:

2026-04-20T20:47:10.520643Z DEBUG with_config: bato: now attribute: POWER_SUPPLY_ENERGY_NOW
2026-04-20T20:47:10.520662Z DEBUG with_config: bato: full attribute: POWER_SUPPLY_ENERGY_FULL

After:

2026-04-20T20:45:46.475763Z TRACE update: bato: capacity: 56040000
2026-04-20T20:45:46.475806Z TRACE update: bato: energy: 41480000

Before:

2026-04-20T20:47:10.528828Z TRACE update: bato: capacity: 71000000
2026-04-20T20:47:10.528885Z TRACE update: bato: energy: 41050000

imho scope wise only a local function makes sense. having parse_line as a static method of Bato does not make any sense since the functionality is only used inside of the config parsing.
Thats why i put it exactly there, i dont think any other parts will need that parsing functionality

If you want to i can move it to lib.rs

3. I moved the logic out to the function in order to add the bail when assigning twice and being able to reuse code. For this the function needs to know if the option is some. => We need Option generic.
   To make the assignment easy the generic function makes a lot of sense. Do you have any idea on how to change this without generating vast amount of duplicate code.
   I will refactor the current generic implementation to be easier to grasp.

[doums]

Both:

2026-04-20T20:47:10.520643Z DEBUG with_config: bato: now attribute: POWER_SUPPLY_ENERGY_NOW
2026-04-20T20:47:10.520662Z DEBUG with_config: bato: full attribute: POWER_SUPPLY_ENERGY_FULL

Then, the key comprehension point you are omitting here is that you disabled full_design in your config, right?

full_design = false

You are running in “true level” mode (not sure the right name for it). Therefore, we expect the parsed capacity to be POWER_SUPPLY_ENERGY_FULL and not the _DESIGN variant. That's the issue, I can reproduce it.
Now I understand. (Also that explains why I missed it until now because I'm running bato in full design mode only).

Good catch.

[haennes]

Hi, sorry that you had to guess again.
As you assumed correctly I changed the default of full_design to false in my config

[doums]

no need to use generic it's overkill

Do you have any idea on how to change this without generating vast amount of duplicate code.

yes, fixed in 5299d99

Thx for the report.