THANKYOUTHANKYOUTHANKYOUTHANKYOU!!!!!!
There was a smaller patch posted to the list for lines
-1389,9 +1390,10
a couple years ago, it helped some - BUT - it was still buggy.
I have a Compaq R3000, I will get this patch integrated pronto and test
Note that since the UPS relies on the voltage from the battery pack to
determine state of charge, it is quite useful to add in the battery pack
voltage to the logs as such:
--- upslog.c.orig 2012-07-31 10:38:58.000000000 -0700
+++ upslog.c 2014-02-20 09:23:14.000000000 -0800
@@ -50,6 +50,7 @@
static flist_t *fhead = NULL;
#define DEFAULT_LOGFORMAT "%TIME @Y at m@d @H at M@S% %VAR
battery.charge% " \
+ "%VAR battery.voltage% %VAR output.current% " \
"%VAR input.voltage% %VAR ups.load% [%VAR ups.status%]
" \
"%VAR ups.temperature% %VAR input.frequency%"
Ted
On 11/3/2014 3:25 PM, thomas schorpp wrote:> Hi,
>
> Am 13.02.2012 um 18:58 schrieb Arnaud Quette:
>> 2012/2/6 thomas schorpp <thomas.schorpp at googlemail.com>:
>>> Hi,
>>
>> Hi Thomas,
>>
>>> I want the driver report the battery status from ABM charging
>>> controllers
>>> -patch attached- :
>>
>
>> For now, I've tracked your patch here:
>>
https://alioth.debian.org/tracker/index.php?func=detail&aid=313541&group_id=30602&atid=411544
>>
>>
>
> Thanks, but no anonymous read access, so not very useful linking on
> public lists:
>
> "You've been redirected to this login page because you have tried
> accessing a page that was not available to you as an anonymous user."
>
>>> *or the charge estimation calculator of the driver is broken:
>>>
>>> battery.capacity.nominal: 17.00
>>> battery.charge: 93.9
>>> battery.runtime: 1620
>>> battery.status.abm: FT
>>> battery.voltage: 27.70
>>> battery.voltage.maximum: 28.20
>>> battery.voltage.minimum: 20.00
>>> battery.voltage.nominal: 24.00
>>> device.mfr: Compaq
>>> device.model: UPS 1000 VA FW -0026
>>> device.serial: E00230050
>
>>
>> as mentioned in the manpage and source code, no battery.charge data is
>> returned from the device.
>> "the driver will guestimate a value based on the nominal battery
>> min/max and the current battery voltage."
>
> Maybe I've found a better "guesstimation", -PATCH found
cleaning up old
> stuff attached-
>
>>
>> so it may be due to both.
>> It may also be a percentage of the nominal level, which may be not
>> reachable after some time.
>
> We're talking about lead/acid batteries here? A lead battery not
> reaching its rated nominal after charge is usually considered to be broken,
> ask Your car garage mechanic ;-)
>
> And now it's after "some (EU warranty) time" for my
batteries:
>
> battery.capacity.nominal: 17.00
> battery.charge: 98.3
> battery.runtime: 2280
> battery.status.abm: RS
> battery.voltage: 25.90
> battery.voltage.maximum: 28.20
> battery.voltage.minimum: 20.00
> battery.voltage.nominal: 24.00
> ups.mfr: Compaq
> ups.model: UPS 1000 VA FW -0026
> ups.serial: E00230050
>
> Voltage still above "nominal" in ABM resting state.
>
> And one more, the "panel test" isn't a "panel
test", it's a complete
> selftest including the controller, inverter and fan under load here.
>
> Here's the last patch for people using NUT and still have got an
> upscode2 talking UPS, who may find it useful, pls report breakage.
>
>>
>> cheers,
>> Arnaud
>>
>
> y
> tom
>
> --- drivers/upscode2.c 2012-05-15 13:22:07.000000000 +0200
> +++ drivers/upscode2.c 2012-07-18 15:39:15.000000000 +0200
> @@ -32,7 +32,7 @@
> * Powerware 9305
> *
> * Also tested against
> - * Compaq T1500h (Per J?nsson <per.jonsson at bth.se>)
> + * Compaq T1000h/T1500h (T.Schorpp, <thomas.schorpp at gmail.com>,
Per
> J?nsson <per.jonsson at bth.se>)
> * Powerware 9120 (Gorm J. Siiger <gjs at sonnit.dk>)
> * Fiskars PowerServer 10 (Per Larsson <tucker at algonet.se>)
> */
> @@ -45,7 +45,7 @@
> #include <math.h>
>
> #define DRIVER_NAME "UPScode II UPS driver"
> -#define DRIVER_VERSION "0.88"
> +#define DRIVER_VERSION "0.89abm"
>
> /* driver description structure */
> upsdrv_info_t upsdrv_info = {
> @@ -54,7 +54,7 @@
> "H K Lygre, <hklygre at online.no>\n" \
> "Niels Baggesen <niels at baggesen.net>\n" \
> "Niklas Edmundsson <nikke at acc.umu.se>",
> - DRV_EXPERIMENTAL,
> + DRV_BETA,
> { NULL }
> };
>
> @@ -262,7 +262,7 @@
> { "STAT", t_list, NULL, 0, 0, att },
> { "STBO", t_status, NULL, UPSC_STAT_ONBATT },
> { "STBL", t_status, NULL, UPSC_STAT_LOBATT },
> - { "STBM", t_ignore },
> + { "STBM", t_string, "battery.status.abm" },
> { "STBP", t_status, NULL, UPSC_STAT_BYPASS },
> { "STEA", t_list, NULL, 0, 0, env },
> { "STEM", t_list, NULL, 0, 0, env },
> @@ -412,8 +412,8 @@
> { "shutdown.stop", "UPPU", NULL },
> { "shutdown.reboot", "UPPC", "IJHLDMGCIU" },
> { "shutdown.reboot.graceful", NULL, NULL },
> - { "test.panel.start", "UPIS", NULL },
> - { "test.panel.stop", NULL, NULL },
> + { "test.selftest.start", "UPIS", NULL }, /*
Spec:"UPIS(cr)INITIATE
> SELF TEST" not "panel test" */
> + { "test.selftest.stop", NULL, NULL },
> { "test.failure.start", NULL, NULL },
> { "test.failure.stop", NULL, NULL },
> { "test.battery.start", "UPBT", "1" },
> @@ -1363,6 +1363,7 @@
> static float batt_charge_pct(void)
> {
> float chg=-1;
> + float batt_volt_rs = (batt_volt_nom * 26/24); /* ABM specs Vrs at
> 108.333 % Vnom */
>
> /* This is only a rough estimate of charge status while charging.
> * When on battery something like Peukert's equation should be used */
> @@ -1389,9 +1390,10 @@
> chg *= (100/maxcurr);
> }
> /* Old method, assumes battery high/low-voltages provided by UPS are
> - * applicable to battery charge, but they usually aren't */
> + * applicable to battery charge, but they usually aren't, cause high
is
> a UPS internal and/or battery
> + * ABSOLUTE MAXIMUM RATING, not reported as "nominal" value, the
> upscode2 spec maybe wrong. */
> else if (batt_volt_low > 0 && batt_volt_high > 0 &&
batt_volt > 0) {
> - if (batt_volt > batt_volt_high) {
> + if (batt_volt > batt_volt_rs) {
> chg=100;
> }
> else if (batt_volt < batt_volt_low) {
> @@ -1399,7 +1401,7 @@
> }
> else {
> chg = (batt_volt - batt_volt_low) /
> - (batt_volt_high - batt_volt_low);
> + (batt_volt_rs - batt_volt_low);
> chg*=100;
> }
> }
>
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Hi Ted, Am 04.11.2014 um 04:12 schrieb Ted Mittelstaedt:>> Note that since the UPS relies on the voltage from the battery pack to > determine state of charge, it is quite useful to add in the battery pack > voltage to the logs as such: > > --- upslog.c.orig 2012-07-31 10:38:58.000000000 -0700 > +++ upslog.c 2014-02-20 09:23:14.000000000 -0800 > @@ -50,6 +50,7 @@ > static flist_t *fhead = NULL; > > #define DEFAULT_LOGFORMAT "%TIME @Y at m@d @H at M@S% %VAR battery.charge% " \ > + "%VAR battery.voltage% %VAR output.current% " \ > "%VAR input.voltage% %VAR ups.load% [%VAR ups.status%] " \ > "%VAR ups.temperature% %VAR input.frequency%" >1. I see no need to patch a program for any parameter (-extension) already handled: $ upslog -f "%VAR battery.voltage%" -s ups at fritz.box -l - Network UPS Tools upslog 2.6.4 logging status of ups at fritz.box to - (30s intervals) writepid: fopen /var/run/nut/upslog.pid: Permission denied 25.90 25.90 ^C25.90 Signal 2: exiting $ $ upslog -f "%VAR battery.status.abm%" -s ups at fritz.box -l - Network UPS Tools upslog 2.6.4 logging status of ups at fritz.box to - (30s intervals) writepid: fopen /var/run/nut/upslog.pid: Permission denied RS RS ^CRS Signal 2: exiting $ And new defaults need PL and broader community consencus, I assume? Suggest You better patch the manpage first encouraging users reading manpages ;-) 2. man upslog: -i interval Wait this many seconds between polls. This defaults to 30 seconds. If you require tighter timing, you should write your own logger using the upsclient(3) library. 30s are far to long to catch short but maybe damaging line power incidents, so I would second that. 3. Maybe You shouldn't top post nor (re)word wrap mails to devlists, thank You. PL ?> > Tedy tom> > > On 11/3/2014 3:25 PM, thomas schorpp wrote: >> Hi, >> >> Am 13.02.2012 um 18:58 schrieb Arnaud Quette: >>> 2012/2/6 thomas schorpp <thomas.schorpp at googlemail.com>: >>>> Hi, >>> >>> Hi Thomas, >>> >>>> I want the driver report the battery status from ABM charging >>>> controllers >>>> -patch attached- : >>> >> >>> For now, I've tracked your patch here: >>> https://alioth.debian.org/tracker/index.php?func=detail&aid=313541&group_id=30602&atid=411544 >>> >>> >> >> Thanks, but no anonymous read access, so not very useful linking on >> public lists: >> >> "You've been redirected to this login page because you have tried >> accessing a page that was not available to you as an anonymous user." >> >>>> *or the charge estimation calculator of the driver is broken: >>>> >>>> battery.capacity.nominal: 17.00 >>>> battery.charge: 93.9 >>>> battery.runtime: 1620 >>>> battery.status.abm: FT >>>> battery.voltage: 27.70 >>>> battery.voltage.maximum: 28.20 >>>> battery.voltage.minimum: 20.00 >>>> battery.voltage.nominal: 24.00 >>>> device.mfr: Compaq >>>> device.model: UPS 1000 VA FW -0026 >>>> device.serial: E00230050 >> >>> >>> as mentioned in the manpage and source code, no battery.charge data is >>> returned from the device. >>> "the driver will guestimate a value based on the nominal battery >>> min/max and the current battery voltage." >> >> Maybe I've found a better "guesstimation", -PATCH found cleaning up old >> stuff attached- >> >>> >>> so it may be due to both. >>> It may also be a percentage of the nominal level, which may be not >>> reachable after some time. >> >> We're talking about lead/acid batteries here? A lead battery not >> reaching its rated nominal after charge is usually considered to be broken, >> ask Your car garage mechanic ;-) >> >> And now it's after "some (EU warranty) time" for my batteries: >> >> battery.capacity.nominal: 17.00 >> battery.charge: 98.3 >> battery.runtime: 2280 >> battery.status.abm: RS >> battery.voltage: 25.90 >> battery.voltage.maximum: 28.20 >> battery.voltage.minimum: 20.00 >> battery.voltage.nominal: 24.00 >> ups.mfr: Compaq >> ups.model: UPS 1000 VA FW -0026 >> ups.serial: E00230050 >> >> Voltage still above "nominal" in ABM resting state. >> >> And one more, the "panel test" isn't a "panel test", it's a complete >> selftest including the controller, inverter and fan under load here. >> >> Here's the last patch for people using NUT and still have got an >> upscode2 talking UPS, who may find it useful, pls report breakage. >> >>> >>> cheers, >>> Arnaud >>> >> >> y >> tom >> >> --- drivers/upscode2.c 2012-05-15 13:22:07.000000000 +0200 >> +++ drivers/upscode2.c 2012-07-18 15:39:15.000000000 +0200-Removed because re-wordwrapped broken- See "RFC: new variable battery.status (was: [PATCH] upscode2: Report ABM Status)" topic.
On 11/3/2014 9:25 PM, thomas schorpp wrote:> Hi Ted, > > Am 04.11.2014 um 04:12 schrieb Ted Mittelstaedt: >> > >> Note that since the UPS relies on the voltage from the battery pack to >> determine state of charge, it is quite useful to add in the battery pack >> voltage to the logs as such: >> >> --- upslog.c.orig 2012-07-31 10:38:58.000000000 -0700 >> +++ upslog.c 2014-02-20 09:23:14.000000000 -0800 >> @@ -50,6 +50,7 @@ >> static flist_t *fhead = NULL; >> >> #define DEFAULT_LOGFORMAT "%TIME @Y at m@d @H at M@S% %VAR battery.charge% " \ >> + "%VAR battery.voltage% %VAR output.current% " \ >> "%VAR input.voltage% %VAR ups.load% [%VAR ups.status%] " \ >> "%VAR ups.temperature% %VAR input.frequency%" >> > > 1. I see no need to patch a program for any parameter (-extension) > already handled: > > $ upslog -f "%VAR battery.voltage%" -s ups at fritz.box -l - > Network UPS Tools upslog 2.6.4 > logging status of ups at fritz.box to - (30s intervals) > writepid: fopen /var/run/nut/upslog.pid: Permission denied > 25.90 > 25.90 > ^C25.90 > Signal 2: exiting > $ > > $ upslog -f "%VAR battery.status.abm%" -s ups at fritz.box -l - > Network UPS Tools upslog 2.6.4 > logging status of ups at fritz.box to - (30s intervals) > writepid: fopen /var/run/nut/upslog.pid: Permission denied > RS > RS > ^CRS > Signal 2: exiting > $ >Actually, it wasn't my intent that patch would go into the distribution, it was my intent to help others who have these UPSes still in service to get a better handle on their pecularities. But, you actually bring up a great point. Why have ANY variables at all in upslog? We should just have the output of upslog an empty log. And tell users to specify ALL the parameters they want that are important to them on the command line to upslog. After all, selecting ANY parameters for default inclusion in upslog must make us look like total know-it-all assholes, right? I think that's what the logic your using is saying.> And new defaults need PL and broader community consencus, I assume? >Yes. All users of upscode2 let's hear what they have to say. You must have many upscode2 UPSes in service, Thomas. I congratulate you as keeping these old units in service actually requires a lot of knowledge of UPSes. I should know as I have one in service :-| But since you have so many more upscode2 UPSes in service you must have a much better knowledge of whether the patch is a good one than I do.> Suggest You better patch the manpage first encouraging users reading > manpages ;-) >You seem very threatened by the suggestion to give users of the software more information in the log that they can use.> 2. man upslog: > > -i interval > Wait this many seconds between polls. This defaults to 30 seconds. > If you require tighter timing, you should write your own logger using > the upsclient(3) library. > > > 30s are far to long to catch short but maybe damaging line power > incidents, so I would second that. > > 3. Maybe You shouldn't top post nor (re)word wrap mails to devlists, > thank You. >Ah. Thank you for posting what is REALLY bothering you. After all, no need to actually make some reasonable explanations of your positions when it's easier to criticize for some imagined slight given by putting photons in a slightly different place on the screen. Much better to reply with cryptically short responses that violate grammar rules and require multiple rereads to even get a sense of what you might possibly be talking about. After all those fuzzball routers just barely have enough CPU available to pass the short emails. Now I suppose your going to respond with that immature drivel that's been floating around, lets see if I remember it:> Because it messes up the order in which people normally read text. > > Why is top-posting such a bad thing? > >> Top-posting. > >>> What is the most annoying thing in e-mail?We all must make sure our postings are formatted so your circa 1982 /bin/mail command can still read it <eyeroll> Ted> PL ? > >> >> Ted > > y > tom > > >> >> >> On 11/3/2014 3:25 PM, thomas schorpp wrote: >>> Hi, >>> >>> Am 13.02.2012 um 18:58 schrieb Arnaud Quette: >>>> 2012/2/6 thomas schorpp <thomas.schorpp at googlemail.com>: >>>>> Hi, >>>> >>>> Hi Thomas, >>>> >>>>> I want the driver report the battery status from ABM charging >>>>> controllers >>>>> -patch attached- : >>>> >>> >>>> For now, I've tracked your patch here: >>>> https://alioth.debian.org/tracker/index.php?func=detail&aid=313541&group_id=30602&atid=411544 >>>> >>>> >>>> >>> >>> Thanks, but no anonymous read access, so not very useful linking on >>> public lists: >>> >>> "You've been redirected to this login page because you have tried >>> accessing a page that was not available to you as an anonymous user." >>> >>>>> *or the charge estimation calculator of the driver is broken: >>>>> >>>>> battery.capacity.nominal: 17.00 >>>>> battery.charge: 93.9 >>>>> battery.runtime: 1620 >>>>> battery.status.abm: FT >>>>> battery.voltage: 27.70 >>>>> battery.voltage.maximum: 28.20 >>>>> battery.voltage.minimum: 20.00 >>>>> battery.voltage.nominal: 24.00 >>>>> device.mfr: Compaq >>>>> device.model: UPS 1000 VA FW -0026 >>>>> device.serial: E00230050 >>> >>>> >>>> as mentioned in the manpage and source code, no battery.charge data is >>>> returned from the device. >>>> "the driver will guestimate a value based on the nominal battery >>>> min/max and the current battery voltage." >>> >>> Maybe I've found a better "guesstimation", -PATCH found cleaning up old >>> stuff attached- >>> >>>> >>>> so it may be due to both. >>>> It may also be a percentage of the nominal level, which may be not >>>> reachable after some time. >>> >>> We're talking about lead/acid batteries here? A lead battery not >>> reaching its rated nominal after charge is usually considered to be >>> broken, >>> ask Your car garage mechanic ;-) >>> >>> And now it's after "some (EU warranty) time" for my batteries: >>> >>> battery.capacity.nominal: 17.00 >>> battery.charge: 98.3 >>> battery.runtime: 2280 >>> battery.status.abm: RS >>> battery.voltage: 25.90 >>> battery.voltage.maximum: 28.20 >>> battery.voltage.minimum: 20.00 >>> battery.voltage.nominal: 24.00 >>> ups.mfr: Compaq >>> ups.model: UPS 1000 VA FW -0026 >>> ups.serial: E00230050 >>> >>> Voltage still above "nominal" in ABM resting state. >>> >>> And one more, the "panel test" isn't a "panel test", it's a complete >>> selftest including the controller, inverter and fan under load here. >>> >>> Here's the last patch for people using NUT and still have got an >>> upscode2 talking UPS, who may find it useful, pls report breakage. >>> >>>> >>>> cheers, >>>> Arnaud >>>> >>> >>> y >>> tom >>> >>> --- drivers/upscode2.c 2012-05-15 13:22:07.000000000 +0200 >>> +++ drivers/upscode2.c 2012-07-18 15:39:15.000000000 +0200 > > -Removed because re-wordwrapped broken- See "RFC: new variable > battery.status (was: [PATCH] upscode2: Report ABM Status)" topic. > >