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