Nut upsuser - Jan 2020 - [EXTERNAL] Re: Tripp Lite SMART1500LCD will not stay shut down when power is disconnected

Your suggestion of rebuilding the driver fixed the issue of the UPS turning
back during a power failure. Now the UPS shuts down the clients, then
powers off appropriately. If power returns it turns back on also.

The only bug is if power returns before the UPS has turned the load off. In
that case the UPS will remain off until it is manually turned on.

This might just be a limitation of this model, I don't know. But at least
this behavior is not catastrophic like before. I suppose I can live with
this edge case bug.

Thank you for your help again!

I don't know if my methods are perfect but just in case anyone has the same
issue, here is the change I made:

https://github.com/Laynezilla/nut/commit/ce3fcd0533e66b8be4adcf63ea0a63a7c45ba024

And here are the commands I used:

sudo apt update
sudo apt install devscripts git
mk-build-deps nut --install --root-cmd sudo --remove
sudo apt remove asciidoc
cd ~/
git clone https://github.com/Laynezilla/nut.git
cd ~/nut
./autogen.sh
./configure \
--build=`gcc -print-multiarch` \
--includedir=/usr/include \
--mandir=/usr/share/man \
--infodir=/usr/share/info \
--sysconfdir=/etc \
--localstatedir=/var \
--disable-silent-rules \
--libdir=/usr/lib/`gcc -print-multiarch` \
--runstatedir=/run \
--enable-maintainer-mode \
--disable-dependency-tracking \
--sysconfdir=/etc/nut \
--includedir=/usr/include \
--mandir=/usr/share/man \
--libdir=/lib/`gcc -print-multiarch` \
--with-ssl \
--with-nss \
--with-cgi \
--with-dev \
--enable-static \
--with-statepath=/run/nut \
--with-altpidpath=/run/nut \
--with-drvpath=/lib/nut \
--with-cgipath=/usr/lib/cgi-bin/nut \
--with-htmlpath=/usr/share/nut/www \
--with-pidpath=/run/nut \
--datadir=/usr/share/nut \
--with-pkgconfig-dir=/usr/lib/`gcc -print-multiarch`/pkgconfig \
--with-user=nut \
--with-group=nut \
--with-udev-dir=/lib/udev \
--with-systemdsystemunitdir=/lib/systemd/system \
--with-systemdshutdowndir=/lib/systemd/system-shutdown
make
make check VERBOSE=1
cd ~/nut/drivers
sudo upsdrvctl stop
sudo make install
sudo apt remove nut-build-deps
sudo apt remove devscripts
sudo apt autoremove
sudo upsdrvctl start

On Sat, Jan 4, 2020 at 5:15 PM Ken Olum <kdo at cosmos.phy.tufts.edu>
wrote:
>    From: Layne Fowler <layne.fowler at gmail.com>
>    Date: Fri, 3 Jan 2020 16:22:10 -0500
>
>    I see, so you kept the load.on.delay command but removed the check to
> see
>    if it was handled. Did you do the same thing for the shutdown.stayoff
> logic?
>
> I didn't, because I don't use that functionality, though it does
look as
> though it should be modified in just the same way.
>
>    This might be a dumb question but did this require you to recompile the
>    kernel? These types of changes are way beyond my depth.
>
> I rebuilt NUT (saying "make install" seems to have been
sufficient).  I
> didn't do anything involving my Linux kernel.
>
>                                         Ken
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20200113/9a6eb06f/attachment.html>

Hi, Layne.  Glad my changes helped.

It's not surprising that there are some remaining race conditions.  I'm
afraid I can't remember whether I have this particular problem or not.
My variable settings shown by upsc are below.

I think the general plan should be to run the system on the UPS for as
long as possible, then shut it down with the shortest delay possible
that still allows for a clean shutdown of your system.  If these times
are, say, 10 minutes and 10 seconds, then you only encounter the race if
the power happens to be off for an interval between 0:10:00 and 0:10:10,
which is quite unlikely.

Actually fixing all races would be better still, but I do not have a
good enough understanding of how my UPS handles the various settings to
be able to do that.

                                        Ken

battery.charge: 100
battery.runtime: 4050
battery.type: PbAC
battery.voltage: 13.4
battery.voltage.nominal: 12.0
device.mfr: Tripp Lite 
device.model: Tripp Lite UPS 
device.type: ups
driver.name: usbhid-ups
driver.parameter.offdelay: 10
driver.parameter.ondelay: 50
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: 2.7.4-476-g6b9971a7
driver.version.data: TrippLite HID 0.82
driver.version.internal: 0.42
input.frequency: 60.0
input.voltage: 118.2
input.voltage.nominal: 120
output.frequency.nominal: 60
output.voltage.nominal: 120
ups.beeper.status: disabled
ups.delay.shutdown: 10
ups.mfr: Tripp Lite 
ups.model: Tripp Lite UPS 
ups.power.nominal: 450
ups.productid: 2010
ups.status: OL
ups.timer.reboot: 65535
ups.timer.shutdown: 65535
ups.vendorid: 09ae
ups.watchdog.status: 0

If you'd like, shoot me over your serial number and the corner-cases you
don't have answers for and I can look into it.

Thank you,
David Zomaya
Tripp Lite
david_zomaya at tripplite.com


-----Original Message-----
From: Nut-upsuser <nut-upsuser-bounces+david_zomaya=tripplite.com at
alioth-lists.debian.net> On Behalf Of Ken Olum
Sent: Tuesday, January 14, 2020 11:24 AM
To: Layne Fowler <layne.fowler at gmail.com>
Cc: nut-upsuser at alioth-lists.debian.net
Subject: [EXTERNAL] Re: [Nut-upsuser] Tripp Lite SMART1500LCD will not stay shut
down when power is disconnected

This is an EXTERNAL email.  Please take a moment and think before clicking any
links or opening any attachments from this email.  If suspicious, please forward
to ishelpdesk at tripplite.com for review.

______________________________________________________________________
Hi, Layne.  Glad my changes helped.

It's not surprising that there are some remaining race conditions.  I'm
afraid I can't remember whether I have this particular problem or not.
My variable settings shown by upsc are below.

I think the general plan should be to run the system on the UPS for as long as
possible, then shut it down with the shortest delay possible that still allows
for a clean shutdown of your system.  If these times are, say, 10 minutes and 10
seconds, then you only encounter the race if the power happens to be off for an
interval between 0:10:00 and 0:10:10, which is quite unlikely.

Actually fixing all races would be better still, but I do not have a good enough
understanding of how my UPS handles the various settings to be able to do that.

                                        Ken

battery.charge: 100
battery.runtime: 4050
battery.type: PbAC
battery.voltage: 13.4
battery.voltage.nominal: 12.0
device.mfr: Tripp Lite
device.model: Tripp Lite UPS
device.type: ups
driver.name: usbhid-ups
driver.parameter.offdelay: 10
driver.parameter.ondelay: 50
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: 2.7.4-476-g6b9971a7
driver.version.data: TrippLite HID 0.82
driver.version.internal: 0.42
input.frequency: 60.0
input.voltage: 118.2
input.voltage.nominal: 120
output.frequency.nominal: 60
output.voltage.nominal: 120
ups.beeper.status: disabled
ups.delay.shutdown: 10
ups.mfr: Tripp Lite
ups.model: Tripp Lite UPS
ups.power.nominal: 450
ups.productid: 2010
ups.status: OL
ups.timer.reboot: 65535
ups.timer.shutdown: 65535
ups.vendorid: 09ae
ups.watchdog.status: 0

_______________________________________________
Nut-upsuser mailing list
Nut-upsuser at alioth-lists.debian.net
https://urldefense.proofpoint.com/v2/url?u=https-3A__alioth-2Dlists.debian.net_cgi-2Dbin_mailman_listinfo_nut-2Dupsuser&d=DwIGaQ&c=f9s1WCuF-N6cmD_YaZ7gBg&r=lhr3k4au5dVQgHY_iS-v_t9g8PHVkn8Px_wyaupZGfQ&m=YIr82dSB38Vr-95Uq_LfLezoJp_d6ETrux_N-rBqTtY&s=Qo4L4SLByAMmB_N2zSRvNm-D3AaY55e3lCW9jT1oR8I&e________________________________
 This message is for the addressee's use only. It may contain confidential
information. If you receive this message in error, please delete it and notify
the sender. Tripp Lite disclaims all warranties and liabilities, and assumes no
responsibility for viruses which may infect an email sent to you from Tripp Lite
and which damage your electronic systems or information. It is your
responsibility to maintain virus detection systems to prevent damage to your
electronic systems and information.