[Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB
arnaud.quette at gmail.com
Wed Jun 14 12:32:41 UTC 2017
2017-06-13 17:49 GMT+02:00 Manuel Wolfshant <wolfy at nobugconsulting.ro>:
> On 06/13/2017 05:48 PM, Arnaud Quette wrote:
> Hi Manuel
> Hi Arno
> 2017-06-07 14:40 GMT+02:00 Charles Lepple <clepple at gmail.com>:
>> On Jun 7, 2017, at 5:47 AM, Manuel Wolfshant <wolfy at nobugconsulting.ro>
>> > If that matters, the OS is a fully updated CentOS 6.9 and this
>> (latest stable ) version of nut was packaged by me. The problem appears on
>> any of the USB ports ( well, I tried the 2 in front and one in the back of
>> the server ).
>> > lsusb -v reports:
>> > wDescriptorLength 549
>> > Warning: incomplete report descriptor
>> > Report Descriptor: (length is 9)
>> > Item(Main ): (null), data=none
>> Because both NUT and lsusb are having trouble retrieving the HID Report
>> Descriptor, I think the problem is at a lower level: probably between the
>> UPS, the kernel, and the USB HCI. The archives have a number of unresolved
>> emails about the 5E and "broken pipe" errors.
>> Probably worth checking with Eaton, too.
> Charles is right in both the fact that the issue is (or at least seems to
> be) upstream to NUT, and also that it's worth checking with "Eaton"
> I've approached "them" ( apparently my request for supported landed at
> after-sales support/Romania ) as soon as Charles replied. Unfortunately the
> "dialogue" rather stalls, they seem to have a policy to not send more than
> one email every 3 days. Leaving aside that after telling them that I am
> using an *USB *unit (and providing USB-related logs ) they wanted to know
> if I was using *SNMP*.
no comments ;)
> Could you please tell me your kernel
> [root at belgrade ~]# uname -r
that may be part of the issue... long time I've not tried the 2.x series,
not sure how it goes nowadays.
btw, any interesting "usb" messages from your syslog?
also, would you be able to test with a 3.x or 4.x, at least to see if that
improves / solves the issue?
> and libusb (0.1) version?
> [root at belgrade ~]# rpm -qa libusb
> Would you also be able to test some github code?
> We have the libusb-1.0 branch that provides both libusb 1.0 support
> (interesting to test to see if the problem still happens) along with few
> other improvements (though these should not help for your issue):
> I can and I will test ( tomorrow, probably ).
> Don't hesitate if you need more guidance for trying this branch.
> Do you happen to know how can I find the version of firmware run by the
> UPS, in _my_ conditions ( remote + the previously mentioned errors) ?
don't bother too much, in the end, such request only get an answer once it
has reached me ;)
> The guys who contacted me from Eaton did not reply yet to my email sent
that requires the driver to be running, then it's published as ups.firmware.
as per my upsc output above (in my case): ups.firmware: 02.06.0019
> FYI, I've just made a test with the same unit, on a Debian jessie (kernel
> 3.16.43-2, libusb 0.1.12-25) both with 2.7.4 and the latest git master, and
> it works fine:
> battery.charge: 62
> battery.runtime: 2725
> battery.type: PbAc
> device.mfr: EATON
> device.model: 5E 1500i
> device.type: ups
> driver.name: usbhid-ups
> I was expecting it to work fine, given https://risc-a-day.blogspot.
> ro/2014/09/getting-my-ups-to-work-with-linux.html ( before the purchase I
> assumed the units to be similar, modulo the maximum power )
you shouldn't be that far...
> thanks a lot. I will come back with more data once I test the github code
> ( yes, I know, everybody hates this kind of threats :) )
looking forward to get news so ;)
Eaton Data Center Automation Solutions - Opensource Leader -
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nut-upsuser