[Nut-upsdev] Liebert GXT2 NUT driver
Richard Gregory
R.Gregory at liverpool.ac.uk
Fri Apr 9 14:47:12 UTC 2010
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 <jobbagy.robert at gmail.com
> <mailto:jobbagy.robert at gmail.com>>
>
> Hi Arjen!
>
> This is the my last patch to Liebert GXT2 driver.
>
>
> ---------- Forwarded message ----------
> From: *Robert Jobbagy* <jobbagy.robert at gmail.com
> <mailto:jobbagy.robert at gmail.com>>
> Date: 2010/4/7
> Subject: Re: [Nut-upsdev] Liebert GXT2 NUT driver
> To: NUT Developers <nut-upsdev at lists.alioth.debian.org
> <mailto:nut-upsdev at lists.alioth.debian.org>>
>
>
> 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 <sivann at gmail.com <mailto:sivann at gmail.com>>
>
> 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 <sivann at gmail.com
> <mailto:sivann at gmail.com>> 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
> <R.Gregory at liverpool.ac.uk
> <mailto:R.Gregory at liverpool.ac.uk>> 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 <jobbagy.robert at gmail.com
> <mailto:jobbagy.robert at gmail.com>>:
>
> 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
> Nut-upsdev at lists.alioth.debian.org
> <mailto:Nut-upsdev at lists.alioth.debian.org>
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>
>
>
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> <mailto:Nut-upsdev at lists.alioth.debian.org>
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>
>
>
>
> --
> Best Regards,
>
> Robert
>
>
>
> --
> Best Regards,
>
> Robert
>
>
>
>
> --
> Best Regards,
>
> Robert
>
More information about the Nut-upsdev
mailing list