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

Fri Mar 13 22:58:37 UTC 2015

[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>