liebert-esp2 driver: some values not correctly retrieved

[pasquik]

Hello,
When using the upsc command on a Liebert GTX3000-RT230 with a contact closure cable the following is retrieved:

root@earth:# upsc qnapups
battery.current: 0.00
battery.runtime: 27180
battery.runtime.low: 120
battery.temperature: 0.0
battery.voltage: 829.0
battery.voltage.nominal: 828.0
device.mfr: Liebert
device.model: GXT2-3000RT230
device.serial: 0307000120AF491
device.type: ups
driver.name: liebert-esp2
driver.parameter.pollinterval: 2
driver.parameter.port: /dev/ttyS0
driver.version: 2.6.4
driver.version.internal: 0.03
input.bypass.current: 0.0
input.bypass.frequency: 50.0
input.bypass.voltage: 224.8
input.frequency: 50.0
input.frequency.nominal: 50.0
input.phases: 1
input.voltage: 224.8
output.current: 0.8
output.frequency: 50.0
output.frequency.nominal: 50.0
output.phases: 1
output.voltage: 230.4
ups.delay.start: 30
ups.firmware: GXT2MR15D-2K3K
ups.load: 0
ups.mfr: Liebert
ups.mfr.date: 10MAR03
ups.model: GXT2-3000RT230
ups.power: 0
ups.power.nominal: 3000
ups.realpower: 0
ups.serial: 0307000120AF491
ups.status: OL
ups.temperature: 33.5
ups.type: online
root@earth:#

as you can see some of these values are "0". Obviously aren't the correct ones. So e.g. ups.load and ups.realpower are really important.
Currently running on:

root@earth:# uname -a
Linux earth 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u2 x86_64 GNU/Linux
root@falken:#

root@earth:~# apt-cache policy nut-server
nut-server:
Installed: 2.6.4-2.3+deb7u1
Candidate: 2.6.4-2.3+deb7u1
Version table:
*** 2.6.4-2.3+deb7u1 0
500 http://ftp.debian.org/debian/ wheezy/main amd64 Packages
100 /var/lib/dpkg/status

[clepple]

Can you try killing the driver, and running it in debug mode?

# killall liebert-esp2
# /lib/nut/liebert-esp2 -a qnapups -DD | tee /tmp/liebert-esp2.log

Not sure how long it will take to read everything, but if the values are always zero, just the first few polling cycles (until upsc returns data like what you posted earlier) should be sufficient.

It is possible that it is getting the wrong multipliers, but there should be reasonable defaults.

[pasquik]

Hi, thank you so much for your answer
here you can find the output of the driver running in debug mode

liebert-esp2.log

and the output of the upsc command.

upsc command output

Feel free to contact me if you need further tests

[clepple]

Just to confirm: is this a single-phase, or three-phase UPS?

Scaling seems to be read here:

https://github.com/networkupstools/nut/blob/master/drivers/liebert-esp2.c#L239

do_command(cmd_scaling1) ->

3.350844 send: (6 bytes) => 01 83 02 01 02 89
3.438632 read: (8 bytes) => 01 83 04 01 02 00 01 8c

reply[6] == 1, which is GXT2, which matches your UPS.

On the other hand, regardless of the scaling constants, zero multiplied by anything is still zero:

20.430784 send: (6 bytes) => 01 95 02 01 06 9f
20.518589 read: (8 bytes) => 01 95 04 01 06 00 00 a1

I'm assuming the reply is the '00 00', following the pattern of the previous query/response.

Looking back in the archives, I notice that some of the commands from this test program are not in the NUT driver:

http://lists.alioth.debian.org/pipermail/nut-upsdev/2009-January/003772.html

Can you compile and run that (with the NUT driver stopped), and let us know what the output looks like?

There is also a slightly newer version that I haven't looked at yet:

http://lists.alioth.debian.org/pipermail/nut-upsdev/2010-April/004726.html

[pasquik]

it is a single phase on-line UPS.

As you requested Here the output of upsesp2.c and the new version Here.

Thank you

[clepple]

It seems as though the test programs match the driver output, e.g.:

SendingM: 001,149,002,001,005,158   LOAD_WATTS,bit/divider:1
READ    : 001,149,004,001,005, 000,000 (000 000), 160
LOAD_WATTS: 0.0

SendingM: 001,149,002,001,006,159   LOAD_VA,bit/divider:1
READ    : 001,149,004,001,006, 000,000 (000 000), 161
LOAD_VA: 0.0

SendingM: 001,149,002,001,007,160   LOAD_PERCENT,bit/divider:1
READ    : 001,149,004,001,007, 000,000 (000 000), 162
LOAD_PERCENT: 0.0

We try not to compute values in the drivers unless there is no other source for them. In your case, output voltage and current are provided, so it would be possible, but it would not be automatic (the UPS should return "not supported" instead of 0 for LOAD_WATTS, etc).

If you have access to the original software for the UPS, it would be interesting to see how it comes up with the values. You might need to use a tool such as PortMon: http://technet.microsoft.com/en-us/sysinternals/bb896644.aspx