Hi guys, I found the troblue and fix it! I attached the patch. 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]; And other bug, battery.runtime compute, you divide this value 60 <- it's wrong right value: divide 1.0 I continue the work on this driver,and I will write if I make a something new. I'm waiting for your reactions. -- Best Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20100402/af41cab9/attachment.htm> -------------- next part -------------- A non-text attachment was scrubbed... Name: liebertgxt2_patch Type: application/octet-stream Size: 868 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20100402/af41cab9/attachment.obj>
Citeren Robert Jobbagy <jobbagy.robert op 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.0Probably 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 -- Please keep list traffic on the list
2010/4/2 Robert Jobbagy <jobbagy.robert at gmail.com>> > > 2010/4/2 Arjen de Korte <nut+devel at de-korte.org <nut%2Bdevel at de-korte.org> > > > > 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. > > > Sorry,it's my mistake. I didn't look it. > Thanks your advice. > >> >> >> 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. >> >> I need work on this driver and I would like add some command and > features this driver what be usefull for me. > I will send it on this maillist. > >> >> Best regards, Arjen >> -- >> Please keep list traffic on the list >> >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20100402/da469d75/attachment.htm>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20100407/57f60bbf/attachment-0001.htm>
-------------- next part --------------
SendingM: 001,095,002,001,001,09A BATTERY_TIME_REMAIN,bit/divider:1
READ : 001,095,004,001,001,000,0E9,085
BATTERY_TIME_REMAIN: 233.0
SendingM: 001,095,002,001,002,09B BATTERY_VOLTAGE,bit/divider:10
READ : 001,095,004,001,002,015,021,0D3
BATTERY_VOLTAGE: 540.9
SendingM: 001,0A1,002,001,00D,0B2 BATTERY_VOLTAGE_NOMINAL,bit/divider:10
READ : 001,0A1,004,001,00D,000,000,0B4
BATTERY_VOLTAGE_NOMINAL: 0.0
SendingM: 001,095,002,001,003,09C BATTERY_CURRENT,bit/divider:1
READ : 001,095,004,001,003,000,000,09E
BATTERY_CURRENT: 0.0
SendingM: 001,095,002,001,004,09D BATTERY_CAPACITY,bit/divider:1
READ : 001,095,004,001,004,000,05E,0FD
BATTERY_CAPACITY: 94.0
SendingM: 001,090,002,001,001,095 BYPASS_VOLTAGE,bit/divider:10
READ : 001,090,004,001,001,009,040,0E0
BYPASS_VOLTAGE: 236.8
SendingM: 001,0A1,002,001,008,0AD MAX_LOAD,bit/divider:1
READ : 001,0A1,004,001,008,000,0C8,077
MAX_LOAD: 200.0
SendingM: 001,095,002,001,005,09E LOAD_WATTS,bit/divider:1
READ : 001,095,004,001,005,000,000,0A0
LOAD_WATTS: 0.0
SendingM: 001,095,002,001,006,09F LOAD_VA,bit/divider:1
READ : 001,095,004,001,006,000,000,0A1
LOAD_VA: 0.0
SendingM: 001,095,002,001,007,0A0 LOAD_PERCENT,bit/divider:1
READ : 001,095,004,001,007,000,000,0A2
LOAD_PERCENT: 0.0
SendingM: 001,095,002,001,008,0A1 INPUT_FREQUENCY,bit/divider:10
READ : 001,095,004,001,008,013,086,03C
INPUT_FREQUENCY: 499.8
SendingM: 001,095,002,001,009,0A2 OUTPUT_FREQUENCY,bit/divider:10
READ : 001,095,004,001,009,013,082,039
OUTPUT_FREQUENCY: 499.4
SendingM: 001,095,002,001,00A,0A3 BYPASS_FREQUENCY,bit/divider:10
READ : 001,095,004,001,00A,013,082,03A
BYPASS_FREQUENCY: 499.4
SendingM: 001,095,002,001,00B,0A4 INVERTER_TEMP,bit/divider:10
READ : 001,095,004,001,00B,000,000,0A6
INVERTER_TEMP: 0.0
SendingM: 001,095,002,001,00C,0A5 BATTERY_TEMP,bit/divider:10
READ : 001,095,004,001,00C,000,0C8,06F
BATTERY_TEMP: 20.0
SendingM: 001,095,002,001,00D,0A6 PFC_TEMP,bit/divider:10
READ : 001,095,004,001,00D,000,000,0A8
PFC_TEMP: 0.0
SendingM: 001,095,002,001,00E,0A7 AMBIENT_TEMP,bit/divider:10
READ : 001,095,004,001,00E,000,0FA,0A3
AMBIENT_TEMP: 25.0
SendingM: 001,090,002,001,003,097 OUTPUT_VOLTAGE,bit/divider:10
READ : 001,090,004,001,003,009,007,0A9
OUTPUT_VOLTAGE: 231.1
SendingM: 001,090,002,001,004,098 OUTPUT_CURRENT,bit/divider:10
READ : 001,090,004,001,004,000,028,0C2
OUTPUT_CURRENT: 4.0
SendingT: 001,088,002,001,004,090 MODEL_NAME,length:15
READ : 001,088,004,001,004,069,04C,047
SendingT: 001,088,002,001,005,091 MODEL_NAME,length:14
READ : 001,088,004,001,005,062,065,05A
SendingT: 001,088,002,001,006,092 MODEL_NAME,length:13
READ : 001,088,004,001,006,072,065,06B
SendingT: 001,088,002,001,007,093 MODEL_NAME,length:12
READ : 001,088,004,001,007,020,074,029
SendingT: 001,088,002,001,008,094 MODEL_NAME,length:11
READ : 001,088,004,001,008,058,04E,03C
SendingT: 001,088,002,001,009,095 MODEL_NAME,length:10
READ : 001,088,004,001,009,000,020,0B7
SendingT: 001,088,002,001,00A,096 MODEL_NAME,length:9
READ : 001,088,004,001,00A,000,000,098
SendingT: 001,088,002,001,00B,097 MODEL_NAME,length:8
READ : 001,088,004,001,00B,000,000,099
SendingT: 001,088,002,001,00C,098 MODEL_NAME,length:7
READ : 001,088,004,001,00C,000,000,09A
SendingT: 001,088,002,001,00D,099 MODEL_NAME,length:6
READ : 001,088,004,001,00D,000,000,09B
SendingT: 001,088,002,001,00E,09A MODEL_NAME,length:5
READ : 001,088,004,001,00E,000,000,09C
SendingT: 001,088,002,001,00F,09B MODEL_NAME,length:4
READ : 001,088,004,001,00F,000,000,09D
SendingT: 001,088,002,001,010,09C MODEL_NAME,length:3
READ : 001,088,004,001,010,000,000,09E
SendingT: 001,088,002,001,011,09D MODEL_NAME,length:2
READ : 001,088,004,001,011,000,000,09F
SendingT: 001,088,002,001,012,09E MODEL_NAME,length:1
READ : 001,088,004,001,012,000,000,0A0
MODEL_NAME: Liebert NX
SendingT: 001,088,002,001,013,09F FW_VER,length:8
READ : 001,088,004,001,013,031,049,01B
SendingT: 001,088,002,001,014,0A0 FW_VER,length:7
READ : 001,088,004,001,014,030,037,009
SendingT: 001,088,002,001,015,0A1 FW_VER,length:6
READ : 001,088,004,001,015,031,052,026
SendingT: 001,088,002,001,016,0A2 FW_VER,length:5
READ : 001,088,004,001,016,030,035,009
SendingT: 001,088,002,001,017,0A3 FW_VER,length:4
READ : 001,088,004,001,017,032,04D,024
SendingT: 001,088,002,001,018,0A4 FW_VER,length:3
READ : 001,088,004,001,018,030,036,00C
SendingT: 001,088,002,001,019,0A5 FW_VER,length:2
READ : 001,088,004,001,019,000,000,0A7
SendingT: 001,088,002,001,01A,0A6 FW_VER,length:1
READ : 001,088,004,001,01A,000,000,0A8
FW_VER: I170R150M260
SendingT: 001,088,002,001,01B,0A7 SN,length:10
READ : 001,037,001,004,03D,000,000,000
SN:
SendingT: 001,088,002,001,025,0B1 MANUF_DATE,length:4
READ : 001,037,001,004,03D,000,000,000
MANUF_DATE:
SendingM: 001,094,002,001,001,099 PFC_ON,bit/divider:0
READ : 001,094,004,001,001,010,005,0B0
PFC_ON: YES
SendingM: 001,094,002,001,001,099 DC_DC_CONVERTER_STATE,bit/divider:1
READ : 001,094,004,001,001,010,005,0B0
DC_DC_CONVERTER_STATE: NO
SendingM: 001,094,002,001,001,099 ON_INVERTER,bit/divider:2
READ : 001,094,004,001,001,010,005,0B0
ON_INVERTER: YES
SendingM: 001,094,002,001,001,099 UTILITY_STATE,bit/divider:3
READ : 001,094,004,001,001,010,005,0B0
UTILITY_STATE: NO
SendingM: 001,094,002,001,001,099 INRUSH_LIMIT_ON,bit/divider:4
READ : 001,094,004,001,001,010,005,0B0
INRUSH_LIMIT_ON: NO
SendingM: 001,094,002,001,001,099 OVERTEMP_WARNING,bit/divider:5
READ : 001,094,004,001,001,010,005,0B0
OVERTEMP_WARNING: NO
SendingM: 001,094,002,001,001,099 BATTERY_TEST_STATE,bit/divider:6
READ : 001,094,004,001,001,010,005,0B0
BATTERY_TEST_STATE: NO
SendingM: 001,094,002,001,001,099 INPUT_OVERVOLTAGE,bit/divider:7
READ : 001,094,004,001,001,010,005,0B0
INPUT_OVERVOLTAGE: NO
SendingM: 001,094,002,001,001,099 ON_BATTERY,bit/divider:8
READ : 001,094,004,001,001,010,005,0B0
ON_BATTERY: NO
SendingM: 001,094,002,001,002,09A ON_BYPASS,bit/divider:0
READ : 001,094,004,001,002,000,000,09C
ON_BYPASS: NO
SendingM: 001,094,002,001,002,09A BATTERY_CHARGED,bit/divider:1
READ : 001,094,004,001,002,000,000,09C
BATTERY_CHARGED: NO
SendingM: 001,094,002,001,002,09A BATTERY_LIFE_ENHANCER_ON,bit/divider:4
READ : 001,094,004,001,002,000,000,09C
BATTERY_LIFE_ENHANCER_ON: NO
SendingM: 001,094,002,001,002,09A REPLACE_BATTERY,bit/divider:5
READ : 001,094,004,001,002,000,000,09C
REPLACE_BATTERY: NO
SendingM: 001,094,002,001,002,09A BOOST_ON,bit/divider:6
READ : 001,094,004,001,002,000,000,09C
BOOST_ON: NO
SendingM: 001,094,002,001,002,09A DIAG_LINK_SET,bit/divider:7
READ : 001,094,004,001,002,000,000,09C
DIAG_LINK_SET: NO
SendingM: 001,094,002,001,002,09A BUCK_ON,bit/divider:9
READ : 001,094,004,001,002,000,000,09C
BUCK_ON: NO
SendingM: 001,094,002,001,003,09B UPS_OVERLOAD,bit/divider:0
READ : 001,094,004,001,003,000,000,09D
UPS_OVERLOAD: NO
SendingM: 001,094,002,001,003,09B BAD_INPUT_FREQ,bit/divider:1
READ : 001,094,004,001,003,000,000,09D
BAD_INPUT_FREQ: NO
SendingM: 001,094,002,001,003,09B SHUTDOWN_PENDING,bit/divider:2
READ : 001,094,004,001,003,000,000,09D
SHUTDOWN_PENDING: NO
SendingM: 001,094,002,001,003,09B CHARGER_FAIL,bit/divider:3
READ : 001,094,004,001,003,000,000,09D
CHARGER_FAIL: NO
SendingM: 001,094,002,001,003,09B LOW_BATTERY,bit/divider:5
READ : 001,094,004,001,003,000,000,09D
LOW_BATTERY: NO
SendingM: 001,094,002,001,003,09B OUTPUT_UNDERVOLTAGE,bit/divider:6
READ : 001,094,004,001,003,000,000,09D
OUTPUT_UNDERVOLTAGE: NO
SendingM: 001,094,002,001,003,09B OUTPUT_OVERVOLTAGE,bit/divider:7
READ : 001,094,004,001,003,000,000,09D
OUTPUT_OVERVOLTAGE: NO
SendingM: 001,094,002,001,003,09B BAD_BYPASS_PWR,bit/divider:8
READ : 001,094,004,001,003,000,000,09D
BAD_BYPASS_PWR: NO
SendingM: 001,094,002,001,003,09B CHECK_AIR_FILTER,bit/divider:10
READ : 001,094,004,001,003,000,000,09D
CHECK_AIR_FILTER: NO
SendingM: 001,094,002,001,007,09F AMBIENT_OVERTEMP,bit/divider:2
READ : 001,094,004,001,007,000,000,0A1
AMBIENT_OVERTEMP: NO
SendingM: 001,094,002,001,013,0AB MAIN_CONTROL_MODULE_FAILED,bit/divider:0
READ : 001,094,004,001,013,000,000,0AD
MAIN_CONTROL_MODULE_FAILED: NO
SendingM: 001,094,002,001,013,0AB
REDUNDANT_CONTROL_MODULE_FAILED,bit/divider:1
READ : 001,094,004,001,013,000,000,0AD
REDUNDANT_CONTROL_MODULE_FAILED: NO
SendingM: 001,094,002,001,013,0AB UI_MODULE_FAILED,bit/divider:2
READ : 001,094,004,001,013,000,000,0AD
UI_MODULE_FAILED: NO
SendingM: 001,094,002,001,013,0AB
REDUNDANT_POWER_MODULE_ALARM,bit/divider:3
READ : 001,094,004,001,013,000,000,0AD
REDUNDANT_POWER_MODULE_ALARM: NO
SendingM: 001,094,002,001,013,0AB
REDUNDANT_BATTERY_MODULE_ALARM,bit/divider:4
READ : 001,094,004,001,013,000,000,0AD
REDUNDANT_BATTERY_MODULE_ALARM: NO
SendingM: 001,094,002,001,013,0AB USER_MAX_LOAD_ALARM,bit/divider:5
READ : 001,094,004,001,013,000,000,0AD
USER_MAX_LOAD_ALARM: NO
SendingM: 001,094,002,001,013,0AB TRANSFORMER_OVERTEMP_ALARM,bit/divider:6
READ : 001,094,004,001,013,000,000,0AD
TRANSFORMER_OVERTEMP_ALARM: NO
SendingM: 001,094,002,001,013,0AB INTERNAL_COMMS_LOST,bit/divider:7
READ : 001,094,004,001,013,000,000,0AD
INTERNAL_COMMS_LOST: NO
SendingM: 001,094,002,001,013,0AB PWR_MOD_FAILED,bit/divider:9
READ : 001,094,004,001,013,000,000,0AD
PWR_MOD_FAILED: NO
SendingM: 001,094,002,001,013,0AB BAT_MOD_FAILED,bit/divider:10
READ : 001,094,004,001,013,000,000,0AD
BAT_MOD_FAILED: NO
SendingM: 001,094,002,001,014,0AC OPTION_CARD_FAIL_1,bit/divider:0
READ : 001,094,004,001,014,000,000,0AE
OPTION_CARD_FAIL_1: NO
SendingM: 001,094,002,001,014,0AC OPTION_CARD_FAIL_2,bit/divider:1
READ : 001,094,004,001,014,000,000,0AE
OPTION_CARD_FAIL_2: NO
SendingM: 001,094,002,001,014,0AC OPTION_CARD_FAIL_3,bit/divider:2
READ : 001,094,004,001,014,000,000,0AE
OPTION_CARD_FAIL_3: NO
SendingM: 001,094,002,001,014,0AC OPTION_CARD_FAIL_4,bit/divider:3
READ : 001,094,004,001,014,000,000,0AE
OPTION_CARD_FAIL_4: NO
SendingM: 001,094,002,001,014,0AC OPTION_CARD_FAIL_5,bit/divider:4
READ : 001,094,004,001,014,000,000,0AE
OPTION_CARD_FAIL_5: NO
SendingM: 001,094,002,001,014,0AC OPTION_CARD_FAIL_6,bit/divider:5
READ : 001,094,004,001,014,000,000,0AE
OPTION_CARD_FAIL_6: NO
SendingM: 001,094,002,001,014,0AC OPTION_CARD_FAIL_7,bit/divider:6
READ : 001,094,004,001,014,000,000,0AE
OPTION_CARD_FAIL_7: NO
SendingM: 001,094,002,001,014,0AC OPTION_CARD_FAIL_8,bit/divider:7
READ : 001,094,004,001,014,000,000,0AE
OPTION_CARD_FAIL_8: NO
SendingM: 001,094,002,001,016,0AE SUMMARY_ALARM,bit/divider:0
READ : 001,094,004,001,016,000,000,0B0
SUMMARY_ALARM: NO
SendingM: 001,094,002,001,018,0B0 RECT_UV_STARTUP_FAIL,bit/divider:0
READ : 001,094,004,001,018,000,000,0B2
RECT_UV_STARTUP_FAIL: NO
SendingM: 001,094,002,001,018,0B0 RECT_FAULT,bit/divider:1
READ : 001,094,004,001,018,000,000,0B2
RECT_FAULT: NO
SendingM: 001,094,002,001,018,0B0 RECT_OVER_CURRENT,bit/divider:2
READ : 001,094,004,001,018,000,000,0B2
RECT_OVER_CURRENT: NO
SendingM: 001,094,002,001,018,0B0 RECT_OVER_TEMP,bit/divider:3
READ : 001,094,004,001,018,000,000,0B2
RECT_OVER_TEMP: NO
SendingM: 001,094,002,001,018,0B0 RECT_INDCTR_OVER_TEMP,bit/divider:4
READ : 001,094,004,001,018,000,000,0B2
RECT_INDCTR_OVER_TEMP: NO
SendingM: 001,094,002,001,018,0B0 RECT_COMM_FAIL,bit/divider:5
READ : 001,094,004,001,018,000,000,0B2
RECT_COMM_FAIL: NO
SendingM: 001,094,002,001,018,0B0 INV_SHUTDOWN_LOW_DC,bit/divider:6
READ : 001,094,004,001,018,000,000,0B2
INV_SHUTDOWN_LOW_DC: NO
SendingM: 001,094,002,001,018,0B0 INV_FAULT,bit/divider:7
READ : 001,094,004,001,018,000,000,0B2
INV_FAULT: NO
SendingM: 001,094,002,001,018,0B0 INV_OVER_CURRENT,bit/divider:8
READ : 001,094,004,001,018,000,000,0B2
INV_OVER_CURRENT: NO
SendingM: 001,094,002,001,018,0B0 INV_OVER_TEMP,bit/divider:9
READ : 001,094,004,001,018,000,000,0B2
INV_OVER_TEMP: NO
SendingM: 001,094,002,001,018,0B0 INV_INDCTR_OVER_TEMP,bit/divider:10
READ : 001,094,004,001,018,000,000,0B2
INV_INDCTR_OVER_TEMP: NO
SendingM: 001,094,002,001,018,0B0 INV_COMM_FAIL,bit/divider:11
READ : 001,094,004,001,018,000,000,0B2
INV_COMM_FAIL: NO
SendingM: 001,094,002,001,018,0B0 INV_DC_OFFSET_OVR,bit/divider:12
READ : 001,094,004,001,018,000,000,0B2
INV_DC_OFFSET_OVR: NO
SendingM: 001,094,002,001,018,0B0 INV_CONTACTOR_FAIL,bit/divider:13
READ : 001,094,004,001,018,000,000,0B2
INV_CONTACTOR_FAIL: NO
SendingM: 001,094,002,001,019,0B1 BAT_FAULT,bit/divider:1
READ : 001,094,004,001,019,080,000,033
BAT_FAULT: NO
SendingM: 001,094,002,001,019,0B1 BAT_CONTACTOR_FAIL,bit/divider:2
READ : 001,094,004,001,019,080,000,033
BAT_CONTACTOR_FAIL: NO
SendingM: 001,094,002,001,019,0B1 CONVERTER_OVER_TEMP,bit/divider:4
READ : 001,094,004,001,019,080,000,033
CONVERTER_OVER_TEMP: NO
SendingM: 001,094,002,001,019,0B1 CONVERTER_OVER_AMPS,bit/divider:5
READ : 001,094,004,001,019,080,000,033
CONVERTER_OVER_AMPS: NO
SendingM: 001,094,002,001,019,0B1 CONVERTER_FAIL,bit/divider:6
READ : 001,094,004,001,019,080,000,033
CONVERTER_FAIL: NO
SendingM: 001,094,002,001,019,0B1 BALANCER_OVER_TEMP,bit/divider:7
READ : 001,094,004,001,019,080,000,033
BALANCER_OVER_TEMP: NO
SendingM: 001,094,002,001,019,0B1 BALANCER_FAULT,bit/divider:8
READ : 001,094,004,001,019,080,000,033
BALANCER_FAULT: NO
SendingM: 001,094,002,001,019,0B1 BALANCER_OVER_CURRENT,bit/divider:9
READ : 001,094,004,001,019,080,000,033
BALANCER_OVER_CURRENT: NO
SendingM: 001,094,002,001,019,0B1 BY_CB_OPEN,bit/divider:10
READ : 001,094,004,001,019,080,000,033
BY_CB_OPEN: NO
SendingM: 001,094,002,001,019,0B1 LOAD_IMPACT_XFER,bit/divider:11
READ : 001,094,004,001,019,080,000,033
LOAD_IMPACT_XFER: NO
SendingM: 001,094,002,001,019,0B1 OPERATION_FAULT,bit/divider:12
READ : 001,094,004,001,019,080,000,033
OPERATION_FAULT: NO
SendingM: 001,094,002,001,019,0B1 OUT_FUSE_BLOWN,bit/divider:13
READ : 001,094,004,001,019,080,000,033
OUT_FUSE_BLOWN: NO
SendingM: 001,094,002,001,019,0B1 ON_JOINT_MODE,bit/divider:14
READ : 001,094,004,001,019,080,000,033
ON_JOINT_MODE: NO
SendingM: 001,094,002,001,01A,0B2 MAIN_NEUTRAL_LOST,bit/divider:4
READ : 001,094,004,001,01A,000,003,0B7
MAIN_NEUTRAL_LOST: NO
SendingM: 001,094,002,001,01B,0B3 PARALLEL_LOW_BAT_WARN,bit/divider:4
READ : 001,094,004,001,01B,000,001,0B6
PARALLEL_LOW_BAT_WARN: NO
SendingM: 001,094,002,001,01B,0B3 PARALLEL_LOAD_SHARE_FAULT,bit/divider:5
READ : 001,094,004,001,01B,000,001,0B6
PARALLEL_LOAD_SHARE_FAULT: NO
SendingM: 001,094,002,001,01B,0B3 PARALLEL_FAULT,bit/divider:6
READ : 001,094,004,001,01B,000,001,0B6
PARALLEL_FAULT: NO
SendingM: 001,094,002,001,01B,0B3 PARALLEL_CONNECT_FAULT,bit/divider:7
READ : 001,094,004,001,01B,000,001,0B6
PARALLEL_CONNECT_FAULT: NO
SendingM: 001,094,002,001,01B,0B3 PARALLEL_COMM_FAIL,bit/divider:8
READ : 001,094,004,001,01B,000,001,0B6
PARALLEL_COMM_FAIL: NO
SendingM: 001,094,002,001,01B,0B3 PARALLEL_SYS_OVER_LOAD,bit/divider:9
READ : 001,094,004,001,01B,000,001,0B6
PARALLEL_SYS_OVER_LOAD: NO
SendingM: 001,094,002,001,01B,0B3 PARALLEL_SYS_XFER,bit/divider:10
READ : 001,094,004,001,01B,000,001,0B6
PARALLEL_SYS_XFER: NO
Sleeping....
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 >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20100407/f006c014/attachment.htm>
Citeren Robert Jobbagy <jobbagy.robert op gmail.com>:> did you look my new patch ?Which one? As far as I know everything relevant you submitted is now in the development version.> Please check it.Please be specific. I have many other things to attend to, so when asking questions, provide some context (and don't rely on me remembering things). Best regards, Arjen -- Please keep list traffic on the list
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>
I support that, have been considering the same. The Liebert GXT2 manual calls the protocol ESP-II. Richard +-- --+ | Biological Sciences, Room 231 | | http://www.csc.liv.ac.uk/~greg | +-- --+ Spiros Ioannou wrote:> I think the protocol is called ESP-II not GXT-2. Thus this could be a > better driver name (liebertesp2 instead of liebertgxt2). GXT-2 is a > model series name, such as NXe. > >