[Nut-upsuser] blazer_ser battery.high / battery.low

[Andreas Lausch / TBT]

On 2014-06-03 00:58, Charles Lepple wrote:

>> I'm pretty sure I wouldn't rely on a charge percentage derived this way ;-)

It's nice to see how much time one has left, event if it's not perfectly 
accurate.

>> As mentioned in the other thread about the tripplite_usb driver, apart from having two sets of calibration constants, one for OL and one for OB, there is no good way to have a one-size-fits-all calibration.
>>
>> My answer was based on the documentation, but you could make a case for the on-battery voltage.

I'm not sure what voltage is shown when plugged into mains. I guess it's 
not the actual battery voltage (one would measure when disconnecting the 
battery), but the charging voltage, which has nothing to do with the 
actual charge.

> A little more explanation under the "Battery Charge" heading:
>
> "If you specify both battery.voltage.high and battery.voltage.low in ups.conf(5), but don’t enter runtimecal, it will guesstimate the state of charge by looking at the battery voltage alone. This is not reliable under load..."
>
> Does your UPS report load? If so, there is the "runtimecal" option.
>
> http://www.networkupstools.org/docs/man/blazer.html#_battery_charge
>

Yes, and it is set-up correctly. The time displayed is not far away from 
reality -- tested during a thunderstorm :-)

> We should probably look into ways to make it easier to build custom .deb files for Ubuntu.

Making a .deb can be automated; adding a ppa is possible and easy (if 
one would maintain such a ppa), I don't see the problem there. But It 
makes no sense to swap a tested, stable repository (ubuntu security 
updates) for a "rolling" repository if there is no real gain.

Anyway, patching a model-specific system + different OB / OL 
calculations into _qx, changing almost every aspect of it, does not 
sound like a job for me :D
If maybe, someday, the driver's author(s) decide to do that, I'd be 
happy to test it.


Andreas