[Nut-upsuser] NUT Configuration Question

Thu Nov 11 23:49:55 GMT 2021

In regards to the "auto" setting for "port" in "ups.conf", after a few 
hours of online reading a number of days ago, I eventually found a post 
to the effect that the "usbhid-ups" driver works in a way that "auto" is 
the appropriate setting. The programmers can explain better than I as to 
why that is.

I have experimented with separating these USB-attached devices, and they 
are the only _external_ USB devices, to different "bus" values per 
'lsusb' and that does not seem to make any difference.

In my case, 1 USB bus has 1 UPS connected and another USB bus has the 
other UPS connected. No other USB devices are on those USB buses per 
'lsusb'.

If USB power saving is a potential issue, then I am interested in what 
Linux commands (this is a Debian Linux box) might be used to check for 
that. Nothing in a 'lsusb -v' output suggesys anything.

As noted in my original post, these 2 UPS have different 'vendorid' and 
I have tried calling the drivers with that value attached in the format 
of "-x vendorid=XXXX", but that does not make any difference. Perhaps 
the driver simply ignores that specific variable? I have not tried other 
unique variables.

My own thinking on this matter is leaning in the direction of some sort 
of software collision or competition since I can 'power cycle by power 
switch', 'hard reset by reset switch', or 'shutdown -r 0' via CLI the 
Linux box and that reboot clears the problem for a random amount of time.

Yes, the occurence of this issue is random, but it appears guaranteed to 
happen within 60 minutes or so of starting up NUT after a power-up or 
reboot.

For the record, I have a monitoring PC that watches 2 different UPS 
devices that use 2 different drivers in NUT. That PC does not encounter 
the issue that I am reporting here.

On 11/11/2021 5:26 PM, Jim Klimov wrote:
> Hello,
> 
>    I can at least address part of your question -- NUT per se is not 
> limited to monitoring one device per system. Each driver runs as a 
> separate process, using a separate device node to talk to USB hardware.
> 
>    Can't vouch however for other variables in the equation, such as 
> system drivers, libusb (0.1 as supported in NUT releases so far), or 
> behavior of the USB hub in the chipset (can it be just overloaded by two 
> devices - electrically or logically? or entering some power-saving mode 
> and resetting all ports instead of one? are there other devices 
> connected to it?)
> 
>    I wonder now, if using "auto" port instead of particular path like 
> /dev/ttyUSB<N> can cause re-discoveries of the device over time, and if 
> the two drivers collide then or steal devices from each other.
> 
>    I believe that with at least master-branch codebase of NUT, it should 
> be possible and valid to specify device details like vendor and product 
> IDs, to auto-match a specific device per driver config instance.
> 
> Jim
> 
> 
> On Wed, Nov 10, 2021, 07:44 Jeff Rickman <jrickman at myamigos.us 
> <mailto:jrickman at myamigos.us>> wrote:
> 
>     ** The actual problem is listed at the very bottom of this email **
>     ** All of the lead-in data is requested per the NUT webpages **
> 
>     OS:
>     4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 GNU/Linux
> 
>     NUT version info:
>     nut-client  2.7.4-8  amd64  network UPS tools - clients
>     nut-server  2.7.4-8  amd64  network UPS tools - core system
> 
>     All aspects of NUT on this Debian system were installed from
>     Debian-provided packages using their "apt" package tool. Even the Linux
>     kernel on this system is from a Debian-provided package.
> 
>     2 UPS devices are in question here, but from different manufacturers
> 
>     UPS Model: Cyberpower CPS CP 1500C
>     - CPS CP 1500C per 'upsc'
>     - has the LCD display and NO front panel USB-A ports
>     - older unit, perhaps 5 years old, batteries have been replaced once
>     - more data requires UP de-installation
>     - NUT "vendorid" of 0764
>     - uses the NUT "usbhid-ups" driver as show here:
> 
>     Network UPS Tools - Generic HID driver 0.41 (2.7.4)
>     USB communication driver 0.33
>     Using subdriver: CyberPower HID 0.4
>     cps_adjust_battery_scale: battery readings will be scaled by 2/3
> 
> 
>     UPS Model: Eaton 5S 1500 LCD (from vendor's tag)
>     - brand new unit
>     - Batteries were manufactuered in April 2021 per shipping box
>     - NUT "vendorid" of 0463
>     - uses the NUT "usbhid-ups" driver as shown here:
> 
>     Network UPS Tools - Generic HID driver 0.41 (2.7.4)
>     USB communication driver 0.33
>     Using subdriver: MGE HID 1.39
> 
> 
>     ** THE PROBLEM **
> 
>     Either UPS connected to any USB2 port on this PC will work fine without
>     any troule what-so-ever.
> 
>     When BOTH UPS are connected to discrete USB2 ports on this PC, or any
>     other Linux PC where I run NUT, _EITHER_UPS_ will eventually drop out
>     with a "Communication Lost" message. There are no mysterious external
>     factors taking place like AC power outages, AC power spikes, or heavy
>     loads on the UPS. A 'upsc' printout of "ups.load" reads 10 or less at
>     all times on the Cyberpower unit; the Eaton unit has nothing plugged
>     into it.
> 
>     A query of the "missing" UPS using "upsc" might show something like
>     this:
> 
>     nano1 ~ # upsc es1500
>     Init SSL without certificate database
>     Error: Unknown UPS
> 
>     Yes, both UPS devices have been entered into "ups.conf" as follows:
>     [cpups]
>     # ups.vendorid: 0764
>         driver = usbhid-ups
>         port = auto
>         desc = "CP UPS on NANO1"
> 
>     [es1500]
>     # ups.vendorid: 0463
>         driver = usbhid-ups
>         port = auto
>         desc = "Eaton Ellipse Pro 1500 on NANO-1"
> 
>     I have experimented with "direct calling" the "usbhid-ups" driver with
>     the "-x vendorid=" parameter... even though the manpages suggest not
>     doing that; they suggest we use "upsdrvctl" instead, but that can't
>     seen
>     to handle 2 different vendor's UPS devices with different vendorid
>     values both using the same driver. Even that direct calling approach
>     does not help as either UPS will eventually disappear with a
>     "Communication Lost" message on the console.
> 
>     Some might be tempted to say, "Oh that UPS must be going bad." or "That
>     USB cable or port must be going bad.". I thought that a few YEARS AGO
>     when I first saw this problem occur. I can easily swap around USB2
>     ports, USB cables (I have a few spares), and monitoring PCs - none of
>     that makes any difference at all.
> 
>     My only workaround hads been to separate the 2 UPS devices that both
>     used the NUT "usbhid-ups" driver to separate monitoring devices (low
>     power Atom PCs or Raspberry Pi boxes). That workaround is getting old
>     and I am hoping for a better solution.
> 
>     I prefer to monitor my UPS devices even when the devices they protect
>     are powered down. In that manner I have caught signs of UPS needing
>     batteries replaced and odd AC power problems.
> 
> 
>     Does the NetworkUPSTools project officially support 2 physically
>     different UPS from 2 completely different vendors (based on NUT
>     reported
>     "vendorid") both accessing the same NUT driver on the same monitoring
>     device? The manpage for the "usbhid-ups" driver does not say if it does
>     or does not support multiple UPS devices requiring it.
> 
> 
>     -- 
>     "No one gets sick on Wednesdays." (unknown)
> 
>     _______________________________________________
>     Nut-upsuser mailing list
>     Nut-upsuser at alioth-lists.debian.net
>     <mailto:Nut-upsuser at alioth-lists.debian.net>
>     https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
> 