Nut upsuser - Mar 2015 - Problems with NUT 2.7.2 on CentOS 7 and using the Mini-Box OpenUPS

I?m a new user of NUT and the OpenUPS - in the past I?ve used APC hardware and
apcupsd on Centos 6.

I?ve built NUT 2.7.2 from source but used the OpenUPS HID driver v0.4 that?s in
github. I?m using firmware version 1.5 on the openups which is the latest
published version; I?ve also tried 1.7 which Mini-box sent to me but reverted to
the published version. Their support seems a bit slow!

I?ve got NUT working OK and the upsd running, with upsmon working OK too - all
is well as long as I leave the power on, or the battery takes over but doesn?t
need to shut down the system!

But if I try to shut down the system using 'upsdrvctl shutdown? I get a USB
error message - ?Can?t claim USB device [04d8:doo4]:? This looks like
permissions but I?ve set up UDEV and the users in accordance with the
instructions.

Also if the battery runs down, there is no communication from the UPS via USB -
the power just dies. I could use the motherboard toggle to shut down the system,
but then I can?t run pre-shutdown scripts.

I also can?t collect any data by upsrw (returns blank) or upscmd (no commands
available) - though these functions might not be implemented in the OpenUPS -
does anyone know?

Any help gratefully received!

Philip.
Can't claim USB device [04d8:d004]: driver 0.32
Can't claim USB device [04d8:d004]:
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150313/e88d550c/attachment.html>

On Mar 13, 2015, at 8:21 AM, Philip Taylor <philip at kelsotowers.co.uk>
wrote:
> I?m a new user of NUT and the OpenUPS - in the past I?ve used APC hardware
and apcupsd on Centos 6.
> 
> I?ve built NUT 2.7.2 from source but used the OpenUPS HID driver v0.4
that?s in github. I?m using firmware version 1.5 on the openups which is the
latest published version; I?ve also tried 1.7 which Mini-box sent to me but
reverted to the published version. Their support seems a bit slow!
> 
> I?ve got NUT working OK and the upsd running, with upsmon working OK too -
all is well as long as I leave the power on, or the battery takes over but
doesn?t need to shut down the system!
> 
> But if I try to shut down the system using 'upsdrvctl shutdown? I get a
USB error message - ?Can?t claim USB device [04d8:doo4]:? This looks like
permissions but I?ve set up UDEV and the users in accordance with the
instructions.
The documentation isn't explicit about this, but 'upsdrvctl
shutdown' is meant to be run after all of the other processes on the system
have been killed, real filesystems have been unmounted, and the kernel shutdown
syscall is about to be called. Usually the init scripts will take care of this,
although I don't know how CentOS handles that specifically.

This includes the existing usbhid-ups driver - only one process can talk
*directly* to the UPS at once, and it is usually a driver that is working with
upsd.

If you want to test the low-battery shutdown procedure (where upsmon tells the
rest of the system to shut down, then tells the UPS to power off), you can run
'upsmon -c fsd' (Forced ShutDown). The init scripts should call
'upsdrvctl shutdown' implicitly when everything else has stopped.
> Also if the battery runs down, there is no communication from the UPS via
USB - the power just dies. I could use the motherboard toggle to shut down the
system, but then I can?t run pre-shutdown scripts.
I wonder if that is a calibration issue? Most UPSes will recalibrate as part of
their battery test process, and that should update the runtime estimates and
other variables necessary to detect a low battery condition. Since you mentioned
that the test commands don't show up in upscmd, is there a button or jumper
to trigger calibration?

If either the runtime or battery percentage variable is reliable, it should also
be possible to use the 'ignorelb' setting to synthesize the low battery
signal:

   http://www.networkupstools.org/docs/man/ups.conf.html
> I also can?t collect any data by upsrw (returns blank) or upscmd (no
commands available) - though these functions might not be implemented in the
OpenUPS - does anyone know?
Technically, 'upsrw' could have been called 'upsw' since it does
not actually read the variables: it just lists the writable ones, and allows one
to set them. But the OpenUPS driver does not list any HID usage items as
read/write, or as commands, so that is to be expected:

   https://github.com/networkupstools/nut/blob/master/drivers/openups-hid.c#L297

NUT takes a somewhat conservative approach to the USB HID drivers: we only query
for variables and commands that are known to work with that vendor's UPS.
There are some debug modes available in usbhid-ups that would list all of the
potential variables that the firmware supports, but you may not want to run
those on a production system. Let us know (this list or nut-upsdev) if you would
like more details on that.

-- 
Charles Lepple
clepple at gmail

> 
> The documentation isn't explicit about this, but 'upsdrvctl
shutdown' is
> meant to be run after all of the other processes on the system have been
> killed, real filesystems have been unmounted, and the kernel shutdown
> syscall is about to be called. Usually the init scripts will take care of
this,
> although I don't know how CentOS handles that specifically.
> 
> If you want to test the low-battery shutdown procedure (where upsmon
> tells the rest of the system to shut down, then tells the UPS to power
off),
> you can run 'upsmon -c fsd' (Forced ShutDown). The init scripts
should call
> 'upsdrvctl shutdown' implicitly when everything else has stopped.
I wish it were explicit.  :)

You say to use FSD for testing the system...what do I use for real?   I thought
I was supposed to call upsdrvctl shutdown with some delay, and THEN begin
shutting down my PC, in the hopes I finish before the delay expires and the UPS
shuts off of the power supply.

When you say "the init scripts will take care of this", do you mean
that if I execute a system shutdown, it will automatically send the
"upsdrvctl shutdown" command at the end?

[please keep the list CC'd. thanks!]

On Mar 13, 2015, at 10:53 AM, Philip Taylor <philip at kelsotowers.co.uk>
wrote:
> I?ve set up UPSMON to simply execute ?shutdown -h now? and my system shuts
down when I type ?upsmon -c fsd?. The problem is that the OpenUPS doesn?t shut
down as a result; and therefore when the power comes back on, unless the battery
has totally run out, the system stays dead. Once the battery dies completely,
the UPS will reboot itself and turn the server on - but this may never happen.
> 
> Do I have to modify the Centos ?shutdown? script to add to it ?upsdrvctl
shutdown? at it?s end point? Or should the fact that upsd is run as a service
(nut-server.service on Centos 7) do this without my intervention?
Again, I don't know what CentOS does with its shutdown scripts. Other
distributions have some sort of hook that calls 'upsdrvctl shutdown'
near the end of the shutdown process.
> I?ve looked at ?ignorelb?. As far as I can tell the OpenUPS never sends LB;
which may be a calibration issue; but there is no documentation to tell you how
this should work. Their documentation talks about ?coulomb counters? and ?fuel
gauges? but says nothing about how it?s implemented! And I?m waiting for a
response from their support desk.
> 
> You say 'NUT takes a conservative approach to USB HID drivers?. I get a
few errors and I don?t know if they matter. Like :
What I meant is that usbhid-ups doesn't try to interpret all of the HID
items, just the ones that are known to contain good values (for some version of
the UPS firmware).
> when I plug in the OpenUPS I see this : 
> 
> [   49.049586] usb 4-5: new full-speed USB device number 3 using ohci-pci
> [   49.215825] usb 4-5: New USB device found, idVendor=04d8, idProduct=d004
> [   49.222717] usb 4-5: New USB device strings: Mfr=1, Product=2,
SerialNumber=4
> [   49.229879] usb 4-5: Product: OPEN-UPS
> [   49.233658] usb 4-5: Manufacturer: Mini-Box.Com
> [   49.238218] usb 4-5: SerialNumber: PBSO4-LiFePO
> [   49.259143] hid-generic 0003:04D8:D004.0002: invalid report_size 248
> [   49.265603] hid-generic 0003:04D8:D004.0002: item 0 1 1 7 parsing failed
> [   49.272485] hid-generic: probe of 0003:04D8:D004.0002 failed with error
-22
You can ignore the hid-generic errors; NUT detaches that kernel driver and
bypasses it with libusb.

That said, it means the HID descriptor has some syntax issues.
> If I manually run 'upsdrvctl start? I get this :
> 
> USB communication driver 0.32
> Using subdriver: openUPS HID 0.4
> libusb_get_string: Invalid argument
> libusb_get_string: Invalid argument
The driver should only call libusb_get_string() for informational purposes, so
it should only affect ups.mfr and ups.model in upsc.
> 
> And if I run upsd with high level of debug, after working OK for a while, I
see these ?broken pipe? messages :
> 
>    0.419974	Entering libusb_get_report
>    0.421967	Report[get]: (4 bytes) => 60 c4 ff 3b
>    0.422056	PhyMax = 0, PhyMin = 0, LogMax = 16777215, LogMin = 0
>    0.422069	Unit = 00001001, UnitExp = 0
>    0.422080	Exponent = 0
>    0.422093	hid_lookup_path: 00840004 -> UPS
>    0.422107	hid_lookup_path: 00840024 -> PowerSummary
>    0.422121	hid_lookup_path: 00850068 -> RunTimeToEmpty
>    0.422146	Path: UPS.PowerSummary.RunTimeToEmpty, Type: Feature, ReportID:
> 0x60, Offset: 0, Size: 24, Value: 3.9321e+06
That looks like a calibration problem: 3.9 million seconds of runtime is a
while.
>    0.422163	Report[buf]: (4 bytes) => 60 c4 ff 3b
>    0.422177	PhyMax = 0, PhyMin = 0, LogMax = 16777215, LogMin = 0
>    0.422188	Unit = 00001001, UnitExp = 0
>    0.422198	Exponent = 0
>    0.422209	hid_lookup_path: 00840004 -> UPS
>    0.422221	hid_lookup_path: 00840024 -> PowerSummary
>    0.422234	hid_lookup_path: 00850068 -> RunTimeToEmpty
>    0.422253	Path: UPS.PowerSummary.RunTimeToEmpty, Type: Input, ReportID:
0x
> 60, Offset: 0, Size: 24, Value: 3.9321e+06
>    0.422264	Entering libusb_get_report
>    0.423983	Can't retrieve Report b1: Broken pipe
>    0.424034	hid_lookup_path: ff000001 -> not found in lookup table
>    0.424060	hid_lookup_path: ff000001 -> not found in lookup table
>    0.424076	Path: ff000001.ff000001, Type: Output, ReportID: 0xb1, Offset:
0
> , Size: 248
>    0.424089	Entering libusb_get_report
>    0.425933	Can't retrieve Report b2: Broken pipe
>    0.425953	hid_lookup_path: ff000001 -> not found in lookup table
>    0.425966	hid_lookup_path: ff000001 -> not found in lookup table
>    0.425980	Path: ff000001.ff000001, Type: Input, ReportID: 0xb2, Offset:
0,
>  Size: 248
>    0.425992	Entering libusb_get_report
>    0.427956	Can't retrieve Report 81: Broken pipe
>    0.428006	hid_lookup_path: ff000001 -> not found in lookup table
>    0.428021	hid_lookup_path: ff000001 -> not found in lookup table
>    0.428036	Path: ff000001.ff000001, Type: Output, ReportID: 0x81, Offset:
0
> , Size: 248
>    0.428048	Entering libusb_get_report
>    0.429891	Can't retrieve Report 82: Broken pipe
>    0.429911	hid_lookup_path: ff000001 -> not found in lookup table
>    0.429925	hid_lookup_path: ff000001 -> not found in lookup table
>    0.429939	Path: ff000001.ff000001, Type: Input, ReportID: 0x82, Offset:
0,
>  Size: 248
>    0.429950	Entering libusb_get_report
Can you send a copy of the debug output (-DDD) from starting the driver for ~30
seconds, gzip'd and attached?

-- 
Charles Lepple
clepple at gmail



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150313/445397b0/attachment-0001.html>