On Jun 2, 2014, at 6:48 PM, Charles Lepple wrote:> On Jun 2, 2014, at 12:25 PM, Andreas Lausch / TBT wrote: > >> >> Hi, >> >> thanks for the reply. >> >> On 2014-05-29 05:21, Charles Lepple wrote: >>>> Now my questions: >>>> 1. should the blazer_ser's high voltage be the voltage during charging >>>> or right after I've unplugged it from the mains? >>> sounds like during charging (or more accurately, during float charging at the end of the cycle): >>> >>> http://www.networkupstools.org/docs/man/blazer.html#_extra_arguments >> >> Are you sure? If I put the 27.4 (reported voltage @ 100%) in the config, >> battery.charge drops immediately when unplugged, because the reported >> battery.voltage then is only 26.xV. (But I'm not sure the battery was at >> 100% when I saw the 26.xV) > > I'm pretty sure I wouldn't rely on a charge percentage derived this way ;-) > > 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.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 -- Charles Lepple clepple at gmail
Andreas Lausch / TBT
2014-Jun-03 13:42 UTC
[Nut-upsuser] blazer_ser battery.high / battery.low
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
hyouko at gmail.com
2014-Jun-29 22:43 UTC
[Nut-upsuser] blazer_ser battery.high / battery.low
(thanks Charles for handling this one too)> 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.What we can do is simply to add a map to link model->voltages and then, provided that runtimecal *and* battery.voltage.{high,low} are not set in ups.conf *and* the UPS is not reporting itself the estimated charge *and* either the user set device.{mfr,model} or the UPS reports them, use it to calculate the 'guesstimated' (and not so reliable) battery charge looking at voltages alone. Obviously the same cannot be made with runtimecal, as you are supposed to update it as time passes and batteries wear. Plus, having enough data from several devices doesn't seem very likely to me... Nonetheless, if there's interest in this feature and no one complains about it, I'll give it a try.