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 _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
