[Nut-upsdev] RFC: new variable battery.status
thomas schorpp
thomas.schorpp at gmail.com
Tue Nov 4 05:25:17 UTC 2014
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 ?
>
> 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.
More information about the Nut-upsdev
mailing list