[Nut-upsdev] Liebert GXT2 NUT driver
Robert Jobbagy
jobbagy.robert at gmail.com
Fri Apr 9 15:48:48 UTC 2010
Hi Richard,
I wrote to Liebert support that my ups has the features what I wrote on this
maillist.
I gave a answer this:
Our UPSs will not support that for security purposes. There is a battery
test function in MultiLink that will do a short test on that battery but the
UPS will still maintain AC power. Let me know if you have any more
questions.
2010/4/9 Richard Gregory <R.Gregory at liverpool.ac.uk>
> 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 <http://www.csc.liv.ac.uk/%7Egreg> |
> +-- --+
>
> 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>
>> <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
>>
>>
--
Best Regards,
Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20100409/f3f06807/attachment-0001.htm>
More information about the Nut-upsdev
mailing list