[Nut-upsdev] Tripplite Smart1500SLT configuration?

Jeff Cunningham jeffrey at cunningham.net
Sat Jul 26 04:27:13 UTC 2008


Arjen de Korte wrote:
>> The 'upsmon -c fsd' is successful.
>> When I pulled the mains plug from the UPS the power stayed up, my
>> consoles notified me I was on battery power. When I ran 'upsmon -c fsd'
>> it shutdown the system cleanly, but the UPS continued to beep
>> indefinitely.
>>
>> Is that normal behavior? At what point does the UPS get shut off to
>> protect the battery from total discharge? I'll confess I am fairly
>> ignorant about what's supposed to happen here, but I understand you
>> don't want to let these batteries go completely dead.
>>     
>
> I suggest that you first read the INSTALL document that came with NUT. If
> anything is not clear after reading this (and the other documentation it
> references), come back to the mailinglist. I don't reply to messages sent
> to me in private, unless a consulting fee is involved.
>   
My humble apologies - I hit reply, expecting that it would go to the 
list (most of the lists I subscribe to are set up that way) and didn't 
notice it was addressed to an individual. So sorry!

I actually have read trunk/INSTALL, trunk/README, most of the files in 
trunk/docs. I think I have a pretty good idea  how it works, but I'm not 
entirely sure about this one point about whether or not the UPS can be 
instructed to power itself off to spare the battery from going totally 
dead. This is important to me because I live up in the mountains and in 
the winter we lose power several times every winter for longer than most 
UPS's can stay up. Their purpose is to keep things up over the glitches 
and short outages.
>   
>> One other question occurred to me. If you look at the status output
>> again the load doesn't seem to make sense:
>>
>> root at golum:# /usr/local/ups/bin/upsc tripplite at localhost
>> battery.charge: 100
>> battery.charge.low: 10
>> battery.charge.warning: 30
>> battery.temperature: 26.9
>> battery.type: PbAC
>> battery.voltage: 40.9
>> battery.voltage.nominal: 36.0
>> driver.name: usbhid-ups
>> driver.parameter.pollfreq: 30
>> driver.parameter.pollinterval: 2
>> driver.parameter.port: auto
>> driver.parameter.vendorid: 09ae
>> driver.version: 2.3.0-1515
>> driver.version.data: TrippLite HID 0.2 (experimental)
>> driver.version.internal: 0.33
>> input.frequency: 59.9
>> input.transfer.high: 145.0
>> input.transfer.low: 95.0
>> input.voltage: 120.9
>> input.voltage.nominal: 120
>> output.frequency: 59.9
>> output.frequency.nominal: 60
>> output.voltage: 120.3
>> output.voltage.nominal: 120
>> ups.beeper.status: enabled
>> ups.delay.shutdown: 20
>> ups.delay.start: 30
>> ups.load: 12
>> ups.mfr: Tripp Lite
>> ups.model: TRIPP LITE SMART1500SLT
>> ups.power.nominal: 1500
>> ups.productid: 3012
>> ups.serial: 9605ALCSM538800161
>> ups.status: OL
>> ups.timer.reboot: -1
>> ups.timer.shutdown: -1
>> ups.timer.start: -1
>> ups.vendorid: 09ae
>> ups.watchdog.status: 0
>>
>> I recall in that thread from a year ago that a 'bug' was fixed for one
>> device by dividing by 10? Would that still be the case? Is my real load
>> 120 Watts? If so, it we've got a 'two against one' situation here: maybe
>> the ad hoc divisor out to come out so reality prevails for a majority of
>> the Tripplite devices   :-)
>>     
>
> Short answer, this is not a bug.
>
> Somewhat longer answer. See the description from 'docs/new-names.txt' for
> this variable. The divisor used depends on the model and is conservatively
> only applied for models that we know need it. Yours doesn't and by the way
> dealt with the battery voltage, not the load. Please note that 'upsc' is
> just an example lightweight UPS client and is not meant to be used without
> fully understanding how NUT (and the variable naming) works.
>
> Best regards, Arjen
>
>   
Thank you for straightening me out on that one. I guess I am surprised 
that that this UPS is showing a ups.load=12%. When I put the same load 
on the other UPS I have (an APC 1500) it shows about an 80 Watt 
continuous load. I thought it was possible there might be a scale factor 
difference still in play.

Regards,
--Jeff



More information about the Nut-upsdev mailing list