battery block: fallback for determining power consumption

[ammgws]

Resolves #429 by implementing the simple approach mentioned here: #429 (comment). This could be worked on in the future for better hysteresis.

I don't have a battery operated device to test with at the moment so would appreciate if @travankor, @GladOSkar could check this out if they have time.

[ammgws]

One thing I'm not sure about is how these changes affect this block:

       let status = self.status()?;
        match status.as_str() {
            "Full" => Ok(((full as f64 / usage) * 60.0) as u64),
            "Discharging" => Ok(((fill / usage) * 60.0) as u64),
            "Charging" => Ok((((full as f64 - fill) / usage) * 60.0) as u64),
            _ => {
                // TODO: What should we return in this case? It seems that under
                // some conditions sysfs will return 0 for some readings (energy
                // or power), so perhaps the most natural thing to do is emulate
                // that.
                Ok(0)
            }
        }

Since it seems that depending on the context, usage has two different values (power or current). Might need to add another if guard to check the current status before setting usage.

[GladOSkar]

Will test in ~4-5 hrs

[GladOSkar]

One thing I'm not sure about is how these changes affect this block:

       let status = self.status()?;
        match status.as_str() {
            "Full" => Ok(((full as f64 / usage) * 60.0) as u64),
            "Discharging" => Ok(((fill / usage) * 60.0) as u64),
            "Charging" => Ok((((full as f64 - fill) / usage) * 60.0) as u64),
            _ => {
                // TODO: What should we return in this case? It seems that under
                // some conditions sysfs will return 0 for some readings (energy
                // or power), so perhaps the most natural thing to do is emulate
                // that.
                Ok(0)
            }
        }

Since it seems that depending on the context, usage has two different values (power or current). Might need to add another if guard to check the current status before setting usage.

Oh wait - i remember writing that part of the code now, i added it via #214 exactly because my system doesn't have energy[Wh] and power[W] but charge[Ah] and current[A].

The idea was that usage, fill and full always represent the abstract values in terms of the current system, independent of what units the device driver was using (Amps or Watts), since apparently the device driver always uses either one or the other for both the now and the full values.

Meaning, to be clear: if the device driver uses the combination of energy_full, energy_now and power_now, all values (full, fill, and usage) are in Watts, while if it uses charge_full, charge_now and current_now, they're in Amps.

It works out anyways because in all 3 equations in the cited code block the units cancel out and we're left with a time value.

So, in conclusion, your changes in fn time_remaining() actually break ERT calculation. fn power_consumption() is correct.

With upower = true, everything works as usual:

With upower = false though (which this PR addresses afaik), both values are messed up:

Firstly, the sysfs value is apparently in μW and needs to be adjusted for that. Secondly, the timer doesn't work.

When removing all changes to fn time_remaining() and dividing the fn power_consumption() result (for the voltage*current case) by 1000000), it's perfect:

[travankor]

Seems like power is returned in μW, while the value is normally returned in W.

Also the battery status reports FULL instead of DISCHARGING

[travankor]

It does not work with upower = false though:

Are you using the sysfs driver?

[GladOSkar]

Hey @travankor i revised my original test because i missed a couple of things. I usually use upower but now focused on sysfs because that's what this PR is for. I saw the μW issue as well.

[GladOSkar]

Added my suggestions as reviews, feel free to adjust to your liking. This github review thing seems to be fighting me, it's weird

[ammgws]

OK so I believe it should be good to go now.

@travankor Can you please test again?

[GladOSkar]

FYI, works fine on my end now.

[ammgws]

Thanks!