Re: Erratically losing connection on usb port from UPS unit
Hi Boudewijn, In article Boudewijn Dijkstra wrote: > Op Wed, 21 Aug 2019 15:06:17 +0200 schreef Walter Alejandro Iglesias > : > > [...] > > > > It has been working for days (with and without NUT) apparently without > > problems except for three times in which the usb signal from the ups got > > cut, apparently for no reason. I get this message in console: > > > > upd0 detached > > uhidev0 detached > > I have a similar recurring message, also very erratically, mean period is > about a month: > > ugen0 detached > ugen0 at uhub1 port 2 "American Power Conversion Smart-UPS 1000 FW:UPS > 09.2 / ID=18" rev 2.00/1.06 addr 2 > > > While using NUT I got "stale" messages from upsmon when that happened. > > I'm using apcupsd, I also get messages for these occurrences. > > I don't know if also in your case but in mine, once that happens, the connection doesn't get back, what means, from then on, the ups stays unmonitored. Another problem I bumped into (this is my first experience with a UPS unit) is before purchasing this device I'd assumed that to wake up the machine once the AC was back would suffice activating the "auto power on when AC is plugged" BIOS option. Wrong. :-) Then I tried a router with dd-wrt software that comes with a wol daemon, it didn't work either. Routing a wol packet from the internet (adding static arp entries in the router as they teach in some forums) wasn't either possible. What makes me conclude: if you can't rely on the machine will be shut down properly and it's so difficult (automatically or remotely), to get the machine powered back, what in the Hell a UPS is useful for?
Re: Erratically losing connection on usb port from UPS unit
On Wed, Aug 21, 2019 at 03:06:17PM +0200, Walter Alejandro Iglesias wrote: > On the Internet some NUT users mention issues with libusb. There is an > old tutorial about using NUT in OpenBSD that advices to install > libusb-compat but, given the current nut package doesn't install it as a > dependency I assumed it's not longer necessary. Here I said something wrong, nut *does* install libusb-compat as a dependency.
Re: Erratically losing connection on usb port from UPS unit
Op Wed, 21 Aug 2019 15:06:17 +0200 schreef Walter Alejandro Iglesias : [...] It has been working for days (with and without NUT) apparently without problems except for three times in which the usb signal from the ups got cut, apparently for no reason. I get this message in console: upd0 detached uhidev0 detached I have a similar recurring message, also very erratically, mean period is about a month: ugen0 detached ugen0 at uhub1 port 2 "American Power Conversion Smart-UPS 1000 FW:UPS 09.2 / ID=18" rev 2.00/1.06 addr 2 While using NUT I got "stale" messages from upsmon when that happened. I'm using apcupsd, I also get messages for these occurrences. -- Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
Erratically losing connection on usb port from UPS unit
Hello everyone, Weeks ago I purchased a UPS unit for my home server. It's attached to the machine via a usb port: uhidev0 at uhub3 port 2 configuration 1 interface 0 "EATON Eaton 3S" rev 2.00/1.00 addr 2 uhidev0: iclass 3/0, 32 report ids upd0 at uhidev0 At first I used NUT from packages but once I became aware of upd(4) already gives me the needed info: hw.sensors.upd0.indicator4=On (ACPresent), OK hw.sensors.upd0.percent0=100.00% (RemainingCapacity), OK ... I simply run a shell script from cron to halt the machine when the battery is low. It has been working for days (with and without NUT) apparently without problems except for three times in which the usb signal from the ups got cut, apparently for no reason. I get this message in console: upd0 detached uhidev0 detached While using NUT I got "stale" messages from upsmon when that happened. What I Investigated So Far -- NUT usbhid-ups driver man page mentions some workaround: https://networkupstools.org/docs/man/usbhid-ups.html pollfreq=num Set polling frequency, in seconds, to reduce the USB data flow. Between two polling requests, the driver will wait for interrupts (aka UPS notifications), which are data changes returned by the UPS by itself. This mechanism allow to avoid or reduce staleness message, due to the UPS being temporarily overloaded with too much polling requests. The default value is 30 (in seconds). But, since the issue happens erratically, so far I couldn't realize if that solves the problem (if it does, it would be possible to teach upd(4) to do something alike?) On the Internet some NUT users mention issues with libusb. There is an old tutorial about using NUT in OpenBSD that advices to install libusb-compat but, given the current nut package doesn't install it as a dependency I assumed it's not longer necessary. There is an item in libusb-compat package info that explains: $ pkg_info libusb-compat [...] 4. Some libusb-0.1 users may have implemented I/O cancellation by running transfers in their own threads and simply killing the thread when they don't want to do the transfer any more. This is bad programming practice for obvious reasons, and this lack of functionality was one of the primary drivers for libusb-1.0 development. With libusb-1.0 or libusb-compat-0.1 backed by libusb-1.0, forcefully killing threads in this way is likely to cause all libusb I/O to halt. Instead, port your application to use libusb-1.0's asynchronous transfer API, which supports transfer cancellation. Is this related? If someone knows where the problem is I'd appreciate any advice. Walter
