Nut upsuser - Jun 2014 - Tripp Lite SMART3000RM2U (protocol 3003) running time and charge?

Hello,

At 09:24 -0400 on 2014-5-23 Charles Lepple wrote:
 >
 > See attached. Still doesn't have the writable V_interval values,
 > but I probably won't have time to test that until later.

Thank you for the patch.

 > Don't worry about the battery physical properties for now - the
 > problem there is that we don't have enough information from the UPS
 > to do a proper calculation. With the V_interval[] settings, you can
 > tweak the new state-of-charge calculation to match what you see via
 > upsc when the battery is fully charged, so that's better than
 > nothing.

Yes, the V_interval[] being exposed is a very good idea and does seem
the only sensible workaround.

 > > In case it matters by the way this is all happening on a box running
 > > kernel version 3.12.13 with Gentoo patches.  The NUT I am playing
with
 > > is the stock Gentoo unstable variety, meaning version 2.7.1 with some
 > > Gentoo patching on top.
 > 
 > Thanks, that is a useful data point. Does Gentoo have an easy way
 > (short of installing the whole OS) to see what those patches are?

Sure.  Gentoo is a port-based, source distribution, so the patches are
in the local Portage tree (code word for the collection of ports, or
ebuilds as they are actually called in Gentoo;-) ).  I am attaching
the complete ebuild to this message (I am sure that the files are also
available somewhere on the Web but I never looked since I already have
them locally so I don't know where).  Note that I renamed the
directory from nut to nut-gentoo to eliminate any possible confusion.

I am using nut-2.7.1.ebuild (latest available).  Most of the content
is irrelevant to you -- in fact I believe that the only useful
information would be the Gentoo patches which for 2.7.1 appear to be:

    files/nut-2.4.1-no-libdummy.patch
    files/nut-2.6.2-lowspeed-buffer-size.patch
    files/nut-2.7.1-fix-scanning.patch
    files/nut-2.7.1-snmpusb-order.patch

(they are all applied to 2.7.1 despite their names).

 > Gentoo would be a good addition to the NUT Buildbot, but the build
 > farm hardware is somewhat memory-constrained at the moment.

No worries, there is nothing to build for Gentoo...

In any event, thank you very much for the assistance.  The current
incarnation of nut works substantially better on my system.  I would
also be more than happy to help in the future so drop me a line as
needed.

Best regards,
Stefan

-- 
If it was so, it might be; and if it were so, it would be; but as it 
isn't, it ain't.  That's logic.  --Lewis Carroll, Through the
Looking-Glass

No HTML emails and proprietary attachments please <http://bruda.ca/ascii>

[ATTACHMENT ~/nut-gentoo.tar, application/x-tar]

On May 24, 2014, at 5:49 PM, Stefan Bruda wrote:
>>> In case it matters by the way this is all happening on a box
running
>>> kernel version 3.12.13 with Gentoo patches.  The NUT I am playing
with
>>> is the stock Gentoo unstable variety, meaning version 2.7.1 with
some
>>> Gentoo patching on top.
>> 
>> Thanks, that is a useful data point. Does Gentoo have an easy way
>> (short of installing the whole OS) to see what those patches are?
> 
> Sure.  Gentoo is a port-based, source distribution, so the patches are
> in the local Portage tree (code word for the collection of ports, or
> ebuilds as they are actually called in Gentoo;-) ).  I am attaching
> the complete ebuild to this message (I am sure that the files are also
> available somewhere on the Web but I never looked since I already have
> them locally so I don't know where).  Note that I renamed the
> directory from nut to nut-gentoo to eliminate any possible confusion.
Seems like the source is here:

http://packages.gentoo.org/package/sys-power/nut

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-power/nut/files/
> I am using nut-2.7.1.ebuild (latest available).  Most of the content
> is irrelevant to you -- in fact I believe that the only useful
> information would be the Gentoo patches which for 2.7.1 appear to be:
> 
>    files/nut-2.4.1-no-libdummy.patch
>    files/nut-2.6.2-lowspeed-buffer-size.patch
>    files/nut-2.7.1-fix-scanning.patch
>    files/nut-2.7.1-snmpusb-order.patch
> 
> (they are all applied to 2.7.1 despite their names).
> 
I will have to look at those patches later. In particular, the
lowspeed-buffer-size.patch seems redundant, since the link points to a commit in
our old SVN archive.
>> Gentoo would be a good addition to the NUT Buildbot, but the build
>> farm hardware is somewhat memory-constrained at the moment.
> 
> No worries, there is nothing to build for Gentoo...
The goal of our Buildbot implementation wasn't so much to provide pre-built
binaries (although it certainly could). It's more of an early-warning system
in case we have old code that doesn't build properly on a particular
distribution.
> In any event, thank you very much for the assistance.  The current
> incarnation of nut works substantially better on my system.  I would
> also be more than happy to help in the future so drop me a line as
> needed.
I will let you know when I get a chance to finish the V_interval variables.
> [ATTACHMENT ~/nut-gentoo.tar, application/x-tar]

compressed and attached below.

-- 
Charles Lepple
clepple at gmail


-------------- next part --------------
A non-text attachment was scrubbed...
Name: nut-gentoo.tar.gz
Type: application/x-gzip
Size: 26605 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140528/f6f705d2/attachment-0001.bin>

On May 24, 2014, at 5:49 PM, Stefan Bruda wrote:
>> Don't worry about the battery physical properties for now - the
>> problem there is that we don't have enough information from the UPS
>> to do a proper calculation. With the V_interval[] settings, you can
>> tweak the new state-of-charge calculation to match what you see via
>> upsc when the battery is fully charged, so that's better than
>> nothing.
> 
> Yes, the V_interval[] being exposed is a very good idea and does seem
> the only sensible workaround.
As of the latest push (rev 0d1e017), the tripplite_usb driver (v0.22) now reads
the battery_min and battery_max variables from ups.conf at startup.

Testing on my OMNIVS1000, the voltage difference between OB and OL is
significant, so aside from having two sets of min/max ranges, I'd say
calibrate it on the discharge side of the slope, and don't put too much
stock in the battery.charge value when it is recharging.

I'm not so sure if it makes sense to make them reconfigurable while the
driver is running-- the driver doesn't take very long to restart, and if
they were made available through upsrw, they wouldn't be saved back to
ups.conf anyway. I could be persuaded, though.

-- 
Charles Lepple
clepple at gmail

Hello,

At 15:42 -0400 on 2014-6-1 Charles Lepple wrote:
 >
 > On May 24, 2014, at 5:49 PM, Stefan Bruda wrote:
 > 
 > >> Don't worry about the battery physical properties for now -
the
 > >> problem there is that we don't have enough information from
the UPS
 > >> to do a proper calculation. With the V_interval[] settings, you
can
 > >> tweak the new state-of-charge calculation to match what you see
via
 > >> upsc when the battery is fully charged, so that's better than
 > >> nothing.
 > > 
 > > Yes, the V_interval[] being exposed is a very good idea and does seem
 > > the only sensible workaround.
 > 
 > As of the latest push (rev 0d1e017), the tripplite_usb driver
 > (v0.22) now reads the battery_min and battery_max variables from
 > ups.conf at startup.

Great, many thanks.  I have pulled tripplite_usb.c only (with the rest
as provided by Gentoo, meaning version 2.7.1) but the result ends up
reading incorrect values:

   0.050452     Setting 'battery_min' to 1e+01
   0.050472     Setting 'battery_max' to 1e+01

I thought that I have to pull some more files, but I note that
revision 0d1e017 does not change anything else worth mentioning.
Strange...

Just to be sure though, this is what I have in /etc/nut/ups.conf:

[post]
    driver = tripplite_usb
    port = auto
    desc = "Main comm UPS"
    battery_min = 11
    battery_max = 13.6

This is how the things need to be specified, right?

In any event, I pulled the whole tree but its build fails as follows:

make[2]: Entering directory `/home/bruda/nut-master/docs/man'
Using existing upsclient.3 manual page, since 'asciidoc' was not found.
Using existing upscli_add_host_cert.3 manual page, since 'asciidoc' was
not found.
Using existing upscli_cleanup.3 manual page, since 'asciidoc' was not
found.
Using existing upscli_connect.3 manual page, since 'asciidoc' was not
found.
Using existing upscli_disconnect.3 manual page, since 'asciidoc' was not
found.
Using existing upscli_fd.3 manual page, since 'asciidoc' was not found.
Using existing upscli_get.3 manual page, since 'asciidoc' was not found.
Using existing upscli_init.3 manual page, since 'asciidoc' was not
found.
Using existing upscli_list_next.3 manual page, since 'asciidoc' was not
found.
Using existing upscli_list_start.3 manual page, since 'asciidoc' was not
found.
Using existing upscli_readline.3 manual page, since 'asciidoc' was not
found.
Using existing upscli_sendline.3 manual page, since 'asciidoc' was not
found.
Using existing upscli_splitaddr.3 manual page, since 'asciidoc' was not
found.
Using existing upscli_splitname.3 manual page, since 'asciidoc' was not
found.
Using existing upscli_ssl.3 manual page, since 'asciidoc' was not found.
Using existing upscli_strerror.3 manual page, since 'asciidoc' was not
found.
Using existing upscli_upserror.3 manual page, since 'asciidoc' was not
found.
Using existing libnutclient.3 manual page, since 'asciidoc' was not
found.
Using existing libnutclient_commands.3 manual page, since 'asciidoc' was
not found.
Using existing libnutclient_devices.3 manual page, since 'asciidoc' was
not found.
Using existing libnutclient_general.3 manual page, since 'asciidoc' was
not found.
Using existing libnutclient_misc.3 manual page, since 'asciidoc' was not
found.
Using existing libnutclient_tcp.3 manual page, since 'asciidoc' was not
found.
Using existing libnutclient_variables.3 manual page, since 'asciidoc'
was not found.
make[2]: *** No rule to make target `nutclient_authenticate.3', needed by
`all-am'.  Stop.
make[2]: Leaving directory `/home/bruda/nut-master/docs/man'
make[1]: *** [all-recursive] Error 1

I don't think that me missing asciidoc is the cause.  Any idea what I
am doing wrong?

 > I'm not so sure if it makes sense to make them reconfigurable while
 > the driver is running-- the driver doesn't take very long to
 > restart, and if they were made available through upsrw, they
 > wouldn't be saved back to ups.conf anyway. I could be persuaded,
 > though.

I will not try to persuade you. :-) I do not see how restarting the
driver is going to be so time consuming as to be worth doing anything
about.  Additionally as you say the dynamic changes are not going to
be persistent, which defies the whole purpose of these values.

Best regards,
Stefan

-- 
If it was so, it might be; and if it were so, it would be; but as it 
isn't, it ain't.  That's logic.  --Lewis Carroll, Through the
Looking-Glass

No HTML emails and proprietary attachments please <http://bruda.ca/ascii>