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 <[email protected]> > 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 <[email protected] <mailto: >> [email protected]>> >> >> >> Hi Arjen! >> >> This is the my last patch to Liebert GXT2 driver. >> >> >> ---------- Forwarded message ---------- >> From: *Robert Jobbagy* <[email protected] >> <mailto:[email protected]>> >> Date: 2010/4/7 >> Subject: Re: [Nut-upsdev] Liebert GXT2 NUT driver >> To: NUT Developers <[email protected] >> <mailto:[email protected]>> >> >> >> 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 <[email protected] <mailto:[email protected]>> >> >> >> 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 <[email protected] >> <mailto:[email protected]>> 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 >> <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>>: >> >> >> 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 >> [email protected] >> <mailto:[email protected]> >> >> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev >> >> >> >> >> _______________________________________________ >> Nut-upsdev mailing list >> [email protected] >> <mailto:[email protected]> >> >> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev >> >> >> >> >> -- Best Regards, >> >> Robert >> >> >> >> -- Best Regards, >> >> Robert >> >> >> >> >> -- >> Best Regards, >> >> Robert >> >> -- Best Regards, Robert
_______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
