[Nut-upsdev] Liebert GXT2 NUT driver
Robert Jobbagy
jobbagy.robert at gmail.com
Fri Apr 9 13:48:24 UTC 2010
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>
> Hi Arjen!
>
> This is the my last patch to Liebert GXT2 driver.
>
>
> ---------- Forwarded message ----------
> From: Robert Jobbagy <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>
>
>
> 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>
>
> 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> 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> 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>:
>>>>>
>>>>> 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
>>>> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Nut-upsdev mailing list
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20100409/3efcbde4/attachment-0001.htm>
More information about the Nut-upsdev
mailing list