Dear Ted,
Am 07.11.2014 um 17:47 schrieb Ted Mittelstaedt:
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@m@d @H@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 [email protected] -l -
Network UPS Tools upslog 2.6.4
logging status of [email protected] 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 [email protected] -l -
Network UPS Tools upslog 2.6.4
logging status of [email protected] 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?
I'm not PL so I don't decide what gets into production here and the point
simply was 1.) , intended to RFC the community of this general developer
practice Q,
but in no way to insult You in any way.
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.
NACK. I just have "assumed":
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.
I've seen a users list around here and I've never claimed anything above after "I
assume?" and since "it was my intent to help others who have these UPSes"
maybe You already could have forwared such QA requests to that list.
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.
No at all. You know what ";-)" means in the netslang? That was supposed to be a
friendly joke, sorry if You've lost any humor at work.
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?
Sorry, can't remember, citation and authentication missing.
We all must make sure our postings are formatted so your circa 1982 /bin/mail command
can still read it <eyeroll>
Pardon, but the majority of OSS/Linux kernel devlists suggests not to top post
and there're good *mature* reasons why not.
As You can read in my headers I'm using Thunderbird and if a "You shouldn't" proposal is
"bothering" You, then I hereby apologize for my bad English.
I'm really sorry, please do what You want and keep up the good work, thank You,
but If You want me off this list for any reason, just say it.
y
tom
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 <[email protected]>:
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.
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
