[Nut-upsuser] Eaton 1500 USB constant disconnections

Spike spike at drba.org
Wed Mar 29 03:38:42 UTC 2017


Arno, thanks for taking the time to write back and no worries about lag,
we're all busy and I'm grateful there is a community to interact with to
begin with.

You're right - the problem went away once I actually configured nut. I
guess I was too "cautious" and when I saw the errors I thought something
was wrong with the usb connection and didn't try to get nut going assuming
it'd failed. Eventually debugging through systemd/udev I realized it was
indeed the device initiating a connection and found out about the pong from
the UPS.

thanks again and maybe worthwhile to have this documented somewhere,  not
sure, maybe the ML archive will work for that.

best,

Spike

On Tue, Mar 28, 2017 at 2:46 AM Arnaud Quette <arnaud.quette at gmail.com>
wrote:

>
> 2017-03-11 4:55 GMT+01:00 Spike <spike at drba.org>:
>
> Hi,
>
>
> Hi Spike,
>
> sorry for the lag in answering, I was collecting the needed information.
>
> I have a eaton 1500 that connects to an Ubuntu Xenial box via USB. The UPS
> works, however exactly *ever 5 minutes* it disconnects and reconnects and I
> see this in syslog:
>
> Mar 10 19:50:32 spike kernel: usb 4-5: USB disconnect, device number 103
> Mar 10 19:50:33 spike kernel: usb 4-5: new low-speed USB device number 104
> using ohci-pci
> Mar 10 19:50:34 spike kernel: usb 4-5: New USB device found,
> idVendor=0463, idProduct=ffff
> Mar 10 19:50:34 spike kernel: usb 4-5: New USB device strings: Mfr=1,
> Product=2, SerialNumber=4
> Mar 10 19:50:34 spike kernel: usb 4-5: Product: Ellipse PRO
> Mar 10 19:50:34 spike kernel: usb 4-5: Manufacturer: EATON
> Mar 10 19:50:34 spike kernel: usb 4-5: SerialNumber: P344G46HW9
> Mar 10 19:50:38 spike kernel: hid-generic 0003:0463:FFFF.1221:
> hiddev0,hidraw2: USB HID v1.10 Device [EATON Ellipse PRO] on
> usb-0000:00:12.0-5/input0
>
> does anybody have any clue why that's happening? besides spamming the logs
> I'm afraid that it may not reconnect at some point and/or fail when it's
> actually needed.
>
>
> this is a workaround implemented to avoid, under some specific conditions,
> a freeze of the USB communication.
> As far as I've been told, when there is an actual SW communication (such
> as with NUT) with requests and replies in the 5mn timeframe, this should
> not occur.
>
> Could you please:
> - confirm back that there is indeed a SW communication setup (NUT or
> UPower for example),
> - send me back the upsc output for this unit, including the serial number
> and firmware revision
>
> thanks and regards,
> Arno
> --
> Eaton Data Center Automation Solutions - Opensource Leader -
> http://42ity.org
> 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...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170329/21ce7558/attachment.html>


More information about the Nut-upsuser mailing list