Hi Robert,
Liebert's Multilink is the only original source of information, so if
Multilink doesn't do it, there is no known command. If Multilink does
offer that function, you will still need to sniff the protocol to find
the commands it uses - only then will it be possible to implement this
feature in NUT.
With regard to the patches so far, we have:
1. reply[] byte swap patch
2. All the other instances of byte swapping reply[] patch
3. "ups.firmware" register location patch
In between this, there was Spiros's observation that the the Liebert NXe
doesn't return some of the text strings that the GXT2 returns. Assuming
the driver is otherwise compatible (is it??), the most compatible fix is
to get the strings separately and only make some of them an error condition.
Also, the NXe has two serial ports, one 2400 baud (same as the GXT2),
which is disabled when using the ethernet option and another at 9600
baud. The NUT driver assumes 2400 baud. To find how to implement this,
will need to find an example NUT driver that uses differing serial baud
rates, any suggestions?
Richard
+-- --+
| Biological Sciences, Room 231 |
| http://www.csc.liv.ac.uk/~greg |
+-- --+
Robert Jobbagy wrote:
Hi guys,
I would like switch to battery from online my ups.
Is it possible?exist something command that I do it?
Thanks your help.
2010/4/9 Robert Jobbagy <[email protected]
<mailto:[email protected]>>
Hi Arjen!
This is the my last patch to Liebert GXT2 driver.
---------- Forwarded message ----------
From: *Robert Jobbagy* <[email protected]
<mailto:[email protected]>>
Date: 2010/4/7
Subject: Re: [Nut-upsdev] Liebert GXT2 NUT driver
To: NUT Developers <[email protected]
<mailto:[email protected]>>
Hi Guys,
I tested this driver and I found a bug,
The wrong output:
device.serial: GXT2MR15D
ups.firmware: 12OCT04
ups.mfr.date: 0428100126AF041
ups.serial: GXT2MR15D
The right output:
device.serial: 0428100126AF041
ups.firmware: GXT2MR15D
ups.mfr.date: 12OCT04
ups.serial: 0428100126AF041
I fix it and attached the patch.
2010/4/7 Spiros Ioannou <[email protected] <mailto:[email protected]>>
On the battery issue:
I did some tests:
BATTERY_CAPACITY is always 94%, no matter its charge, probably
indicating its decay.
BATTERY_CHARGED is always NO for me
BATTERY_CURRENT does actually indicate when battery is charging
or discharging. In the case of discharging (ups on battery) a
negative value is indicated.
The correct value can be calculated as follows:
float f;
f=(signed short int)(256*H+L)/(float)100; //100 is the divider
to convert value to Amperes.
The actual value of BATTERY_CURRENT in Amperes need to be
divided by 100:
*CHARGING:*
# ./upsesp2 /dev/ttyS0 BATTERY_CURRENT
SendingM: 001,095,002,001,003,09C
BATTERY_CURRENT,bit/divider:100
READ : 001,095,004,001,003, 001,056 (001 086), 0F5 (returned
values H,L are decimal 001 086)
BATTERY_CURRENT: 3.4
*DISCHARGING (on battery)*
# ./upsesp2 /dev/ttyS0 BATTERY_CURRENT
SendingM: 001,095,002,001,003,09C
BATTERY_CURRENT,bit/divider:100
READ : 001,095,004,001,003, 0FC,020 (252 032), 0BA
BATTERY_CURRENT: -9.9
-9.9 comes from (255-252)*256 + (255-032) or by casting to
signed short int which does the same.
After the power comes back on, between discharging and charging
there is a period of no battery current (0 Amp) for a few seconds.
-S
On Tue, Apr 6, 2010 at 9:12 PM, Spiros Ioannou <[email protected]
<mailto:[email protected]>> wrote:
Hi,
I managed to find another Liebert UPS, this time a Liebert
NXe 20KVA unit, so I can help with the driver again.
This one has 2 serial ports, one gets disabled if you
connect the ethernet module. The other port is @9600bps. The
9600 is the one I use.
I applied Richard's patch with the bit correction, and tried
the driver (after changing the bitrate), but it failed at
startup because Liebert NXe doesn't provide its Serial
Number. It seems when trying to read the initial UPS
model,SN etc, the UPS replies an invalid 5-byte reply
instead of the usual 8-byte one. I attach a debug output
(hex) from my upsesp2.c for comparison. Look at line 109 of
dbg_hex.txt.
The solution is to replace
for (i = 0; i < 37; i++) {
with
for (i = 0; i < 15; i++) {
to just check for MODEL_NAME
As for the CHARGED, it seems that in my case the battery
BATTERY_CHARGED is always NO perhaps because the UPS uses a
percentage battery charge indicator (BATTERY_CAPACITY). I'm
not sure I follow your logic with ANDing with the OL flag.
The Charging could probably be deducted from the
BATTERY_CURRENT value.This could be negative if the battery
is charging, but I cannot test it right now.
./liebertgxt2 -a nxe -DD
Network UPS Tools - Liebert GXT2 serial UPS driver 0.02
(2.4.3-2420)
Warning: This is an experimental driver.
Some features may not function correctly.
0.000000 debug level is '2'
0.000737 send: (6 bytes) => 01 88 02 01 04 90
0.072087 read: (8 bytes) => 01 88 04 01 04 69 4c 47
0.072216 send: (6 bytes) => 01 88 02 01 05 91
0.136206 read: (8 bytes) => 01 88 04 01 05 62 65 5a
0.136343 send: (6 bytes) => 01 88 02 01 06 92
0.202086 read: (8 bytes) => 01 88 04 01 06 72 65 6b
0.202209 send: (6 bytes) => 01 88 02 01 07 93
0.266083 read: (8 bytes) => 01 88 04 01 07 20 74 29
0.266205 send: (6 bytes) => 01 88 02 01 08 94
0.328099 read: (8 bytes) => 01 88 04 01 08 58 4e 3c
0.328222 send: (6 bytes) => 01 88 02 01 09 95
0.402090 read: (8 bytes) => 01 88 04 01 09 00 20 b7
0.402212 send: (6 bytes) => 01 88 02 01 0a 96
0.468096 read: (8 bytes) => 01 88 04 01 0a 00 00 98
0.468220 send: (6 bytes) => 01 88 02 01 0b 97
0.559082 read: (8 bytes) => 01 88 04 01 0b 00 00 99
0.559205 send: (6 bytes) => 01 88 02 01 0c 98
0.623082 read: (8 bytes) => 01 88 04 01 0c 00 00 9a
0.623204 send: (6 bytes) => 01 88 02 01 0d 99
0.687179 read: (8 bytes) => 01 88 04 01 0d 00 00 9b
0.687316 send: (6 bytes) => 01 88 02 01 0e 9a
0.753149 read: (8 bytes) => 01 88 04 01 0e 00 00 9c
0.753285 send: (6 bytes) => 01 88 02 01 0f 9b
0.818205 read: (8 bytes) => 01 88 04 01 0f 00 00 9d
0.818342 send: (6 bytes) => 01 88 02 01 10 9c
0.880087 read: (8 bytes) => 01 88 04 01 10 00 00 9e
0.880210 send: (6 bytes) => 01 88 02 01 11 9d
0.972080 read: (8 bytes) => 01 88 04 01 11 00 00 9f
0.972203 send: (6 bytes) => 01 88 02 01 12 9e
1.052085 read: (8 bytes) => 01 88 04 01 12 00 00 a0
1.052211 send: (6 bytes) => 01 88 02 01 13 9f
1.116147 read: (8 bytes) => 01 88 04 01 13 31 49 1b
1.116283 send: (6 bytes) => 01 88 02 01 14 a0
1.180087 read: (8 bytes) => 01 88 04 01 14 30 37 09
1.180210 send: (6 bytes) => 01 88 02 01 15 a1
1.263082 read: (8 bytes) => 01 88 04 01 15 31 52 26
1.263205 send: (6 bytes) => 01 88 02 01 16 a2
1.329086 read: (8 bytes) => 01 88 04 01 16 30 35 09
1.329210 send: (6 bytes) => 01 88 02 01 17 a3
1.395086 read: (8 bytes) => 01 88 04 01 17 32 4d 24
1.395208 send: (6 bytes) => 01 88 02 01 18 a4
1.469080 read: (8 bytes) => 01 88 04 01 18 30 36 0c
1.469202 send: (6 bytes) => 01 88 02 01 19 a5
1.533086 read: (8 bytes) => 01 88 04 01 19 00 00 a7
1.533209 send: (6 bytes) => 01 88 02 01 1a a6
1.597114 read: (8 bytes) => 01 88 04 01 1a 00 00 a8
1.597239 send: (6 bytes) => 01 88 02 01 1b a7
1.662085 read: truncated: (5 bytes) => 01 37 01 04 3d
1.662194 GTX2 capable UPS not detected
On Tue, Apr 6, 2010 at 4:32 PM, Richard Gregory
<[email protected]
<mailto:[email protected]>> wrote:
Hi All,
There were other byte swap issues with the driver,
making all the bit field flags wrong. Have swapped them
and can confirm the OL, OB and CHRG flags work. CHaRGing
is not the inverse of Liebert's BATTERY_CHARGED flag as
that means CHRG is set when the UPS is on battery. Is it
reasonable to correct for this by ANDing with the OL flag?
Byte swapping patch attached.
Richard
+-- --+
| Biological Sciences, Room 231 |
| http://www.csc.liv.ac.uk/~greg
<http://www.csc.liv.ac.uk/%7Egreg> |
+-- --+
Arjen de Korte wrote:
Citeren Robert Jobbagy <[email protected]
<mailto:[email protected]>>:
The trouble was in the command reply buffer use.
You compute the value that value =
reply[6]*256+reply[5] <- it's wrong
The right solution: value = reply[5] * 256 +
reply[6];
Thanks for this patch. I just committed it to the
development version. But please note that this is
an experimental driver. Most of the functions are
untested (since nobody took the time to try it out
and post the results back to the mailing list).
And other bug,
battery.runtime compute, you divide this value
60 <- it's wrong
right value: divide 1.0
Probably not. Per the NUT standard, the
'battery.runtime' value is reported in seconds. As
far as I understand, the UPS reports runtime
remaining in minutes, so we need to multiply by 60
here. See 'docs/new-names.txt' for a listing of
(almost) all variables supported in NUT.
I continue the work on this driver,and I will
write if I make a something
new.
Please do. It should be trivial to add additional
commands and variables to the existing ones.
Best regards, Arjen
_______________________________________________
Nut-upsdev mailing list
[email protected]
<mailto:[email protected]>
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
_______________________________________________
Nut-upsdev mailing list
[email protected]
<mailto:[email protected]>
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
--
Best Regards,
Robert
--
Best Regards,
Robert
--
Best Regards,
Robert
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
