Re: Erratically losing connection on usb port from UPS unit

2019-08-23 Thread Walter Alejandro Iglesias
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

2019-08-23 Thread Walter Alejandro Iglesias
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

2019-08-23 Thread Boudewijn Dijkstra
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

2019-08-21 Thread Walter Alejandro Iglesias
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