[Nut-upsuser] battery.charge and other fixes needed for X-Power Tigra 1kVA

Tmima Pliroforikis Perifereiakis Enotitas Pierias pliroforiki at pieria.pkm.gov.gr
Fri May 11 06:05:02 UTC 2012


Charles Lepple wrote:
> On May 10, 2012, at 3:11 AM, Tmima Pliroforikis Perifereiakis Enotitas Pierias wrote:
>
>> 1) Any ideas on why battery.charge is set to -24.8 (note also the negative sign)
>
> The "bestups" driver does not have a lot of debugging information, and when that driver was written, it was also not possible to anticipate the wide range of products which would use this protocol.

Indeed, trying blazer_ser worked. I had to use novendor, but apart from 
that it does report data back to me, and battery charge seems perfect 
this time, without any needed adjustments to ups.conf:

battery.charge: 100
battery.voltage: 41.04
battery.voltage.high: 39.00
battery.voltage.low: 31.20
battery.voltage.nominal: 36.0
beeper.status: disabled
device.type: ups
driver.flag.novendor: enabled
driver.name: blazer_ser
driver.parameter.pollinterval: 2
driver.parameter.port: com1
driver.version: 2.6.3-3534:3545M
driver.version.internal: 1.52
input.current.nominal: 5.0
input.frequency: 50.0
input.frequency.nominal: 50
input.voltage: 225.1
input.voltage.fault: 223.7
input.voltage.nominal: 230
output.voltage: 230.7
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 35
ups.status: OL
ups.temperature: 30.0
ups.type: online

Thanks a zillion! Perhaps you'd like to add XPower Tigra 1000 to the 
database as working with blazer_ser?

> I think it is worth trying the "blazer_ser" driver (which theoretically works with a superset of the Best UPS protocols). If nothing else, it should provide some more information on the strings returned by the UPS, so it might be easier to see where that negative number is coming from.
>
>> 3) Regardless if the battery.charge is correct, will the system shutdown when battery charge is low?
>
> It should, since the "on battery" and "battery low" states are, by default, signaled by status bits directly from the UPS (not from any calculations in the driver).

Thanks, this is the single thing that I want to be properly working. I 
hope that the NUT Windows code to perform a shutdown and clean the 
killflag is stable, back then in FreeBSD I did stumble upon a number of 
power race issues. Hope they are resolved here.

And some more questions:

1) Upon reception of a shutdown command, my server takes approx. 60" for 
shutdown. Can I set on this Windows server the ups itself to power down 
after say 90"? According to the upsc output above, the ups has set 
ups.delay.shutdown to 30". By adding offdelay = 120 (from the docs it 
seems that offdelay values > 60" are rounded to multiples of 60") in 
ups.conf or by other means will NUT as part of the shutdown procedure 
call automatically:
	upscmd <upsname> shutdown.return 1
for it to work? Or should I insert this command somewhere to make sure 
that the offdelay value will be respected?

2) Similarly, I'd like the UPS to turn on after 3'. ondelay is already 
set to 180". Should I do something else like specifying:
	upscmd <upsname> shutdown.return 1
at some point, or will upsmon take care of this automatically?

3) Finally, something tricky. Upon reception low battery, I would also 
like to issue an extra command to a VMWare ESXi 5 (the free vSphere 
hypervisor) host to turn off. This is the free ESXi 5 version. I have 
found a related article, which needs a SSH connection to occur the 
VMWare host at shutdown time. So I was thinking on how a command like 
that should be issued. Remember that the server that the UPS is 
connected to is a physical (not VM) Win 2003 server. Would modifying 
SHUTDOWNCMD to, say, :
SHUTDOWNCMD "C:\\myown.bat"

...and having myown.bat do the actual shutdown, in parallel with the 
SSHing stuff like do the trick?

myown.bat:
==========
SSH cmd here blah blah
C:\WINDOWS\system32\shutdown.exe -s -t 0
========================================

Thanks for your info!

BR,


Michail.-



More information about the Nut-upsuser mailing list