[Nut-upsuser] Tripp Lite SMART3000RM2U (protocol 3003) running time and charge?

[Stefan Bruda]

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>