Nut upsuser - Dec 2012 - Tripp Lite SMART1000RM2U

Hi,

I recently purchased a Tripp Lite SMART1000RM2U UPS
(http://www.tripplite.com/en/products/model.cfm?txtSeriesID=744&txtModelID=2657)
and tried to configure the NUT with tripplite_usb driver and encounter
the following problems:

1. battery.charge doesn't report correct charge level when the UPS is
On Batter.  It just reports 0.  Even though it will report 100 when on
line power.

2. I tried a shutdown test, but the NUT daemon failed to issue the
shutdown command.  About 30 min after I switched off the line power,
the UPS started the long beep, which indicated low battery, and I did
receive the LOWBATTERY notification from the NUT daemon.  But the
computer didn't shutdown, until another 25 min later, when the battery
was depleted.

3. Another thing I suppose it's a problem of the UPS itself, is that
it will go into ONBATTERY status for a few seconds, even though the
line power is never lost.  I guess it could be caused by some
transient in the power line?

I've listed the output of upsc and tripplite_usb --DDD below.  I'm
running NUT 2.4.3 with tripplite_usb driver 0.20 on Fedora 14 x86_64.

[root at denali ~]# upsc serverups
battery.charge: 100
battery.voltage: 27.40
battery.voltage.nominal: 24
device.mfr: Tripp Lite
device.model: SMART1000RM2U
device.type: ups
driver.name: tripplite_usb
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.product: .*SMART1000RM2U.*
driver.version: 2.4.3
driver.version.internal: 0.20
input.frequency: 60.0
input.frequency.nominal: 60
input.voltage: 115
input.voltage.maximum: 123
input.voltage.minimum:   0
input.voltage.nominal: 120
outlet.1.desc: Load 1
outlet.1.id: 1
outlet.1.switch: 1
outlet.1.switchable: 1
outlet.2.desc: Load 2
outlet.2.id: 2
outlet.2.switch: 1
outlet.2.switchable: 1
outlet.3.desc: Load 3
outlet.3.id: 3
outlet.3.switchable: 0
ups.debug.D: 37 35 38 41 0d 00 00 '758A...'
ups.debug.load_banks: 2
ups.debug.S: 31 34 30 00 64 30 0d '140.d0.'
ups.debug.T: 38 44 32 35 38 31 0d '8D2581.'
ups.debug.V: 31 30 34 32 58 58 0d '1042XX.'
ups.delay.shutdown: 64
ups.firmware: F1218.A
ups.firmware.aux: protocol 3003
ups.id: 65535
ups.load: 19
ups.mfr: Tripp Lite
ups.model: SMART1000RM2U
ups.power.nominal: 1000
ups.productid: 0001
ups.status: OL
ups.temperature: 30.3
ups.vendorid: 09ae

[root at denali ~]# tripplite_usb -DDD -a serverups
Network UPS Tools - Tripp Lite OMNIVS / SMARTPRO driver 0.20 (2.4.3)
Warning: This is an experimental driver.
Some features may not function correctly.

   0.000000     debug level is '3'
   0.041911     Checking device (09AE/0001) (002/006)
   0.054038     - VendorID: 09ae
   0.054081     - ProductID: 0001
   0.054099     - Manufacturer: TRIPP LITE
   0.054118     - Product: TRIPP LITE SMART1000RM2U
   0.054137     - Serial Number: unknown
   0.054155     - Bus: 002
   0.054172     Trying to match device
   0.054431     Device matches
   0.060025     Detected a UPS: TRIPP LITE/TRIPP LITE SMART1000RM2U
   0.060105     send_cmd(msg_len=2, type='
   0.173908     Using SMARTPRO protocol (3003)
   0.173939     send_cmd(msg_len=2, type='S')
   0.301966     send_cmd(msg_len=2, type='P')
   0.430071     send_cmd(msg_len=2, type='F')
   0.558070     send_cmd(msg_len=2, type='V')
   0.685956     send_cmd(msg_len=2, type='V')
   0.814089     send_cmd(msg_len=2, type='U')
   0.941977     Unit ID: 65535
Attached to Tripp Lite SMART1000RM2U
   0.942057     send_cmd(msg_len=2, type='S')
   1.069977     send_cmd(msg_len=2, type='D')
   1.197972     send_cmd(msg_len=2, type='M')
   1.325961     send_cmd(msg_len=2, type='T')
   1.454100     send_cmd(msg_len=2, type='L')
   1.581984     send_cmd(msg_len=2, type='D')
   1.710176     dstate_init: sock /var/run/nut/tripplite_usb-serverups
open on fd 5
   1.710227     send_cmd(msg_len=2, type='S')
   1.837960     send_cmd(msg_len=2, type='D')
   1.965919     send_cmd(msg_len=2, type='M')
   2.093898     send_cmd(msg_len=2, type='T')
   2.221909     send_cmd(msg_len=2, type='L')
   2.349886     send_cmd(msg_len=2, type='D')
   3.711517     send_cmd(msg_len=2, type='S')
   3.821631     send_cmd(msg_len=2, type='D')
   3.949819     send_cmd(msg_len=2, type='M')
   4.077798     send_cmd(msg_len=2, type='T')
   4.205805     send_cmd(msg_len=2, type='L')
   4.333797     send_cmd(msg_len=2, type='D')
   5.712795     send_cmd(msg_len=2, type='S')
   5.837575     send_cmd(msg_len=2, type='D')
   5.965731     send_cmd(msg_len=2, type='M')
   6.093715     send_cmd(msg_len=2, type='T')
   6.221735     send_cmd(msg_len=2, type='L')
   6.349725     send_cmd(msg_len=2, type='D')
   7.714064     send_cmd(msg_len=2, type='S')
   7.821224     send_cmd(msg_len=2, type='D')
   7.949666     send_cmd(msg_len=2, type='M')
   8.077652     send_cmd(msg_len=2, type='T')
   8.205634     send_cmd(msg_len=2, type='L')
   8.333612     send_cmd(msg_len=2, type='D')
   9.715343     send_cmd(msg_len=2, type='S')
   9.837281     send_cmd(msg_len=2, type='D')
   9.965593     send_cmd(msg_len=2, type='M')
  10.093572     send_cmd(msg_len=2, type='T')

On Dec 7, 2012, at 3:01 AM, Dawning Sky wrote:
> 1. battery.charge doesn't report correct charge level when the UPS is
> On Batter.  It just reports 0.  Even though it will report 100 when on
> line power.
I wonder if this is connected with the following:
> ups.debug.S: 31 34 30 00 64 30 0d '140.d0.'
As I remember it, '4' is the status character representing
"self-test status is unknown". You might need to do a deep discharge
test first before the state-of-charge constants are programmed into the UPS.

If you can start a deep discharge test from the front panel, I'd try that
first. Otherwise, there is a "test.battery.start" command in NUT which
might be what you're looking for. However, bear in mind that this driver was
written without the benefit of protocol documentation.

-- 
Charles Lepple
clepple at gmail

[please keep the list CC'd. thanks]

On Dec 10, 2012, at 3:31 AM, Dawning Sky wrote:
> On Sun, Dec 9, 2012 at 5:30 PM, Charles Lepple <clepple at gmail.com>
wrote:
>> On Dec 7, 2012, at 3:01 AM, Dawning Sky wrote:
>> 
>>> 1. battery.charge doesn't report correct charge level when the
UPS is
>>> On Batter.  It just reports 0.  Even though it will report 100 when
on
>>> line power.
>> 
>> I wonder if this is connected with the following:
>> 
>>> ups.debug.S: 31 34 30 00 64 30 0d '140.d0.'
>> 
>> As I remember it, '4' is the status character representing
"self-test status is unknown". You might need to do a deep discharge
test first before the state-of-charge constants are programmed into the UPS.
>> 
>> If you can start a deep discharge test from the front panel, I'd
try that first. Otherwise, there is a "test.battery.start" command in
NUT which might be what you're looking for. However, bear in mind that this
driver was written without the benefit of protocol documentation.
>> 
> 
> Charles,
> 
> Thanks for getting back to me.  I thought I did a battery test from
> the front panel some time ago.  Just to be sure, I did another test
> from the panel and a test by test.battery.start.  It doesn't seem to
> help with the battery.charge.  Part of upsc output is
> 
> battery.charge: 0
> battery.test.status: Battery OK
> battery.voltage: 25.20
> ...
> ups.debug.S: 31 30 30 00 00 30 0d '100..0.'
OK. Not really sure what to tell you - that 5th byte is what is converted to
state-of-charge, and your original post had 64 when battery.charge was 100%.

If you have a Windows system handy (might work in VirtualBox or VMWare), you can
compare with the regular Tripp Lite software.
> In any case, I can probably live with this.  But I'm really troubled
> with the fact that the NUT daemon didn't issue the shutdown command,
> even though Do you have any thoughts on this?  Is it possible that the
> user "nut" doesn't have the privilege to shutdown?

I misread the part where you mentioned that you got the low battery signal - I
was thinking "on battery".

upsmon is designed to be started as root, and when it forks, it leaves behind a
parent process that retains root privileges:

http://www.networkupstools.org/docs/man/upsmon.html#_reloading_nuances

If SHUTDOWNCMD is a script, check permissions on it. (Even root needs execute
permissions on scripts - it's only the read/write permissions that it can
override.) Also, the next section in the above URL mentions 'upsmon -c
fsd', which can be used to test the shutdown sequence without draining the
UPS.

Are you building from source, or installing a package?

-- 
Charles Lepple
clepple at gmail