Nut upsdev - Nov 2014 - RFC: new variable battery.status

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.
>
>

On Nov 7, 2014, at 11:47 AM, Ted Mittelstaedt <tedm at mittelstaedt.us>
wrote:
> 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,

As someone who spends a lot of time digging through the NUT mailing list
archives, trying to find the context for previous list discussions, this is
actually not such a ridiculous request. I know, we could solve this by moving to
some mailing list software that folds previous replies like current mail readers
do. But it's a lot of work for not much gain.

While the text formatting hasn't evolved much since Usenet, I would hope the
people have evolved during that same timeframe. You seem to have a lot of UPS
experience, and it's a shame that we can't put it to a more constructive
use. I'm still open to the doc/FAQ improvements we discussed in July.

-- 
Charles Lepple
clepple at gmail

Am 08.11.2014 um 14:38 schrieb Charles Lepple:
> On Nov 7, 2014, at 11:47 AM, Ted Mittelstaedt <tedm at
mittelstaedt.us> wrote:
>
>> 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>
Guys...
>
> Ted,
>
> As someone who spends a lot of time digging through the NUT mailing list
archives, trying to find the context for previous list discussions, this is
actually not such a ridiculous request. I know, we could solve this by moving to
some mailing list software that folds previous replies like current mail readers
do. But it's a lot of work for not much gain.
That wasn't a "request", it was a "should" *suggestion*
passing what I was honoured to learn from kernel mailing lists maintainers Years
before.
>
> While the text formatting hasn't evolved much since Usenet, I would
hope the people have evolved during that same timeframe. You seem to have a lot
of UPS experience, and it's a shame that we can't put it to a more
constructive use. I'm still open to the doc/FAQ improvements we discussed in
July.
>
I WOULD second that, too. And I've not yet got why Ted reacts on me like I
had dropped an UPS on his cat.

I'll give it another try.

y
tom

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 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?
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 <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/8/2014 6:54 AM, thomas schorpp wrote:
> 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 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?
>
> 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.
>
Hi Thomas,

   Sorry, I didn't mean to come off so harsh, I don't have a cat but if
any of my USPes fell on one it would be a flat cat. :-)  I 
misinterpreted your post,

   The upscode2 driver has been a PIA for me for years, or maybe it isn't
the driver but the UPS.  Yeah, probably it's the UPS.  Besides the 
issues with underreporting the battery state of charge, the upscode2
driver periodically gets a no data response from the UPS.  Beats me why
that is.

Ted

On 11/3/2014 3:25 PM, thomas schorpp wrote:
>And now it's after "some (EU warranty) time" for my batteries:
Sorry, there's no such years warranty time for batteries neither in DE,
assume nor in EU, only DOA...2 Weeks, USA/ASIA?
Batteries are usually considered as "fast wearing off"
consumables/supplies by sellers around here.

Not off-topic because you could back warranty claims by Your NUT logs and prove
You're using an advanced ABM or better charger,
because some sellers/suppliers could try to reject warranty claims by blaming
Your hardware.
> y
> tom
y
tom