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