Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems
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
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
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
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
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
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
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
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
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
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
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
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 0.063558 Path: UPS
Re: [Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems
[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
[Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems
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. Any ideas how to get more reasonable behavior, in particular not turning the system back on until the AC power is restored? Here is the status reported by upsc: 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: 20 driver.parameter.ondelay: -1 driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.7.2 driver.version.data: TrippLite HID 0.81 driver.version.internal: 0.38 input.frequency: 60.0 input.voltage: 118.2 input.voltage.nominal: 120 output.frequency.nominal: 60 output.voltage.nominal: 120 ups.beeper.status: enabled ups.delay.shutdown: 20 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 I said /lib/nut/usbhid-ups -DD -a bcpers450 and got: Network UPS Tools - Generic HID driver 0.38 (2.7.2) USB communication driver 0.32 0.00 debug level is '2' 0.000808 upsdrv_initups... 0.017090 Checking device (1D6B/0003) (002/001) 0.033199 - VendorID: 1d6b 0.033215 - ProductID: 0003 0.033217 - Manufacturer: unknown 0.033220 - Product: unknown 0.033222 - Serial Number: unknown 0.033224 - Bus: 002 0.033227 Trying to match device 0.033232 Device does not match - skipping 0.033289 Checking device (09AE/2010) (001/014) 0.036998 - VendorID: 09ae 0.037011 - ProductID: 2010 0.037014 - Manufacturer: Tripp Lite 0.037018 - Product: Tripp Lite UPS 0.037021 - Serial Number: unknown 0.037024 - Bus: 001 0.037027 Trying to match device 0.037042 Device matches 0.037886 HID descriptor too short (expected 8, got 0) 0.037901 HID descriptor length 613 0.057332 Report Descriptor size = 613 0.057663 Using subdriver: TrippLite HID 0.81 0.058304 Path: UPS.PowerSummary.iProduct, Type: Feature, ReportID: 0x28, Offset: 0, Size: 8, Value: 2 0.059008 Path: UPS.PowerSummary.iSerialNumber, Type: Feature, ReportID: 0x29, Offset: 0, Size: 8, Value: 3 0.059619 Path: UPS.PowerSummary.iManufacturer, Type: Feature, ReportID: 0x2b, Offset: 0, Size: 8, Value: 1 0.060167 Path: UPS.PowerSummary.00d9, Type: Feature, ReportID: 0xc0, Offset: 0, Size: 8, Value: 5 0.060709 Path: UPS.PowerSummary.Input.ConfigVoltage, Type: Feature, ReportID: 0x30, Offset: 0, Size: 8, Value: 120 0.061316 Path: UPS.PowerSummary.AudibleAlarmControl, Type: Feature, ReportID: 0x11, Offset: 0, Size: 8, Value: 2 0.061905 Path: UPS.PowerSummary.iDeviceChemistry, Type: Feature, ReportID: 0x2a, Offset: 0, Size: 8, Value: 4 0.062534 Path: UPS.PowerSummary.CapacityMode, Type: Feature, ReportID: 0x33, Offset: 0, Size: 8, Value: 2 0.063079 Path: UPS.PowerSummary.Rechargeable, Type: Feature, ReportID: 0x2c, Offset: 0, Size: 8, Value: 1 0.063619 Path: UPS.PowerSummary.RunTimeToEmpty, Type: Input, ReportID: 0x35, Offset: 0, Size: 16, Value: 4050 0.063658 Path: UPS.PowerSummary.RunTimeToEmpty, Type: Feature, ReportID: 0x35, Offset: 0, Size: 16, Value: 4050 0.064254 Path: UPS.PowerSummary.RemainingCapacity, Type: Input, ReportID: 0x34, Offset: 0, Size: 8, Value: 100 0.064292 Path: UPS.PowerSummary.RemainingCapacity, Type: Feature, ReportID: 0x34, Offset: 0, Size: 8, Value: 100 0.064954 Path: UPS.PowerSummary.FullChargeCapacity, Type: Feature, ReportID: 0x37, Offset: 0, Size: 8, Value: 100 0.065578 Path: UPS.PowerSummary.DesignCapacity, Type: Feature, ReportID: 0x36, Offset: 0, Size: 8, Value: 100 0.066133 Path: UPS.PowerSummary.PresentStatus.Voltage, Type: Feature, ReportID: 0x31, Offset: 0, Size: 16, Value: 1182 0.066673 Path: UPS.PowerSummary.PresentStatus.ShutdownImminent, Type: Input, ReportID: 0x32, Offset: 0, Size: 1, Value: 0 0.066711 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input, ReportID: 0x32, Offset: 1, Size: 1, Value: 1 0.066736 Path: UPS.PowerSummary.PresentStatus.Charging, Type: Input, ReportID: 0x32, Offset: 2, Size: 1, Value: 1 to 0.066756 Path: UPS.PowerSummary.PresentStatus.Discharging, Type: Input, ReportID: 0x32, Offset: 3, Size: 1, Value: 0 0.066777 Path: UPS.PowerSummary.PresentSta
