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

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.

Hi, David.  Thanks for the offer of help.  I have BCPERS450 serial
number 2701DVHBC809300177.  Unfortunately I'm about to go on a trip and
will be away until the end of the month, so I don't have much time to
discuss these things at the moment, but maybe Layne will have something
to say.

My understanding from when I was working on this a couple years ago is
that the main problem in getting NUT working right with Tripp-Lite
equipment is to understand the mappings of the various controls.  For
example, we have ReportID: 0x15, which maps to
UPS.OutletSystem.Outlet.DelayBeforeShutdown.  I think this mapping is
given by the UPS.  NUT than maps this control to load.off.delay.  Is
that mapping correct, i.e., does setting the control in the UPS do the
function that NUT expects?

More importantly, is there anything in the UPS that NUT should be
mapping to load.on.delay?  It does not find such an object, so
load.on.delay is not mapped, which was the original source of the
problem.

Incidentally, according to my old notes, when I ask my UPS to shut
down in ten seconds by setting UPS.OutletSystem.Outlet.DelayBeforeShutdown,
it shuts down even if the power comes back on during those ten seconds.
This is the right behavior because once I send the command I shut down
my system and it needs the power cycle to restart.  My understanding is
that Layne's system does not do this, so there is some difference in
configuration or between the different models.

The only corner case affecting my system that I am aware of is this:
suppose the line power comes back at the same time that my system has
decided to shut down.  The UPS tries to notify the system that the power
is back on, but it's too late and the system is already in the process of
sending the UPS.OutletSystem.Outlet.DelayBeforeShutdown.  Having done
so, the system thinks the UPS will shut off and so shuts down.  However,
because the power was on by the time that UPS actually received the
command, it does not in fact shut off.  Thus the system is shut down and
never reboots.  I don't know how this case is supposed to be handled.

Thanks again.

                                        Ken

Thanks Ken.
I'll plan to sit down and look up the protocol information over the next
week or so and follow up.
________________________________
From: Ken Olum <kdo at cosmos.phy.tufts.edu>
Sent: Tuesday, January 14, 2020 1:35:10 PM
To: David Zomaya
Cc: kdo at cosmos.phy.tufts.edu; layne.fowler at gmail.com; 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, David.  Thanks for the offer of help.  I have BCPERS450 serial
number 2701DVHBC809300177.  Unfortunately I'm about to go on a trip and
will be away until the end of the month, so I don't have much time to
discuss these things at the moment, but maybe Layne will have something
to say.

My understanding from when I was working on this a couple years ago is
that the main problem in getting NUT working right with Tripp-Lite
equipment is to understand the mappings of the various controls.  For
example, we have ReportID: 0x15, which maps to
UPS.OutletSystem.Outlet.DelayBeforeShutdown.  I think this mapping is
given by the UPS.  NUT than maps this control to load.off.delay.  Is
that mapping correct, i.e., does setting the control in the UPS do the
function that NUT expects?

More importantly, is there anything in the UPS that NUT should be
mapping to load.on.delay?  It does not find such an object, so
load.on.delay is not mapped, which was the original source of the
problem.

Incidentally, according to my old notes, when I ask my UPS to shut
down in ten seconds by setting UPS.OutletSystem.Outlet.DelayBeforeShutdown,
it shuts down even if the power comes back on during those ten seconds.
This is the right behavior because once I send the command I shut down
my system and it needs the power cycle to restart.  My understanding is
that Layne's system does not do this, so there is some difference in
configuration or between the different models.

The only corner case affecting my system that I am aware of is this:
suppose the line power comes back at the same time that my system has
decided to shut down.  The UPS tries to notify the system that the power
is back on, but it's too late and the system is already in the process of
sending the UPS.OutletSystem.Outlet.DelayBeforeShutdown.  Having done
so, the system thinks the UPS will shut off and so shuts down.  However,
because the power was on by the time that UPS actually received the
command, it does not in fact shut off.  Thus the system is shut down and
never reboots.  I don't know how this case is supposed to be handled.

Thanks again.

                                        Ken




________________________________
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20200115/731b9055/attachment-0001.html>