Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

2018-03-23 Thread Ken Olum
Thanks, Charles.  I pulled your change and it fixed my segmentation
fault.

I discovered the following code at line 571 in usbhid-ups.c.  This is
part of the "checking for alternatives" code:

if (!strcasecmp(cmdname, "shutdown.return")) {
int ret;

/* Ensure "ups.start.auto" is set to "yes", if 
supported */
if (dstate_getinfo("ups.start.auto")) {
setvar("ups.start.auto", "yes");
}

ret = instcmd("load.on.delay", 
dstate_getinfo("ups.delay.start"));
if (ret != STAT_INSTCMD_HANDLED) {
return ret;
}

return instcmd("load.off.delay", 
dstate_getinfo("ups.delay.shutdown"));
}

My understanding of this code is that it attempts to set the
load.on.delay control.  If that works, it then uses load.off.delay to
schedule a shutdown.  My unit has nothing that maps into load.on.delay,
so that command fails, and then it does not use load.off.delay.  Instead
it fails, and the calling code goes on to try shutdown.reboot, which in
my case has the completely wrong functionality.

However, load.off.delay seems to be the right thing to use for me.
Without any other setting, it shuts off the UPS after the delay and
reboots it when the power returns.  I don't know what functionality
load.on.delay is supposed to represent.  Is it trying to avoid the race
where the power comes on before the load.off.delay command has reached
the UPS, which then never restarts the load?

Since this race seems fairly unlikely to cause trouble and with the code
above my UPS is unusable, I modified my copy of the code to remove the
check for the return value from load.on.delay.  This indeed causes it to
shut down the UPS as it should.

I'm sure this is not the right fix in general, but I don't understand
the situation well enough to know what would be better.  Among other
things I don't know is whether my real problem is with this logic or
whether it is with the mapping of things like
UPS.OutletSystem.Outlet.DelayBeforeShutdown to things like
load.off.delay.

Ken

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser


Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

2018-03-21 Thread Charles Lepple
On Mar 20, 2018, at 11:53 AM, Ken Olum  wrote:
> 
> Hi, Charles.  Are you by any chance planning to address my problems
> where NUT does not know how to schedule a shutdown of this Tripp-Lite
> UPS?  If not, could you point me in the right direction?  My best
> understanding of the situation of the moment is that the right control
> is UPS.OutletSystem.Outlet.DelayBeforeShutdown but that NUT does not
> know to use that.

Ken,

I apologize for the delay - I forgot that your segfault was on the master 
branch, not the libusb-1.0+0.1 branch. (There are some merge issues with the 
latter, and I have been fighting a losing battle trying to find time to test 
the merge with actual working hardware.)

If you pull the master branch again, you should get a tree that includes commit 
e34d94a94f0: "usbhid-ups: fix instcmd logging before fallback check", and 
rebuilding with that should fix the segfault.

I wouldn't read too much into the distinction between "outlet" and "load" and 
the UPS itself, especially for a single ganged output control.

Because of the way the code is written, it tries a bunch of different 
combinations of commands until one works, but unless someone provides debug 
logs, we don't know the exact sequence for a given UPS. That's why I am 
hesitant to push a change without doing baseline testing on known working 
hardware (and grabbing the logs).

I am attempting to gather the Ubuntu/Debian rebuild instructions here: 
https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu

My only caution with removing the distro packages is that the init/systemd 
scripts from the NUT repository may not be the best match. (Then again, there 
are some open issues with Debian/Ubuntu package shutdown scripts...)

In an earlier email, you asked about matching up the NUT "usage path" to the 
Report ID. In Wireshark, find the "GET DESCRIPTOR Response" for the HID Report 
Descriptor (might say "Unknown type 34" if you have an old version like on this 
computer). Each of the NUT 32-bit hex components of the path are a combination 
of the 16-bit Usage Page and the 16-bit Usage. The dots in the path correspond 
to a Collection. The Report ID is nested in among all of the other items. Given 
this structure, and that Wireshark usually collapses all of the elements of the 
report descriptor, it is often easier to find report IDs in the usbhid-ups 
debug output.

-- 
- Charles Lepple
https://ghz.cc/charles/



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser


Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

2018-03-20 Thread Ken Olum
Hi, Charles.  Are you by any chance planning to address my problems
where NUT does not know how to schedule a shutdown of this Tripp-Lite
UPS?  If not, could you point me in the right direction?  My best
understanding of the situation of the moment is that the right control
is UPS.OutletSystem.Outlet.DelayBeforeShutdown but that NUT does not
know to use that.

Thanks.

Ken

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser


Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

2018-01-23 Thread Ken Olum
   From: Charles Lepple 
   Date: Tue, 23 Jan 2018 09:02:14 -0500

   On Jan 22, 2018, at 3:00 PM, Ken Olum  wrote:
   > 
   > I tested the effect of setting UPS.OutletSystem.Outlet.DelayBeforeShutdown
   > using Tripp Lite's software, which appears to be as follows:
   > 
   Theoretically, this should be the same as running the command "upscmd 
bcpers@localhost -u  load.off.delay ".

It is.  And now I can see that it sets ups.timer.shutdown (as reported
by upsc) to the number that you give and that then counts down until the
shutdown.

But note that in spite of the words "outlet" and "load" in the
descriptors, what this control actually does is to shut down the UPS,
not just the load.  So is the real problem here that the system has
somehow misidentified the UPS delayed shutdown control as the delayed
load-off control, and that's why it doesn't use it when you say
"usbhid-ups -k"?

   in the mean time, would you be interested in setting things up to
   rebuild the driver?

I was able to build it following your directions.  Some things went in
the same place as the Ubuntu packages had used, but others did not, so I
removed the Ubuntu packages, and installed from source.  Most things
seem to work, though "/lib/nut/usbhid-ups -a bcpers450 -k" now gets a
segfault instead of doing the (wrong) thing it did before.

Ken

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser


Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

2018-01-23 Thread Charles Lepple
On Jan 22, 2018, at 3:00 PM, Ken Olum  wrote:
> 
> I tested the effect of setting UPS.OutletSystem.Outlet.DelayBeforeShutdown
> using Tripp Lite's software, which appears to be as follows:
> 
Theoretically, this should be the same as running the command "upscmd 
bcpers@localhost -u  load.off.delay ".

> So if you could fix nut to use UPS.OutletSystem.Outlet.DelayBeforeShutdown
> in my case, or tell me how do it, I would appreciate that.

I still haven't had a good chunk of time to walk through the shutdown code (the 
part that handles "usbhid-ups ... -k"), but in the mean time, would you be 
interested in setting things up to rebuild the driver? (The next week is 
looking pretty ridiculous for me, so I don't anticipate being able to dust off 
my .deb build tree soon.)

My thought is that you can rebuild NUT with the same configuration options as 
the .debs, and the usbhid-ups driver should just drop in. The instructions are 
almost the same for Ubuntu as for Debian:

http://lists.alioth.debian.org/pipermail/nut-upsdev/2017-October/007341.html and

http://lists.alioth.debian.org/pipermail/nut-upsdev/2017-October/007343.html 
(omit the "git checkout" line; although we have a new-and-improved libusb 
branch, I think it's an unnecessary delta for your situation.)



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser


Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

2018-01-22 Thread Ken Olum
I tested the effect of setting UPS.OutletSystem.Outlet.DelayBeforeShutdown
using Tripp Lite's software, which appears to be as follows:

1.  If you set it when the line power is on, it turns off the UPS after
the delay, and does not turn it back on again, even if you cycle the
line power.

2.  If you set it when the UPS is running on battery, wait for the UPS
to turn off, and turn back on the line power, the UPS restarts and turns
on the load.  So the basic functionality of this control works.

3.  If you set it when the UPS is running on battery, and turn back on
the line power before the timer has expired, then the UPS turns off the
load at the given time, and then turns on the load after some delay. (I
don't how this delay is determined.)  Thus it avoids the race where the
power comes on again during the shutdown delay.

There is presumably still a race where the power returns before the
delayed shutdown command is issued but after the system is committed to
issuing it.  But that is less important and I'm willing to risk it.

So if you could fix nut to use UPS.OutletSystem.Outlet.DelayBeforeShutdown
in my case, or tell me how do it, I would appreciate that.

Ken

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser


Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

2018-01-12 Thread Ken Olum
   From: Charles Lepple 
   Date: Thu, 11 Jan 2018 22:31:54 -0500

   The trick will be adding support for this without breaking other
   models.

For whatever it's worth, Tripp lite's software does not display the
model number anywhere, so it may be treating all models the same.

   In case you are interested, this mapping between the "Path" and the
   report ID is in the HID Report Descriptor which should be early in
   the Wireshark capture.

I see something called GET DESCRIPTOR Response HID Report which lists
the report IDs, but I don't say where it gives information to map it to
the path.

   Other HID UPS models tend to provide both DelayBeforeShutdown and
   DelayBeforeStartup

There is something called Path: UPS.OutletSystem.Outlet.DelayBeforeReboot,
ReportID: 0x17.  This is sent by the "Immediate Device Reboot" action of
the Tripp lite software.  Its function seems to be to turn off the load
immediately and turn it back on after the given number of seconds.  I'm
not sure why this would be useful.

   For completeness, would you mind sending the output of "upsrw" and
   "upscmd -l"?

Below.

Thanks again for your help.  I will be away until Monday afternoon, so
please forgive delay in answering e-mails.

Ken

% upsrw bcpers450@localhost
[ups.delay.shutdown]
Interval to wait after shutdown with delay command (seconds)
Type: STRING
Maximum length: 10
Value: 200

% upscmd -l bcpers450@localhost
Instant commands supported on UPS [bcpers450]:

beeper.disable - Disable the UPS beeper
beeper.enable - Enable the UPS beeper
beeper.mute - Temporarily mute the UPS beeper
beeper.off - Obsolete (use beeper.disable or beeper.mute)
beeper.on - Obsolete (use beeper.enable)
load.off - Turn off the load immediately
load.off.delay - Turn off the load with a delay (seconds)
reset.watchdog - Reset watchdog timer
shutdown.reboot - Shut down the load briefly while rebooting the UPS
shutdown.stop - Stop a shutdown in progress
test.battery.start.deep - Start a deep battery test
test.battery.start.quick - Start a quick battery test
test.battery.stop - Stop the battery test

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser


Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

2018-01-11 Thread Charles Lepple
On Jan 11, 2018, at 3:14 PM, Ken Olum wrote:
> 
> So I monitored the USB port with wireshark (an interesting endeavor
> since I didn't start out with any knowledge of USB protocols).  But I
> have managed to discover that when I ask Tripp Lite's poweralert
> software to schedule a UPS shutdown, it does it by using the SET_REPORT
> function of the USB HID protocol with ReportType "Feature", ReportID 21
> (0x15), and 3 bytes of data which are 0x15 followed by the number of
> seconds to wait before shutting down in two bytes, LSB first.
> 
> Below I include wireshark packet dissections for two such commands.  The
> difference is in the "data fragment".  In the first case it is 150500,
> representing a shutdown in 5 seconds, and the second 153701,
> representing a shutdown in 311 = 0x0137 seconds.
> 
> Is this helpful?

Definitely. (The trick will be adding support for this without breaking other 
models.)

Here's the debug output describing ReportID 0x15:

  0.070916  Path: UPS.OutletSystem.Outlet.DelayBeforeShutdown, Type: 
Feature, ReportID: 0x15, Offset: 0, Size: 16, Value: 65535

(In case you are interested, this mapping between the "Path" and the report ID 
is in the HID Report Descriptor which should be early in the Wireshark capture.)

Other HID UPS models tend to provide both DelayBeforeShutdown and 
DelayBeforeStartup, so I will need to reacquaint myself with how that is 
handled in the code, since your UPS only seems to need one of those (and this 
command is an exception to the usual 1:1 mapping of HID Usage IDs to NUT 
variables). That might not happen until the weekend.

For completeness, would you mind sending the output of "upsrw" and "upscmd -l"? 
I would like to verify some of the other mappings, and also publish that here: 
http://networkupstools.org/ddl/Tripp_Lite/index.html
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser


Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

2018-01-11 Thread Ken Olum
Thanks again for your help, Charles.  I was able to install the Tripp
Lite software on my Ubuntu machine, and it sort of works.  It does
something which continually changes the USB device ID of the UPS, and
prints voluminous error messages in the log.  However, one of the things
that it can do is to schedule a UPS shutdown, which Nut does not know
how to do.

So I monitored the USB port with wireshark (an interesting endeavor
since I didn't start out with any knowledge of USB protocols).  But I
have managed to discover that when I ask Tripp Lite's poweralert
software to schedule a UPS shutdown, it does it by using the SET_REPORT
function of the USB HID protocol with ReportType "Feature", ReportID 21
(0x15), and 3 bytes of data which are 0x15 followed by the number of
seconds to wait before shutting down in two bytes, LSB first.

Below I include wireshark packet dissections for two such commands.  The
difference is in the "data fragment".  In the first case it is 150500,
representing a shutdown in 5 seconds, and the second 153701,
representing a shutdown in 311 = 0x0137 seconds.

Is this helpful?

Ken


  27738 174.290305 host  1.44.0USBHID   67  
   SET_REPORT Request

Frame 27738: 67 bytes on wire (536 bits), 67 bytes captured (536 bits) on 
interface 0
USB URB
[Source: host]
[Destination: 1.44.0]
URB id: 0x964d9a2f8540
URB type: URB_SUBMIT ('S')
URB transfer type: URB_CONTROL (0x02)
Endpoint: 0x00, Direction: OUT
Device: 44
URB bus id: 1
Device setup request: relevant (0)
Data: present (0)
URB sec: 1515699253
URB usec: 785764
URB status: Operation now in progress (-EINPROGRESS) (-115)
URB length [bytes]: 3
Data length [bytes]: 3
[Response in: 27739]
Interval: 0
Start frame: 0
Copy of Transfer Flags: 0x
Number of ISO descriptors: 0
[bInterfaceClass: HID (0x03)]
URB setup
bmRequestType: 0x21
bRequest: 9
wValue: 0x0315
wIndex: 0 (0x)
wLength: 3
Data Fragment: 150500
bRequest: SET_REPORT (0x09)
wValue: 0x0315
ReportID: 21
ReportType: Feature (3)
wIndex: 0
wLength: 3

  66224 1042.041242host  1.48.0USBHID   67  
   SET_REPORT Request

Frame 66224: 67 bytes on wire (536 bits), 67 bytes captured (536 bits) on 
interface 0
USB URB
[Source: host]
[Destination: 1.48.0]
URB id: 0x964c9246bd80
URB type: URB_SUBMIT ('S')
URB transfer type: URB_CONTROL (0x02)
Endpoint: 0x00, Direction: OUT
Device: 48
URB bus id: 1
Device setup request: relevant (0)
Data: present (0)
URB sec: 1515700121
URB usec: 536701
URB status: Operation now in progress (-EINPROGRESS) (-115)
URB length [bytes]: 3
Data length [bytes]: 3
[Response in: 66225]
Interval: 0
Start frame: 0
Copy of Transfer Flags: 0x
Number of ISO descriptors: 0
[bInterfaceClass: HID (0x03)]
URB setup
bmRequestType: 0x21
bRequest: 9
wValue: 0x0315
wIndex: 0 (0x)
wLength: 3
Data Fragment: 153701
bRequest: SET_REPORT (0x09)
wValue: 0x0315
ReportID: 21
ReportType: Feature (3)
wIndex: 0
wLength: 3

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser


Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

2018-01-10 Thread Charles Lepple
On Dec 20, 2017, at 10:32 AM, Ken Olum wrote:
> 
>   0.090564find_nut_info: unknown info type: load.on.delay
>   0.090577find_nut_info: unknown info type: load.on.delay
>   0.090585Initiating UPS shutdown
>   0.090593upsdrv_shutdown...
>   0.090601instcmd(shutdown.return, [NULL])
>   0.090614find_nut_info: unknown info type: shutdown.return
>   0.090624instcmd(load.on.delay, [NULL])
>   0.090633find_nut_info: unknown info type: load.on.delay
>   0.090641instcmd: info element unavailable load.on.delay
> 
>   0.090649instcmd(shutdown.reboot, [NULL])
>   0.091107upsdrv_cleanup...

Sorry, I missed this part from the "-k" output. This at least seems to explain 
the 10-second delay. Here's what I think is going on:

NUT looks up the "shutdown.return" ("Turn off the load and return when power is 
back") command, and finds nothing that matches your UPS. Then it tries 
"load.on.delay" - same problem. It then finds the path for "shutdown.reboot", 
which is most likely mapped to this line: 
https://github.com/networkupstools/nut/blob/v2.7.2/drivers/tripplite-hid.c#L394 
(IIRC it's the first match, otherwise it would be 
https://github.com/networkupstools/nut/blob/v2.7.2/drivers/tripplite-hid.c#L397 
)

That sends a value of 10 (likely corresponding to the 10-second delay) to 
UPS.OutletSystem.Outlet.DelayBeforeReboot

The fact that there is not a "UPS.OutletSystem.Outlet.DelayBeforeStartup" or 
"UPS.OutletSystem.Outlet.TLDelayBeforeStartup" in the debug output for your UPS 
means that the "wait for power" functionality is probably hidden behind 
something else, possibly another vendor-specific item (see, for instance, 
"UPS.OutletSystem.Outlet.00bc" and the other * names after 
"*.DelayBeforeShutdown").

To be honest, if you can set up the Tripp-Lite software somewhere temporarily 
(possibly an older laptop, or maybe even in a VM - though VMs have their own 
issues), that might be the quickest way to get the behavior you are looking 
for. You could set absurdly large shutdown timers, and fire up usbhid-ups in 
debug mode to watch the counters. I think that would be safer than trying to 
set various vendor-specific items to random values.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser


Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

2018-01-09 Thread Ken Olum
Any more thoughts about how I might get this UPS working?  I guess I
could try using the software from Tripp-Lite, but it is intended for
ancient versions of Fedora and OpenSUSE, whereas I'm running Ubuntu
16.04.  It would be much nicer to use Nut, but I don't know how to
proceed.

Thanks.

Ken

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser


Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

2017-12-20 Thread Ken Olum
Thanks for your help.

   From: Charles Lepple 
   Date: Mon, 18 Dec 2017 19:26:56 -0500

   This may sound like an apples-to-oranges comparison, but we did uncover an 
issue with CyberPower UPSes where the delay values needed to be greater than or 
equal to 60 (seconds), since they were being rounded down to integer numbers of 
minutes internally:

   What was the largest delay you tried?

I have now tried 200 seconds without any change.  The offdelay setting
does appear in the status as ups.delay.shutdown, but seems to have no effect.

   > ups.timer.reboot: 65535
   > ups.timer.shutdown: 65535
   > 

   I seem to remember that these values should change to e.g. -60 if you
   set the delay to 60, and then they should begin counting down after
   the shutdown command is sent. It has been a while since I messed with
   that code, though.

No matter what settings I use, the UPS seems to turn off the load
immediately in response to the shutdown command.  I have never seen
ups.timer.shutdown change from the value above.  After shutting off the
load, ups.timer.reboot changes to 10, regardless of the setting of
driver.parameter.ondelay.  It then counts down to 0 and turns the load
back on.

   What log messages do you get with "/lib/nut/usbhid-ups -DD -a
   bcpers450 -k"?

See below.

   For future reference, was this UPS manufactured recently? 

I have just purchased it new, so presumably yes.

Ken

--

# /lib/nut/usbhid-ups -DD -a bcpers450 -k
Network UPS Tools - Generic HID driver 0.38 (2.7.2)
USB communication driver 0.32
   0.00 debug level is '2'
   0.000852 upsdrv_initups...
   0.014448 Checking device (1D6B/0003) (002/001)
   0.030206 - VendorID: 1d6b
   0.030219 - ProductID: 0003
   0.030239 - Manufacturer: unknown
   0.030242 - Product: unknown
   0.030246 - Serial Number: unknown
   0.030249 - Bus: 002
   0.030253 Trying to match device
   0.030259 Device does not match - skipping
   0.030304 Checking device (09AE/2010) (001/009)
   0.034107 - VendorID: 09ae
   0.034120 - ProductID: 2010
   0.034122 - Manufacturer: Tripp Lite 
   0.034153 - Product: Tripp Lite UPS 
   0.034156 - Serial Number: unknown
   0.034159 - Bus: 001
   0.034162 Trying to match device
   0.034179 Device matches
   0.034195 failed to claim USB device: could not claim interface 0: Device 
or resource busy
   0.034209 detached kernel driver from USB device...
   0.035773 HID descriptor length 613
   0.054980 Report Descriptor size = 613
   0.055190 Using subdriver: TrippLite HID 0.81
   0.055810 Path: UPS.PowerSummary.iProduct, Type: Feature, ReportID: 0x28, 
Offset: 0, Size: 8, Value: 2
   0.056434 Path: UPS.PowerSummary.iSerialNumber, Type: Feature, ReportID: 
0x29, Offset: 0, Size: 8, Value: 3
   0.056913 Path: UPS.PowerSummary.iManufacturer, Type: Feature, ReportID: 
0x2b, Offset: 0, Size: 8, Value: 1
   0.057431 Path: UPS.PowerSummary.00d9, Type: Feature, ReportID: 0xc0, 
Offset: 0, Size: 8, Value: 5
   0.057855 Path: UPS.PowerSummary.Input.ConfigVoltage, Type: Feature, 
ReportID: 0x30, Offset: 0, Size: 8, Value: 120
   0.058533 Path: UPS.PowerSummary.AudibleAlarmControl, Type: Feature, 
ReportID: 0x11, Offset: 0, Size: 8, Value: 2
   0.059163 Path: UPS.PowerSummary.iDeviceChemistry, Type: Feature, 
ReportID: 0x2a, Offset: 0, Size: 8, Value: 4
   0.059667 Path: UPS.PowerSummary.CapacityMode, Type: Feature, ReportID: 
0x33, Offset: 0, Size: 8, Value: 2
   0.060193 Path: UPS.PowerSummary.Rechargeable, Type: Feature, ReportID: 
0x2c, Offset: 0, Size: 8, Value: 1
   0.060733 Path: UPS.PowerSummary.RunTimeToEmpty, Type: Input, ReportID: 
0x35, Offset: 0, Size: 16, Value: 5740
   0.060755 Path: UPS.PowerSummary.RunTimeToEmpty, Type: Feature, ReportID: 
0x35, Offset: 0, Size: 16, Value: 5740
   0.061271 Path: UPS.PowerSummary.RemainingCapacity, Type: Input, 
ReportID: 0x34, Offset: 0, Size: 8, Value: 100
   0.061291 Path: UPS.PowerSummary.RemainingCapacity, Type: Feature, 
ReportID: 0x34, Offset: 0, Size: 8, Value: 100
   0.061896 Path: UPS.PowerSummary.FullChargeCapacity, Type: Feature, 
ReportID: 0x37, Offset: 0, Size: 8, Value: 100
   0.062368 Path: UPS.PowerSummary.DesignCapacity, Type: Feature, ReportID: 
0x36, Offset: 0, Size: 8, Value: 100
   0.062904 Path: UPS.PowerSummary.PresentStatus.Voltage, Type: Feature, 
ReportID: 0x31, Offset: 0, Size: 16, Value: 0
   0.063470 Path: UPS.PowerSummary.PresentStatus.ShutdownImminent, Type: 
Input, ReportID: 0x32, Offset: 0, Size: 1, Value: 0
   0.063512 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input, 
ReportID: 0x32, Offset: 1, Size: 1, Value: 0
   0.063539 Path: UPS.PowerSummary.PresentStatus.Charging, Type: Input, 
ReportID: 0x32, Offset: 2, Size: 1, Value: 0
   

Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

2017-12-18 Thread Charles Lepple
[please use reply-all to post to the list - the mailing list does not add a 
reply-to header. thanks!]

On Dec 18, 2017, at 11:37 AM, Ken Olum wrote:
> 
> I have a Tripp-Lite BCPERS450, connected to a system running Ubuntu
> 16.04.3 LTS and NUT 2.7.2-4ubuntu1.2.  I had to make my own
> /lib/systemd/system-shutdown/nutshutdown, but now everything is working
> except for powering on and off the UPS.  Regardless of the settings of
> offdelay and ondelay in upsconf, and regardless of whether the AC power
> is on, when I say "upsdrvctl shutdown" the UPS turns off the power to
> the system instantly and turns it back on in ten seconds.

Thanks for the specific version info and detailed logs.

This may sound like an apples-to-oranges comparison, but we did uncover an 
issue with CyberPower UPSes where the delay values needed to be greater than or 
equal to 60 (seconds), since they were being rounded down to integer numbers of 
minutes internally:

https://github.com/networkupstools/nut/issues/432

What was the largest delay you tried?

> ups.timer.reboot: 65535
> ups.timer.shutdown: 65535
> 

I can't test this on either one of my Tripp-Lite units (one is too old, and the 
other has the ill-fated 3016 protocol USB controller that can't stay on the bus 
long enough to do anything useful), but I seem to remember that these values 
should change to e.g. -60 if you set the delay to 60, and then they should 
begin counting down after the shutdown command is sent. It has been a while 
since I messed with that code, though.

What log messages do you get with "/lib/nut/usbhid-ups -DD -a bcpers450 -k"? 
(NOTE this will also tell the UPS to shut down immediately - it's the command 
that upsdrvctl runs, but with more debugging.)

For future reference, was this UPS manufactured recently? The NUT source code 
mentions that the TLCustom prefix is 0x0010, but the HID descriptor dump 
shows a few items under "UPS.0015". Hopefully the delays haven't been moved 
to those values, since we don't have good information on the corresponding 
names.

Also, it may be worthwhile to reach out to Tripp Lite support. A few years ago, 
the NUT project got a large spreadsheet of testing results (mostly upsc output, 
rather than full end-to-end) from connecting many of their their USB UPS models 
to NUT from one of their sales offices. Interestingly, the following models 
have the same USB product ID as your UPS, and the Smart1000LCD was on that list:

 * http://networkupstools.org/ddl/Tripp_Lite/AVR900U.html
 * http://networkupstools.org/ddl/Tripp_Lite/G1010USB.html
 * http://networkupstools.org/ddl/Tripp_Lite/SMART1000LCD.html

> ___
> Nut-upsuser mailing list
> Nut-upsuser@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser


___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser