[Nut-upsuser] NUT Configuration Question

Manuel Wolfshant wolfy at nobugconsulting.ro
Fri Nov 12 01:34:07 GMT 2021

On 11/12/21 01:49, Jeff Rickman wrote:
> 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.
A configuration  which specifies the vendorid or the busid in the config 
file i.e. similar to the one from the man page ( included below for 
reference )  is definitely supported

                    driver = usbhid-ups
                    port = auto
                    vendorid = 0463
                    driver = usbhid-ups
                    port = auto
                    vendorid = 09ae

> 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.

More information about the Nut-upsuser mailing list