Okay, now that I've got NUT up and running with the newhidups driver, I can
give it a quick shakedown.
Most of the values look good, but are few are off. Here's what I get:
elrond@foxstar:~$ upsc foxstarups@localhost
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.date: 3150/08/01
battery.mfr.date: 2005/03/22
battery.runtime: 1935
battery.runtime.low: 120
battery.temperature: 302.0
battery.voltage: 27.0
battery.voltage.nominal: 24.0
driver.name: newhidups
driver.parameter.offdelay: 600
driver.parameter.port: auto
driver.version: 2.0.3
driver.version.data: APC HID 0.8
driver.version.internal: 0.28
input.voltage: -6437.0
input.voltage.nominal: 120
output.voltage: 120.0
output.voltage.target.line: 120.0
ups.beeper.status: enabled
ups.delay.shutdown: -1
ups.firmware: 9.o2 .D
ups.firmware.aux: o2
ups.load: 25.0
ups.mfr: American Power Conversion
ups.mfr.date: 2005/03/22
ups.model: Back-UPS BR 800
ups.serial: QB0513140434
ups.status: OL
ups.temperature: 302.0
ups.test.result: No test initiated
In particular, the bad ones are:
battery.date, battery.temperature, input.voltage, ups.temperature, and maybe
battery.voltage.
battery.date has a very wrong year.
battery.temperature is very high. The NUT cgi scripts treat this value as a
reading in Celcius, which would seem appropriate. However, it looks as though
the UPS is actually giving a reading in Kelvin. 302 degrees Kelvin is about
46 degrees Celius. That's a far more reasonable reading. The same
conversion
would be appropriate for ups.temperature.
input.voltage is just plain wrong.
battery.voltage... I'm not really sure if this is wrong or not. It's
higher
than the nominal voltage of 24V. Once charged, shouldn't the voltage be
near
the "nominal" value?
All of the other values look at least in the ballpark. The runtime looks
good. And by turning devices on and off I think the load value is correct to.
--
--John Gruenenfelder Research Assistant, UMass Amherst student
Systems Manager, MKS Imaging Technology, LLC.
Try Weasel Reader for PalmOS -- http://gutenpalm.sf.net
"This is the most fun I've had without being drenched in the blood
of my enemies!"
--Sam of Sam & Max
This is a duplicate bug report. It was first reported by Gordon Rowell on Feb 06 on the Nut-upsdev list, and has subsequently been fixed in CVS. See http://boxster.ghz.cc/projects/nut/changeset/352 Arnaud, should we backport these bugfixes to 2.0.3? I have a feeling we will see this bug reported several times more. -- Peter John Gruenenfelder wrote:> > Okay, now that I've got NUT up and running with the newhidups driver, I can > give it a quick shakedown. > > Most of the values look good, but are few are off. Here's what I get: > > elrond@foxstar:~$ upsc foxstarups@localhost > battery.charge: 100 > battery.charge.low: 10 > battery.charge.warning: 50 > battery.date: 3150/08/01 > battery.mfr.date: 2005/03/22 > battery.runtime: 1935 > battery.runtime.low: 120 > battery.temperature: 302.0 > battery.voltage: 27.0 > battery.voltage.nominal: 24.0 > driver.name: newhidups > driver.parameter.offdelay: 600 > driver.parameter.port: auto > driver.version: 2.0.3 > driver.version.data: APC HID 0.8 > driver.version.internal: 0.28 > input.voltage: -6437.0 > input.voltage.nominal: 120 > output.voltage: 120.0 > output.voltage.target.line: 120.0 > ups.beeper.status: enabled > ups.delay.shutdown: -1 > ups.firmware: 9.o2 .D > ups.firmware.aux: o2 > ups.load: 25.0 > ups.mfr: American Power Conversion > ups.mfr.date: 2005/03/22 > ups.model: Back-UPS BR 800 > ups.serial: QB0513140434 > ups.status: OL > ups.temperature: 302.0 > ups.test.result: No test initiated > > In particular, the bad ones are: > battery.date, battery.temperature, input.voltage, ups.temperature, and maybe > battery.voltage. > > battery.date has a very wrong year. > > battery.temperature is very high. The NUT cgi scripts treat this value as a > reading in Celcius, which would seem appropriate. However, it looks as though > the UPS is actually giving a reading in Kelvin. 302 degrees Kelvin is about > 46 degrees Celius. That's a far more reasonable reading. The same conversion > would be appropriate for ups.temperature. > > input.voltage is just plain wrong. > > battery.voltage... I'm not really sure if this is wrong or not. It's higher > than the nominal voltage of 24V. Once charged, shouldn't the voltage be near > the "nominal" value? > > All of the other values look at least in the ballpark. The runtime looks > good. And by turning devices on and off I think the load value is correct to. > > > -- > --John Gruenenfelder Research Assistant, UMass Amherst student > Systems Manager, MKS Imaging Technology, LLC. > Try Weasel Reader for PalmOS -- http://gutenpalm.sf.net > "This is the most fun I've had without being drenched in the blood > of my enemies!" > --Sam of Sam & Max > > _______________________________________________ > Nut-upsuser mailing list > Nut-upsuser@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser >
2006/3/1, Peter Selinger <selinger@mathstat.dal.ca>:> This is a duplicate bug report. It was first reported by Gordon Rowell > on Feb 06 on the Nut-upsdev list, and has subsequently been fixed in > CVS. See > > http://boxster.ghz.cc/projects/nut/changeset/352 > > Arnaud, should we backport these bugfixes to 2.0.3? I have a feeling > we will see this bug reported several times more. >definitly, yes. but commit on the Testing branch.
OK, I just backported this bug fix to the testing branch. John, could you please check that it is now showing the correct values for your UPS? You can get the fixed version from SVN: svn co svn://svn.debian.org/svn/nut/branches/Testing then build as usual (./configure --with-drivers newhidups; make; make install). Please report back to the list. Thanks! -- Peter Arnaud Quette wrote:> > 2006/3/1, Peter Selinger <selinger@mathstat.dal.ca>: > > This is a duplicate bug report. It was first reported by Gordon Rowell > > on Feb 06 on the Nut-upsdev list, and has subsequently been fixed in > > CVS. See > > > > http://boxster.ghz.cc/projects/nut/changeset/352 > > > > Arnaud, should we backport these bugfixes to 2.0.3? I have a feeling > > we will see this bug reported several times more. > > > > definitly, yes. but commit on the Testing branch. >